mom_static_problems() fetches each MyOpenMath problem with its graphs embedded as SVG and writes each SVG to a file. It then uses Playwright's headless Chromium only to make two copies of each, a PDF for LaTeX and a PNG, launching a new browser for every SVG. Could a lighter tool make those copies?
Tried on the two MyOpenMath SVGs committed with the sample article (examples/sample-article/gen/problems/images/mom-930582-1.svg and -2.svg):
- PyMuPDF, already used for PDF conversions, gets the page size and the text right, but it draws no arrowheads (it does not render SVG markers at all), and it ignores
fill-opacity inside a style attribute, so translucent fills come out solid. It will not do.
rsvg-convert (librsvg 2.60) matches Chromium: the arrowheads, the transparency, and the PDF page size (64 mm by 97 mm) all come out right. Its PNG has a transparent background where Chromium's is white; --background-color=white makes them match. PreFigure already uses rsvg-convert for its own PDF and PNG output, so authors using PreFigure have it.
So the choice is between rsvg-convert, an external program PreTeXt would call directly (a new key in pretext.cfg, and an installation note), with no browser at all, and Chromium, which needs nothing new, and which #3247 would reduce to one browser for all of a document's SVGs.
One more thing noticed along the way: these files declare version="1.1", but one of their three arrowhead markers uses orient="auto-start-reverse", which is SVG 2. Chromium and rsvg-convert both handle it. Batik, which XSL-FO's FOP uses and which handles only SVG 1.1, might not, if XSL-FO ever reads these files directly; that is unchecked.
Claude Opus 5.5, acting as a coding assistant for Rob Beezer
mom_static_problems()fetches each MyOpenMath problem with its graphs embedded as SVG and writes each SVG to a file. It then uses Playwright's headless Chromium only to make two copies of each, a PDF for LaTeX and a PNG, launching a new browser for every SVG. Could a lighter tool make those copies?Tried on the two MyOpenMath SVGs committed with the sample article (
examples/sample-article/gen/problems/images/mom-930582-1.svgand-2.svg):fill-opacityinside astyleattribute, so translucent fills come out solid. It will not do.rsvg-convert(librsvg 2.60) matches Chromium: the arrowheads, the transparency, and the PDF page size (64 mm by 97 mm) all come out right. Its PNG has a transparent background where Chromium's is white;--background-color=whitemakes them match. PreFigure already usesrsvg-convertfor its own PDF and PNG output, so authors using PreFigure have it.So the choice is between
rsvg-convert, an external program PreTeXt would call directly (a new key inpretext.cfg, and an installation note), with no browser at all, and Chromium, which needs nothing new, and which #3247 would reduce to one browser for all of a document's SVGs.One more thing noticed along the way: these files declare
version="1.1", but one of their three arrowhead markers usesorient="auto-start-reverse", which is SVG 2. Chromium andrsvg-convertboth handle it. Batik, which XSL-FO's FOP uses and which handles only SVG 1.1, might not, if XSL-FO ever reads these files directly; that is unchecked.Claude Opus 5.5, acting as a coding assistant for Rob Beezer