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: |
Nobody in particular
|
Requestors: |
tlhackque [...] yahoo.com
|
Cc: |
|
AdminCc: |
|
|
Severity: |
(no value)
|
Broken in: |
0.59 |
Fixed in: |
(no value)
|
|
Sun Feb 16 14:17:40 2014
tlhackque [...] yahoo.com - Ticket created
Currently, the Spreadsheet::ParseExcel APIs convert the internal excel units to 'user units' before returning them to the caller.
(User units are roughly characters in Arial 10 pt.)
This is convenient for spreadsheet users, who are used to these units on the screen.
But applications need an API that returns the dimensions in some more useful units, such as CSS pixels.
Currently, I have to back-convert to translate to pixels. While this is OK for height, for width I can't undo the rounding that occurs in ParseExcel::_convert_col_width. So I get approximate widths.
I would like to see an API added that returns width and height values in pixels. E.g. The standard 8.43 character column width should also return 64px.
Perhaps get_row_heights, get_col_widths, get_default_row_height, and get_default_col_width could take a 'units' parameter, with the default user units, and an argument of 'px' returning pixels. (I don't object to additional units, but that's not necessary.)
This would be very helpful for those of us who try to display XLS files in other formats. (Such as HTML and PDF.)
Thanks!
(For anyone else dealing with this, the approximate answer is
wid-px = (value <= 1.0)? value * 12 : (value * 7) + 5
hgt-px = value * 96 / 72
, where 'value' is what's returned in the arrays returned by get_row_heights and get_col_widths)