If you use the rescaling feature of the directive img with a smaller image it will distort. E.g. an image with 150x250 rescaled into size=200x200. --bastla

More specifically: img normally preserves aspect ratio: size=200x200 normally means "as large as possible, keeping the width 200px or less, the height 200px or less, and the aspect ratio correct". So a 4:3 image with size=200x200 would actually come out 200px wide and 150px tall.

However, when (desired width is specified) && (desired height is specified) && ((width > desired width) || (height > desired height)), it uses exactly the desired size, without preserving aspect ratio. --smcv

Available in a git repository branch.
Branch: chrysn/imgforpdf-and-more
Author: chrysn

i've implemented a fix for this along with a unit test.

the patch branch is based on the imgforpdf branch (svg and pdf conversion fails), because it would not cleanly merge. the branch also enhances on how images are handled in preview, falling back to data: urls if the image has not been rendered in a saved version. please review. --chrysn

Mostly looks good to me.

Minor things, which wouldn't stop me merging it if I could:

• $imgdatalink = "data:image/".$im->Get("magick").";base64,".encode_base64($blob[0]);: is the ImageMagick file type always valid as the second part of a MIME type?

• In this code:

  +open (my $outhtmlfd, "<", "$outpath.html");
  +local $/=undef;
  +my $outhtml = <$outhtmlfd>;
  +close $outhtmlfd;
  

  no block is closed, so the "local" is ineffective, so the <> operator remains in read-entire-file mode afterwards. To avoid odd side-effects, I would suggest using readfile() like t/trail.t does.

Available in a git repository branch.
Branch: smcv/ready/imgforpdf-and-more
Author: chrysn, smcv

I've used readfile() (but not done anything about the ImageMagick file type) in my copy of the branch.

--smcv

merged --smcv