CTAN sync 202002030302

1 files changed, 311 insertions, 233 deletions

diff --git a/macros/latex-dev/base/ltnews31.tex b/macros/latex-dev/base/ltnews31.tex
index c365e527c0..5622ea103f 100644
--- a/macros/latex-dev/base/ltnews31.tex
+++ b/macros/latex-dev/base/ltnews31.tex
@@ -30,6 +30,8 @@
 %
 % This is issue 31 of LaTeX News.
 
+\NeedsTeXFormat{LaTeX2e}[2020-02-02]
+
 \documentclass{ltnews}
 \usepackage[T1]{fontenc}
 
@@ -38,7 +40,6 @@
 \usepackage{csquotes}
 \usepackage{multicol}
 
-\providecommand\acro[1]{\textsc{#1}}
 \providecommand\meta[1]{$\langle$\textit{#1}$\rangle$}
 \providecommand\option[1]{\texttt{#1}}
 \providecommand\env[1]{\texttt{#1}}
@@ -76,6 +77,9 @@
 \let\cls\pkg
 \providecommand\env[1]{\texttt{#1}}
 
+\vbadness=1400  % accept slightly empty columns
+
+
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 \iffalse % only for TUB production
 \usepackage{graphicx}
@@ -123,98 +127,107 @@
 %\addtolength\textheight{4.2pc}   % only for TUB
 
 \maketitle
-\tableofcontents
+{\hyphenpenalty=10000 \spaceskip=3.33pt \hbadness=10000 \tableofcontents}
 
 \setlength\rightskip{0pt plus 3em}
 
-%\newpage
 
 \medskip
 
 
-\section{Introduction}
-
-This document is under construction \ldots
+%\section{Introduction}
+%
+%This document is under construction \ldots
 
 
-\section{Experiences with the \LaTeX\texttt{-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\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.
+readily available in \TeX{} systems and is getting real use\\
+beyond the team.
 
 The current
-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
+release has been tested by a number of people, and we have had valuable feedback
+on a range of the new ideas. This has allowed us to fix issues in several of the
+new features, as described below.
+
+
+We wish to thank all the dedicated users who have been
+trying out the development formats, and we encourage others to do so. Pre-testing
+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}
 
-In \TeX{}Live 2020 the Lua\LaTeX{} format will use the new LuaHB\TeX{}
-engine, which is Lua\TeX{} with an embedded HarfBuzz library.
+\section{Concerning this release \ldots (Lua\LaTeX{} engine)}
+
+The new LuaHB\TeX{} engine 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 always uses HarfBuzz.
+
+To simplify testing of the new engine, binaries have
+already been added to MiK\TeX{} and \TeX{}~Live 2019 and both distributions have already now changed
 the Lua\LaTeX-dev format to use it.
 
+Going forward, Lua\LaTeX\ (and Lua\LaTeX-dev) will both use the LuaHB\TeX{}
+engine.
+The timing of the switch to the LuaHB\TeX{} engine
+depends on the distribution you use
+(for \TeX{}~Live this will be with \TeX{}~Live 2020).
+
+
 
 
 \section{Improved load-times for \pkg{expl3}}
 
 The \LaTeX3 programming layer, \pkg{expl3}, has over the past decade moved from
 being largely experimental to broadly stable. It is now used in a significant
-number of third-party packages, most notably \pkg{xparse} for defining
+number of third-party packages, most notably \pkg{xparse}, for defining
 interfaces in cases where no \pkg{expl3} code is \enquote{visible}. In addition, most
 \LaTeX{} documents compiled using \XeTeX{} or \LuaTeX{} load \pkg{fontspec},
 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)]
+\section[Improvements to \LaTeX{} font selection: 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 +239,104 @@ 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 font series management in NFSS}
 
-\subsection{Extending the series management of NFSS}
+Many of the newer font families also come provided with additional
+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.
 
-Many of the the newer font families also come provided with additional
-weights (thin, semi-bold, ultra-bold, etc.\@) or several running lengths
-such 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
+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 be 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 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 of \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 for 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-extend face when \cs{textbf} is used
-while with another it should be bold (not extended) or semibold, etc.
+With additional weights and widths 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 +346,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 +357,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 generalised so that you can now specify for arbitrary nesting
 levels how emphasis should be handled.
 
 The declaration \cs{DeclareEmphSequence} expects a comma separated
@@ -358,35 +373,34 @@ emphasis. For example,
 \end{verbatim}
 uses italics for the first, small capitals for the second, and italic
 small capitals for the third level (provided you use a font that
-supports these shapes).  If there are a more nesting levels than
+supports these shapes).  If there are more nesting levels than
 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
-mechanism to use the level, even if the font attributes appear to be
+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
-chosen document font.  For such cases NFSS now offers
+with the chosen document font.  For such cases NFSS now offers
 \cs{DeclareFontFamilySubstitution}, for example:
 \begin{verbatim}
   \DeclareFontFamilySubstitution{LGR}
@@ -394,45 +408,52 @@ 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.
+
 
+\typeout{^^J^^J***************************************}
+\typeout{** This example needs LaTeX 2020-02-02}
+\typeout{** to come out correctly !!}
+\typeout{***************************************^^J^^J}
 
 \textsf{This is most noticeable with \cs{oldstylenums} which are now
   taken from \texttt{TS1} so that you no longer get
-  \textrm{\oldstylenums{123}} but \oldstylenums{123} when typesetting
-  in sans serif fonts}\texttt{ and \oldstylenums{123} when using
+  \textrm{\oldstylenums{1234}} but \oldstylenums{1234} when typesetting
+  in sans serif fonts}\texttt{ and \oldstylenums{1234} when using
   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,97 +461,135 @@ 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 I know
+
 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
-got unnecessary substitution warnings such as \enquote{\texttt{Font
-    T1/abc/bold/n not found using T1/abc/b/n instead}}.
+\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}}.
 
-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
-warnings.
+%FMi the message above is actually different and longer but ...
 
+We now provide a new NFSS  size function, \texttt{alias}, 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, so that only significant font substitutions show
+up as warnings.
 
 
+\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 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, written to the \texttt{.log} file.  %
+\githubissue{172}
 
-\subsection{UTF-8 characters in package descriptions}
+\vspace{-\smallskipamount}
+\pagebreak
 
-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}
+\section{Other changes to the \LaTeX{} kernel}
 
 
-\subsection{Suppress unnecessary font substitution warnings}
+\subsection{UTF-8 characters in package descriptions}
 
-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
-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
-written to the \texttt{.log} file.
+In 2018 we made UTF-8 the default input encoding for \LaTeX{} but we
+overlooked the case of non-ASCII characters in the short
+package descriptions used in declarations, e.g., in the optional argument to
+\cs{ProvidesPackage}.
+They worked (sometimes) before, but the switch to UTF-8 made them always
+generate an error.
+This has been corrected.
 %
-\githubissue{172}
+\githubissue{52}
 
 
-\subsection{Fix inconsistent hook setting when loading packages}
+\subsection[Fix inconsistent hook setting when\texorpdfstring{\\}{} loading packages]%
+           {Fix inconsistent hook setting when loading packages}
 
-When a package is loaded
-\texttt{\textbackslash}\textit{package}\texttt{.sty-h@@k} is set, but
-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 becoming undefined again.  Now the hook remains defined
+so that extra 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} was changed first.
+This was corrected.
 %
 \githubissue{199}
 
-
+\enlargethispage{-\smallskipamount}
+\vspace{-\medskipamount}
 
 \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 to \pkg{amsmath}.
+%
+\githubissue{251}
+
+
 \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
-\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.
+open write streams, and when those have been used up, then
+\texttt{filecontents} or any other code trying to open one
+will fail.
+In \LuaTeX{} more write streams are available and those can
+also now be utilised.
 %
 \githubissue{238}
 
+\subsection{Allow spaces in \texttt{filecontents} option list}
+
+Leaving spaces or newlines in the option list prevented the options
+from being correctly recognized. This\\ 
+has been corrected.
+%
+\githubissue{256}
+
 
+\subsection{New \texttt{reverselist} Lua callback type}
+
+A new callback type, \texttt{reverselist}, was added:\\ 
+\texttt{post\_mlist\_to\_hlist\_filter} and \texttt{post\_linebreak\_filter} 
+are now of this type.
 
 
 \section{Changes to packages in the \pkg{graphics} category}
@@ -538,52 +597,53 @@ 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},
+%\pagebreak
+such as \cs{textcolor} or \cs{includegraphics}, were
+still fragile so didn't work in moving arguments.\\
+All of these are now 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
-balanced boxed multicols sometimes ended up having different height
+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
@@ -593,23 +653,25 @@ 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.
-
-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,
-which uses \cs{ifincsname}. The following primitive functionality (which in
-\LuaTeX{} may be achieved using Lua code) will therefore be \emph{required} by
-the \LaTeX{} kernel from the start of 2021:
+been incorporated into \XeTeX{} and (u)p-\TeX{}; they were  already available in
+\LuaTeX{}.
+
+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 the \LaTeX{} kernel and core\\
+packages from the start of 2021:
 %
 \begingroup\setlength\columnsep{0pt}
 \begin{multicols}{2}
+\fontsize{9.3}{11.3}\selectfont
 \begin{itemize}
   \item \cs{expanded}
   \item \cs{ifincsname}
@@ -625,6 +687,14 @@ the \LaTeX{} kernel from the start of 2021:
   \item \cs{pdfnormaldeviate}
   \item \cs{pdfpageheight}
   \item \cs{pdfpagewidth}
+%\end{itemize}
+%\end{multicols}
+%
+% very manual! multicol needs update to detect that it is used
+% inside twocolumn!
+%
+%\begin{multicols}{2}
+%\begin{itemize}
   \item \cs{pdfprimitive}
   \item \cs{pdfrandomseed}
   \item \cs{pdfresettimer}
@@ -636,40 +706,47 @@ 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 these utility primitives
+has been available in \XeTeX{} from the 2019 \TeX{}~Live release, and has
+always been available in \LuaTeX{} (some by Lua emulation).
 %
-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 bar \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
-%
+The Japanese p\TeX{} and
+up\TeX{} gained all of the above (except \cs{ifincsname}) for \TeX{}~Live
+2019 and will both have that primitive also from the 2020 release onward.
+
+At the same time, engines which are fully Unicode-capable must provide
+the following three primitives:
+
+\vspace{-\smallskipamount}
 \begingroup\setlength\columnsep{0pt}
 \begin{multicols}{2}
+\fontsize{9.3}{11.3}\selectfont
 \begin{itemize}
   \item \cs{Uchar}
-  \item \cs{Ucharcat}
+  \quad \textbullet{}\hspace{\labelsep}\cs{Ucharcat}
   \item \cs{Umathcode}
 \end{itemize}
 \end{multicols}
+\vspace{-\smallskipamount}
 \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 use Unicode features
+of the \LaTeXe{} kernel or \pkg{expl3}. Note also that up\TeX{} can
+handling Unicode but it is not classed as a Unicode engine by the 
+base \LaTeX\ code.
+
+\enlargethispage*{\baselineskip}
+\vspace{3.9pt}               % manual adjustment to align the bottom
+
 
 \begin{thebibliography}{9}
 
-%\fontsize{9.3}{11.3}\selectfont
+\fontsize{9.3}{11.3}\selectfont
 
 \bibitem{31:devformat} Frank Mittelbach:
   \emph{The
@@ -679,12 +756,13 @@ but is not classed as a Unicode engine by the base LaTeX code.
 
 \bibitem{31:fntguide} \LaTeX{} Project Team:
   \emph{\LaTeXe{} font selection}.\\
-  \url{https://latex-project.org/documentation/}
+  \url{https://latex-project.org/help/documentation/fntguide.pdf}
 
 \bibitem{31:site-doc}
   \emph{\LaTeX{} documentation on the \LaTeX{} Project Website}.\\
-  \url{https://latex-project.org/documentation/}
+  \url{https://latex-project.org/help/documentation/}
 
 \end{thebibliography}
 
+
 \end{document}