in reply to Reading and Writing from / to XLSX file (optimization)
Why so complex? Maybe I don't get it, looking at sample data there's just continuous list @A (column) of keys (strings) in file #2, to be extracted with a one-liner. Almost as easily, file #1 to be read to %H, keys transformed by well-defined rule (?) to correspond to strings from @A. And finally, output @A and @H{@A} -- for sake of efficiency (hope so) "in one go".
To start with (though OT), _checkFilesExtensions doesn't do what comment says, and die "..." if $file !~ /\.xlsx?$/i;
Update. W.r.t. your question about how "to modify the cell size", I'm sure you've found the set_row and set_column. The "height" is easy and looks like value in Postscript points. The unit of measure for "width" is something hideous, in number of digits of 11-points-Calibri, but also involves some padding and rounding, i.e. width can be set only approximately. If my reverse-engineering-foo serves me right this time of day, to set a cell to be 40 mm wide and 30 mm high, I'd write
$worksheet-> set_row( 0, 30 / 25.4 * 72 ); $worksheet-> set_column( 0, 0, ( 40 / 25.4 * 72 - 5 ) / 7 );
but I only have LibreOffice here to confirm
P.S. And of course, reading my original answer above, I meant "make %A = map { $_ => 1 } @A, then only read those lines from file #1, which have keys existing in %A, then etc." :-)
And wrong link for "one go" sneaked in, here's perhaps more efficient one. I hope it was a final edit.
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re^2: Reading and Writing from / to XLSX file (optimization)
by thanos1983 (Parson) on Nov 01, 2017 at 12:13 UTC |