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: 93065
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.63



Subject: Colors black and auto return white
Download (untitled) / with headers
text/plain 2.5k
Never thought I'd complain that "black is white", but here it is: When a cell's border color is set to 'auto' or 'black', the RGB value returned is 0xFFFFFF, which is white. Reproducer: Microsoft Excel 2003 - latest (11.8404.8405) SP3 under windows 7. Create a new sheet, save it. Ctrl/1 (Format cells) Select border tab. Click on left line (Thin, color auto - which means black) Save. (Default type - Microsoft Excel workbook (.xls)) Run the test program; the returned color index is 64; the conversion table @aColor in ParseExcel.pm translates this to 0xFFFFFF, which is white. Ctrl/1, select black, click on left line to change color to black. Result: index 8, also mapped to 0xFFFFFF. All other colors return reasonable values. I checked four at a time (one on each side), so it appears that the color index is being found in the right place. The fix is probably as simple as changing the entries at 8 and 64 to 0x000000. Here is the supporting detail: Perl version : 5.008008 OS name : linux Module versions: (not all are required) Spreadsheet::ParseExcel 0.59 Scalar::Util 1.23 Unicode::Map 0.112 Spreadsheet::WriteExcel (not installed) Parse::RecDescent 1.967009 File::Temp 0.22 OLE::Storage_Lite 0.19 IO::Stringy 2.110 My test program (no error checking for clarity): #!/usr/bin/perl use warnings; use strict; use Spreadsheet::ParseExcel; use Data::Dumper; $Data::Dumper::Sortkeys=1; my $ss=Spreadsheet::ParseExcel->new; my $wb=$ss->parse('TestSheet97.xls'); my $ws=$wb->worksheet(0); my $c = $ws->get_cell(0,0); exit unless $c; print Dumper( $c->{Format}{BdrColor} ); print( $ss->ColorIdxToRGB( $_ ), "\n" ) foreach @{$c->{Format}{BdrColor}}; exit; __END__ Output from first three tests (auto, black, red): $VAR1 = [ 64, 0, 0, 0 ]; FFFFFF << This is white! 000000 000000 000000 Switch to black: $VAR1 = [ 8, < Note different index 0, 0, 0 ]; FFFFFF << Still white 000000 000000 000000 Switch to red $VAR1 = [ 10, 0, 0, 0 ]; FF0000 << This is red! 000000 000000 000000 The attached copy of a spreadsheet has all four sides set to automatic. $VAR1 = [ 64, 64, 64, 64 ]; FFFFFF FFFFFF FFFFFF FFFFFF
Subject: TestSheet97.xls
Download TestSheet97.xls
application/vnd.ms-excel 13.5k

Message body not shown because it is not plain text.

