Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Large amount of warnings when setting font (re-opening closed issue 819) #924

Open
rdtennent opened this issue Aug 18, 2022 · 22 comments
Open

Comments

@rdtennent
Copy link

This issue was closed because a developer denied that it was a tectonic issue. I believe he's mistaken. If I compile a simple test document that uses roboto with xelatex, no Requested font messages are output to the terminal; they go to the log file. So I believe tectonic should elide Requested font messages from the user output.

I'm the maintainer of the roboto package and many other font packages; I've never had any complaints about this and I would think some users depend on \XeTeXtracingfonts.

Bob Tennent

@vlasakm
Copy link
Contributor

vlasakm commented Aug 18, 2022

Linking the mentioned issue: #819

I think that there are two main things here:

  1. TeX's and Tectonic's handling of warnings / diagnostics.

  2. Use of \XeTeXtracingfonts=1.

Tectonic's handling of warnings / diagnostics.

\XeTeXtracingfonts makes XeTeX output a "diagnostic", like most things enabled by tracings. Normally traces are written to log only, unless \tracingonline=1. When any such diagnostic is emitted TeX permanently switches to "warning issued" state. As far as I can see that state is only used for emitting the "see the transcript for additional information" (or "warnings were issued by the TeX engine; use --print and/or --keep-logs for details" in Tectonic). So while tracing is on one hand completely normal, TeX has the notion of it being a kind of warning or something that needs attention.

This is weird in and of itself. But the venerable "Missing character: There is no X in font Y" message is also emitted by the very same tracing mechanism (\tracinglostchars which is enabled by LaTeX) and that definitely is something that should be loud.

Maybe most of tracings shouldn't have calls to diagnostic_begin_capture_warning_here, which from quick glance seems to be what in Tectonic makes these "warnings" (traces) stand out. Consider for example:

\documentclass{article}
\tracingmacros=1
\begin{document}
a
\end{document}

I don't expect any warnings from the above, but as of now each line of tracing output is a warning. But maybe it was intended, since if the user explicitly asks for those messages, they should see them prominently?

As a user of Tectonic I know that I don't get the log file by default, but that's fine because I can still get it and look at the traces. I also think that ignoring \tracingonline=1 (i.e. not outputting tracing to terminal even if explicitly requested) is ok in Tectonic, since it generally doesn't write anything to terminal. E.g.

\documentclass{article}
\begin{document}
a
\message{Hello world}
\end{document}

I expect that the above doesn't write "Hello world" to the terminal and that is also what happens.

Use of \XeTeXtracingfonts=1.

So now I hope that we both agree that maybe Tectonic shouldn't output tracing information to the terminal as warnings.

I personally think that you shouldn't enable any tracing in packages. I as a user would expect that your package is correct and that you used tracings locally to debug it. If I have a problem with it due to my environment I should be the one to enable tracings and look for issues. At the very least restoring the tracing state after your package is done would be nice.

Apart from also slowing down TeX runs, and making for large log files (which wears disks more),. The noisy tracings also generally display information that is of no real use to users (since there are usually no issues), this makes important information stand out less and makes the users ignore all messages equally. AFAICT that is why Tectonic doesn't output log files by default - it most of the time doesn't contain useful information.

All in all I don't see a reason for unconditionally enabling XeTeX font tracing in your packages, especially if it gets burried in logs, but I understand that you can't / don't want to change it due to backwards compatibility.

@rdtennent
Copy link
Author

The following has been suggested to me as a justification for enabling xelatex font tracing by default:

If you compile with lualatex or pdflatex you see in the log at the
end the fonts used with absolute paths, e.g.

c:/texlive/2022/texmf-dist/fonts/opentype/google/roboto/Roboto-Regular.otf
or
c:/texlive/2022/texmf-dist/fonts/type1/public/amsfonts/cm/cmss10.pfb

This info isn't provided by xelatex (as the actual font is included
by xdvipdfmx). With \XeTeXtracingfonts=1 you get a quite sensible
replacement. Debugging font problems with xelatex typically start
with the advice "add \XeTeXtracingfonts=1 and then show the
log-file".

