jmcnamara / excel-writer-xlsx

Perl module to create Excel XLSX files.
https://metacpan.org/pod/distribution/Excel-Writer-XLSX/lib/Excel/Writer/XLSX.pm
Other
102 stars 51 forks source link

inserted graphic displayed w/wrong aspect ratio #143

Closed rlauer6 closed 9 years ago

rlauer6 commented 9 years ago

I've upgraded from 0.78 to 0.84 & 0.85. Going from 0.78 I've noticed that my inserted graphics are now displaying "squashed" and misshapen.

Changing height/width of row/column does not seem to change outcome. Suggestions?

jmcnamara commented 9 years ago

Could you post a sample image that demonstrates the issue.

Thanks.

rlauer6 commented 9 years ago

report-logo

rlauer6 commented 9 years ago

i have two files that I created 1 with ver 0.78 and one with ver 0.84 that show the issue if you want me to send the .xlsx files...although not sure how to upload them here.

jmcnamara commented 9 years ago

There was a change in version 0.79 to fix images that didn't have a dpi of 96.

However, this change should be an improvement, and images such as the one above with 72dpi should be displayed the same way as in Excel.

For example I downloaded the above image as gh143.jpg and ran the following program:

use strict;
use Excel::Writer::XLSX;

my $workbook  = Excel::Writer::XLSX->new( 'test.xlsx' );
my $worksheet = $workbook->add_worksheet();

$worksheet->insert_image( 'B2', 'gh143.jpg' );

$workbook->close();

And the output looks like this:

screen shot 2015-09-20 at 20 51 51

Which is the same as if it was imported by Excel.

rlauer6 commented 9 years ago

Hi John...I'm still seeing squashed images...not sure what is going on. Here's what the compressed graphic looks like and here's what the graphic is supposed to look like...any thoughts on why I might be getting a different result? screenshot 2015-09-28 at 11 06 24 am screenshot 2015-09-28 at 11 06 14 am

rlauer6 commented 9 years ago

Sorry - I believe I may be resetting the column width and causing compression of the image. I thought at one point the graphic would span columns and one only needed to worry about the row height?

jmcnamara commented 9 years ago

I thought at one point the graphic would span columns and one only needed to worry about the row height?

That should be the case. The row height can occasionally get reset automatically by Excel if there are fonts that cause the it to change. That shouldn't happen with columns.

If you are viewing the output file in Excel for Mac then you may see some squashing of the image. That happens with all Excel files and isn't E::W::X specific.

The best thing to do is to post the image and create a small example file that demonstrates the issue.

John

rlauer6 commented 9 years ago

So...upon further review...you are correct. Even in Google sheets my example seems to be scaled correctly and spans a column that is narrower than the image. I was fooled because I am converting these .xlsx files to PDF.

What I've discovered...and maybe this will help some other folks that use this same technique, is that using libreoffice (or openoffice) in headless mode to convert these documents to PDF is problematic with regard to this scaling...it's not so (or too) smart and attempts to fit the graphic into the column width.

Thanks for your patience...I'll investigate libreoffice options and version behaviors and report back in case someone else has the same issue. As always, you do a great job with this amazing module and your responsiveness to the community. Thanks.

rlauer6 commented 9 years ago

Libreoffice 4.3 does not "do the right thing" with regard to images inserted into a cell when it exports the PDF...it tries hard to jam them in there resulting in a squashed image if the column width is too narrow.

Libreoffice 5.0 does the right thing...woohoo!

...and here's how to convert your .xlsx into a PDF using Libreoffice on Linux...

#!/bin/bash

# $Id: doc2pdf.in,v 1.5 2014/09/16 02:36:44 rlauer Exp $
# convert a file to PDF
# usage: doc2pdf input-name [output-name]

# pick your poison
SOFFICE=/opt/libreoffice4.3/program/soffice
#SOFFICE=/home/rlauer/libreoffice/opt/libreoffice5.0/program/soffice

# create a temp directory for output and potentially for profile directory
outdir=$(mktemp -d)
LIBREOFFICE_HOME=$outdir

# cleanup temp dir on exit
trap '[ -d "$outdir" ] && rm -rf $outdir' EXIT

OPTS="--headless --convert-to pdf"
LOCKFILE=/tmp/oo-lock

#
# wait up to 2m for a lock - if the server is VERY busy this might be
# a problem...at some point we may want to simply queue up document
# conversion requests rather than take the chance that a conversion
# might fail do to high server load.
#
if ! test -e $LOCKFILE; then
  touch $LOCKFILE
  chmod o+w $LOCKFILE
fi

flock -x -w 120 $LOCKFILE -c "HOME=$LIBREOFFICE_HOME $SOFFICE $OPTS $1 --outdir $outdir" >/dev/null 2>&1

filename=$(basename $1)
# strip off extension
filename=${filename%%.*}

if test -s "${outdir}/${filename}.pdf"; then

    # move file to dest if we have second arg, else to pwd
    if [[ -n "$2" ]]; then
        mv ${outdir}/${filename}.pdf $2
    else
        mv ${outdir}/${filename}.pdf $(dirname $1)
    fi

    exit 0
else
    exit 1
fi
jmcnamara commented 9 years ago

Hi Rob,

Thanks for the update. I'm glad you tracked the issue down.

And thanks for the script. I'm sure people will find that useful.

Closing the issue.

John