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
imgnormally preserves aspect ratio:
size=200x200normally 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=200x200would 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
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);: 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()(but not done anything about the ImageMagick file type) in my copy of the branch.