@pkgw
Copy link
Collaborator

pkgw commented Sep 10, 2022

Apologies for being slow in following up here — thanks @vlasakm for giving a nice summary of the situation with Tectonic.

I have to say that, even if @rdtennent hasn't gotten any complaints about it, I really feel quite strongly, like @vlasakm, that it's not a good practice for packages to unconditionally turn on any of the TeX tracing options. They are debugging mechanisms and I think that they should remain off unless the document author is, well, explicitly debugging something. The quoted debugging advice of "add \XeTeXtracingfonts=1 and then show the log-file" seems perfectly fine to me!

That being said, this is basically an aesthetic stance — the main "cost" to turning on tracing in TeX is that there's a some additional output, and traditional TeX emits a lot of output to begin with. I believe this is precisely the reason that Roboto users haven't complained thus far.

@vlasakm is also correct that it's not ideal for Tectonic to surface tracing output as warnings. Doing so was just an expedient way to deal with those outputs, founded on the assumption that they'd only ever be emitted if/when the user intentionally turns them on. It would be more correct to add a separate "trace" output category, which could potentially be handled slightly differently than warnings.

In terms of what's actionable here, @rdtennent, I do continue to encourage you to remove the always-on tracing behavior. But under the assumption that you haven't changed your mind about that, I think probably the most sensible approach for Tectonic would be to turn the XeTeXtracingfonts output into regular output and not report it as a warning.

A slightly more elaborate solution would maybe be to add that "trace" output category and then only surface that output to the user if \tracingonline=1. Granting that I don't feel like I fully understand the semantics of \tracingonline, I think that would be sensible, and prevent the user from being barraged with messages when using roboto in a standard way?

@rdtennent
Copy link
Author

rdtennent commented Sep 10, 2022 via email

@pkgw
Copy link
Collaborator

pkgw commented Sep 10, 2022

Thank you for even considering such an undertaking! Tectonic's users will be grateful.

@Neved4
Copy link

Neved4 commented Oct 28, 2022

Hello @rdtennent, I'm not aware: is this an issue of locating where the macro is or do manual modifications because other code relies on it?

@pkgw @vlasakm interestingly, as of 2022-10-28, TeX Live 2022 has a total of 24 packages that use \XeTeXtracingfonts=1:

$ rg -l '\\XeTeXtracingfonts=1'
./texmf-dist/tex/latex/opensans/opensans.sty
./texmf-dist/tex/latex/xcharter/XCharter.sty
./texmf-dist/tex/latex/firamath-otf/firamath-otf.sty
./texmf-dist/tex/latex/poiretone/PoiretOne.sty
./texmf-dist/tex/latex/heros-otf/heros-otf.sty
./texmf-dist/tex/latex/gillius/gillius.sty
./texmf-dist/tex/latex/gillius/gillius2.sty
./texmf-dist/tex/latex/accanthis/accanthis.sty
./texmf-dist/tex/latex/inter/inter.sty
./texmf-dist/tex/latex/linguisticspro/linguisticspro.sty
./texmf-dist/tex/latex/cochineal/cochineal.sty
./texmf-dist/tex/latex/pagella-otf/pagella-otf.sty
./texmf-dist/tex/latex/schola-otf/schola-otf.sty
./texmf-dist/tex/latex/comfortaa/comfortaa.sty
./texmf-dist/tex/latex/newpx/newpxtext.sty
./texmf-dist/tex/latex/lato/lato.sty
./texmf-dist/tex/latex/libertinus-otf/libertinus-otf.sty
./texmf-dist/tex/latex/newtx/newtxtext.sty
./texmf-dist/tex/latex/cantarell/cantarell.sty
./texmf-dist/tex/latex/termes-otf/termes-otf.sty
./texmf-dist/tex/latex/playfair/PlayfairDisplay.sty
./texmf-dist/tex/latex/droid/droidsansmono.sty
./texmf-dist/tex/latex/droid/droidsans.sty
./texmf-dist/tex/latex/droid/droidserif.sty

