[latex3-commits] [git/LaTeX3-latex3-latex2e] ltnew33: Merge branch 'ltnew33' of git at github.com:latex3/latex2e.git (9ec7cec8)

Chris Rowley car222222 at github.github.io
Mon May 17 12:59:40 CEST 2021


Repository : https://github.com/latex3/latex2e
On branch  : ltnew33
Link       : https://github.com/latex3/latex2e/commit/9ec7cec8e4548c3cc17f7df31d434a5c804d97ee

>---------------------------------------------------------------

commit 9ec7cec8e4548c3cc17f7df31d434a5c804d97ee
Merge: 6b38d844 3edec635
Author: Chris Rowley <car222222 at users.noreply.github.com>
Date:   Mon May 17 17:59:40 2021 +0700

    Merge branch 'ltnew33' of git at github.com:latex3/latex2e.git


>---------------------------------------------------------------

9ec7cec8e4548c3cc17f7df31d434a5c804d97ee
 base/doc/ltnews33.tex | 76 ++++++++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 75 insertions(+), 1 deletion(-)

diff --cc base/doc/ltnews33.tex
index cf20e29f,78d04140..7f0aaaf0
--- a/base/doc/ltnews33.tex
+++ b/base/doc/ltnews33.tex
@@@ -326,12 -346,10 +326,12 @@@ and uses \file{mychap.aux}
  The handling of file names has been modified so that \verb|\string| is
  applied to normalize robust commands within the file name.
  Previously, for example, \verb|\input{\sqrt{2}}| would cause
- \LaTeX\ to loop indefinitely whereas with with the new normalization
+ \LaTeX\ to loop indefinitely whereas with the new normalization
  it looks for the file named \verb|sqrt {2}.tex|
 -%%FMi
 -(and reports a file not found failure instead).
 +%%FMi  (and reports a file not found failure instead).
 +%%CCC : 
 +(and therefore very likely reports ‘file not found’).
 +
  %
  \githubissue{481}
  
@@@ -446,9 -477,85 +446,83 @@@ certainly better than no glyph showing 
  \githubissue{502}
  
  
+ \subsection{A note on the \texttt{TS1} encoding}
+ 
+ The \enquote{text symbol encoding} (\texttt{TS1}) was originally
+ designed at the Cork Conference as a companion to the \texttt{T1}
+ encoding. In it various symbols that are not subject to hyphenation
+ got assembled and the \pkg{textcomp} package was developed to make
+ them accessible. Unfortunately the \TeX{} community was a bit too
+ enthusiastic and included several symbols only available in a few
+ \TeX{} fonts and some, such as the capital accents, not available at
+ all but developed as part of the reference font implementation.
+ 
+ In hindsight that was a very bad idea because it meant that other
+ existing fonts (at the time) and later new fonts that got developed
+ were unable to provide the full set of glyphs that made up the
+ \texttt{TS1} encoding. For existing free PostScript fonts people to
+ the extra effort and produced virtual fonts that faked (some) of
+ the missing glyphs. But this was and is a time consuming effort so it
+ was done only for a few basic fonts. But even then, only some fonts
+ included all glyphs from \texttt{TS1} so the \pkg{textcomp} already
+ back then contained a long list, dividing fonts into 5 categories
+ according to which glyphs were implemented and which were missing.
+ 
+ A couple of releases back the functionality of the \pkg{textcomp}
+ package got integrated into the core code of the \LaTeX{} kernel so
+ that its glyph definitions, e.g., \cs{textcopyright}, \cs{texteuro} or
+ \cs{textyen}, are now automatically available without the need to load
+ an additional package in the preamble.
+ 
+ At the time this happened many new free fonts had appeared and
+ unfortunately the chaos around the question \enquote{which glyphs of
+   the \texttt{TS1} encoding are implemented by which font} had
+ increased with it. Not only did one find many new holes it was next to
+ impossible to order the set of fonts into a reasonable set of
+ sub-encodings that are contained in each other in a single sequence.
+ 
+ In the end we decided on nine or ten sub-encodings with a reasonable
+ number of font in each so that all font implemented all glyphs of the
+ sub-encoding they got mapped to. Thus when typesetting with a font one
+ could be sure that a command like \cs{textcopyleft} would either
+ typeset the requested character (if the glyph was part of the
+ sub-encoding the font belonged to) or it would raise an error, saying
+ that the glyph is unavailable in that fact. The mapping would ensure
+ that \LaTeX{} always errs on the side of caution, because it might
+ claim a glyph is unavailable even though in fact it is.
+ 
+ For example, the old \texttt{pcr} (PostScript Courier) font (as well
+ as most other older PS fonts) is mapped to sub-encoding 5 and
+ therefore claims that \cs{textasciigrave} is unavailable even though
+ in fact for Courier this is not true. If one uses such a font and this
+ becomes an issue then there are a couple (suboptimal) possibilities.
+ For one, one can alter the mapping of Courier and pretend that belongs
+ to a fuller sub-encoding, e.g.
+ \begin{verbatim}
+   \DeclareEncodingSubset{TS1}{pcr}{2}
+ \end{verbatim}
+ The downside is, that \LaTeX{} then believes other glyphs that are in fact
+ unavailable are also there, so that it is important to check that the
+ final document doesn't have some missing glyphs.
+ 
+ An alternative is to pretend that \cs{textasciigrave} can always be
+ taken from the \texttt{TS1} encoding (no questions asked):
+ \begin{verbatim}
+   \DeclareTextSymbolDefault{\textasciigrave}{TS1}
+ \end{verbatim}
+ Again there is a danger that this is not true when it is used with a
+ different font and would then generate a missing glyph.
+ 
+ Finally, and possibly the best solution, if not impossible for other
+ reasons, is to simply use a different font, for example, to use the
+ \TeX{} Gyre Cursor font (a reimplementation of Courier but with a
+ much more complete glyph set).
+ 
+ 
+ 
  
 -
  \section{New or improved commands}
  
 -
  \subsection{Adjusting \env{itemize} labels with \cs{labelitemfont}}
  
  The command \cs{labelitemfont} was introduced already with the





More information about the latex3-commits mailing list.