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: 60092
Status: open
Priority: 0/
Queue: Spreadsheet-ParseExcel

People
Owner: jmcnamara [...] cpan.org
Requestors: ch [...] pkts.ca
Cc:
AdminCc:

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



Subject: Partially able to parse file from scientific plate reader
Date: Wed, 04 Aug 2010 15:22:08 -0700
To: bug-Spreadsheet-ParseExcel [...] rt.cpan.org
From: Charles Howes <ch [...] pkts.ca>
This Excel file was generated by SkanIt, version 2.4.3 RE for Varioskan Flash. (http://www.thermoscientific.com/skanit) The attached excel file can't be parsed fully by Spreadsheet::ParseExcel. The cells are in the right place, but they have some kind of garbage in them. Only the third sheet has readable data. Oddly enough, the file can be read fine by Openoffice and Gnumeric, and probably Excel (not tested by me, but I support this lab). The 'file' command reports: Tn5_OD400_1.xls: CDF V2 Document, corrupt: Cannot read summary info Here is the output of your diagnostic program: Perl version : 5.010000 OS name : linux Module versions: (not all are required) Spreadsheet::ParseExcel 0.57 Scalar::Util 1.21 Unicode::Map 0.112 Spreadsheet::WriteExcel 2.25 Parse::RecDescent 1.962.2 File::Temp 0.21 OLE::Storage_Lite 0.19 IO::Stringy 2.110 I use Fedora 12, and upgraded to the latest Spreadsheet::ParseExcel using CPAN, as the rpm repositories don't have 0.57 yet. My included test program just reads and writes the (corrupted) spreadsheet to a new file. The problem isn't in the writing; Data::Dumper shows corrupted data in the storage array before it gets to the writing section. Thanks for a great program! -- Charles Howes <ch@pkts.ca>

Message body is not shown because sender requested not to inline it.

Download Tn5_OD400_1.xls
application/vnd.ms-excel 89k

Message body not shown because it is not plain text.

On Wed Aug 04 18:22:32 2010, ch@pkts.ca wrote: Show quoted text
> This Excel file was generated by SkanIt, version 2.4.3 RE for Varioskan > Flash. (http://www.thermoscientific.com/skanit) > > The attached excel file can't be parsed fully by > Spreadsheet::ParseExcel. The cells are in the right place, but they > have some kind of garbage in them. Only the third sheet has readable > data.
Hi, The application that created the Excel file is storing the strings in an unorthodox way. Nevertheless Spreadsheet::ParseExcel doesn't handle it correctly and it should. I'll have a look at fixing it. Thanks, John. --
I'm not at all sure what to do here, but some things I've noticed: When parsing your example, in order to not get truncated data I changed: ( $iR, $iC, $iF, $iL ) = unpack( "v3V", $sWk ); #( $iR, $iC, $iF, $iL ) = unpack( "v4", $sWk ); in ParseExcel::_subRString. I'm not real sure exactly what that function is for...it is not currently called in any of the tests. I threw a 'die' into it and all tests still passed. So I'm not at all sure if that's the right fix or if will break things for everyone else. For every cell in the row, I did: for (@$row) { s/^\x01// or next; s/\x00$//; $_ = Encode::decode('UTF-16BE', $_); } Then at least I got the properly(?) decoded value. Maybe someone else can make sense of this and make suggestions...