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.
Owner: |
jmcnamara [...] cpan.org
|
Requestors: |
ch [...] pkts.ca
|
Cc: |
|
AdminCc: |
|
|
Severity: |
(no value)
|
Broken in: |
(no value)
|
Fixed in: |
(no value)
|
averagecolor.pl
Tn5_OD400_1.xls
|
Wed Aug 04 18:22:32 2010
ch [...] pkts.ca - Ticket created
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.
Message body not shown because it is not plain text.
Fri Aug 06 06:36:57 2010
jmcnamara [...] cpan.org - Taken
Fri Aug 06 09:32:02 2010
jmcnamara [...] cpan.org - Correspondence added
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.
--
Fri Aug 06 09:32:03 2010
The RT System itself - Status changed from 'new' to 'open'
Tue Mar 11 19:57:47 2014
DOUGW [...] cpan.org - Correspondence added
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...