From: tlhackque [...] yahoo.com
Download (untitled) / with headers
text/plain 474b
With a bit more experience, I think the right fix is more like: For 8 (black), return 000000 For 64 (auto) return something unique - perhaps undef or 1000000. Auto isn't always black; e.g. as a fill color it probably means 'transparent' FWIW, I have found some clues in the microsoft spec, which you might want to refer to in the pod: http://download.microsoft.com/download/0/B/E/0BE8BDD7-E5E8-422A-ABFD-4342ED7AD886/Excel97-2007BinaryFileFormat(xls)Specification.xps
Download (untitled) / with headers
text/plain 476b
On Sun Feb 16 13:43:16 2014, tlhackque wrote: Show quoted text
> With a bit more experience, I think the right fix is more like: > > For 8 (black), return 000000 > > For 64 (auto) return something unique - perhaps undef or 1000000. > Auto isn't always black; e.g. as a fill color it probably means > 'transparent'
Auto may not always be black, but I think it is black most of the time, so '000000' might be considered reasonable. I'll get this fixed in github and push it out next release.
Subject: Re: [rt.cpan.org #93065] Colors black and auto return white
Date: Thu, 27 Feb 2014 05:09:23 -0500
To: bug-Spreadsheet-ParseExcel [...] rt.cpan.org
From: tlhackque <tlhackque [...] yahoo.com>
Download (untitled) / with headers
text/plain 1.1k
On 26-Feb-14 18:08, Douglas Wilson via RT wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=93065 > > > On Sun Feb 16 13:43:16 2014, tlhackque wrote:
>> With a bit more experience, I think the right fix is more like: >> >> For 8 (black), return 000000 >> >> For 64 (auto) return something unique - perhaps undef or 1000000. >> Auto isn't always black; e.g. as a fill color it probably means >> 'transparent'
> Auto may not always be black, but I think it is black most of the time, so '000000' might be considered reasonable. I'll get this fixed in github and push it out next release. >
Yes, though it would be nice to have a constant to know the difference. Even a constant for '64' so the caller can check if it cares... As you can probably tell, I'm re-rendering some spreadsheets with this and finding a bunch of issues. If you prefer, send me the gitub repo & I can incorporate several of my patches directly, or as pull requests. Assuming that there will be a next release sometime soon, that may be easier for both of us. -- This communication may not represent my employer's views, if any, on the matters discussed.
Download (untitled) / with headers
text/plain 645b
On Thu Feb 27 05:09:33 2014, tlhackque wrote: Show quoted text
> > If you prefer, send me the gitub repo & I can incorporate several of > my > patches directly, or as pull requests.
The repo is at: https://github.com/runrig/spreadsheet-parseexcel But I still tend to think that ColorIdxToRGB() should return an RGB value, not some other made up constant, and that 'black' is the best default value for 'auto'. If you want to handle it differently, then why not before you call ColorIdxToRGB, or, perhaps I can just change the lexical aColor array to a package global and/or maybe provide a SetColorIdxToRGB() to set any custom index to RGB mapping you want to.
Subject: Re: [rt.cpan.org #93065] Colors black and auto return white
Date: Thu, 27 Feb 2014 22:19:49 -0500
To: bug-Spreadsheet-ParseExcel [...] rt.cpan.org
From: tlhackque <tlhackque [...] yahoo.com>
Download (untitled) / with headers
text/plain 2.4k
On 27-Feb-14 13:23, Douglas Wilson via RT wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=93065 > > > On Thu Feb 27 05:09:33 2014, tlhackque wrote:
>> If you prefer, send me the gitub repo & I can incorporate several of >> my >> patches directly, or as pull requests.
> The repo is at: > https://github.com/runrig/spreadsheet-parseexcel > > But I still tend to think that ColorIdxToRGB() should return an RGB value, not some other made up constant, and that 'black' is the best default value for 'auto'. If you want to handle it differently, then why not before you call ColorIdxToRGB, or, perhaps I can just change the lexical aColor array to a package global and/or maybe provide a SetColorIdxToRGB() to set any custom index to RGB mapping you want to.
No, don't want custom mapping. Mapping should return what worksheet/book specifies. It appears that the color array is updated as palette records are encountered (!). see _subPalette() This means that state is sticky across workbooks. E.g., open one, it updates @aColor, open another, they shrare the table, but should not. Sigh. Each workbook object needs a private copy. For a constant, I suggest (and meant) that you provide a constant for '64' the caller can then check for 'auto' BEFORE calling ColorIdxToRGB. It doesn't seem right for the caller to know that 64 is magic, better for caller to be able to use a name. Just define a constant Spreadsheet::ParseExcel::AutoColor = 64 and I'd be happy. Agree the call should return black; it's the 98% case.. Have cloned the repo, pushed the changes for hidden row, col, active sheeet, hidden sheet, tab color and fixes for get_row/col_heights exceptions. You can merge from https://github.com/tlhackque/spreadsheet-parseexcel, or I can issue a formal pull request. Your choice. I added you as a collaborator in case you want to push any changes while I'm working on using this. I didn't merge my work-around for default col format - I think a different approach is in order there. Suggest that cell->get_format do the work when a cell's format is requested. (There are some other cases that get_cell_format could handle, like merged areas - for now I deal with those in the caller.) Note that there seems to be a corresponding default row format - but I haven't worried about it (at least, not yet). Thanks. -- This communication may not represent my employer's views, if any, on the matters discussed.
Download (untitled) / with headers
text/plain 279b
On Thu Feb 27 22:19:59 2014, tlhackque wrote: Show quoted text
> On 27-Feb-14 13:23, Douglas Wilson via RT wrote: > Just define a constant > Spreadsheet::ParseExcel::AutoColor = 64 and I'd be happy.
This was done in 0.63, though some update to the docs is still needed. Black was already done.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.