Rasterize dvi files without dvipng. #30039
Conversation
What is the consequence of not doing that? Font output depending on installed FreeType version? It seems like the bonding boxes are a bit off in the new one? The top part of
|
But in most cases, the "new" bounding boxes look "better"! |
It would, although I don't think this is really a problem (there's just 3 usetex baseline images which would now need to get the same treatment as all other baseline images with text, so that only very slightly makes things worse in that aspect). The main reason to keep the old path would be for strict backcompat if anyone really cares. Also, there's the somewhat obscure case of #20469, where dvipng was providing extra support for an otherwise unsupported font type, but this was already broken for other output formats anyways, and if/when we merge {xe,lua}tex support, users will be able to use TrueType versions of the concrete math font which will just work everywhere. (Plus, if someone wants to implement pk font support per #20469 (comment), that's still an option.)
I did notice that, probably needs a more careful investigation. But I also suspect this may be related to how exactly we draw the bbox (which itself has nonzero thickness). Even if we arrange for it to have exactly 1-px width, we'd probably want it to be drawn immediately outside the outermost inked pixels, which means that the height/width would likely be 1-px bigger than the text extents, and I don't think we do any of that...
Deprecating a rcParam is a bit annoying, hence the suggestion to fold into text.latex.engine. |
Shall we target the |
|
Sure, that works too. |
| .def("_draw_glyph_at", &PyFT2Font__draw_glyph_at, | ||
| "image"_a, "x"_a, "y"_a, "glyph"_a, py::kw_only(), "antialiased"_a=true, | ||
| PyFT2Font__draw_glyph_at__doc__) |
There was a problem hiding this comment.
How does this correlate with #30059?
There was a problem hiding this comment.
This is indeed redundant with the _render_glyph method of #30059; when both PRs are in I'll rewrite this in terms of the #30059 API.
However #30059 seems a bit further away from merging, both because of the API design choices at #30059 (comment), and because of the maybe-off-by-1 positioning issues mentioned at #30059 (comment) (actually I haven't revisited that at all since then, so that may need a bit of re-checking). So if this goes in first I think _draw_glyph_at is fine as temporary API.
This patch drops the reliance on dvipng to rasterize dvi files prior to
inclusion by agg, instead performing the rasterization ourselves (as a
consequence, the rasterization output also becomes dependent of the
freetype version used). Note that this approach will be needed anyways
to support xetex and luatex, as dvipng doesn't support dvi files
generated by these engines.
Baseline images change slightly, for the better or the worse. The
top-left blue cross text in test_rotation.py ("Myrt0") seems to be
better top-aligned against the blue line (the old version overshot a
bit); the bounding box of the formulas in test_usetex.py seems a bit
worse.
|
I have regenerated the baselines and split them into a separate commit. |
This patch drops the reliance on dvipng to rasterize dvi files prior to inclusion by agg, instead performing the rasterization ourselves (as a consequence, the rasterization output also becomes dependent of the freetype version used). Note that this approach will be needed anyways to support xetex and luatex, as dvipng doesn't support dvi files generated by these engines.
Baseline images change slightly, for the better or the worse. The top-left blue cross text in test_rotation.py ("Myrt0") seems to be better top-aligned against the blue line (the old version overshot a bit); the bounding box of the formulas in test_usetex.py seems a bit worse.
Small API point that needs to be discussed: do we want to keep the old dvipng-based codepath? (likely, at least temporarily) If so, what kind of switch do we want to expose to the end-user? I would suggest already looking forward to the future support for xetex/luatex which would likely be implemented using
rcParams["text.latex.engine"] = {"latex", "xelatex", "lualatex"}and further add a possible "latex+dvipng" value in there, which would correspond to the old default; "latex" would be the dvipng-less codepath; both "latex" and "latex+dvipng" would behave the same for backends other than agg. (Also note that if we decide later to remove that dvipng codepath, it is easier to deprecate an allowable value from a rcParams entry than to completely deprecate an entry.)I will either implement the switch or strip out the dvipng code, and write the corresponding docs, depending on the decision above.
PR summary
PR checklist