Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

anntzer
Copy link
Contributor

@anntzer anntzer commented Mar 25, 2025

Currently, this PR is mostly a proof of concept; it only implements the
dvi generation and parsing parts, but does not implement rendering in
any of the builtin backends, except svg (under rcParams["svg.fonttype"]
= "none", the default). However, there is a companion branch on the
mplcairo repository, also named "luadvi", which implements support.

Example (requiring both this PR, and mplcairo installed from its luadvi
branch; or try saving to svg with the builtin svg backend):

import matplotlib as mpl; mpl.use("module://mplcairo.qt")
from matplotlib import pyplot as plt

plt.rcParams["text.latex.engine"] = "lualatex"  # or "xelatex"
plt.rcParams["text.latex.preamble"] = (
    # {lua,xe}tex can use any font installed on the system, spec'd using its
    # "normal" name.  Try e.g. DejaVu Sans instead.
    r"\usepackage{fontspec}\setmainfont{TeX Gyre Pagella}")
plt.figtext(.5, .5, r"\textrm{gff\textwon}", usetex=True)
plt.show()

TODO:

  • Fix many likely remaining bugs.
  • Rework font selection in texmanager, which is currently very ad-hoc
    due to the limited number of fonts supported by latex.
  • Implement rendering support in the (other) builtin backends. In
    particular, the Agg (and, if we care, cairo) backend will require
    significant reworking because dvipng, currently used to rasterize dvi
    to png, doesn't support luatex-generated dvi; instead we will need to
    proceed as with the other backends, reading the glyphs one at a time
    from the dvi file and rasterizing them one at a time to the output
    buffer. Working on the other backends is not very high on my priority
    list (as I already have mplcairo as playground...) so it would be nice
    if others showed some interest for it :-)

See #20262, #22715, #28131.

PR summary

PR checklist

@anntzer anntzer changed the title Support luatex as alternative usetex engine. Support {lua,xe}tex as alternative usetex engine. Mar 26, 2025
@anntzer anntzer force-pushed the luadvi branch 2 times, most recently from 4d488f4 to 697d106 Compare March 26, 2025 23:42
@anntzer anntzer force-pushed the luadvi branch 3 times, most recently from ff9ecdd to 4f93376 Compare March 27, 2025 22:39
@anntzer anntzer force-pushed the luadvi branch 2 times, most recently from 85a73b8 to f1b16f2 Compare March 28, 2025 10:48
@anntzer anntzer force-pushed the luadvi branch 2 times, most recently from c134a34 to ccf927c Compare March 30, 2025 13:49
Currently, this PR is mostly a proof of concept; only the svg backend
is supported (under rcParams["svg.fonttype"] = "none", the default).
However, there is a companion branch on the mplcairo repository, also
named "luadvi", which implements support for all output formats.

Example (requiring both this PR, and mplcairo installed from its luadvi
branch):
```
import matplotlib as mpl; mpl.use("module://mplcairo.qt")
from matplotlib import pyplot as plt

plt.rcParams["text.latex.engine"] = "lualatex"  # or "xelatex"
plt.rcParams["text.latex.preamble"] = (
    # {lua,xe}tex can use any font installed on the system, spec'd using its
    # "normal" name.  Try e.g. DejaVu Sans instead.
    r"\usepackage{fontspec}\setmainfont{TeX Gyre Pagella}")
plt.figtext(.5, .5, r"\textrm{gff\textwon}", usetex=True)
plt.show()
```
Font effects are supported by mplcairo, e.g.
`\fontspec{DejaVu Sans}[FakeSlant=0.2] abc`.

TODO:

- Fix many likely remaining bugs.
- Rework font selection in texmanager, which is currently very ad-hoc
  due to the limited number of fonts supported by latex.
- Implement rendering support in the (other) builtin backends.  In
  particular, the Agg (and, if we care, cairo) backend will require
  significant reworking because dvipng, currently used to rasterize dvi
  to png, doesn't support luatex-generated dvi; instead we will need to
  proceed as with the other backends, reading the glyphs one at a time
  from the dvi file and rasterizing them one at a time to the output
  buffer.  Working on the other backends is not very high on my priority
  list (as I already have mplcairo as playground...) so it would be nice
  if others showed some interest for it :-)
r"\usepackage[utf8]{inputenc}",
r"\DeclareUnicodeCharacter{2212}{\ensuremath{-}}",
font_preamble,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Moving this would be a behaviour change, wouldn't it? I don't recall which usepackage wins though. Also, do we not want to allow a preamble for other engines?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think moving the font preamble after inputenc & DeclareUnicodeCharacter would really make a difference for latex, and there's no behaviour change for xe/lualatex as these weren't supported before.

However, it is correct that there's a bit of behavior design that needs to be decided here, which is what is the default font for xe/lualatex? Right now the behavior for latex is: pick one of the few supported fonts (PSNFSS) that more or less matches the rcParams settings, defaulting to computer modern serif (as the default rcParam, DejaVu Sans, is not supported). Note that the Text object's FontProperties is not used (except for the fontsize).

For xel/lualatex, right now this PR does the same thing, and we could very well just document "set rcParams["text.latex.preamble"] = r"\usepackage{fontspec}\setmainfont{...}" to pick whatever font with xe/lualatex". Alternatively, a perhaps better option would be to actually use the Text object's FontProperties (which would need to be threaded down to TexManager, but that seems likely doable) and draw text using the standardly configured font (similarly to rcParams["pgf.rcfonts"] = True for the pgf backend). In that case, usetex with xe/lualatex would not use computer modern, unless the Text's FontProperties say so.

My preference would definitely be for the latter case (just use whatever fonts are configured using the normal mechanism), but I deferred this discussion (and implementation) until the preliminary parts of the work (dvi parsing) got in. Thoughts?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Waiting for other PR
Development

Successfully merging this pull request may close these issues.

2 participants