Open xworld21 opened 3 years ago
@xworld21 I think this request may be a matter of refactoring all low-level calls to the image objects through LaTeXML::Util::Image::image_internalop
, which has the error handling implemented.
It may be helpful to get a minimal example or two, since I am a little concerned not to break LaTeXImages.pm
, as we don't have active tests for it yet.
It may be helpful to get a minimal example or two, since I am a little concerned not to break
LaTeXImages.pm
, as we don't have active tests for it yet.
Do you mean, a CI test? That might be tricky because SVG generation is very non-deterministic. Still, if you want to test this behaviour, it's enough to run latexml --mathsvg
in an environment without dvisvgm and with a misconfigured ImageMagick (e.g. without potrace, or with the wrong name for the potrace binary). LaTeXML won't complain but there won't be any images. Or at least it used to do that two years ago.
an environment without dvisvgm
I see. I think this is something we can reasonably guard against first - lack of a properly working dvisvgm
, dvipng
and/or dvips
. Currently the only check in LaTeXImages::canProcess
is whether the machine has a working image interface and a latex
executable, assuming that the rest will be properly configured if so.
Btw I don't have potrace
on my Ubuntu OS, and that binary sounded new to me, but that is fine - external delegates can vary between systems.
lack of a properly working
dvisvgm
,dvipng
and/ordvips
. Currently the only check inLaTeXImages::canProcess
is whether the machine has a working image interface and alatex
executable, assuming that the rest will be properly configured if so
If you go this route, it means disabling --mathsvg
if dvisvgm
is not present. Which is absolutely sensible after all.
For reference: https://github.com/brucemiller/LaTeXML/blob/b7059a29b0e1932ef656f973f8b8096cfac558f2/lib/LaTeXML/Post/LaTeXImages.pm#L61-L66 is where latexml checks for dvisvgm, but intentionally goes ahead even if SVG was requested (because you can still get it in principle using potrace or similar).
It appears that ImageMagick can fail in ways that LaTeXML does not detect, and that makes it really hard to debug installation problems. As far as I can tell, there are two situations that need to be fixed:
potrace
is not in the PATH, but LaTeXML eats the error message and reports that everything is fine.gs
is not available in the PATH.I can see how 1. can be handled, in different ways actually (push the results into a local
$report
, and process them at the end of the function; wrap the entire image object and spit out warning/errors along the way; etc). For 2. the PerlMagick docs [1] are not clear about how to recover an error message; it's possible that one needs to do feature detection. I really hope not, though.I am happy to do some work if you have a preferred approach in mind.
[1] https://imagemagick.org/script/perl-magick.php#exceptions