[$pagenumber] to the filename to deal with multipage documents such as PDFs.
Image::Magick doesn't seem to like page selection for filenames containing a colon. This is also the case for imagemagick binaries:
$ identify 'screenshot_2015-06-06_18:37:53.png' screenshot_2015-06-06_18:37:53.png PNG 453x122 453x122+0+0 8-bit sRGB 11.2KB 0.000u 0:00.000 $ identify 'screenshot_2015-06-06_18:37:53.png' identify: no decode delegate for this image format `37' @ error/constitute.c/ReadImage/501. $ mv 'screenshot_2015-06-06_18:37:53.png' 'screenshot_2015-06-06_18-37-53.png' $ identify 'screenshot_2015-06-06_18-37-53.png' screenshot_2015-06-06_18-37-53.png=>screenshot_2015-06-06_18-37-53.png PNG 453x122 453x122+0+0 8-bit sRGB 11.2KB 0.000u 0:00.000
This might be an imagemagick bug, but it's also possible that colons are interpreted somehow.
Yes they are: ImageMagick has syntax to force the file to be interpreted as a particular format, like gif:foobar.img to read foobar.img as a GIF, or to use unusual I/O patterns, like fd:5. --smcv
Anyway, to render such images properly in ikiwiki I had to remove
the colons. An easy fix is to remove ‘:’ from
but this can break existing installations.
I think we should remove
:from the default
wiki_file_charseither as soon as we have a way to handle backwards compatibility, or in ikiwiki 4; but you're right that it's a compat problem, so we can't just do that as a solution. --s
A better solution would be to make
IkiWiki::Plugin::img croak on
such image filenames (which anyway are currently not rendered, but
Image::Magick's error message is quite cryptic).
Better still would be to fix the bug by escaping the filename so ImageMagick treats it as just a filename. It seems the way to do that is to call
Read("hello:world.png"), which I have now done. --s