2014-02-28 17:59:08 +01:00
If you use the rescaling feature of the directive [[ikiwiki/directive/img/]] with a smaller image it will distort. E.g. an image with 150x250 rescaled into size=200x200. --bastla
2014-07-12 00:33:38 +02:00
> 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
2014-07-15 19:40:48 +02:00
>> [[!template id=gitbranch branch=chrysn/imgforpdf-and-more author="[[chrysn]]"]]
>>
>> [[!tag patch]]
>>
>> i've implemented a fix for this along with a unit test.
>>
>> the patch branch is based on the imgforpdf branch
>> ([[bugs/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]]
2014-07-17 12:07:22 +02:00
>>> Mostly [[looks good to me|users/smcv/ready]].
>>>
>>> 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.
>>>
>>> --[[smcv]]
