ConTeXt in MacTeX 2011

I recently stumbled across an issue with my ConTeXt set up, while looking at a question about Tikz and ConTeXt. While ConTeXt Mark II was fine, I got the rather cryptic error:

mtxrun          | forcing cache reload
resolvers       | resolving | configuration files already identified
resolvers       | resolving | skipping configuration file
'selfautoparent:/texmfcnf.lua' (no content)
resolvers       | resolving | no texmf paths are defined (using TEXMF)
resolvers       | resolving |
mtxrun          | the resolver databases are not present or outdated
resolvers       | resolving | using suffix based filetype 'lua'
resolvers       | resolving | using suffix based filetype 'lua'
resolvers       | resolving | remembered file 'mtx-context.lua'
resolvers       | resolving | using suffix based filetype 'lua'
mtxrun          | unknown script 'context.lua' or 'mtx-context.lua'

when trying to run ConTeXt Mark IV. It seems that this because I installed MacTeX 2011 during pre-testing. A quick e-mail to the ConTeXt mailing list pointed to the file /usr/local/texlive/2011/texmfcnf.lua, which for me read

-- (Public domain.)
-- This texmfcnf.lua file should exist only if you have personal changes
-- from the distributed file; for example, if TEXMFVAR was changed in
-- the installer.
return { TEXMFCACHE = '~/Library/texlive/2011/texmf-var' }

It seems that this is defective, as replacing the content with

return {
  content = {
    variables = {
      TEXMFHOME = "~/Library/texmf",
      TEXMFVAR = "~/Library/texlive/2011/texmf-var",
      TEXMFCONFIG = "~/Library/texlive/2011/texmf-config",

(as suggested by Mojca Miklavec) sorted the issue straight away.

EuroTeX 2009 Proceedings

In my post box a few days ago was the proceedings of the EuroTeX 2009 conference (TUGBoat 30:3, which I get as a joint member of TUG and UK-TUG). Quite a few of the articles are about ConTeXt, not surprising as the 3rd ConTeXt meeting took place in parallel to EuroTeX. The highlights will be different for everyone, of course. I’ll pick out a few articles that caught my attention (and perhaps add a few more in a later post):

  • Siep Kroonenberg wrote about maintaining a (Windows) network installation of TeX Live. While not a step by step guide, I found this a useful insight into getting started on providing multi-user access to TeX.
  • Péter Szabó looked at optimising PDF size, both using pdfTeX and with post-production tools. This has come up recently on the TeX Live mailing list, so it was interesting to see more detail about the concepts involved.
  • Taco Hoekwater explained how the development work on LuaTeX has finally removed all of the Pascal code from the sources, and why this was a ‘Good Thing’. An interesting insight into work at the engine level.
  • In the ‘Abstracts Only’ section I was particularly interested in one about PPCHTeX by Hans Hagen. PPCHTeX is an approach to typesetting chemical structures in TeX, and is therefore of more than passing interest to me in my day job.

I note for my diary that EuroTeX 2010 is scheduled for the 25th to the 29th of August 2010 in Pisa. I’ll see how my diary works out: perhaps I’ll make this one!

Lua, TeX, LaTeX and ConTeXt

There is currently a very active thread on comp.text.tex about LuaTeX. Several related questions have come up, and it seems that some kind of summary would help me, at least.

Why did the LuaTeX team choose Lua?

Possibly the most frequently asked question with LuaTeX is why the team behind it chose Lua, as opposed to one of the other scripting languages available. The LuaTeX FAQ addresses this as question 1, so it’s obviously important. As I understand it, they looked at a number of possible languages for extending TeX, and decided that many of the “obvious” candidates (Java, Perl, Python, Ruby, Scheme) were not suitable. Not everyone is going to agree with that assessment, and some people are bound to feel that there was not sufficient consultation.

With LuaTeX already at version 0.40, it is progressing and will deliver. So unless a team can be got together to provided an alternative scripting system, it looks like Lua is what we will get. I don’t see there being enough experienced programmers with time on their hands to deliver a complete alternative at the moment.

How does LuaTeX relate to ConTeXt and LaTeX?

LuaTeX is an “engine”, like pdfTeX or XeTeX. So it provides certain functions, which might or might not get used. The end-user can use them directly, but this is really not helping most people as they don’t want to do this type of low-level work. So in the main it is down to either the TeX format (ConTeXt, LaTeX, …) or an add on (LaTeX package, ConTeXt module, etc.) to take advantage of them.

In the ConTeXt case, the entire format is being re-written as “Mark IV”, which will use a lot of Lua. This of course means things fundamentally change compared to early versions of ConTeXt, and ties it to a single engine.

In the LaTeX case, the format is written to work on plain TeX, no extensions at all. That is not about to change: essentially, LaTeX2e will never be “updated” in that sense. The current LaTeX3 plans don’t envisage requiring LuaTeX, although I’d hope that some low-level support will be included if LaTeX3 ever becomes a reality. There will, though, be LaTeX packages that use Lua: I’m sure that at some point there will be a fontspec-like package for LuaTeX, for example.

What is wrong with LaTeX2ε?

One issue that always comes up when future directions for TeX are discussed is whether LaTeX2ε needs to change, or whether it is okay as it is. Currently, if you know what you are doing then you can achieve a lot with LaTeX. There are a vast range of packages, and these cover very many of the things you could ever hope to do in TeX. So in a sense LaTeX works as it is. On the other hand, you have to know which packages to load, even to get some of the basics right (try making a new float type without loading any packages and using one of the base classes!). At the same time, things like UTF-8 text, system fonts and so on are not available using only the kernel.

A more fundamental issue is that LaTeX currently doesn’t do enough to provide structured data, and is not a good choice for dealing with XML input. This makes it hard to get data in and out, and is closely related to the fact that there is not enough separation of appearance and structure in the kernel and in add-on packages.

Neither of these points has escaped the notice of the LaTeX team. The question is whether a successor to LaTeX2ε will appear, and if it does whether it can succeed. There is a need to start from scratch with many things, meaning that a new LaTeX simply won’t work with most packages currently available. So the team have to deliver something that really works.

How can (La)TeX recruit new users?

One question that comes up here is what is a typical (La)TeX user anyway. Everyone has their own view on this: some people see TeX users mainly as mathematicians and physicists, other people point out that particularly with XeTeX available there is a lot of potential in the humanities.

Making life easier for new users is a priority for gaining new users. This means making it easy to install TeX (which both TeX Live and MiKTeX do, I think), making it easier to edit TeX files (the excellent TeXworks helps here), and making it easier to use TeX. It is, of course, the last one that is the problem. I think that we do need a new LaTeX as part of this. Removing the need to load a dozen packages and alter half a dozen internal macros to get reasonable output would benefit all LaTeX users. At the same time, something as simple as a generic thesis template could be made available: that would again help to “sell” LaTeX and by extension TeX as a whole.

LuaTeX has a role to play here. Using system fonts with pdfTeX is not easy, and XeTeX has helped a lot with this. LuaTeX provides this possibility and many more, and so we can hopefully look forward to not having to worry about loading system fonts at all. At the same time, it should be possible to do things similar to the current BibTeX and MakeIndex programs directly in the engine, but with full UTF-8 input. This is something that is long overdue, and again can’t hurt when it comes to selling (La)TeX.

Programming: Lua versus TeX

As LuaTeX progresses, the desire to use it in real documents increases. ConTeXt Mark IV is clearly the leading exponent of this, although it is still experimental and so perhaps not the best choice for day-to-day work. Karl Berry has said to me that he hopes that the inclusion of a “proper” programming language will bring new talent to (La)TeX. After all, some of the methods used to program TeX are complex to say the least.

This raises the question of how much to do in Lua and how much in TeX. Clearly, LuaTeX brings things to TeX that are impossible without it. So there it is simple: use Lua. However, what about things that can be done with either Lua or TeX? Part of this probably depends on the complexity of the different solutions (if it is easy in TeX, why do it in Lua, and vice versa). I’d also imagine that experiences TeX programmers will tend to stick to what they know, and favour TeX. On the other hand, new programmers coming to TeX because of Lua will favour the Lua route. I imagine that there will still be a lot more TeX than Lua code.

Units in ConTeXt

Looking to gather ideas, I was looking at the ConTeXtunits” module. The approach taken there is to create free-standing macros, such as \Second or \Candela, and to use them to build up a string of units. Like some of the LaTeX solutions, this means that the user has to maunally include symbols (such as \Times) to get the formatting right. On the other hand, ConTeXt uses a glossary-like method for defining units (something I’ve thought about for siunitx in the past). I’ll certainly be thinking about something like that for siunitx version 2.