Skip Menu |

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the Spreadsheet-ParseExcel CPAN distribution.

Maintainer(s)' notes

If you are reporting a bug in Spreadsheet::ParseExcel here are some pointers

1) State the issues as clearly and as concisely as possible. A simple program or Excel test file (see below) will often explain the issue better than a lot of text.

2) Provide information on your system, version of perl and module versions. The following program will generate everything that is required. Put this information in your bug report.

    #!/usr/bin/perl -w

    print "\n    Perl version   : $]";
    print "\n    OS name        : $^O";
    print "\n    Module versions: (not all are required)\n";

    my @modules = qw(
                      Spreadsheet::ParseExcel
                      Scalar::Util
                      Unicode::Map
                      Spreadsheet::WriteExcel
                      Parse::RecDescent
                      File::Temp
                      OLE::Storage_Lite
                      IO::Stringy
                    );

    for my $module (@modules) {
        my $version;
        eval "require $module";

        if (not $@) {
            $version = $module->VERSION;
            $version = '(unknown)' if not defined $version;
        }
        else {
            $version = '(not installed)';
        }

        printf "%21s%-24s\t%s\n", "", $module, $version;
    }

    __END__

3) Upgrade to the latest version of Spreadsheet::ParseExcel (or at least test on a system with an upgraded version). The issue you are reporting may already have been fixed.

4) Create a small example program that demonstrates your problem. The program should be as small as possible. A few lines of codes are worth tens of lines of text when trying to describe a bug.

5) Supply an Excel file that demonstrates the problem. This is very important. If the file is big, or contains confidential information, try to reduce it down to the smallest Excel file that represents the issue. If you don't wish to post a file here then send it to me directly: jmcnamara@cpan.org

6) Say if the test file was created by Excel, OpenOffice, Gnumeric or something else. Say which version of that application you used.

7) If you are submitting a patch you should check with the maintainer whether the issue has already been patched or if a fix is in the works. Patches should be accompanied by test cases.

Asking a question

If you would like to ask a more general question there is the Spreadsheet::ParseExcel Google Group.

Report information
The Basics
Id: 16786
Status: open
Priority: 0/
Queue: Spreadsheet-ParseExcel

People
Owner: Nobody in particular
Requestors: ntyni [...] iki.fi
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in: 0.2603
Fixed in: (no value)



Subject: RSTRING doesn't know about BIFF8 (unicode) strings
Hi, this bug was originally reported as Debian bug #299870, http://bugs.debian.org/299870 . The problem is that text in the reporter's spreadsheet comes out containing zero bytes. I have verified this on Perl 5.8.7 on Debian GNU/Linux. I looked into this, and the bug is in SpreadSheet::ParseExcel::_subRString(), which doesn't accept BIFF8 type unicode strings. The attached patch fixes the problem. Cheers, -- Niko Tyni (on behalf of the Debian Perl Group) ntyni@iki.fi
--- libspreadsheet-parseexcel-perl-0.2603.orig/ParseExcel.pm +++ libspreadsheet-parseexcel-perl-0.2603/ParseExcel.pm @@ -620,10 +620,21 @@ my($oBook, $bOp, $bLen, $sWk) = @_; my($iR, $iC, $iF, $iL, $sTxt); ($iR, $iC, $iF, $iL) = unpack("v4", $sWk); - $sTxt = substr($sWk, 8, $iL); + my $bver = $oBook->{BIFFVersion}; + my ($rich, $sCode); + if($bver == verBIFF8) { + my( $raBuff, @rest) = _convBIFF8String($oBook, substr($sWk, 6), 1); + $sTxt = $raBuff->[0]; + $sCode = ($raBuff->[1])? 'ucs2': undef; + $rich = $raBuff->[2]; + } else { + $sTxt = substr($sWk, 8, $iL); + $sCode = '_native_'; + $rich = substr($sWk, (8+$iL)+1) + if (length($sWk) > (8+$iL)); + } - #Has STRUN - if(length($sWk) > (8+$iL)) { + if($rich) { _NewCell ( $oBook, $iR, $iC, Kind => 'RString', @@ -631,9 +642,9 @@ FormatNo=> $iF, Format => $oBook->{Format}[$iF], Numeric => 0, - Code => '_native_', #undef, + Code => $sCode, Book => $oBook, - Rich => substr($sWk, (8+$iL)+1), + Rich => $rich, ); } else { @@ -644,7 +657,7 @@ FormatNo=> $iF, Format => $oBook->{Format}[$iF], Numeric => 0, - Code => '_native_', + Code => $sCode, Book => $oBook, ); }
On Thu Dec 29 08:45:17 2005, guest wrote: Show quoted text
> > this bug was originally reported as Debian bug #299870, > http://bugs.debian.org/299870 .
That debian bug indicates that the issue has been fixed, and I see BIFF8 test files in the test suite, so I'm closing this issue. The test file referenced in the debian ticket is no longer accessible, so I cannot test it specifically.
From: fschlich [...] zedat.fu-berlin.de
Hi Dough, On Wed Mar 05 16:36:51 2014, DOUGW wrote: Show quoted text
> On Thu Dec 29 08:45:17 2005, guest wrote:
> > > > this bug was originally reported as Debian bug #299870, > > http://bugs.debian.org/299870 .
> > That debian bug indicates that the issue has been fixed, and I see > BIFF8 test files in the test suite, so I'm closing this issue. The > test file referenced in the debian ticket is no longer accessible, so > I cannot test it specifically.
I believe this is incorrect. The Debian bug is marked fixed because of the patch that was forwarded in this bug report, and that patch still applies (with offset, but no fuzz) on version 0.65. Having said that, I don't have any way to test the issue either, but Debian still applies this patch.