achemso package has provided the standard
BibTeX styles following the American Chemical Society (ACS) guidelines since
before I started using LaTeX. I’ve looked after achemso since 2008, and took
it from a simple BibTeX .bst to a bundle including submission class, a demo
document and other goodies.
I started the class many years ago, and with hindsight some of it was not such
a great plan. More importantly, the ACS have never used LaTeX in production,
which has always meant that using a dedicated class was a bit awkward: getting
things into a specific class only for them to strip that out again. I’ve
therefore recently agreed with the ACS to move from a dedicated class to a
simple template, now available on
GitHub and soon to appear on the
ACS website. Authors can then simply use article with minor adjustments and
get something that is suitable for production.
At the same time, classical BibTeX styles, whilst still widely used, are
better replaced by biblatex methods.
That opens up a lot of flexibility to the user, and avoids needing add-on
packages to provide control or compound citations.
So I’m marking achemso as for historical support only, and recommending all
new content shifts to updated approaches. I’ll keep achemso working of
course: not that there should be much to do! But it’s time for people to move
away from what was a rather rigid approach in new documents.
ltx-talk to CTAN. This is a new
tagging-aware class which works similarly to
beamer. I’ve talked
before about the need to write a
class from scratch for tagged presentations, so this should be no real
surprise.
This is very much a work-in-progress, so don’t be surprised if things you’ve
used in beamer simply don’t work. But something like
\DocumentMetadata{tagging = on}
\documentclass{ltx-talk}
\begin{document}
\begin{frame}
\begin{itemize}[<+->]
\item First
\item Second
\item Third
\end{itemize}
\end{frame}
will work fine.
If you want to see a full example, I’ve uploaded my lecture slides on polymer
chemistry, which I’ve updated from beamer to
ltx-talk for teaching in the autumn.
A version of ConTeXt does go into TeX Live, but to date that’s been a once-a-year change with some non-trivial work to match up with how TeX Live works. That’s now changed: Max Chernoff has set up a scripted approach which automatically does the work and means that ConTeXt in TeX Live will now only be a day or two behind the official release.
This will be really useful for anyone working with mixed TeX formats (ConTeXt,
LaTeX, plain, OpTeX), as they’ll not have to worry if they are using ConTeXt
from TeX Live or from the standalone. It also means it will be easier to test
other TeX code against current ConTeXt just by using a single standard setup.
That should be good for example for testing generic
expl3 loading in ConTeXt, something we’ve
worked on recently.
beamer, and was recently reminded about that.
The first thing to say is that beamer (or rather presentations/slides) are a
tricky topic. There is lots of (legal) pressure for people doing teaching to
provide accessible resources, which includes slides (at least to some extent).
On the other hand, there are a lot of structural things that make presentations
a lot more complexes from a tagging point of view than more classical
‘documents’ (articles and the like). Presentations also tend to be limited-life
documents: most people will revise slides each time they present, unlike an
article that once published is basically ‘frozen’. That means that the idea
that documents have to work ‘unchanged’ isn’t quite the same for beamer as it
is for say the article class. But work does need to be done.
The wider reason that tagging currently doesn’t work at all with beamer is
that internally, the class is ‘interesting’. There is a lot of re-boxing
material, and very little in the way of semantic flow. The class also does
things its own way: that means that in a lot of places, standard LaTeX code is
ignored or overwritten, and so the work being done on tagging in general
doesn’t apply.
Along with other members of the team, I’ve looked at beamer in detail and
we’ve concluded that ‘upgrading’ to tagging isn’t realistic in the current
class. What’s needed instead is a beamer replacement, taking forward key
ideas (and as much of the syntax as we can), but starting from the idea of
including tagging support.
Writing something that covers everything beamer does will take a long time,
so that’s not the initial target. Rather, we want to pick off specific areas.
First, the simple idea of a tagged structure that looks like a slide, then
moving on to simple overlays before even looking at the ‘visual effects’ that
people like to use in presentations. At the moment, the code for this effort is
not public, but once there is something that works for simple slides (like my
own teaching), that will change.
As well as the LaTeX Project team, there are a few other people with an interest in this work. So I hope I can get things moving along once the basics are in place.
There is a particular point to consider when tagging is that it makes little
sense to try to tag slides themselves, at least unless they use no
animations. If you think about a typical beamer slide such as
\begin{frame}
\frametitle{Some things I did}
\begin{itemize}[<+->]
\item One
\item Two
\item Three
\end{itemize}
\end{frame}
the resulting PDF will have three pages, each of which contains at least one of the list items, and all of which have the same title. For tagging/reuse, we almost certainly don’t want that: we want the ‘flattened’ version (as you’d have in an handout).
That looks OK if you take a simple example, but once authors start using overlays to swap one image for another ‘in place’, etc., it’s no longer clear what the right tagging might be. So part of the overall project here will be about working with users to explore what the answers are.
]]>Over time, several people have done the hard work of translation to several languages. Recently, Daniel Zhang has completed translations to simplified and traditional Chinese. This meant working on some technical aspects that don’t come up automatically for e.g. western European languages. Many thanks to Daniel for the hard work.
There are a few issues suggesting people started on other translations. It would be great if interested (native) speakers took on the challenge of finishing for example Japanese, Turkish and Korean translations, or started on other languages.
]]>The plans for LaTeX3 developed by the team in the early 1990s envisaged reimplementing LaTeX with a much cleaner underlying programming framework and well-defined separation of user interface, design functions and programming. A lot of these ideas were prototyped very early on, with a version of the programming layer created well before LaTeX2e was finalised. But performance was the big issue: yes, you could test things as a developer, but that was basically it. At the same time, some ideas were not fully ready: before e-TeX (pdfTeX extensions, etc.), there was less that the engine could do, and whilst Knuth’s TeX is an excellent piece of software, the LaTeX3 ideas pushed it to the limit.
So LaTeX2e was released in 1994, and development focussed on packages for many years. That meant that ‘LaTeX3’ became something of an amusing idea: talked about but with no likelihood of (visible) delivery.
Development of ‘LaTeX3’ ideas never stopped, of course: it was just that they
moved from being primarily targeting a new kernel to building on top of
LaTeX2e. That results in a bundle called l3in2e and one called xpackages on
CTAN, although both were marked as experimental.
When I joined the LaTeX Project team in 2009, that’s largely where things were.
However, the landscape had evolved: computers had become more powerful, e-TeX
and pdfTeX extensions to TeX were very widely available and development was
easier. That meant that LaTeX3 ideas, particularly the programming language
(expl3) was usable in real documents: the
fontspec package in particular was written
in expl3 and was quite usable. I picked that up and wrote the second version
of siunitx in expl3.
At the same time, some of my first work on the team was in getting expl3 to
the point that the ‘experimental’ was no longer really true: you could use it
in a package and be happy that the code would continue to work between
releases. The other major task early in my team career was getting us into a
position that releases, first of expl3 and then of the LaTeX2e kernel, were
easy to make from whatever platform we wanted: Linux, macOS and Windows.
Over the 2010s, this meant the team could round out ideas that had been
suggested first over 20 years before. Development was still as packages adding
on to the kernel, but xparse (document commands), xtemplate (flexible
document structures) and xgalley (a new approach to the main vertical list)
were all revised and testable.
By 2020, work on the core idea of a programming layer had reached the point
that the code was stable and performant, and that the team wanted to be able to
rely on it for kernel developments. So we took the step to integrate loading
expl3 into the LaTeX2e kernel, with the rather cryptic description ‘Improved
load times for expl3’ in LaTeX News. Following that, xparse and
xtemplate have also been (largely) added to the kernel, tightening up the
parts that worked from those that do turn out to have been purely experiments.
With this functionality available, new ideas such as hook management and
re-implementation of older ones such as lists is possible: some of that is
currently only activated if you use \DocumentMetadata as a ‘marker’. For
updated documents, that means many of the LaTeX3 ideas are being used: the
programming layer, a way of making document commands (\NewDocumentCommand
originally from xparse) and templates (originally from xtemplate and used
to update list code, etc.).
There are also more subtle changes across the kernel, for example updating commands to use UTF-8 everywhere, make more functions engine-robust, etc. Put together, the 2024 LaTeX2e is quite different from the 1994 one: but you can still rely on the long-term stability that’s always been there.
Whilst there will never be a stand-alone ‘LaTeX3’ format, the ideas that were first explored by the LaTeX Project team in the early 1990s are now available to users in the LaTeX kernel. They are being used to deliver an updated LaTeX capable of producing accessible documents, and more widely to bring customisation to the kernel. So whilst ‘LaTeX3’ might not be something you’ll ever say you use, if you use LaTeX, you are getting those features today.
]]>LuaTeX offers the widest range of features, including the ability to access the node list as it’s constructed. We can use that to generate MathML automatically for math mode fragments. It also allows us to do tagging in fewer passes than in other engines and offers support for larger documents (due to dynamic memory allocation). As such, LuaTeX is the recommended engine for all new documents.
Work is continuing on adjusting parts of the setup to improve automation here: for the present, you should be using
\usepackage{unicode-math}
to get the best results for math mode.
The situation with XeTeX contrasts strongly with LuaTeX: although both are Unicode engines, XeTeX has none of the flexibility available in LuaTeX. There are significant technical limitations which mean that XeTeX cannot create accessible PDFs at all: this is unlikely to change. The engine itself is unmaintained, and with no access to internals, fixing the current issues alone would not really help. XeTeX does not produce PDFs directly, and that essentially rules out full tagging support (see below).
All of this means it is time to move away from XeTeX: certainly for new
documents, and even for existing ones. Users should look at alternative
approaches here, even if it means some source changes. This is most obvious for
users of xeCJK, who will need to look at the
methods offered by luatexja instead: whilst
the latter is described as for Japanese, the underlying mechanisms should be
suitable for other East Asian languages.
pdfTeX is widely used as it is superbly stable and fast, at least if you are dealing with languages where an 8-bit approach works. There are as a result a vast body of existing LaTeX documents which rely on pdfTeX. As such, the LaTeX Project are working to produce fully tagged PDFs from these sources, although we cannot do quite the same job as with LuaTeX.
For new documents, moving to LuaTeX is the recommended approach: it will continue to offer the most complete tagging support. For existing documents, tagging is available and we hope to improve it further: this may eventually use a LuaTeX-based approach emulating 8-bit approaches. At present, however, tagging in pdfTeX is more limited than in LuaTeX.
There are other engines, most notable (u)pTeX. Like XeTeX, these do not generate PDF directly, so may well be more limited in tagging support. Unlike XeTeX, other engines do have (small) support teams and so may see developments that help with tagging. However, the LaTeX Project team do not test these engines, and so where possible a move to LuaTeX is suggested.
The time to move to LuaTeX for new LaTeX documents is here. For existing pdfTeX sources, tagging will be available, although it may be more limited than for LuaTeX. pdfTeX users can keep their existing sources and will see tagging available. XeTeX users really do need to re-work their sources for LuaTeX.
]]>We (Frank, Ulrike and I) went to the recent DocEng 2024 conference in San José. Ulrike presented a workshop showing what is doable right now with the updated code. At present, this is still an opt-in testphase, but most of the time
\DocumentMetadata{testphase = {phase-III,firstaid,math,table,title}}
is enough to use it. As you can probably tell, this uses the current (phase III) code plus add-ons for maths, tables and titles: that is all a bit more experimental but is worth exploring.
We are building up an idea of which packages and classes work out-of-the-box
with the latest code: you can view the current list online. It’s amazing how many
packages already work, but of course there is work to do. I’ve got some
adjustments to make for siunitx, but as the
tagging structures are still not finalised, I’m waiting a bit. We also need to
look at performance: tagging takes time, but when we make it opt-out we need it
to be as fast as possible.
On the to-do list here is beamer: a complex class with a lot of challenges! I
think that deserves it’s own post, so I’ll return to that soon in a dedicated
post.
But for day-to-day use, I’m finding tagging something I can mainly switch on and just use. So other than slides, all of my LaTeX work is now tagged - may not perfectly just yet, but each release getting better and better.
]]>expl3 from day one. A basic
expl3 function name such as \foo:nn shows how many unmodified braced
arguments it takes: so called n-type arguments. We can then create variants,
which can lead to expansion only once (o-type), to the value of a variable
(V-type) or to the value retrieved by constructing the name of a variable and
then finding the value (v-type). We can do the same with single-token
(N-type) arguments, which are often themselves functions and can be given as a
constructed name (c-type).
How about exhaustively expanding all of the tokens in an argument? To date,
that has been handled by x-type expansion. This uses \edef
behind-the-scenes, so the experienced TeX programmer will see that it cannot
itself work in an expansion context. Using \edef also has the side effect that
# tokens need to be doubled in the input.
\expandedA little while ago now, the LaTeX Team arranged for a ‘new’ primitive
\expanded to be added to the major TeX
engines. This works almost in the same
way as \edef except that it is itself expandable and it does not require #
tokens to be doubled. Using this primitive, we added e-type expansion to
expl3, and have used it for creating variants of expandable functions.
That left us with two almost-identical variants and a tricky task giving an
explanation of which to use, as there are places we want e-type expansion even
if the underlying function isn’t expandable (where that # doubling business is
an issue). In particular, with a bit of care for a few edge cases, it turns out
that everything that is set up for x-type expansion can be converted to
e-type. That includes things like \cs_set_nopar:Npx, where when you look
closely we should have called it \cs_set_nopar:Npe from the word go: there’s
no # doubling as this is just \edef renamed.
So we’ve now made the decision to pivot toward e-type expansion across the
board. We’ll be retaining the (now deprecated) x-type variants that are
already in expl3, but the documentation and all new variants will only be
e-type. Once the new release is out, package authors are encouraged to move
all of their x-type usage to e-type. The timeframe will of course depend on
the stability approach of individual package authors: for siunitx, I’m simply
going to step the minimum required expl3 release and be done with it, but
others may be more cautious.
What is important here is that almost all users should see minimal impact:
provided the installed expl3 core files match, there should be no obvious
change for end users. What we gain, though, at the code level is a lot more
consistency and clarity of design choice.
That leaves one additional variant: f-type, which is almost like e-type
but stops at the first non-expandable token. It exists largely as we needed
something expandable before we had e-type, but it still has a few edge use
cases. So we won’t be dropping it, but in almost all cases code using f-type
expansion can move to e-type. Again, I’ve done that in siunitx and will do a
sweep over the expl3 core soon. So we can expect to see a move to almost no
use of f-type other than some specialist low-level places.
A key driver in the tidy up here is that we would like to provide as far as
possible pre-defined variants for the core expl3 functions. That means having
some way of avoiding a combinatorial explosion: the more variants we need, the
more this is an issue. So we are aiming to get the ‘core’ set to n, V, v
and e, and N and c, with o and f where they are required. The latest
expl3 release fleshes out more pre-defined variants for this set, and we
expect that to grow a little more as we try to standardise more functions around
this core set.
The keen expl3 programmer is likely wondering what they need to do in detail.
Working on the basis that you are already requiring the expl3 release with
these changes (2023-10-10), then
x-type variants provided by expl3 have now got a matching e-type, so
you can simply change the naming unless …# tokens in an argument, in which case you also need to
undouble themx-type variants with e-type ones for internal codex-typeAs an example of the point on # tokens, you might currently have something like
\use:x
{
\cs_new:Npn \exp_not:N \mypkg_foo:w ##1 \c_colon_str ##2 \c_underscore_str
{
% Code using ##1 and ##2
}
}
which would need to change to
\use:e
{
\cs_new:Npn \exp_not:N \mypkg_foo:w #1 \c_colon_str #2 \c_underscore_str
{
% Code using #1 and #2
}
}
Of course, if there are no doubled # to worry about, it’s really just a
search-and-replace. So we can all now get on and use the ‘Jag’!
siunitx has supported uncertainty values in
numbers. Uncertainties are a key piece of information about a lot of scientific
values, and so it’s important to have a convenient way to present them.
The most common uncertainty we see is one that is symmetrical, a value
plus-or-minus some number, for example 1.23 ± 0.04. This could be a standard
deviation from repeated measurement, or a tolerance, or derived some other way.
Luckily for me, the source of such a value doesn’t matter: siunitx just
needs to be able to read the input, store it and print the output. For both
reading and printing, siunitx has two ways of handling these symmetrical
uncertainties
In version 3 of siunitx, I took that existing support and added a
long-requested new feature: rounding to an uncertainty. That means that if you
have something like 1.2345 ± 0.0367 and ask to round to one place, the
uncertainty is first rounded (to 0.04), then the main value is rounded to the
same precision (to 1.23).
Building on that, v3.1 added the idea of multiple uncertainties. These come up
in some areas (astronomy is one, particle physics another) where there are clear
sources of distinct uncertainty elements. Supporting multiple uncertainties also
means supporting descriptions for them: if you are dividing up uncertainty,
you likely want to say why. So in v3.1, you can say 1.23(4)(5) or 1.23 ± 0.04
± 0.05, and set up the descriptors, and have something like 1.23 ± 0.04 (sys)
± 0.05 (stat) get printed. I’ve not had any feedback yet on this new feature:
fingers-crossed that means it all works 100%!
Now, for v3.3, I’ve looked at another long-standing request: asymmetric
uncertainties. For this release, I’ve kept this area simple, as it’s one I know
less about. There’s just a ‘compact’ input form, and one (compact) output form.
So we can input 1.23(4:5) and get in TeX terms $1.23^{+0.04}_{-0.05}$
typeset. Asymmetric and symmetric uncertainties can be intermixed, and you can
have multiple asymmetric ones. I’m hoping this feature gets picked up by users,
and that I get some idea of what to do next. I suspect there might be
alternative output formats requested, and I wonder whether a ‘long’ input form
1.23 + 0.04 - 0.05 will be asked for: I’ve not done that yet as it’s more
tricky if the user misses one part out!
Hopefully, with the introduction of asymmetric uncertainty support, siunitx
covers just about all types of uncertainty in scientific data: aiming to be a
comprehensive (SI) units package, after all!