{{ message }}
Repository navigation
Conversation
Graphics::Magick doesn't know the attribute, and its error handler exits the process with status 10 (OptionError 410 % 100) without a message. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.

Fixes #2239, and with it the silent exits in #2446 and #2077. It is also what prompted #2705.
When
Graphics::Magickis installed, LaTeXML prefers it overImage::Magick, e.g., on Arch, where Inkscape pulls in GraphicsMagick.image_readthen setsbefore every image read.
optionis an Image::Magick attribute; Graphics::Magick doesn't know it (nordefine) and raisesOptionError(410). PerlMagick'sMagickErrorHandlerhas no error list to report into duringSet, so it callsexit(severity % 100), which ends latexml with status 10 and no message. That's whyeval {}around the conversion didn't help in #2239. A backtrace at theexit_group:#2077 shows the same thing from the warning side:
Exception 410: Unrecognized attribute (option) at .../LaTeXML/Util/Image.pm.This PR sets the option only for Image::Magick. GraphicsMagick has no crop-box support in its PDF reader to switch on instead, so nothing is lost there.
Note: with this fix, GraphicsMagick no longer crashes, but GraphicsMagick 1.3.48 then writes corrupted PNGs: rows truncated to 3/4 width, color channels shifted. That's a bug in its PNG writer for images with an alpha channel that is fully opaque, which is what
Transparentproduces for a PDF read without alpha. Minimal reproduction, without LaTeXML:It is fixed upstream (GraphicsMagick ChangeLog 2026-09-29, SourceForge issue #779 "GraphicsMagick >= 1.3.48 broke png conversion"), but not released yet. Image::Magick doesn't have the problem. Since this is the second GraphicsMagick-only failure, it may be worth preferring Image::Magick when both are installed, as discussed in #2705. I left that out of this PR.
Tested with GraphicsMagick 1.3.48 and ImageMagick 7 both installed: arXiv:1308.6132 (25 PDF figures) died with status 10 before and now converts to HTML; its figures are then hit by the GraphicsMagick PNG bug above, and come out correct with Image::Magick.
prove -l t/gives the same results with and without the patch.🤖 Generated with Claude Code