-
-
Notifications
You must be signed in to change notification settings - Fork 8k
Parse {lua,xe}tex-generated dvi in dviread. #29939
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
af451c9
to
87e0ecf
Compare
149992b
to
6a177bd
Compare
Milestoning to 3.11 because I think this is fairly self-contained, and is already something that mplcairo could benefit from, even before #29807 adds support in the builtin backends. But feel free to remilestone if it doesn't make it in the end. |
f8d6ee7
to
b987e24
Compare
9b5488f
to
3db0ce0
Compare
lib/matplotlib/tests/test_dviread.py
Outdated
subprocess_run_for_testing( | ||
[*cmd, "test.tex"], cwd=tmp_path, check=True, capture_output=True) | ||
# dviread must be run from the tmppath directory because {xe,lua}tex output | ||
# record the path to DejaVuSans.ttf as it is written in the tex source, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
# record the path to DejaVuSans.ttf as it is written in the tex source, | |
# records the path to DejaVuSans.ttf as it is written in the tex source, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fixed
The next step after #29829 ("Rework mapping of dvi glyph indices to freetype indices.") in preparation for #29807 ("Support {lua,xe}tex as alternative usetex engine.").
luatex and xetex generate slightly different versions of dvi files (compared to plain tex and also between themselves) to give them the ability to refer to TrueType (OpenType) fonts installed system-wide. This patch implements parsing for these dialects, and adjusts the relevant classes in dvifont so that one can indeed represent these fonts and their metrics.
Minor API design point: The DviFont.path (cached) property can raise an exception if no type1 font is associated with the tex fontname. This should be rare (and not recoverable, i.e. we would fail to generate proper output in that case anyways), but it does feel a bit dirty to raise an exception in a property. I can switch that to a plain method, e.g. DviFont.get_path or DviFont.resolve_path, if desired (but then there would be a bit of asymmetry with the other (never-raising) properties DviFont.subfont and DviFont.effects). Not a very big deal, but just in case anyone has an opinion...I decided in favor of resolve_path() (with manual caching), in particular because there is a future case (#20469 pk font support) where mapping the texname to an actual font file will even require on-the-fly generation of the font file (see mktex=pk option of kpsewhich, https://linux.die.net/man/1/kpsewhich).
PR summary
PR checklist