@pkgw
Copy link
Collaborator

pkgw commented Oct 28, 2022

@mnrvwl I believe that @rdtennent maintains most of those packages and was talking about changing them upstream.

@rdtennent
Copy link
Author

rdtennent commented Oct 28, 2022 via email

@rdtennent
Copy link
Author

rdtennent commented Oct 28, 2022 via email

@Neved4
Copy link

Neved4 commented Oct 28, 2022

Thanks so much for the undertaking!

You're right, I was reviewing TeX Live sources instead of tectonic's bundle, to see what's ahead of us but the changes should hit tectonic when the bundle is updated.

@rdtennent
Copy link
Author

rdtennent commented Oct 28, 2022 via email

@rdtennent
Copy link
Author

I've sent an e-mail requesting removal of \XeTeXtracingfonts=1 to the following font-package maintainers:

[email protected],
[email protected],
[email protected],
[email protected]

The following are the font packages that require editing:

cantarell
cochineal
comfortaa
droid
firamath-otf
heros-otf
inter
lato
libertinus-otf
newpx
newtx
opensans
pagella-otf
schola-otf
termes-otf
xcharter

Bob T.

@Neved4
Copy link

Neved4 commented Oct 31, 2022

@rdtennent Thx a lot!

I can check this with a ripgrep run in a few months from now, see what the state of things is.

@9SMTM6
Copy link

9SMTM6 commented Nov 11, 2022

@mnrvwl do you know when the bundles typically get updated btw? For now I'm using a manual installation of roboto to avoid this, but would love to switch ASAP, and this could also serve as a test ;-).

Otherwise, these fixes will take some time to trickle downstream to here, but this could probably be closed at some point if you dont want to keep it open until all changes arrived.

@rdtennent
Copy link
Author

rdtennent commented Nov 12, 2022 via email

@Neved4
Copy link

Neved4 commented Nov 13, 2022

@9SMTM6 I'd say at least ~6 months after a new TeX Live official release, so around October 2023.

@rdtennent
Copy link
Author

6 months after an annual release? Seems unreasonably long. Font packages don't have any binary components and are updated continuously at TeXLive; is there some reason why tectonic doesn't update its font packages regularly?

@9SMTM6
Copy link

9SMTM6 commented Nov 14, 2022

I think it's one blob with all packages etc. I don't know precisely what role it fulfills, but in that context it's not entirely difficult to understand.

One could still perhaps make an exception, ultimately I'll live with it though.

@Neved4
Copy link

Neved4 commented Nov 14, 2022

@rdtennent updating the bundles takes a lot, see: tectonic-typesetting/tectonic-staging#17 (comment)

In the past releases we had ⪆ 12 months delay from last TeX Live.
Thanks to recent changes the time span can be reduced, but it still is a lot of manual work.

@rdtennent
Copy link
Author

rdtennent commented Nov 14, 2022 via email

@vlasakm
Copy link
Contributor

vlasakm commented Nov 26, 2022

CC @LuckyTurtleDev

A workaround to silence the warnings is to add the following before the offending font packages are loaded:

\newcount\XeTeXtracingfonts

This makes \XeTeXtracingfonts more or less a dummy that doesn't do anything.

It is of course also possible to do this at the engine level. Though a radical solution and a one that disables the possibility of tracing for everyone, could this be a temporary workaround in Tectonic until fixes in packages propagate? Or could we patch the packages in bundle? Or should we just not go through the "warning code path" for \XeTeXtracingfonts? Or update the bundles more often so that resolving upstream issues like this doesn't take "years"?

@pkgw
Copy link
Collaborator

pkgw commented Jan 24, 2023

FWIW, at this point, I'd be happy to accept PRs to the tectonic-texlive-bundles repo to patch the relevant packages — I want to avoid patches where possible, but in this circumstance it's a small effort for a nice quality-of-life win here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants