\DeclareErrorFont should not be set in font encoding files

[FrankMittelbach]

This is incorrect. That declaration is system wide and not meant to be used in such places for individual encodings. If one want to define font substitutions use \DeclareFontsubstitution for a particular encoding instead (which can be placed into such files)

There is no point in changing the ErrorFont even if the document is using uncommon encodings. That declaration is only used if something is very much wrong with the whole setup and getting, say, an Thai font when typesetting in an Arabic encoding for which a font is missing, doesn't help.

Problem files on TL

generic/babel-thai/lthenc.def:26:\DeclareErrorFont{LTH}{norasi}{m}{n}{10}
generic/babel-hebrew/lheenc.def:60:\DeclareErrorFont{LHE}{cmr}{m}{n}{10}
generic/babel-hebrew/he8enc.def:60:\DeclareErrorFont{HE8}{cmr}{m}{n}{10} 

Please pass on to the right maintainers if necessary, thanks.

[FrankMittelbach]

One more with babel in its name:

latex/ibycus-babel/lgienc.def:27:\DeclareErrorFont{LGI}{fib}{m}{n}{10} 

[ivankokan]

How about this one: https://ctan.org/tex-archive/language/lithuanian/tex/latex/lithuanian, l7xenc.def?

Background: https://tex.stackexchange.com/questions/394182/l7x-font-encoding-ellipsis-issue

[FrankMittelbach]

As I said: \DeclareErrorFont is a system wide NFSS declaration that shouldn't appear in randomly loaded .def files (or .fd files or anywhere.

[ivankokan]

There are still no changes within the l7xenc.def, although I successfully reached the maintainer in September 2019.

Nevertheless, it is not critical - but I take the opportunity to ask the experts about the policy whether the interventions in CTAN packages (and source code) can be done exclusively by the listed Authors/Maintainers (maybe not the right place to ask).

[Udi-Fogiel]

I have moved the files generic/babel-hebrew/lheenc.def, generic/babel-hebrew/he8enc.def to latex/hebrew-fonts and removed the problematic lines.

[ivankokan]

@FrankMittelbach

There are still no changes within the l7xenc.def, although I successfully reached the maintainer in September 2019.

It seems to be resolved https://www.ctan.org/ctan-ann/id/mailman.4503.1678301186.3715.ctan-ann@ctan.org (in March 2023).

Nevertheless, it is not critical - but I take the opportunity to ask the experts about the policy whether the interventions in CTAN packages (and source code) can be done exclusively by the listed Authors/Maintainers (maybe not the right place to ask).

?

[jbezos]

👍 Perfect. Thanks.

[mrpiggi]

Nevertheless, it is not critical - but I take the opportunity to ask the experts about the policy whether the interventions in CTAN packages (and source code) can be done exclusively by the listed Authors/Maintainers (maybe not the right place to ask).

That's correct. But you should contact the CTAN team as they maybe do have additional contact information from the authors.

[FrankMittelbach]

Nevertheless, it is not critical - but I take the opportunity to ask the experts about the policy whether the interventions in CTAN packages (and source code) can be done exclusively by the listed Authors/Maintainers (maybe not the right place to ask).

?

If a package is licensed under LPPL there is a maintainers clause (unless explicitly disabled) that describes how maintenance can move on under certain situations. But invoking that is a bit of a pain (deliberately). For other licenses CTAN does not normally accept updates from the outside which is understandable but somewhat unfortunate because it results in dead and stale packages that can only be revitalized by providing a new package under a different name.

As suggested by @mrpiggi you might try your luck talking to the CTAN folks directly to see what they suggest in case on an obvious bug like that.