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

warning for latex-provided ts1? #1518

Open
kberry opened this issue Oct 30, 2024 · 10 comments
Open

warning for latex-provided ts1? #1518

kberry opened this issue Oct 30, 2024 · 10 comments

Comments

@kberry
Copy link

kberry commented Oct 30, 2024

I was looking at ltnews39 and was reminded of the need for font package maintainers to provide TS1 subset declarations. If that's started happening, fine. But if not (as I suspect), I wondered about having LaTeX emit a warning ("tell the font maintainer to update their package") when its subset declaration is used.

Just an idea. If this is already being done, sorry. I couldn't easily check right now.

@FrankMittelbach
Copy link
Member

To be honest I think it would perhaps better if we do collect the email addresses of the dozen or less people that produce font packages and write to them privately and ask them to please make that update (which is not that difficult I would say, given that there is the code to generate the right setting for you). Putting such warnings it each an every log file means a) a lot of noise for all users and b) it is actually not that easy to determine when it would be appropriate: the default may as well be the correct value c) I doubt that much is reaching the maintainers this way.

It essentially just requires getting the right email addresses (or perhaps the github accounts and assign them here) ... once that happened I'm happy write that email.

Any takers for the collection part? If not I may do it at some point myself, but right now I don't have the bandwidth.

@mbertucci47
Copy link
Contributor

mbertucci47 commented Oct 30, 2024

Had a moment so figured I'd write down those I could think of.

@kberry
Copy link
Author

kberry commented Oct 30, 2024 via email

@cfr42
Copy link
Contributor

cfr42 commented Oct 31, 2024

Some package authors do provide declarations, but they typically seem to be in .sty files.

Packages I'm responsible have declarations in the various .sty files1. For various reasons, I'm not going to put them into .fds unless somebody convinces me the advantages outweigh the disadvantages. For the record, I discussed this with two members of the LaTeX Project, but I'm not currently persuaded.

Hirwen Harendal ... https://ctan.org/author/harendal

Hirwen Harendal is not responsible for the LaTeX support, but for the fonts. This is explained in the packages' documentation, so that name shouldn't be on your list.

gentium-tug doesn't include declarations, but the default is recommended, so they would only be necessary if there's some reason to include them even in that case2.

To be honest I think it would perhaps better if we do collect the email addresses of the dozen or less people that produce font packages and write to them privately and ask them to please make that update (which is not that difficult I would say, given that there is the code to generate the right setting for you).

Note that tools which auto-generate .fd files don't typically support adding the declarations, so it is not necessarily the best place for them from a maintenance perspective. Almost all the .fd files I make are auto-generated by fontinst. (berenisadf is the exception.) Experience suggests that anything which requires me to remember to change an auto-generated file prior to upload is likely to result in erroneous uploads3.

There is also the question of what to then do with the result the test gives you, which is not so obvious, imho.

1Very few (probably none) are 'correct' according to the test. This is one reason I don't want them in the .fd files. Another is that there's no way to say 'use whatever declaration FM uses for font X for font Y'. Admittedly, there's probably not great demand for such a feature.
2Testing gentium-tug was how I discovered the typo in the test file.
3This isn't my reason for not putting them in the .fd files as fontinst.lua can already add variable scaling factors, which fontinst doesn't support either.

@car222222
Copy link
Contributor

Many thanks, Clea, for all this e tra information: very useful.

@cfr42
Copy link
Contributor

cfr42 commented Oct 31, 2024

grep -l DeclareEncodingSubset tex/latex/*/*.sty tex/latex/*/*.fd > /tmp/ts1-decs

on a very recently updated TeX Live produces:

tex/latex/algolrevived/algolrevived.sty
tex/latex/baskervaldadf/baskervald.sty
tex/latex/berenisadf/berenis.sty
tex/latex/cfr-lm/cfr-lm.sty
tex/latex/chivo/Chivo.sty
tex/latex/cochineal/cochineal.sty
tex/latex/electrumadf/electrum.sty
tex/latex/erewhon/erewhon.sty
tex/latex/gfsdidot/gfsdidot.sty
tex/latex/libris/libris.sty
tex/latex/newpx/newpxtext.sty
tex/latex/newtx/newtxtext.sty
tex/latex/newtxtt/newtxtt.sty
tex/latex/romandeadf/romande.sty
tex/latex/scholax/scholax.sty
tex/latex/tudscr/tudscrfonts.sty
tex/latex/venturisadf/venturis.sty
tex/latex/venturisadf/venturis2.sty
tex/latex/venturisadf/venturisold.sty
tex/latex/xcharter/XCharter.sty
tex/latex/ysabeau/ysabeau.sty
tex/latex/zlmtt/zlmtt.sty

