Paulo Cereda has updated his excellent TeXprinter application to version 2, and even posted a demonstration video. For those of you who’ve missed it, TeXprinter takes the information available on the TeX.sx Q&A site and turns it into a PDF or LaTeX source for printing. It’s therefore a great way to get something more permanent than a webpage, and in a variety of formats. I guess the next phase is to take multiple questions and automatically build an entire book of frequently asked (La)TeX questions!
A subject which comes up quite a bit is the age of TeX Live systems shipped with common Linux distributions. While the current ‘vanilla’ release is TeX Live 2011, many Linux distributions use TeX Live 2009, or even TeX Live 2007. This leaves many people wondering why. Now, I’m no expert in this area, but reading the various mailing lists gives me some ideas about the ‘time lag’. Some of this is technical, and some is more conceptual.
The first thing to say is that for many Linux users with a personal system, where they can install vanilla TeX Live each year directly from TUG, it’s probably easiest to simply not worry about this entire area and simply install TeX Live themselves. However, a lot of Linux systems are either multi-user or server set ups, and it’s there that a lot of the following is more important.
The technical reason for the delay seems to be the way binaries are ‘linked’ to standard support libraries. To understand this, you first need to know that most programs use third-party code for standard tasks. So for example pdfTeX uses libraries for both
.png and PDF support. In the vanilla TeX Live system (on Linux and other systems) these links are ‘static’, and the appropriate support material is supplied as part of the entire bundle. However, Linux distributions link ‘dynamically’. The advantage of the latter approach is that you only have one version of each library installed, and it is easy to update (for example for security fixes). So re-bundling TeX Live for Linux means building the binaries using dynamic linking. That of course means doing some work, and this is not trivial.
Size is the second stumbling block. TeX Live is big, as it includes a lot of (La)TeX packages and more importantly all of the documentation, mainly in PDF format. On a modern system, the hit in terms of hard disk space is not usually an issue, but at the same time there’s pressure in the Linux world to keep systems small and only install what is needed. So there is work to do in dividing TeX Live up into the constituent parts, a task that seems pretty difficult to me.
Finally, there is a conceptual point. TeX Live is not a single ‘product’, but is instead a bundle of different items from hundreds of different contributors. So while there is an overall TeX Live version, this does not reflect the status of each constituent part. The Linux packaging approach works best when each package has a small development team and a single version. It’s not really so well adapted to the much more diffuse status of items in TeX Live. So you often see discussions about stability, that probably make sense for a single software package but fits much less well for TeX systems.
As I said above, for single-user systems where the user can update TeX Live each year it’s probably easiest to simply bypass all of this. It’s also worth noting that having TeX Live available is a lot better than the alternative.
There is a lot of work going on to develop methods for directly including mathematical meaning in documents. Projects such as STIX, XITS and Latin Modern Math are intended to provide a range of glyphs for mathematical use while retaining meaning by using the appropriate Unicode code point. Undoubtedly, this is a great idea for reusing information. However, there is always a pay-off, and in this case it is some awkwardness with document styling.
In a standard TeX math font, attributes such as bold or sans-serif can be switched on pretty easily, and also apply on an ‘ongoing’ basis. I make use of this in siunitx to allow ‘detection’ of the local font conditions. Life is much more complex with Unicode maths fonts. Instead of something like bold being a casual attribute of a symbol, it’s intrinsic to the symbol. So you can’t simply switch from on bold, or sans-serif, or anything else.
For serious mathematicians, that probably makes good sense: they make a wide and complex use of the appearance of symbols to convey meaning. On the other hand, it’s a bit awkward if you have a caption which is set in bold and want your simple piece of mathematics to match. I’m still thinking about the best way to handle this: suggestions are welcome!
The regular arrival of TUGBoat is always welcome, and a chance for an interesting read. Everyone will have their favourite entry, but I thought I’d pick out one or two highlights.
Hans Hagen writes about creating e-books using ConTeXt. Now, there is a lot of very good information in the article about the problems at hand. However, what makes it a highlight for me is the take he has on the e-book concept. There are a lot of very good points about the limits of an electronic book: for example, drop a book and it will be fine, drop an e-book …
Another highlight for me is not an original article but a reprint. Now reprints on TeX topics are not unusual, but in this case they’ve looked a bit wider and included one from Print, a magazine dedicated to visual design. Looking at books as design objects, rather than as something to code, is a refreshing change (at least for me)!
The third highlight for me is not a single article, but a set of book reviews. Boris Veytsman has taken on the task of co-ordinating (and often writing) reviews, and the current TUGBoat includes four. Hopefully this will be a regular feature, and help keep us all up to date with what’s going on in print for both TeX users and the wider world.