Parse {lua,xe}tex-generated dvi in dviread.#29939
Merged
timhoffm merged 1 commit intomatplotlib:mainfrom Sep 3, 2025
Merged
Conversation
anntzer
force-pushed
the
luadviparse
branch
2 times, most recently
from
af451c9 to
87e0ecf
Compare
5 tasks
anntzer
force-pushed
the
luadviparse
branch
2 times, most recently
from
149992b to
6a177bd
Compare
Contributor
Author
|
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. |
7 tasks
QuLogic
reviewed
Jul 31, 2025
anntzer
force-pushed
the
luadviparse
branch
2 times, most recently
from
f8d6ee7 to
b987e24
Compare
QuLogic
reviewed
Aug 1, 2025
anntzer
force-pushed
the
luadviparse
branch
2 times, most recently
from
9b5488f to
3db0ce0
Compare
QuLogic
approved these changes
Aug 12, 2025
timhoffm
approved these changes
Sep 2, 2025
| A glyph in the dvi file. | ||
|
|
||
| The *x* and *y* attributes directly position the glyph. The *font*, | ||
| *glyph*, and *width* attributes are kept public for back-compatibility, |
Member
There was a problem hiding this comment.
What about the glyph and width fields? Are they used?
Contributor
Author
There was a problem hiding this comment.
I restored their documentation. There's not plan to deprecate them (they are useful anyways, and deprecating fields in a namedtuple is a bit annoying) so I removed the mention of backcompat.
Member
There was a problem hiding this comment.
Not sure I see the docs back again?
github-project-automation
bot
moved this from Ready for Review
to Done
in Font and text overhaul
Contributor
Author
|
Thanks for the review :) |
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
3 participants
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.
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