[I removed results for base.]

@cfr42
Copy link
Contributor

cfr42 commented Oct 31, 2024

Note that I initially put them in the .sty files because I copied what I found in 2e's sources. Just as I put scaling factors in the .fd files because I copied from psnfss (as it says in my source code, I think).

So I don't think it should be surprising that authors who've done this have used .sty files rather than .fds. To avoid that, I think you'd at least need comments in base .sty files and sources2e clearly recommending people not to put the lines in .stys. If I'm updating a font package, I'm much more likely to be reading your source code than I am ltnews.

@FrankMittelbach
Copy link
Member

Packages I'm responsible have declarations in the various .sty files1. For various reasons, I'm not going to put them into .fds unless somebody convinces me the advantages outweigh the disadvantages. For the record, I discussed this with two members of the LaTeX Project, but I'm not currently persuaded.

well, the main reason is that it is technically the place where it belongs, meaning in many cases you can use fonts without an additional .sty support file, e.g., by just doing \fontfamily{family}\selectfont in which case LaTeX would load the necessary .fd files but nothing else.

Note that tools which auto-generate .fd files don't typically support adding the declarations, so it is not necessarily the best place for them from a maintenance perspective. Almost all the .fd files I make are auto-generated by fontinst. (berenisadf is the exception.) Experience suggests that anything which requires me to remember to change an auto-generated file prior to upload is likely to result in erroneous uploads.

Are you using the original fontinst of the tool my Marc?

In either case, I agree with you that it would be best to have that automated as part of the autogeneration of the .fd files.
But that could, I would think, done by passing the generated fd through a script that appends the right declaration to the file at the end.

There is also the question of what to then do with the result the test gives you, which is not so obvious, imho.

I'm sure, the script and documentation could be improved, but what exactly do you find difficult or non-obvious from, say, the output

TS1 encoding subset for Cochineal-TLF (ok)
Use sub-encoding 5\relax 

It could spit out the full declaration line, which is probably better, but otherwise?

@FrankMittelbach
Copy link
Member

FrankMittelbach commented Oct 31, 2024

Note that I initially put them in the .sty files because I copied what I found in 2e's sources. Just as I put scaling factors in the .fd files because I copied from psnfss (as it says in my source code, I think).

So I don't think it should be surprising that authors who've done this have used .sty files rather than .fds. To avoid that, I think you'd at least need comments in base .sty files and sources2e clearly recommending people not to put the lines in .stys. If I'm updating a font package, I'm much more likely to be reading your source code than I am ltnews.

It is always a bit difficult to figure out where people are going to look and how much you therefore should duplicate in the documentation.

fntguide.pdf that contains the full description of what should go into an .fd file say

Maintainers of font bundles that include TS1 encoded font files should add an appropriate declaration 
into the corresponding ts1family.fd file, because otherwise the default subencoding is assumed, which is 
probably disabling too many glyphs that are actually available in the font.

but yes perhaps it could be extended and explicitly say that this is the right place and not a .sty file, because the font could be used without that .sty file.

I don't think the 2e sources use that declaration anywhere in a sty file, if we do it is a mistake.

@davidcarlisle
Copy link
Member

I don't think the 2e sources use that declaration anywhere in a sty file, if we do it is a mistake.

the only place we use it is in textcomp.sty (it's not in the ts1 fd files in base) in fact in texlive tex/latex area I only see it in packages

$ grep -l 'DeclareEncodingSubset{TS1}' */*{sty,fd}
algolrevived/algolrevived.sty
base/latexrelease.sty
base/textcomp-2018-08-11.sty
base/textcomp.sty
baskervaldadf/baskervald.sty
berenisadf/berenis.sty
cfr-lm/cfr-lm.sty
chivo/Chivo.sty
cochineal/cochineal.sty
electrumadf/electrum.sty
erewhon/erewhon.sty
gfsdidot/gfsdidot.sty
libris/libris.sty
newpx/newpxtext.sty
newtx/newtxtext.sty
newtxtt/newtxtt.sty
romandeadf/romande.sty
scholax/scholax.sty
tudscr/tudscrfonts.sty
venturisadf/venturis.sty
venturisadf/venturis2.sty
venturisadf/venturisold.sty
xcharter/XCharter.sty
ysabeau/ysabeau.sty
zlmtt/zlmtt.sty

so while I agree with the argument that it's better to be in the fd files to allow direct use of the font, the current situation is rather different

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

No branches or pull requests

6 participants