ImageMagick 7 incompatibilities (was Rotation of an included graphics leads to error in latexmlpost

[asmaier]

A simple example document with an included graphic like

\documentclass[12pt,a4paper,twoside]{book}
\usepackage{graphicx}
\begin{document}
\begin{figure}[t]
	\includegraphics[angle=90,width=0.7\linewidth]{some.eps}
\end{figure}
\end{document}

leads to an error in the latexml post processing

$ latexml testgraphics.tex --dest=testgraphics.xml
...
Conversion complete: No obvious problems.
$ latexmlpost --format=html5 --dest=testgraphics.html testgraphics.xml
...
(Graphics testgraphics.html processing...
Error:imageprocessing:Rotate Image processing operation Rotate (degrees, -90, color, #FFFFFF) returned Exception 410: unrecognized option `color' @ error/Q16HDRI.xs/XS_Image__Magick__Q16HDRI_Mogrify/7807
	In Post::Graphics[@0x7fb0e3bca0f8] ->transformGraphic

Warning:expected:image Couldn't get usable image for some.eps
	In Post::Graphics[@0x7fb0e3bca0f8] ->transformGraphic
 0.75 sec)
(XSLT[using LaTeXML-html5.xsl] testgraphics.html processing... 0.02 sec)

The message Exception 410: unrecognized option `color' seems harmless to me. Maybe the error handling is a bit too strict. I think the processing of the image should not be aborted, because of this issue.

[brucemiller]

This is a shot in the dark; perhaps there's a change in Image Magick;'s behaviour? I've got version 6.9.9.27 and don't see such an error message. But it seems as if possibly "color" should actually be "background". If you can update from git, let me know if this fixes the problem.

[asmaier]

Sorry, I didn't mention the versions I'm using:

• Mac OS X 10.12.6
• LaTeXML (0.8.2)
• ImageMagick 7.0.7-21 Q16 x86_64
  (installed as described in Support and document installation of LaTeXML via homebrew on Mac OS X #929).
  So you are probably right. It could be a change in ImageMagick behaviour since version 7.

[matteosecli]

I could reproduce the issue on MacOS 10.13.2 and ImageMagick 7.0.7-22 with LaTeXML 3064b94, while LaTeXML c1dc5fb solves the issue for me.

[dginev]

If the great triage by @matteosecli has nailed down the issue we could use this as another signal that a soonish release of 0.8.3 will decrease friction for casual users.

Could you confirm with installing latexml from github @asmaier ?

[asmaier]

So I can confirm now, that with HEAD version of LaTeXML the error when rotating an included image doesn't occur anymore. Unfortunately the rotated images of my test document turn out to be empty and I also see the following warning:

Warning:imageprocessing:Write Image processing operation Write (filename, thesis/docs/x75.png) returned Exception 350: profile 'icc': 'RGB ': RGB color space not permitted on grayscale PNG `thesis/docs/x75.png' @ warning/png.c/MagickPNGWarningHandler/1744
	In Post::Graphics[@0x7fb21fa3e7b0] ->transformGraphic

[brucemiller]

I was afraid of that; where there's one "incompatibility" (if you wan't to call it that), there'd likely be more. I probably can't do much till I can get ahold of a system with ImageMagick 7 and work through the changes.

[asmaier]

Actually I have to correct myself. It turns out that rotation of images works fine now with HEAD version of LaTeXML. The reason why my images turned out to be empty first seem to be related to LaTeXML interpreting the numbers for trim and width differently than pdflatex does. Sorry for the confusion.

[brucemiller]

Cool, then maybe the best is to go ahead and close here (while expecting that some ImageMagick issues may pop up in the future).

If the trim & width inconsistency is problematic, could you open a new issue w/sample code & images?
Note, however, that some things that can be done with included graphics in latex (like overlapping the adjacent text) are hard to replicate in xml/html.