Finding symbols

Usually, finding a symbol in (La)TeX means reading through Scott Pakin’s Comprehensive Symbol List. However, that can be hard if all you know is what the symbol looks like. A while ago, there was a suggestion to create some kind of system to find symbols from a drawing. Daniel Kirsch has now taken this on and created Detexify. Initial impressions are very good: the idea is great and is clearly something to keep an eye on. The system relies on being trained: hopefully, a few people taking an interest will build up a good set of training data quickly.

Lowering the entry barrier

There has been a very active thread recently on the TeXworks mailing list concerning how the aim of “lowering the entry barrier to the TeX world” goes beyond the basics of the TeXworks interface. There are, as always, lots of ideas, with several very important points raised.

One big issue is the separation of TeX distributions, TeX engines and TeX editors. How do you explain to a new user that their editor is not their TeX system, and that their TeX system is independent of the engine they are using. This is all complicated, and it is not easy to put it into two or three sentences! All-in-one installers help to some extent, but that can lead to confusion later.

Another issue is which format to choose as the default. Currently, this is pdfTeX (plain TeX using the pdfTeX engine). Is this a good choice for beginners? Probably not the best, but then almost every other choice has pluses and minuses. If you favour pdfTeX as the engine, using system fonts and Unicode input is more awkward. On the other hand, if XeTeX is the default engine, then there are issues with micrography and interacting with other people. Then there is the LaTeX versus ConTeXt choice, and again you can argue things both ways.

TeXworks is designed around PDF output. That is a good thing in the long term, but at the moment a lot of people still want to use the DVI route. Making that available from within TeXworks is hard to do in a cross-platform way (things that work on *nix fail on Windows).

There are other issues. For example, how much help should be built into TeXworks: again, the TeX format makes a difference here. Error-tracking is another awkward one: the differing formats again do different things.

There are a lot of difficult issues, and they are definitely worth thinking about. One day we’ll have LuaTeX finalised (and perhaps even LaTeX3), and some of these things will be sorted. But at the moment, there is lots to do.

UK TeX FAQ

Robin Fairbairns released a new version of the UK TeX FAQ last week. As always, Robin has done a great job adding even more useful information to the list: over 400 questions and rising! In the release notice, Robin says

my target is to make it possible for the faq to be a collaborative project

I hope that Robin gets some volunteers: I’ve already dropped him a line offer whatever help he needs. The FAQ are really vital to the TeX community, and I think everyone benefits from them.

LaTeX3: xparse

The next step for LaTeX3 development is to revise the two existing “xpackages” which are available to make a link between the code level and the user: xparse and template. Of the two, the xparse package is by far the easier to understand.

In LaTeX2e, you can either use the LaTeX method to create new commands:

\newcommand*\mycommand[2][]{%
  code goes here, using #1 and #2
}

or you can do things yourself using a mixture of TeX primitives and LaTeX internal functions (and ignoring the issue of default value):

\def\mycommand{%
  \@ifnextchar[{%
    \@mycommand
  }{%
    \@mycommand[]%
  }%
}
\def\@mycommand[#1]#2{%
  code goes here, using #1 and #2
}

This does not make for code which is easy to alter to reflect different input syntax (for example XML), or to change internal functions without knowing how the user input works. The idea of xparse is to separate out the user syntax from the internal code. Currently, exactly what tools need to be available is still being decided. The current version of xparse would expect the following syntax:

\DeclareDocumentCommand \mycommand { o m } {
  code goes here, using #1 and #2
}

The idea is that each argument is represented by a letter, for example o for an optional argument, m for a mandatory one or s for an optional star. This makes it possible it see immediately from the definition how many arguments are needed (one for each letter). It also means that the internal functions, which implement things, can be separated totally from the user part of the system. In that way, internal functions can have a fixed number of arguments, and leave xparse to supply them. So if the internal function needs to be changed, it does not matter how it is used, or vice versa.

That all sounds very good, but there are some outstanding issues. For example, handling verbatim arguments is not straight-forward. There are a couple of possible approaches to this. Either stick to a simple system, and accept that not everything can be done in the same way, or make the system more flexible but complicated. I’m currently in favour of the first approach: almost every user function is simple (especially as we have the ε-TeX extensions and so can \scantokens our way out of a lot of problems). I’d be interested to hear what other people think would be useful.

LaTeX3 snapshot release

The LaTeX3 Project (of which I’m a member) have made a snapshot release of the current LaTeX3 code to CTAN today. This is in two parts:

  • expl3, the base layer for LaTeX3, which provides a consistent programming interface for LaTeX3 on top of TeX (or rather, on top of pdfTeX, XeTeX or LuaTeX).
  • xpackages, higher level interface ideas for LaTeX3.

expl3 is now reasonably stable: the code has been carefully reviewed and the Team are happy that what is there works well. There are gaps, and some of these are definitely on the “to do” list. On the other hand, the xpackages bundle is not so close to being finished. At the moment, it includes only the parts of the experimental code that look the closest to reaching some kind of conclusion. However, it is also the part that is actively being reviewed at the moment. So I expect changes!

I’m hoping that as expl3 gets distributed around the TeX world it will be possible to consider using it for coding new packages. The ideas in expl3 make coding much easier, over all, even if initially there is a lot to learn. Of course, delivering more of LaTeX3 will help in getting people interested as well. That is something I’m definitely keen on.

Scripting in TeXworks

Stefan Löffler has recently posted to the TeXworks mailing list that he’s sorted out a patch to integrate Lua into TeXworks. Many people will be aware that Lua is very much the scripting language of the moment in the TeX world, because of the LuaTeX project. So it makes sense to consider it as a method for scripting TeXworks. The idea has always been that TeXworks will have a simple interface but powerful features available to those who want them. So adding scripting is a vital step forward. With a light-weight scripting system available, power users can code their own features into TeXworks while leaving the basics accessible to everyone.

That doesn’t mean that Lua has to be the (only) language available: Jonathan Kew (TeXworks lead developer) has suggested QtScript (which is JavaScript-like) as a possibility. TeXworks is built using Qt, so there is a definite logic here. As Jonathan himself points out, actually having a patch available certainly means that Lua is likely to be integrated!