Loading textcomp turns LaTeX Info messages into Package textcomp Info messages

[user227621]

Brief outline of the enhancement

If you use a TS1 symbol that is not provided by the current font, you get a LaTeX Info message by default:

\RequirePackage{latexbug}
\documentclass{article}

\begin{document}

\fontfamily{pplx}\selectfont \textrightarrow

\end{document}

LaTeX Info: Symbol \textrightarrow not provided by
            font family pplx in TS1 encoding.
            Default family used instead on input line 6.

However, if you load the package textcomp, you get a Package textcomp Info message instead:

\RequirePackage{latexbug}
\documentclass{article}
\usepackage{textcomp}

\begin{document}

\fontfamily{pplx}\selectfont \textrightarrow

\end{document}

Package textcomp Info: Symbol \textrightarrow not provided by
(textcomp)             font family pplx in TS1 encoding.
(textcomp)             Default family used instead on input line 8.

I find this inconsistent and it does not correspond to the description in LaTeX News 31, which explicitly mentions LaTeX warnings and LaTeX errors:

With the text companion symbols as part of the
kernel, it is normally no longer necessary to load the
textcomp package, but for backwards compatibility this
package will remain available. There is, however, one
use case where it remains useful: if you load the package
with the option error or warn then substitutions will
change their behavior and result in a LaTeX error or a
LaTeX warning (on the terminal), respectively. Without
the package the substitution information only appears
in the .log file. If you use the option quiet, then even
the information in the transcript is suppressed (which is
not really recommended).

As described above, the functionality of the textcomp package has been moved to the LaTeX kernel, so that the processes that generate the messages are now executed by the LaTeX kernel. The package itself is only there to change the status of the messages to "warning" or "error". However, even if the textcomp package is loaded without options (as in the example above), the LaTeX Info messages turn into package textcomp Info messages, as the textcomp code contains \ExecuteOptions{info}.

At least if the package textcomp is loaded without options, the LaTeX Info messages should not turn into Package textcomp Info messages, as the package really does nothing in this case. This often happens in real documents, as many packages still contain \RequirePackage{textcomp} just for compatibility.

[muzimuzhi]

Initially LaTeX defines \tc@errorwarn to use \@latex@info while loading textcomp package would redefine it to use one of \Package(Info|warning|error) or just be quite.

latex2e/base/lttextcomp.dtx

Lines 297 to 306 in 4b00f33

	% To set up the glyphs for the subsets we need a number helpers.
	%
	% \begin{macro}{\tc@errorwarn}
	% To we produce errors, warnings, or only info in the transcripts
	% if glyphs require substitutions? By default it is ``info''
	% only. With the \texttt{textcomp} package that can be changed.
	% \begin{macrocode}
	\def\tc@errorwarn#1#2{\@latex@info{#1}}
	% \end{macrocode}
	% \end{macro}

latex2e/base/lttextcomp.dtx

Lines 1560 to 1571 in 4b00f33

	% The next set of options define the warning level (default in the
	% kernel is info only). Using the package options you can change this behavior.
	% \changes{v2.0n}{2020/02/05}{Changed the package default to info (gh/262)}
	% \begin{macrocode}
	\DeclareOption{error}
	{\gdef\tc@errorwarn{\PackageError{textcomp}}}
	\DeclareOption{warn}
	{\gdef\tc@errorwarn#1#2{\PackageWarning{textcomp}{#1}}}
	\DeclareOption{info}
	{\gdef\tc@errorwarn#1#2{\PackageInfo{textcomp}{#1}}}
	\DeclareOption{quiet}{\gdef\tc@errorwarn#1#2{}}
	% \end{macrocode}

At least if the package textcomp is loaded without options, the LaTeX Info messages should not turn into Package textcomp Info messages, as the package really does nothing in this case.

Except for \ExecuteOptions{info}, loading textcomp package also loads textcomp.cfg if it exists. But I agree with the idea that loading textcomp without options should not change the header of messages.

One choice is to remove \ExecuteOptions{info} so only when textcomp is loaded with explicit package option(s) then the header of messages would change. Considering the obsolete state of textcomp on CTAN, another choice is to replace all uses of \Package(Info|warning|error) with corresponding \@latex@(info|warning|error) in textcomp.sty.

[user227621]

Except for \ExecuteOptions{info}, loading textcomp package also loads textcomp.cfg if it exists.

I wonder if it would be better if textcomp.cfg was not loaded by default if the LaTeX kernel already provides the textcomp functionality, and there was an option to load this file. If \RequirePackage{textcomp} is included in some package just for compatibility and you have a recent LaTeX kernel, loading textcomp.cfg is probably not desirable in general. On the other hand, I don't know how often such a textcomp.cfg actually exists in practice.

Also, I think that the version test at the beginning of textcomp.sty is not really useful:

\providecommand\DeclareRelease[3]{}
\providecommand\DeclareCurrentRelease[2]{}

\DeclareRelease{}{2018-08-11}{textcomp-2018-08-11.sty}
\DeclareCurrentRelease{}{2020-02-02}

If you manage to compile the above textcomp.sty with a very old LaTeX kernel that does not know \DeclareRelease, then the file textcomp-2018-08-11.sty will not be loaded, although you would need it just then. Wouldn't something like the following be better?

\providecommand\IfFormatAtLeastTF{\@ifl@t@r\fmtversion}
\IfFormatAtLeastTF{2020-02-02}{}{\input{textcomp-2018-08-11.sty}\endinput}

\DeclareRelease{}{2018-08-11}{textcomp-2018-08-11.sty}
\DeclareCurrentRelease{}{2020-02-02}

[FrankMittelbach]

loading textcomp is compatibility behavior and that package loaded a .cfg file if it existed. I don't think that should change or get a different logic.

We do a lot of backwards compatibility, but I don't think packages need to account for LaTeX distributions that are very old, ie older than 2015. In such a distribution there is a textcomp that would fit the distribution and that somebody keeps such a distribution but updates individual packages to their 2024 version is in my opinion unsupported. So I'm not really in favor of trying to support that even if the change seems simple. It just adds a sense of availablity that is really not there, and such a mix is bound to fail in other places. So it can't serve as a model for how to do this.

I also think one should keep the errors, warnings, ... as package warnings (if issued by package code). I don't want to see kernel messages there as it gives somebody who just takes a quick look into the package the wrong ideas how such messages should or could be provided in a package.

But I agree with dropping the \ExecuteOptions so that after just loading the package the kernel message style remains.
@muzimuzhi care to make a pull request? Would be appreciated, thanks.

[muzimuzhi]

I also think one should keep the errors, warnings, ... as package warnings (if issued by package code).

In preparing the pull request, I found ltnews31 for release 2020-02 says textcomp options error and warn would change substitution info to kernel error and warning respectively, not package messages.

latex2e/base/doc/ltnews31.tex

Lines 459 to 468 in d694edf

	With the text companion symbols as part of the kernel, it is normally
	no longer necessary to load the \pkg{textcomp} package, but for
	backwards compatibility this package will remain available. There is,
	however, one use case where it remains useful: if you load the package
	with the option \option{error} or \option{warn} then substitutions
	will change their behavior and result in a \LaTeX{} error or a
	\LaTeX{} warning (on the terminal), respectively. Without the package
	the substitution information only appears in the \texttt{.log}
	file. If you use the option \option{quiet}, then even the information in
	the transcript is suppressed (which is not really recommended).

[FrankMittelbach]

I don't think this is a contradition. Yes, it says LaTeX warning and perhaps it should have been precise and said LaTeX package warning, but LaTeX warning is just the generic term in my view, which could be kernel, package or class warnings if not further specified and it is pretty much often used this way in writing.

[user227621]

We do a lot of backwards compatibility, but I don't think packages need to account for LaTeX distributions that are very old, ie older than 2015. In such a distribution there is a textcomp that would fit the distribution and that somebody keeps such a distribution but updates individual packages to their 2024 version is in my opinion unsupported. So I'm not really in favor of trying to support that even if the change seems simple. It just adds a sense of availablity that is really not there, and such a mix is bound to fail in other places. So it can't serve as a model for how to do this.

@FrankMittelbach Wouldn't it then be better to drop the lines

\providecommand\DeclareRelease[3]{}
\providecommand\DeclareCurrentRelease[2]{}

altogether? Rolling back to a date before 2018-08-11 with latexrelease fails with

! LaTeX Error: Suspicious rollback date given.

and if using the new textcomp.sty together with an old LaTeX kernel is (understandably) considered unsupported, then there is no case where these two lines come into effect.

[FrankMittelbach]

You are right that one could drop those provide lines these days, they are there in case you natively run the package in a format that doesn't yet know about latexrelease commands which initially was the right thing to do when these declarations were fairly new. However, in that case you get a low-level error with such an old format.

but regardless of this, I think we should add

\DeclareRelease{}{1997-12-01}{textcomp-2018-08-11.sty}

so that a real rollback to something before 2018 is is not generating this "suspicious" error. after all the package was around even though in a slighlty different version (butthe 2018 version approx that well enough). @muzimuzhi could you perhaps add this to the pr?

[user227621]

You are right that one could drop those provide lines these days, they are there in case you natively run the package in a format that doesn't yet know about latexrelease commands which initially was the right thing to do when these declarations were fairly new. However, in that case you get a low-level error with such an old format.

@FrankMittelbach I think getting the low-level error

! Undefined control sequence.
l.3 \DeclareRelease

is actually preferable in such a case, as you will then quickly find out that it is caused by the LaTeX kernel being too old. If, on the other hand, the file contains

\providecommand\DeclareRelease[3]{}
\providecommand\DeclareCurrentRelease[2]{}

then loading the file with an old kernel that does not know \DeclareRelease will not immediately fail, but then the latest version of the file will be loaded afterwards (instead of an old one), which is unlikely to work and may fail with obscure errors that are not obvious to be caused by the LaTeX kernel being too old.

but regardless of this, I think we should add

\DeclareRelease{}{1997-12-01}{textcomp-2018-08-11.sty}

so that a real rollback to something before 2018 is is not generating this "suspicious" error. after all the package was around even though in a slighlty different version (butthe 2018 version approx that well enough). @muzimuzhi could you perhaps add this to the pr?

The problem that rollback does not work also affects other packages. For example

\RequirePackage[2020-01-01]{latexrelease}
\documentclass{article}
\usepackage{longtable}

\begin{document}

Text

\end{document}

also fails with

! LaTeX Error: Suspicious rollback date given.

although the longtable package existed long before 2020. Does this also need to be fixed?

[FrankMittelbach]

You are right that one could drop those provide lines these days, they are there in case you natively run the package in a format that doesn't yet know about latexrelease commands which initially was the right thing to do when these declarations were fairly new. However, in that case you get a low-level error with such an old format.

@FrankMittelbach I think getting the low-level error

! Undefined control sequence.
l.3 \DeclareRelease

is actually preferable in such a case, as you will then quickly find out that it is caused by the LaTeX kernel being too old.

as I said these days it could be taken out, it was there for the first years after latexrelease was introduced.
And I agree, getting this low-level error is probably more instructive than that rollback error :-) so I guess we should take it out.

but regardless of this, I think we should add

\DeclareRelease{}{1997-12-01}{textcomp-2018-08-11.sty}

so that a real rollback to something before 2018 is is not generating this "suspicious" error. after all the package was around even though in a slighlty different version (butthe 2018 version approx that well enough). @muzimuzhi could you perhaps add this to the pr?

The problem that rollback does not work also affects other packages. For example

\RequirePackage[2020-01-01]{latexrelease}
\documentclass{article}
\usepackage{longtable}

\begin{document}

Text

\end{document}

also fails with

! LaTeX Error: Suspicious rollback date given.

although the longtable package existed long before 2020. Does this also need to be fixed?

perhaps. I don't think it is anything of high importance, but yes we could find out when packages came into existance and try to use that as the first release info to avoid this error. It is a lot of footwork though, so to make this happen I guess we would need some help.

[FrankMittelbach]

.. could be taken out ... (not couldn't)

[muzimuzhi]

@FrankMittelbach Added.

[FrankMittelbach]

We usually keep them open unitl the the code moves from dev to the main release

[car222222]

Not directly relevant, but should this policy on closure be reviewed perhaps?

Pragmatically, it is much easier to close an issue as part of dealing with it and, if necessary scary, adding code to develop:
compared with having to track all the relevant issues at the time of the actual,final release.

(Also, the current policy does seem to cause surprises/confusion for many of us:-).

[FrankMittelbach]

@car222222 maybe it does, maybe it doesn't (for many, as there aren't many people that close or can close issues).
The rationale for doing so is that

• a bug that has been fixed in dev still appears for users as being unfixed
• searching within open bugs will then allow them to more or less easily find that it is already reported
• the label "fixed in dev" and the other info on the issue will then tell them the status, e.g., that it will appear in the next release
• if they have to search through closed bugs as well the then they see 1000+ closed bugs, any of which could be relevant, so it is basically unusable even if you try to use search strings

So from my perspective it is the right approach given that we have delays of up to 6 months until a minor fixed bug is fixed in the main format that people can use.

[user227621]

perhaps. I don't think it is anything of high importance, but yes we could find out when packages came into existance and try to use that as the first release info to avoid this error. It is a lot of footwork though, so to make this happen I guess we would need some help.

@FrankMittelbach Should a new issue be opened for this?

The following files from base, amsmath, graphics and tools contain \DeclareRelease declarations:

doc.sty
amsmath.sty
graphics.sty
array.sty
array-2020-02-10.sty
longtable.sty
multicol.sty
multicol-2019-10-01.sty
showkeys.sty
varioref.sty

These files could be improved by removing the lines

\providecommand\DeclareRelease[3]{}
\providecommand\DeclareCurrentRelease[2]{}

and potentially by adding an additional \DeclareRelease{}{<date>}{<file>} line to support rollback to older dates (this would require finding out when the packages were first released).

[FrankMittelbach]

yes, I think it should be a separate issue, and yes, it would reqiure a bit of detective work to find a reasonable starting point (even though 0000 would probably work well enough for the above, it might be better if we really put in the date when they got first released).

[user227621]

I have opened a new issue: #1336

[davidcarlisle]

this would require finding out when the packages were first released).

they all predate latex2e so could use 0000-00-00 as far as rollback is concerned.
Actually graphics was released slightly after 2e, but I'd still use the zero date

[FrankMittelbach]

not sure about varioref but that could get 0000-00-00 too or perhaps better all could get 1994-06-01 matching the first release of LaTeX 2e

[user227621]

@FrankMittelbach The copyright notice in varioref.sty reads Copyright (C) 1992-2020 Frank Mittelbach, all rights reserved.

[FrankMittelbach]

unbelievable :-) could have sworn I've done that later, so much the better.

[car222222]

'92 fits with my (very flaky) memory of those days!