Images as source versus as files

[Rob Beezer]

Some ideas while thinking about images, and particularly those we have described
by "source languages", such as #prefigure, #latex-image, #asymptote, #mermaid
and more. Generally, Python will rip these out, run some executable, and
produce images in various file formats. The CLI does a good job of hiding most
of this from an author or publisher, so it is not such an obstacle anymore.

Two exceptions are relevant:

1. For #latex-image we just place the source language carefully into the
LaTeX file we create for making a PDF, and the LaTeX executable does the right
thing.

2. For #mermaid it is the converse. We plop the raw Mermaid into our HTML
output, and some Javascript does the rendering in/on the page.

Would it be better to use the manufactured images in these two cases? A
latex-image PDF inclusion into LaTeX, and a Mermaid SVG inclusion for HTML?

Pros:

For (2) the Mermaid SVG seem pretty small and perhaps they load up faster when
pre-built than running the Mermaid JS?

Andrew S has looked into accessibility for Mermaid, maybe getting our hands on
the SVG would be a plus:
https://github.com/PreTeXtBook/pretext/issues/2724

Cons:

Lots of dissatisfaction with #latex-image in HTML and font sizes not matching up
etc, a whole mess revolving around scaling. To a certain extent we avoid that
in the PDF output, I think, so (1) could be a backward step. (I am *not*
reopening the HTML discussion here.)

Any really good ideas in this, or any really bad ideas? Or is the status quo
just fine?

Rob

[Alex Jordan]

Check out the three graphs here:

Paragraph

And then in PDF here on PDF page 226 (page number 212).

https://spot.pcc.edu/math/orcca/ed3/pdf/orcca-edition3-partI.pdf

Note that the PDF uses the ambient font sans serif, not just font size. The image we see in HTML is using some default font, and I never investigated how I might make it use some other font (either the one from the PDF or something like the ambient HTML font). I could start to lean in favor of the proposed change if we had a good way to set all the ambient font stuff up for standalone latex-image files, instead of relying on whatever the defaults are.

It's not 100% true that LaTeX production avoids scaling issues. When the image is in a sidebyside, it gets more complicated. The image is produced off in the aether somewhere assuming some size, then gets shrunk to a different size so that it fits in the sidebyside. The shrinkage can be problematic, ending with too-small text, or too-thin lines drawn. I'm unsure if the proposed change could help with that, but it's maybe something to keep in mind. If you get things such that the HTML image looks the way you want it, and *exactly* that same image were used in print, maybe it could help. Except again maybe you don't want that, if you want different fonts for HTML and print.

--
You received this message because you are subscribed to the Google Groups "PreTeXt development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pretext-dev...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/MTAwMDAyMy5iZWV6ZXI.1763671498%40pnsh.

[Andrew Scholer]

For Mermaid, the primary issue with prerendering would be light/dark mode. Mermaid is set to render light/dark as appropriate (although currently a white background is being inserted in dark mode... look for a PR to remove that). A prerendered image would have to be one or the other. Or have some code to magically switch between two versions.

Other than that, I don't think there is any benefit to rendering the diagrams at display time via JS instead of build time. If anything, rendering at build time would reduce delay for readers and allow us to build code that treats mermaid images more like "non-source" images.

To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/CA%2BR-jrf011o0moYWU%2BrCB%3DEkf7VG2Rde0zWHckycd1PTSogjQQ%40mail.gmail.com.

[Alex Jordan]

A complicated pgfplots image can add several seconds to PDF build time. And then if you have many of them, and are at a stage of PDF production where you are rebuilding a lot, it adds up to a lot of time. So a noteworthy pro of includegraphics-ing pre-built PDF images would be faster builds in some cases.

To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/CACm44N9yb3y8%3DhiVuSN98FMHrAMVUVXOdBOYzhQFL3szZFDu6Q%40mail.gmail.com.

[Sean Fitzpatrick]

It would be interesting to see how much this would reduce the time it takes to run one LaTeX pass on the .tex file for APEX. 

(It's now only slightly less time than building the HTML.)

To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/CA%2BR-jrdF1SpbnoLrzQiuxeR0asT2rgD5YbLkqTZph9mSuMRiVQ%40mail.gmail.com.

[Rob Beezer]

On 11/20/25 16:36, Sean Fitzpatrick wrote:
> It would be interesting to see how much this would reduce the time it takes to
> run one LaTeX pass on the .tex file for APEX.

Crude test on the sample article. Simply blotting out #latex-image entirely so
the xelatex run won't stumble on them. No pre-built alternate as a replacment
(which I would think is fast?).

11 seconds for each pass with xelatex, remove 30 images (some trivial, some
complex), and you save 2 seconds on each pass.

For APEX:

In xsl/pretext-latex-common.xsl, go to current line 9401 inside template with
signature:

<xsl:template match="image[latex-image]" mode="image-inclusion">

Comment out the three lines (do not remove the template, just neuter it).
Sample article still compiled fine when I did this.

Report back?

Rob