[latex3-commits] [git/LaTeX3-latex3-latex2e] develop: edits by Chris with some changes by me (704ba01b)
Frank Mittelbach
frank.mittelbach at latex-project.org
Thu Jan 23 18:37:35 CET 2020
Repository : https://github.com/latex3/latex2e
On branch : develop
Link : https://github.com/latex3/latex2e/commit/704ba01bf1397edf82e557e650c3b23ae6c9d70c
>---------------------------------------------------------------
commit 704ba01bf1397edf82e557e650c3b23ae6c9d70c
Author: Frank Mittelbach <frank.mittelbach at latex-project.org>
Date: Thu Jan 23 18:37:35 2020 +0100
edits by Chris with some changes by me
>---------------------------------------------------------------
704ba01bf1397edf82e557e650c3b23ae6c9d70c
base/doc/ltnews31.tex | 413 ++++++++++++++++++++++++++------------------------
1 file changed, 217 insertions(+), 196 deletions(-)
diff --git a/base/doc/ltnews31.tex b/base/doc/ltnews31.tex
index 55efd42a..31ea9d03 100644
--- a/base/doc/ltnews31.tex
+++ b/base/doc/ltnews31.tex
@@ -132,15 +132,15 @@
\medskip
-\section{Introduction}
-
-This document is under construction \ldots
+%\section{Introduction}
+%
+%This document is under construction \ldots
-\section{Experiences with the \LaTeX-dev formats}
+\section{Experiences with the \LaTeX\ \texttt{-dev} formats}
As reported in the previous \emph{\LaTeX{} News}, we have made a pre-release
-version of the \LaTeX{} kernel available as \LaTeX-dev. Overall, the
+version of the \LaTeX{} kernel available as \LaTeX\texttt{-dev}. Overall, the
approach of having an explicit testing release has been positive: it is now
readily available in \TeX{} systems and is getting real use beyond the team.
@@ -149,19 +149,21 @@ release has been tested by a number of users, and we have had useful feedback
on a range of new ideas. This has allowed us to fix issues in several of the
new features described below. We thank the dedicated users who have been
trying out the development formats, and encourage others to do so. Pre-testing
-in this way does mean that for the vast majority of users, problems are solved
+in this way does mean that, for the vast majority of users problems are solved
before they even appear!
-\section{Concerning this pre-release \ldots}
+
+\section{Concerning this release \ldots (Lua\LaTeX{} engine)}
In \TeX{}Live 2020 the Lua\LaTeX{} format will use the new LuaHB\TeX{}
engine, which is Lua\TeX{} with an embedded HarfBuzz library.
HarfBuzz can be used by setting a suitable renderer in the font
declaration. A basic interface for that is provided by \pkg{fontspec}.
This additional font renderer will greatly improve the shaping of
-various scripts which are currently handled correctly only by
-\XeTeX{}. To simplify the testing of the new engine, binaries have
-been already added to MiK\TeX{} and \TeX{}Live 2019 and both have changed
+various scripts when using Lua\LaTeX{}, many of which are currently handled correctly only by
+\XeTeX{} which is always using HarfBuzz.
+To simplify testing of the new engine, binaries have
+already been added to MiK\TeX{} and \TeX{}Live 2019 and both have already now changed
the Lua\LaTeX-dev format to use it.
@@ -176,45 +178,43 @@ interfaces in cases where no \pkg{expl3} code is \enquote{visible}. In addition,
which is written using \pkg{expl3}.
The \pkg{expl3} layer contains a non-trivial number of macros, and when used
-with the \XeTeX{} and \LuaTeX{} engines, it loads a large body of Unicode data.
-This means that even on a fast computer, there is a relatively large load time for
+with the \XeTeX{} and \LuaTeX{} engines, it also loads a large body of Unicode data.
+This means that even on a fast computer, there is a relatively large load time when
using \pkg{expl3}.
For this release, the team have made adjustments in the \LaTeXe{} kernel to
-pre-load a significant portion of \pkg{expl3} as the format is built. This is
-transparent at the user level, other than the significant decrease in document
-processing time: there will be no \enquote{pause} for loading Unicode data
-files. Loading of \pkg{expl3} in documents and packages can be done as usual;
+pre-load a significant portion of \pkg{expl3} when the format is built. This is
+transparent to the user, other than the significant decrease in document
+processing time: there will be no \enquote{pause} whilst loading the Unicode data
+files. Loading \pkg{expl3} in documents and packages can continue to be done as usual;
eventually, it will be possible to omit
\begin{verbatim}
\RequirePackage{expl3}
\end{verbatim}
-entirely, but to support older formats, this is still recommended at present.
-
-
-
-
+entirely but, to support older formats, this is still recommended at present.
\section[Improvements to \LaTeX{}'s font selection\\ mechanism (NFSS)]
{Improvements to \LaTeX{}'s font selection\\ mechanism (NFSS)}
-\subsection{Extending the shape management of NFSS}
+\subsection{Extending the shape management in NFSS}
-Over time more and more fonts have become available for use with
-\LaTeX{}. Many such font families offer additional shapes, e.g., small
-caps italics (\texttt{scit}), small caps slanted (\texttt{scsl}) or
-swash letters (\texttt{sw}). By using \cs{fontshape} those shapes can
-be explicitly selected and for the swash letter shapes there is also
+Over time, more and more fonts have become available for use with
+\LaTeX{}. Many such font families offer additional shapes such as small
+caps italic
+(\texttt{scit}), small caps slanted (\texttt{scsl}) or
+swash (\texttt{sw}).
+By using \cs{fontshape} those shapes can
+be explicitly selected. For the swash shapes there is also
\cs{swshape} and \cs{textsw} available.
In the original font selection implementation a request to select a new shape
always overrode the current shape. With the 2020 release of \LaTeX{}
this has changed and \cs{fontshape} can now be used to combine small
-capitals with italics, slanted or swash letters, either by explicitly
+capitals with italic, slanted or swash letters, either by explicitly
asking for \texttt{scit}, etc., or by asking for italics when typesetting
-already in small caps and so forth.
+already in small caps, and so forth.
Using \cs{upshape} will still change italics or slanted back to an
upright shape but will not any longer alter the small caps setting. To
@@ -226,103 +226,103 @@ There is one exception: for compatibility reasons \cs{upshape} will
change small capitals back to upright (\texttt{n} shape), if the
current shape is \texttt{sc}. This is done so that something like
\cs{scshape}\allowbreak\texttt{...}\allowbreak\cs{upshape} continues
-to work, but we suggest that you don't use that deprecated method in
+to work as before, but we suggest that you don't use that deprecated method in
new documents.
+
Finally, if you want to
reset the shape back to normal you can use \cs{normalshape} which is a
shorthand for \cs{upshape}\cs{ulcshape}.
-The way that shapes combine with each other is not hardwired but is
-customizable and extensible if there is ever a need for it. The
-mappings are defined through \cs{DeclareFontShapeChangeRule} and the
+The way that shapes combine with each other is not hardwired; it is
+customizable and extensible if there is ever a need for this. The
+mappings
+are defined through \cs{DeclareFontShapeChangeRule} and the
details for developers are documented in \texttt{source2e.pdf}.
The ideas for this interface extension have been pioneered in
-\pkg{fontspec} by Will Robertson for Unicode engines and in
-\pkg{fontaxes} by Andreas Bühmann and Michael Ummels for \pdfTeX{} and
-used in many font support packages.
-
+\pkg{fontspec} by Will Robertson for Unicode engines, and in
+\pkg{fontaxes} by Andreas Bühmann and Michael Ummels for \pdfTeX{};
+they are by now used in many font support packages.
-\subsection{Extending the series management of NFSS}
+\subsection{Extending the font series management in NFSS}
Many of the the newer font families also come provided with additional
-weights (thin, semi-bold, ultra-bold, etc.\@) or several running lengths
-such as a condensed or extra-condensed. In some cases the number of
-different series values is really impressive, for example, Noto Sans
-offers 36 fonts from ultra-light extra condensed to ultra-bold medium width.
-
-Already in its original design, NFSS supported 9 weight levels from
-ultra-light (\texttt{ul}) to ultra-bold (\texttt{ub}) and also 9 width
-levels from ultra-condensed (\texttt{uc}) to ultra-expanded
-(\texttt{ux}) so more than enough even for a font family like Noto
+weights (thin, semi-bold, ultra-bold, etc.\@) or several running widths,
+such as condensed or extra-condensed. In some cases the number of
+different values for series (weight plus width) is really impressive:
+for example, Noto Sans
+offers 36 fonts, from ultra-light extra condensed to ultra-bold medium width.
+
+Already in its original design, NFSS supported 9 weight levels, from
+ultra-light (\texttt{ul}) to ultra-bold (\texttt{ub}), and also 9 width
+levels, from ultra-condensed (\texttt{uc}) to ultra-expanded
+(\texttt{ux}): more than enough, even for a font family like Noto
Sans. Unfortunately, some font support packages nevertheless invented
-their own names so in recent years you could find all kinds of
-non-standard series names like \texttt{k}, \texttt{i}, \texttt{j} and
-others making it impossible to combine different fonts successfully
+their own names, so in recent years you have been able to find all kinds of
+non-standard series names (\texttt{k}, \texttt{i}, \texttt{j} and
+others), making it impossible to combine different fonts successfully
using the standard NFSS mechanisms.
Over the course of the last year a small number of individuals,
-notably, Bob Tennent, Michael Sharpe and Marc Penninga worked hard to
-bring this unsatisfying situation back under control and today we are
+notably, Bob Tennent, Michael Sharpe and Marc Penninga, have worked hard to
+bring this unsatisfactory situation back under control; so today we are
happy to report that the internal font support files for more than a
-hundred font families are back to following the standard NFSS conventions
-so that combining them is now again rather nice and easy (of course,
+hundred font families are all back to following the standard NFSS conventions.
+Combining them is now again rather nice and easy, and from a technical
+perspective they can now easily matched; but, of course,
there is still the task of choosing combinations that visually work
-well together, but from a technical perspective they can now be easily
-matched).
-
+well together.
In the original font selection implementation, a request to select a new series
always overrode the current one. This was reasonable because there
were nearly no fonts available that offered anything other than a
medium or a bold series. Now that this has changed and families such
as Noto Sans are available, combining weight and width into a single
-attribute is no longer appropriate. With the 2020 release of \LaTeX{}
-the series management therefore changed to allow for independently
-setting the weight and the width attribute of the series.
+attribute is no longer appropriate. With the 2020 release of \LaTeX{},
+the management of series therefore changed to allow independent
+settings of the weight and the width attributes of the series.
For most users this change will be largely transparent as \LaTeX{}
offers only \cs{textbf} or \cs{bfseries} to select a bolder face (and
-\cs{textmd} and \cs{mdseries} to return to a medium series) but no
-high-level command for selecting a condensed face, etc. However, with
-the NFSS low-level interface, it is now possible to ask for, say,
-\verb=\fontseries{c}\selectfont= in a marginal note to get a condensed
-face and that would still allow using \cs{textbf} inside. This then would
-select a bold condensed face and not a rather odd-looking
-bold-extended face in the middle of condensed type.
-
-The expectation is that this functionality is largely used by class and package
-designers, but given that the low-level NFSS commands are usable on
-the document level and not really difficult to apply, there are
-probably also a number of users who will enjoy using the new
-possibilities that bring \LaTeX{} back into the front league when it
-comes to font usage.
-
-The way different series values combine with each other is not
+\cs{textmd} and \cs{mdseries} to return to a medium series): there is no
+high-level command for selecting a condensed face, etc. However, using
+the NFSS low-level interface it is now possible to ask for, say,
+\verb=\fontseries{c}\selectfont= to get a condensed
+face (suitable for a marginal note) and that would still allow
+the use \cs{textbf} inside the note, which would
+select a bold-condensed face (and not a rather odd-looking
+bold-extended face in the middle of condensed type).
+
+The expectation is that this functionality will be used largely by
+class and package designers but, given that the low-level NFSS
+commands are usable on the document level and that they are not really
+difficult to apply, there are probably also a number of users who will
+enjoy using these new possibilities that bring \LaTeX{} back into the
+premier league when it comes to font usage.
+
+The ways in which the different series values combine with each other is not
hardwired but is again customizable and extensible. The mappings are
defined through \cs{DeclareFontSeriesChangeRule} and the details for
developers are documented in \texttt{source2e.pdf}.
-
\subsection{Font series defaults per document family}
-With additional weights and widths available in many font families it
-becomes more likely that somebody wants to match, say, a medium weight
-serif family with a semi-light sans serif family or that with one
-family one wants to use the bold-extended face when \cs{textbf} is used
+With additional weights and widths available now being available in many font families, it
+is more likely that somebody will want to match, say, a medium weight
+serif family with a semi-light sans serif family, or that with one
+family one wants to use the bold-extended face when \cs{textbf} is used,
while with another it should be bold (not extended) or semibold, etc.
-In the past this kind of extension was made available with the
-\pkg{mweights} package by Bob Tennent which has been used in many font
+In the past this kind of extension was provided by Bob Tennent's
+\pkg{mweights} package, which has been used in many font
support packages.
-
With the 2020 release of \LaTeX{} this feature is now available out
of the box. In addition we also offer a document-level interface to adjust the
-behavior of the high-level series commands \cs{textbf}, \cs{textmd} and their
-declaration forms \cs{bfseries} and \cs{mdseries} so that they can
+behavior of the high-level series commands \cs{textbf}, \cs{textmd}, and of their
+declaration forms \cs{bfseries} and \cs{mdseries}, so that they can
have different effects for the serif, sans serif and typewriter
families used in a document.
@@ -332,8 +332,9 @@ For example, specifying
\DeclareFontSeriesDefault[tt]{md}{lc}
\end{verbatim}
in the document preamble would result in \cs{textbf} producing
-semi-bold (\texttt{sb}) when typesetting in roman typeface and
-that typewriter is by default (medium series \texttt{md}) using
+semi-bold (\texttt{sb}) when typesetting in a roman typeface.
+The second line says that the
+typewriter default face (i.e., the medium series \texttt{md}) should be
a light-condensed face. The optional argument here can be either
\texttt{rm}, \texttt{sf} or \texttt{tt} to indicate one of the three
main font families in a document; if omitted you will change the
@@ -342,11 +343,11 @@ specify either \texttt{md} or \texttt{bf} and the second mandatory
argument then gives the desired series value in NFSS nomenclature.
-\subsection{Emphasis handling generalized}
+\subsection{Handling of nested emphasis}
-With previous releases of \LaTeX{} nested \cs{emph} commands
+In previous releases of \LaTeX{}, nested \cs{emph} commands
automatically alternated between italics and upright. This mechanism
-has now been generalized and you can now specify for arbitrary nesting
+has now been generalized so that you can now specify for arbitrary nesting
levels how emphasis should be handled.
The declaration \cs{DeclareEmphSequence} expects a comma separated
@@ -363,26 +364,25 @@ provided, \LaTeX{} uses the declarations stored in \cs{emreset} (by
default \cs{ulcshape}\cs{upshape}) for the next level and then
restarts the list.
-The mechanism tries to be \enquote{smart} and verifies that the given
-declarations actually alter the current font. If not it continues and
+The mechanism tries to be \enquote{smart} by verifying that the given
+declarations actually alter the current font. If not, it continues and
tries the next level---the assumption being that there was already a
manual font change in the document to the font that is now supposed to
be used for emphasis.
%
-Of course, this only works if the declarations in the list entries
+Of course, this only works if the declarations in the list's entries
actually change the font and not, for example, just the color. In such
-a scenario one has to add \cs{emforce} to the entry which directs the
+a scenario one has to add \cs{emforce} to the entry, which directs the
mechanism to use the entry, even if the font attributes appear to be
unchanged.
-
\subsection{Providing font family substitutions}
-Given that \pdfTeX{} can only handle fonts with up to 256 glyphs a
+Given that \pdfTeX{} can only handle fonts with up to 256 glyphs, a
single font encoding can only support a few languages. The \texttt{T1}
-encoding, for example, does support many of the Latin-based scripts,
-but if you want to write in Greek or Russian you need to switch
+encoding, for example, does support many Latin-based scripts,
+but if you want to write in Greek or Cyrillic then you will need to switch
encodings to \texttt{LGR} or \texttt{T2A}. Given that not every font
family offers glyphs in such encodings, you may end up with some
default family (e.g., Computer Modern) that doesn’t blend in well
@@ -394,27 +394,29 @@ with the chosen document font. For such cases NFSS now offers
\end{verbatim}
tells \LaTeX{} that if you are typesetting in the sans serif font
\texttt{Montserrat-LF} and the Greek encoding \texttt{LGR} is asked
-for, then \LaTeX{} should use \texttt{IBMPlexSans-TLF} to fulfill the
-encoding request.
+for, then \LaTeX{} should use \texttt{IBMPlexSans-TLF} to fulfill
+the encoding request.
The code is based on ideas from the \pkg{substitutefont}
-package by Günter Milde, but implemented differently.
+package by Günter Milde, but the implementation is different.
\subsection{Providing all text companion symbols by default}
The text companion encoding \texttt{TS1} was originally not available
by default, but only when the \pkg{textcomp} package was loaded. The
-main reason for this was limited availability in fonts other than
-Computer Modern and memory restrictions back in the nineties. These
-days neither limitation exists any more so with the 2020 release all
+main reason for this was limited availability of fonts with this encoding other than
+Computer Modern; another was the memory restrictions back in the nineties.
+These days neither limitation remains, so with the 2020 release all
the symbols provided with the \pkg{textcomp} package are available out
of the box.
Furthermore, an intelligent substitution mechanism has been
-implemented so that missing glyphs are automatically substituted with
-defaults that are sans serif if you typeset in \cs{textsf} and
-monospaced if you typeset using \cs{texttt} and not always serifed.
+implemented so that glyphs missing in some fonts are automatically
+substituted with default glyphs that are sans serif if you typeset in
+\cs{textsf} and monospaced if you typeset using \cs{texttt}. In the
+past they were always taken from Computer Modern Roman if substitution
+was necessary.
\textsf{This is most noticeable with \cs{oldstylenums} which are now
@@ -424,15 +426,15 @@ monospaced if you typeset using \cs{texttt} and not always serifed.
typewriter fonts.}
If there ever is a need to use the original (inferior) definition,
-then that remains available as \cs{legacyoldstylenums} and to fully
+then that remains available as \cs{legacyoldstylenums}; and to fully
revert to the old behavior there is also
-\cs{UseLegacyTextSymbols}. That declaration reverts \cs{oldstylenums}
+\cs{UseLegacyTextSymbols}. The latter declaration reverts \cs{oldstylenums}
and also changes the footnote symbols, such as \cs{textdagger},
-\cs{textparagraph}, etc.\ pick up their glyphs again from the math
+\cs{textparagraph}, etc., to pick up their glyphs from the math
fonts instead of the current text font (this means they always keep
the same shape and do not nicely blend in with the text font).
-With the text companion symbols as part of the kernel it is normally
+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
@@ -440,72 +442,83 @@ with the option \texttt{error} or \texttt{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 \texttt{quit}, then even the information in
+file. If you use the option \texttt{quiet}, then even the information in
the transcript is suppressed (which is not really recommended).
-\section{Other changes to the \LaTeX{} kernel}
+
\subsection{New \texttt{alias} size function for use in \texttt{.fd} files}
+% these are really called ``size functions'' in NFSS, a bit weird
+
+
Most of the newer fonts supported in \TeX{} have been set up with the
-\texttt{autoinst} tool by Marc Penninga. In the past this program did
-set up the font faces using the face names chosen by its designer,
-e.g., \enquote{\texttt{regular}}, \enquote{\texttt{bold}}, etc., and
-then mapped those via substitution to the standard NFSS shape names,
-i.e., \enquote{\texttt{m}} or \enquote{\texttt{b}}. As a result one
+\texttt{autoinst} tool by Marc Penninga. In the past, this program
+set up each font using the face name chosen by that font's designer,
+e.g., \enquote{\texttt{regular}}, \enquote{\texttt{bold}}, etc.
+These face names were
+then mapped by substitution to the standard NFSS series
+ names, i.e., \enquote{\texttt{m}} or \enquote{\texttt{b}}. As a result one
got unnecessary substitution warnings such as \enquote{\texttt{Font
- T1/abc/bold/n not found using T1/abc/b/n instead}}.
+ T1/abc/bold/n not found, using T1/abc/b/n instead}}.
+
+%FMi the message above is actually different
We now provide a new NFSS \texttt{alias} size function that can and will be
used by \texttt{autoinst} in the future. It provides the same
functionality as the \texttt{subst} function but is less vocal about
-its actions, such that only relevant font substitutions show up as
+its actions, so that only significant font substitutions show up as
warnings.
-
-
-
-\subsection{UTF-8 characters in package descriptions}
-
-In 2018 we made UTF-8 the default input encoding for \LaTeX{} but we
-overlooked the case of package descriptions in declarations such as
-\cs{ProvidesPackage} which worked (sometimes) before but now died
-always. This has been corrected.
-\githubissue{52}
-
-
\subsection{Suppress unnecessary font substitution warnings}
Many sans serif fonts do not have real italics but usually only
oblique/slanted shapes, so the substitution of slanted for italics is
natural and in fact many designers talk about italic sans serif faces
even if in reality they are oblique. With nearly all sans serif font
-family the \LaTeX{} support files therefore silently substitute
+families, the \LaTeX{} support files therefore silently substitute
slanted if you ask for \cs{itshape} or \cs{textit}. This is also true
for Computer Modern in \texttt{T1} encoding but in \texttt{OT1} you
got a warning on the terminal even though there is nothing you can do
-about it. This has now been changed to an information message only
+about it. This has now been changed to an information message only,
written to the \texttt{.log} file.
%
\githubissue{172}
+\section{Other changes to the \LaTeX{} kernel}
+
+
+\subsection{UTF-8 characters in package descriptions}
+
+In 2018 we made UTF-8 the default input encoding for \LaTeX{} but we
+overlooked the case of of non-\acro{ascii} characters in the short
+package descriptions in declarations such as
+\cs{ProvidesPackage}. They worked (sometimes) before, but now always
+generate an error. This has been corrected.
+%
+\githubissue{52}
+
+
+
\subsection{Fix inconsistent hook setting when loading packages}
-When a package is loaded
-\texttt{\textbackslash}\textit{package}\texttt{.sty-h@@k} is set, but
-if it was loaded several times it was unset again. Relevant only to
-package developers.
+As part of loading a package the command
+\texttt{\textbackslash}\textit{package}\texttt{.sty-h@@k} gets
+defined. However, attempting to load a package a second time resulted
+in this hook to become undefined again. Now the hook remains defined
+and one or several loading attempts do not change the state of
+\LaTeX{} (relevant only to package developers).
%
\githubissue{198}
\subsection{Avoid spurious warning if \texttt{LY1} is made the default encoding}
-Making \texttt{LY1} the default encoding as done by some font support
-packages gave a spurious warning even if \cs{rmdefault} was changed
-first. This was corrected.
+Making \texttt{LY1} the default encoding, as is done by some font support
+packages, gave a spurious warning even if \cs{rmdefault} had first been changed.
+This was corrected.
%
\githubissue{199}
@@ -514,15 +527,17 @@ first. This was corrected.
\subsection{Ensure that \cs{\textbackslash} remains robust}
In the last release we made most document-level commands robust, but
-\cs{\textbackslash} became fragile again if \cs{raggedright}
-typesetting was used.
+\cs{\textbackslash} became fragile again whenever
+\cs{raggedright} or similar typesetting was used.
+This has been fixed.
%
\githubissue{203}
+
\subsection{Make math delimiters robust in a different way}
Making math delimiters robust caused an issue in some situations. This
-has been corrected. This also involved a correction in \pkg{amsmath}.
+has been corrected. This also involved a correction to \pkg{amsmath}.
%
\githubissue{251}
@@ -530,10 +545,10 @@ has been corrected. This also involved a correction in \pkg{amsmath}.
\subsection{Allow more write streams with \texttt{filecontents} in \LuaTeX}
Most \TeX{} engines only support a maximum of sixteen concurrently
-open write streams and if those have been used up, then
+open write streams, and when those have been used up, then
\texttt{filecontents} or any other code trying to open another one
will fail. In \LuaTeX{} more write streams are available and those can
-now be utilized as well.
+also now be utilized.
%
\githubissue{238}
@@ -545,52 +560,51 @@ now be utilized as well.
\subsection[Make \pkg{color}/\pkg{graphics} user-level commands robust]
{Make \pkg{color} \& \pkg{graphics} user-level commands robust}
-Some of the user-level commands of \pkg{color}, \pkg{graphics} and
-\pkg{graphicx} such as \cs{textcolor} or \cs{includegraphics} were
-still fragile, so didn't work in moving arguments without extra
-protection. All of them have now been made robust.
+Some of the user-level commands in \pkg{color}, \pkg{graphics} and
+\pkg{graphicx}, such as \cs{textcolor} or \cs{includegraphics}, were
+still fragile so didn't work in moving arguments without extra
+protection. All of these have now been made robust.
%
\githubissue{208}
-
-
\section{Changes to packages in the \pkg{tools} category}
\subsection{Fixed column depth in boxed \texttt{multicols}}
The \texttt{multicols} environment was setting \cs{maxdepth} when
-splitting boxes but the way the internal interfaces of \LaTeX{} are
-designed it should have used \cs{@maxdepth} instead. As a result
+splitting boxes; but, due to the way the internal interfaces of \LaTeX{} are
+designed, it should have used \cs{@maxdepth} instead. As a result,
balanced boxed multicols sometimes ended up having different heights
even if they had exactly the same content.
%
\githubissue{190}
-\subsection{Ensure that \texttt{multicols} is not losing text}
+\subsection{Ensure that \texttt{multicols} does not lose text}
-The \texttt{multicols} environment needs a set of consecutive boxes to
+The \texttt{multicols} environment needs a set of consecutively numbered boxes to
collect column material. The way those got allocated could result in
-disaster if other packages allocated most boxes below box 255 (which
+disaster if other packages allocated most boxes below box~255 (which
\TeX{} always uses for the output page). In the original
-implementation that problem was identified because one could only
-allocate boxes below 255, but nowadays the \LaTeX{} allocation routine
-allows allocating boxes below and above 255. So the assumption that
-asking for, say 20 boxes you get a consecutive sequence of box
-registers was no longer true and so some of the column material could
-end in box 255 and be overwritten. This has now been corrected by
-allocating all necessary boxes above 255 if there aren't enough
-registers available.
+implementation that problem was avoided because one could only
+allocate box numbers below~255, but nowadays the \LaTeX{} allocation routine
+allows allocating box numbers both below and above~255. So the assumption that
+when asking for, say, 20~boxes you always get a consecutive sequence of~20 box
+register numbers became no longer true:
+some of the column material could
+end up in box~255, where it would get overwritten. This has now been corrected by
+allocating all necessary boxes with numbers above~255 whenever there aren't enough
+lower-numbered registers available.
%
\githubissue{237}
\subsection{Allow spaces in \cs{hhline} arguments}
-The verb \verb|\hhline| command which allows
-specification of rule segments in \texttt{tabular} environments now
-allows (and ignores) spaces between its tokens so
-\verb|\hhline{: = : =}| is now allowed and equivalent to
+The \verb|\hhline| command, which allows the
+specification of rule segments in \texttt{tabular} environments, now
+allows (but ignores) spaces between its tokens: so
+\verb|\hhline{: = : =}| is now allowed and is equivalent to
\verb|\hhline{:=:=}|. This matches similar token arguments in \LaTeX{}
such as the \verb|[h t p]| argument on floats. A similar change has
been made to the extended \verb|\hhline| command in the
@@ -600,19 +614,20 @@ been made to the extended \verb|\hhline| command in the
-\section{Primitive requirements}
+\section{\LaTeX{} requirements on engine primitives}
Since the finalization of \eTeX{} in 1999, a number of additional `utility'
primitives have been added to \pdfTeX{}. Several of these are broadly useful
-and have been requirements for \pkg{expl3} for some time, most notably
+and have been required by \pkg{expl3} for some time, most notably
\cs{pdfstrcmp}. Over time, a common set of these `post-\eTeX{}' primitives have
-been incorporated into \XeTeX{} and (u)p-\TeX{}; they were available in
-\LuaTeX{} already.
+been incorporated into \XeTeX{} and (u)p-\TeX{}; they were already available in
+\LuaTeX{}.
-A number of the additional primitives are needed to support new or improved
-functionality in \LaTeX{}. This is seen for example in improved UTF-8 handling,
+A number of these additional primitives are needed to support new or improved
+functionality in \LaTeX{}. This is seen for example in the improved UTF-8 handling,
which uses \cs{ifincsname}. The following primitive functionality (which in
-\LuaTeX{} may be achieved using Lua code) will therefore be \emph{required} by
+\LuaTeX{} may be achieved using Lua code)
+will therefore be \emph{required} by
the \LaTeX{} kernel from the start of 2021:
%
\begingroup\setlength\columnsep{0pt}
@@ -628,6 +643,14 @@ the \LaTeX{} kernel from the start of 2021:
\item \cs{pdffilesize}
\item \cs{pdflastxpos}
\item \cs{pdflastypos}
+\end{itemize}
+\end{multicols}
+%
+% very manual! multicol needs update to detect that it is used
+% inside twocolumn!
+%
+\begin{multicols}{2}
+\begin{itemize}
\item \cs{pdfmdfivesum}
\item \cs{pdfnormaldeviate}
\item \cs{pdfpageheight}
@@ -643,19 +666,18 @@ the \LaTeX{} kernel from the start of 2021:
\end{itemize}
\end{multicols}
\endgroup
-%
-For ease of reference, these primitives will be referred to
-as the `\pdfTeX{} utilities'. With the exception of \cs{expanded},
-these have been present in \pdfTeX{} since the release of version
-1.40.0 in 2007; \cs{expanded} was added for \TeX{}~Live
-2019. Similarly, the full set of utility primitives have been
-available in \XeTeX{} from the 2019 \TeX{}~Live release, and have
-always been available in \LuaTeX{} (some by Lua emulation). p\TeX{}
-and up\TeX{} gained all of the above except \cs{ifincsname} for
-\TeX{}~Live 2019, and will have that primitive from the 2020 release.
-
-At the same time, engines which are fully Unicode-capable must all
-provide the following primitives
+For ease of reference, these primitives will be referred to as the
+`\pdfTeX{} utilities'. With the exception of \cs{expanded}, these have been
+present in \pdfTeX{} since the release of version 1.40.0 in 2007; \cs{expanded}
+was added for \TeX{}~Live 2019. Similarly, the full set of these utility primitives
+have been available in \XeTeX{} from the 2019 \TeX{}~Live release, and has
+always been available in \LuaTeX{} (some by Lua emulation). Whilst p\TeX{} and
+up\TeX{} gained all of the above (except \cs{ifincsname}) for \TeX{}~Live
+% bnb changed from 'bar'
+2019 and will both have that primitive also from the 2020 release.
+
+At the same time, engines which are fully Unicode-capable must provide
+the following primitives:
%
\begingroup\setlength\columnsep{0pt}
\begin{multicols}{2}
@@ -667,12 +689,11 @@ provide the following primitives
\end{multicols}
\endgroup
%
-Note that it has become standard practice to check for Unicode-aware
-engines with the existence of the \cs{Umathcode} primitive. As such,
-this is already a requirement: engines lacking these primitives cannot
-access Unicode features of the \LaTeXe{} kernel or of
-\pkg{expl3}. Note that up\TeX{} has facilities for handling Unicode
-but is not classed as a Unicode engine by the base LaTeX code.
+Note that it has become standard practice to check for Unicode-aware engines
+by using the existence of the \cs{Umathcode} primitive. As such, this is already
+a requirement: engines lacking these primitives cannot access the Unicode features
+of the \LaTeXe{} kernel or of \pkg{expl3}. Note that up\TeX{} has facilities for
+handling Unicode but it is not classed as a Unicode engine by the base LaTeX code.
\begin{thebibliography}{9}
More information about the latex3-commits
mailing list