Large SVGs are rendered incorrectly in latex output #9660
Labels
Comments
This seems the best solution. I'll do that. |
|
OK, I tried this, and with |
|
See mrpiggi/svg#60 (comment), especially the last two paragraphs. |
|
Quoting from that comment:
This is already ensured. But I guess the main point is that we need to always specify an explicit size with an SVG. I think we should just be able to read size information from the SVG and add the size attribute if it's missing.... |
jgm
added a commit
that referenced
this issue
Apr 18, 2024
Remove old method of scaling images so they don't overflow. This relied on graphicx internals and made global changes that caused problems with includesvg (see #9660). Instead, add a macro `\pandocbounded` that will do this on a local basis. We will have to modify the writer to add this explicitly when images lack explicit size information.
jgm
added a commit
that referenced
this issue
Apr 18, 2024
Previously we relied on graphicx internals and made global changes to Gin to force images to be resized if they exceed textwidth. This approach is brittle and caused problems with `\includesvg` (see #9660). The new approach uses a new macro `\pandocbounded` that is now defined in the LaTeX template. (Thanks here to Falk Hanisch in mrpiggi/svg#60.) The LaTeX writer has been changed to enclose `\includegraphics` and `\includesvg` commands in this macro when they don't explicitly specify a width or height. Compatibility issues: if custom templates are used with the new LaTeX writer, they will have to be updated to include the new `\pandocbounded` macro, or an error will be raised because of the undefined macro. Closes #9660.
|
jgm
added a commit
that referenced
this issue
Jun 23, 2024
Previously we relied on graphicx internals and made global changes to Gin to force images to be resized if they exceed textwidth. This approach is brittle and caused problems with `\includesvg` (see #9660). The new approach uses a new macro `\pandocbounded` that is now defined in the LaTeX template. (Thanks here to Falk Hanisch in mrpiggi/svg#60.) The LaTeX writer has been changed to enclose `\includegraphics` and `\includesvg` commands in this macro when they don't explicitly specify a width or height. Compatibility issues: - If custom templates are used with the new LaTeX writer, they will have to be updated to include the new `\pandocbounded` macro, or an error will be raised because of the undefined macro. - Documents that specify explicit dimensions for an image may render differently, if the dimensions are greater than the line width or page height. Previously pandoc would shrink these images to fit, but the new behavior takes the specified dimensions literally. Closes #9660.
jgm
added a commit
that referenced
this issue
Jun 23, 2024
Previously we relied on graphicx internals and made global changes to Gin to force images to be resized if they exceed textwidth. This approach is brittle and caused problems with `\includesvg` (see #9660). The new approach uses a new macro `\pandocbounded` that is now defined in the LaTeX template. (Thanks here to Falk Hanisch in mrpiggi/svg#60.) The LaTeX writer has been changed to enclose `\includegraphics` and `\includesvg` commands in this macro when they don't explicitly specify a width or height. In addition, the writer now adds `keepaspectratio` to the `\includegraphics` options if `height` is specified without width, or vice versa. Previously, this was set in the preamble as a global option. Compatibility issues: - If custom templates are used with the new LaTeX writer, they will have to be updated to include the new `\pandocbounded` macro, or an error will be raised because of the undefined macro. - Documents that specify explicit dimensions for an image may render differently, if the dimensions are greater than the line width or page height. Previously pandoc would shrink these images to fit, but the new behavior takes the specified dimensions literally. In addition, pandoc previously always enforced `keepaspectratio`, even when width and height were both specified, so images with width and height specified that do not conform to their intrinsic aspect ratio will appear differently. Closes #9660.
jgm
added a commit
that referenced
this issue
Jun 23, 2024
Previously we relied on graphicx internals and made global changes to Gin to force images to be resized if they exceed textwidth. This approach is brittle and caused problems with `\includesvg` (see #9660). The new approach uses a new macro `\pandocbounded` that is now defined in the LaTeX template. (Thanks here to Falk Hanisch in mrpiggi/svg#60.) The LaTeX writer has been changed to enclose `\includegraphics` and `\includesvg` commands in this macro when they don't explicitly specify a width or height. In addition, the writer now adds `keepaspectratio` to the `\includegraphics` or `\includesvg` options if `height` is specified without width, or vice versa. Previously, this was set in the preamble as a global option. Compatibility issues: - If custom templates are used with the new LaTeX writer, they will have to be updated to include the new `\pandocbounded` macro, or an error will be raised because of the undefined macro. - Documents that specify explicit dimensions for an image may render differently, if the dimensions are greater than the line width or page height. Previously pandoc would shrink these images to fit, but the new behavior takes the specified dimensions literally. In addition, pandoc previously always enforced `keepaspectratio`, even when width and height were both specified, so images with width and height specified that do not conform to their intrinsic aspect ratio will appear differently. Closes #9660.
This was referenced Jun 25, 2024
|
I found this issue from a Google search for the error message If anyone else wants to see what template updates are needed, here is the commit: jgm/pandoc-templates@6c0e7b0#diff-f218051b4ca8f740a9f585a149101d4a3025037c568b391b5216edf7b14cfadc |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Explain the problem.
Firstly, I just want to mention this is not an issue with pandoc's internal translation of svgs to pdf. That works fine! The issue here is when svgs are outputted into 'latex'.
Consider the following one line markdown document, using this svg:
If we build this by doing:
pandoc pan.md --to latex -o pan.tex -spdflatex --shell-escape pan.tex(--shell-escape is required as we have an svg inside the tex file. The latex svg package will invoke inkscape to render the svg).Then the output is badly corrupted.
This happens (I think) because the SVG needs to be resized, and the resizing doesn't work correctly due to the setting of
Ginin the\setkeys{Gin}{...}line of the latex template. I raised this issue with thesvglatex package here: mrpiggi/svg#60 , where I was told settingGinin this way isn't supported.The reason the bad rendering happens at all is by default the latex
svgpackage extracts text from the svg and renders it using the latex engine. The resizing is messing up the placement of this text.This could be fixed by setting
inkscapelatexin thesvgpackage to false. This makes the svg latex package just render the svg to a single PDF and everything works fine. This would stop text in SVGs being rendered as latex, if anyone was using that functionality (they can of course get it back by editing the template).The other option would be to disable auto-resizing, but that would effect all images (not just svg), and be much worse (as large pictures would overflow the page).
This problem was originally found as an issue in quarto, which does this two-step pass of using pandoc to turn markdown -> tex, then compiling the resulting tex.
Pandoc version?
Ubuntu 23.04
The text was updated successfully, but these errors were encountered: