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

People
Owner: Nobody in particular
Requestors: tlhackque [...] yahoo.com
Cc:
AdminCc:

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



Subject: Color index leaks from one workbook to another.
Color index leaks from one workbook to another. If you open a workbook & parse it, the global palette (@aColor) is updated. Parse another, and it uses the updated global. This can get the colors wrong in the second workbook. Correct behavior is for each workbook to start from the initial palette and maintain it from there. Fix is in https://github.com/tlhackque/spreadsheet-parseexcel Deprecates S:P:E:ColorIdxToRGB - this now applies to the last parsed workbook, which is compatible with existing code. (It does produce the right answer most of the time, but different wrong answers when it's wrong). Replacement is $workbook->ColorIdxToRGB. diff --git a/lib/Spreadsheet/ParseExcel.pm b/lib/Spreadsheet/ParseExcel.pm index a96af12..e65fa88 100644 --- a/lib/Spreadsheet/ParseExcel.pm +++ b/lib/Spreadsheet/ParseExcel.pm @@ -22,7 +22,7 @@ use Config; use Crypt::RC4; use Digest::Perl::MD5; -our $VERSION = '0.59'; +our $VERSION = '0.60'; use Spreadsheet::ParseExcel::Workbook; use Spreadsheet::ParseExcel::Worksheet; @@ -31,6 +31,7 @@ use Spreadsheet::ParseExcel::Format; use Spreadsheet::ParseExcel::Cell; use Spreadsheet::ParseExcel::FmtDefault; +my $oCurrentBook; my @aColor = ( '000000', # 0x00 'FFFFFF', 'FFFFFF', 'FFFFFF', 'FFFFFF', @@ -514,10 +515,12 @@ sub parse { my ( $self, $source, $formatter ) = @_; my $workbook = Spreadsheet::ParseExcel::Workbook->new(); + $oCurrentBook = $workbook; $workbook->{SheetCount} = 0; $workbook->{CellHandler} = $self->{CellHandler}; $workbook->{NotSetCell} = $self->{NotSetCell}; $workbook->{Object} = $self->{Object}; + $workbook->{aColor} = [ @aColor ]; my ( $biff_data, $data_length ) = $self->_get_content( $source, $workbook ); return undef if not $biff_data; @@ -1634,7 +1637,7 @@ sub _subPalette { for ( my $i = 0 ; $i < unpack( 'v', $sWk ) ; $i++ ) { # push @aColor, unpack('H6', substr($sWk, $i*4+2)); - $aColor[ $i + 8 ] = unpack( 'H6', substr( $sWk, $i * 4 + 2 ) ); + $oBook->{aColor}[ $i + 8 ] = unpack( 'H6', substr( $sWk, $i * 4 + 2 ) ); } } @@ -2479,12 +2482,19 @@ sub _NewCell { #------------------------------------------------------------------------------ # ColorIdxToRGB (for Spreadsheet::ParseExcel) # -# TODO JMN Make this a Workbook method and re-document. +# Returns for most recently opened book for compatibility, use +# Workbook::ColorIdxToRGB instead # #------------------------------------------------------------------------------ sub ColorIdxToRGB { my ( $sPkg, $iIdx ) = @_; - return ( ( defined $aColor[$iIdx] ) ? $aColor[$iIdx] : $aColor[0] ); + + + unless( defined $oCurrentBook ) { + return ( ( defined $aColor[$iIdx] ) ? $aColor[$iIdx] : $aColor[0] ); + } + + return $oCurrentBook->ColorIdxToRGB( $iIdx ); } @@ -2996,7 +3006,12 @@ Returns the style of an underlined font where the value has the following meanin =head2 $font->{Color} -Returns the color index for the font. The index can be converted to a RGB string using the C<ColorIdxToRGB()> Parser method. +Returns the color index for the font. The mapping to an RGB color is defined by each workbook. + +The index can be converted to a RGB string using the C<$workbook->ColorIdxToRGB()> Parser method. + +(Older versions of C<Spreadsheet::ParseExcel> provided the C<ColorIdxToRGB> class method, which is deprecated.) + =head2 $font->{Strikeout} diff --git a/lib/Spreadsheet/ParseExcel/Workbook.pm b/lib/Spreadsheet/ParseExcel/Workbook.pm index ba0381f..d58f98b 100644 --- a/lib/Spreadsheet/ParseExcel/Workbook.pm +++ b/lib/Spreadsheet/ParseExcel/Workbook.pm @@ -33,6 +33,14 @@ sub new { } ############################################################################### +sub ColorIdxToRGB { + my( $oBook, $iIdx ) = @_; + + my $palette = $oBook->{aColor}; + return ( ( defined $palette->[$iIdx] ) ? $palette->[$iIdx] : $palette->[0] ); +} + +############################################################################### # # worksheet() #
On Fri Feb 28 06:24:28 2014, tlhackque wrote: Show quoted text
> +Returns the color index for the font. The mapping to an RGB color is > defined by each workbook. > + > +The index can be converted to a RGB string using the C<$workbook-
> >ColorIdxToRGB()> Parser method.
Hi Timothe, That look okay overall and as the TODO testifies, it was on the back of my mind to do it eventually. If the method is being made public then it should have a under_score style name like: $workbook->color_id_to_rgb() John
Subject: Re: [rt.cpan.org #93425] Color index leaks from one workbook to another.
Date: Fri, 28 Feb 2014 08:51:58 -0500
To: bug-Spreadsheet-ParseExcel [...] rt.cpan.org
From: tlhackque <tlhackque [...] yahoo.com>
On 28-Feb-14 08:07, John McNamara via RT wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=93425 > > > On Fri Feb 28 06:24:28 2014, tlhackque wrote: >
>> +Returns the color index for the font. The mapping to an RGB color is >> defined by each workbook. >> + >> +The index can be converted to a RGB string using the C<$workbook-
>>> ColorIdxToRGB()> Parser method.
> Hi Timothe, > > That look okay overall and as the TODO testifies, it was on the back of my mind to do it eventually. > > If the method is being made public then it should have a under_score style name like: > > > $workbook->color_id_to_rgb() > > John
I've hit several of your TODOs as I've needed things for my project. I appreciate that you left hints even where you left things as TODOs. I will change the name - though I was trying to remain consistent with the the previous method's name. I thought that updating callers would be easier (switch $parser-> to $workbook->). I guess it depends on what kind of consistency we want to achieve. Re: overall style: I'm focused on my project, not S:P:E. I'll code patches in whatever the native style du jour is, but switching is out of scope. -- This communication may not represent my employer's views, if any, on the matters discussed.
On Fri Feb 28 08:52:07 2014, tlhackque wrote: Show quoted text
> I guess it depends on what kind of consistency we want to achieve.
Hi Timothe, Basically, no camel case names in new code, and use names like $workbook, $worksheet, etc. instead of $oBook, $oSheet. Old, untouched code can stay as it is. Show quoted text
> Re: overall style: I'm focused on my project, not S:P:E. I'll code > patches in whatever the native style du jour is, but switching is out > of scope.
I think that it is only fair that if you are submitting code that will mainly (if not only) benefit your project that you make the effort to make that code acceptable to the maintainers. And add tests. John
Subject: Re: [rt.cpan.org #93425] Color index leaks from one workbook to another.
Date: Fri, 28 Feb 2014 10:23:56 -0500
To: bug-Spreadsheet-ParseExcel [...] rt.cpan.org
From: tlhackque <tlhackque [...] yahoo.com>
On 28-Feb-14 10:06, John McNamara via RT wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=93425 > > > On Fri Feb 28 08:52:07 2014, tlhackque wrote:
>> I guess it depends on what kind of consistency we want to achieve.
> Hi Timothe, > > Basically, no camel case names in new code, and use names like $workbook, $worksheet, etc. instead of $oBook, $oSheet. > > Old, untouched code can stay as it is. > >
>> Re: overall style: I'm focused on my project, not S:P:E. I'll code >> patches in whatever the native style du jour is, but switching is out >> of scope.
> I think that it is only fair that if you are submitting code that will mainly (if not only) benefit your project that you make the effort to make that code acceptable to the maintainers. And add tests. > > > John > > > > >
I wasn't clear. What I meant was that I am not inclined to switch the style of existing routines where I just add a line or two of code. Or whole files, just because I touch them. I'm happy to write new code in whatever style. With no guidance [except that the module was unmaintained], I used the existing style. That's normal when submitting patches. Given your guidance, I will make the new hook routines use lowercase names. It would be good to add a note to the README documenting this so future contributors don't have to redo work. I have already changed the name of the color index routine as requested and committed tests for the new routines. I'm trying to be reasonable - but not to become the defacto maintainer of the module. I'm glad to see that there is hope for a release - which I think will benefit others. -- This communication may not represent my employer's views, if any, on the matters discussed.
I believe I have all of your changes committed to runrig/master. Examine the latest Changes file, let me know if I listed everything so I know what tickets to close. I'll get this released soon.
Fixed in 0.61