Parse {lua,xe}tex-generated dvi in dviread. #29939
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. |
lib/matplotlib/tests/test_dviread.py
Outdated
| }[engine] | ||
| if shutil.which(cmd[0]) is None: | ||
| pytest.skip(f"{cmd[0]} is not available") | ||
| subprocess.run( |
There was a problem hiding this comment.
Should this use subprocess_run_for_testing?
There was a problem hiding this comment.
I guess tests didn't like that.
There was a problem hiding this comment.
Bah, _subprocess_run_for_testing was missing that kwarg. I think moving towards reproducing the full (typing.pyi) signature of subprocess.run (200 lines starting at https://github.com/python/typeshed/blob/52652635af481013dec895de8272bb987e8ee019/stdlib/subprocess.pyi#L92) into _subprocess_run_for_testing is silly, so I went for a decorator approach (if that looks good to you the idea would be to use it at all call sites later); or we could just make _subprocess_run_for_testing untyped, whatever you prefer.
f8d6ee7 to
b987e24
Compare
(The test uses _ignoring_cygwin_fork_failure rather than adding a new `cwd` kwarg to subprocess_run_for_testing because to avoid going towards reproducing the full signature of subprocess.run.)
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