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

• "closes #0000" is in the body of the PR description tolink the related issue
• new and changed code istested
• Plotting related features are demonstrated in anexample
• New Features andAPI Changes are noted with adirective and release note
• Documentation complies withgeneral anddocstring guidelines