Problems with \textasciigrave in textcomp context

[jfbu]

Brief outline of the bug

There are some things I do not understand with handling of \textasciigrave. It seems the glyph at slot 96 is there in the TS1-encoded fonts nevertheless LaTeX complains and falls back to cmr.

This was encountered in a third-party document whose font config I indicate commented out.

I report two cases: with psnfss palation (from mathpazo) and with the zlmtt from eponymous package which provides access in particular to "light" variant of Latin Modern typewriter.

Minimal example showing the bug

\RequirePackage{latexbug}
\documentclass{article}
\usepackage[T1]{fontenc}
\usepackage[warn]{textcomp}

% original real life third-party example has:
% \usepackage[sc,osf]{mathpazo}
% \linespread{1.05}  % see http://www.tug.dk/FontCatalogue/urwpalladio/
% \renewcommand{\sfdefault}{pplj}  % Palatino instead of sans serif
% \IfFileExists{zlmtt.sty}{
%     \usepackage[light,scaled=1.05]{zlmtt}  % light typewriter font from lmodern
% }{
%     \renewcommand{\ttdefault}{lmtt}  % typewriter font from lmodern
% }
% this third party document either has \textasciigrave directly in the
% source or has \usepackage{upquote} and some ` in verbatim style environment
% which is then mapped to \textasciigrave
\begin{document}


% I) with psnfsss (mathpazo) COMPLAINS AND FALLS BACK
\fontfamily{ppl}\fontencoding{T1}\selectfont
\textasciigrave % will try TS1, complain and use \TS1/cmr/m/n/10 `

\fontfamily{ppl}\fontencoding{TS1}\selectfont

% but this does look fine (\TS1/ppl/m/n/10 `)
\char96

% II) with zlmtt originally using eponymous package COMPLAINS AND FALLS BACK

\fontfamily{zlmtt}\fontencoding{T1}\fontseries{l}\selectfont
\textasciigrave % will try TS1, complain and finally use  \TS1/cmtt/m/n/10 `

\fontfamily{zlmtt}\fontencoding{TS1}\fontseries{l}\selectfont

% but this does look fine (\TS1/zlmtt/l/n/10 `)
\char96

% III) with lmtt NO COMPLAINTS (be it with \fontseries{m} or {l})

\fontfamily{lmtt}\fontencoding{T1}\fontseries{m}\selectfont
\textasciigrave % will switch to TS1 and thus give same as next one

\fontfamily{lmtt}\fontencoding{TS1}\fontseries{m}\selectfont
\char96


\thispagestyle{empty}
\showoutput
\end{document}

Log file (required) and possibly PDF file

(commented) extract:

....\TS1/cmr/m/n/10 `
BUT there is this looking fine in PDF
....\TS1/ppl/m/n/10 `

....\TS1/cmr/m/n/10 `
BUT there is this looking fine in PDF
....\TS1/zlmtt/l/n/10 `


....\TS1/lmtt/m/n/10 `

....\TS1/lmtt/m/n/10 `

full log

testtextasciigrave.log

EDIT: this may be a duplicate of #478

It seems once a year I raise the same issue (because I am hit again by it... when looking at LaTeX aspects in some other people projects).

[FrankMittelbach]

Unfortunately there are nearly as many TS1-subencodings around as there are fonts available for TeX. Thus textcomp (and nowadays the kernel) has divided them into 9 subsets with decreasing number of glyphs supported. However, some fonts do not fit into any these categories and in that case textcomp errs on the side of caution and pretends that a font is only supporting the subset which is fully available.

• \textasciigrave is in subset 0 and 1 but ppl is subset 5.
• zlmtt is not known on the kernel level so it gets the cautious subset 9

You can define the right default for zlmtt and you can pretend that ppl is better than it is, but then you get missing glyphs (or rather square blobs of ink probably) for other characters

\DeclareEncodingSubset{TS1}{zlmtt}{1}     % I guess (or even 0) but I haven't checked
\DeclareEncodingSubset{TS1}{ppl}{1}        % definitely not what the font suports but contains asciigrave

The relevant textcomp commands are documented in fntguide including in which glyph is available in which subencoding.

None of this is really a bug in LaTeX font handling but a rather unfortunate mess in the way TS1 came about and how it is supported by different fonts. So I'm closing this.

To find out which font family has which subencoding use \UseName{TS1:ppl} (there is no interface for this --- or look at source2e.

[jfbu]

Thanks @FrankMittelbach for your detailed informative answer and sorry for (almost) duplicate (the zlmtt was a bit new). In the meantime I had become aware of the relevant ltnews33 entry and read the #478 thread. I think the \textasciigrave is particularly bound to happen often due to upquote+verbatim combination.

[jfbu]

I will gently ping the maintainer of zlmtt about this.

[FrankMittelbach]

In general, I think font packages should set the TS1 subencoding that they support. The fact that the LaTeX kernel has a core set already defined doesn't mean it makes sense for the kernel to try and define that for each and every font.

However, looking the code over I will reopen this pr because, \DeclareEncodingSubset should be usable in the corresponding .fd file, which right now it isn't reliably (because the definition is not made globally, but the fd file might be loaded in a group).

[FrankMittelbach]

In the meantime I had become aware of the relevant ltnews33 entry and read the #478 thread. I think the \textasciigrave is particularly bound to happen often due to upquote+verbatim combination.

ok, so we both forgot that you came across this font issue before and I gave a lenthy answer back then why it is as it is (let's hope you and I remember next time and you aren't opening up another pr for another font. In general font issues are not latex bugs even if latexbug is not detecting that you use fonts outside core LaTeX ones.

it is true that this may come up with people using more fonts and upquote is getting at the TS1 glyph, but as I said before that part is not somehting LaTeX can fix, because you can't mechanically test if the glyph (even if there is one) is actually the right one.

As I said, I keep this pr open to make \DeclareEncodingSubset gets enhanced that it can be correctly used in .fd files but that's all that can be done from a general LaTeX point of view.

[jfbu]

For the record, I encountered again this problem with mlmodern (at least with its typewriter mlmtt font).