I’ve just sent the first (v0.1.0) release of 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.

ConTeXt has traditionally had a somewhat different distribution approach to other TeX code. The ConTeXt developers provide a stand-alone installer which provides the macro and Lua code which make up ConTeXt, the binaries which are needed and fonts in a predictable way. This self-contained approach makes it easier to ensure that macros, Lua and binaries are all matched up.

I talked a little while ago about work that the LaTeX Project team are doing on creating tagged PDFs automatically from ‘standard’ LaTeX sources. I promised to talk about how this might impact beamer, and was recently reminded about that.

We launched learnlatex to provide high-quality teaching of core LaTeX concepts with interactive examples. From the start, we wanted to offer the ‘course’ in multiple languages: this was part of the structure from the start.

When the LaTeX Project team took over maintenance of LaTeX from Leslie Lamport, LaTeX2e was planned as an intermediate release to resolve immediate issues with the then-current LaTeX2.09. The ‘e’ (or properly ε) was meant to indicate a small change from LaTeX2.09, with longer-term plans centred on LaTeX3. As we know, that proved rather hopeful, and we are still using LaTeX2e today: at least, that’s how it still announces itself.

The latest release of LaTeX went to CTAN on Friday, and moves us forward in truly automatic tagging for PDFs, particularly for mathematics. As part of the work, we have been looking at the capabilities of different engines. Here, I want to summarise what users should take from that for existing and for new documents.

The LaTeX Project have been working for about 4 years now on creation of automatically tagged PDFs from (more-or-less) unmodified LaTeX documents. We’ve been reporting regularly in LaTeX News, and things are moving forward nicely.

Controlling expansion has been a key part of 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).

Right from the first version, 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.

It is quite natural to think that separating a word up into individual characters is quite easy. It turns out that for the computer this isn’t really the case. If we look at a system that understands Unicode (like XeTeX or LuaTeX), most of the time one ‘character’ is stored as one codepoint. A codepoint is a single character entity for a Unicode programme. For example, if we take the input café, it is made up of four codepoints: