TeXLive deadline approaching

The deadline for inclusion in TeX Live 2009 is approaching (some time in May, I think). I’ve got a few things I’d like to get in, so they are keeping me busy. The updates to rsc, achemso (which had a bug fix today) and trivfloat should all be included, and I want to fix one thing in siunitx and look at some chemstyle issues. As well as that, there have been some things for LaTeX3 to get sorted out: it now includes a new “messages” module l3msg. So work on siunitx version 2 is currently a little delayed. Hopefully I’ll get back on to that next week.

Submission template for the RSC

I’ve just uploaded a new version of my rsc package to CTAN. There are a few improvements to the BibTeX styles the package provides (mciteplus is still supported, but is no longer mandatory), but the main change is that I’ve added a short template to the bundle. I get the occasional e-mail seeking advice about writing papers to submit to the RSC, so it seemed like a good idea to provide something a bit more formalised than the odd hint to individuals.

Of course, I don’t know what the RSC want, but I’ve got a pretty good idea about what most chemistry paper drafts look like. I’ve also got the work I’ve done on achemso to go from. The basic points are to keep it simple and not to expect “publication ready” formatting. I think this confuses a lot of people who come from a more physics-based background. A lot of physics journals typeset stuff directly from authors’ drafts, and so print-ready templates are common. On the other hand, in chemistry papers tend to be submitted in Word format and are extensively altered by the publishers. So there is no real need for print-ready material when submitting to chemistry journals.

Hopefully, the clues I’ve provided in the rsc bundle will make life a little easier for prospective authors.

trivfloat reaches v1.4

The LaTeX kernel does not make it easy to make new types of float. As a result, packages such as float and floatrow have been developed to make life easier. The memoir class includes similar functionality. However, all of these systems still require modifications to get new floats to look like the base LaTeX ones. So some time ago I wrote the trivfloat package, which warps all of this up into a single macro. I’ve not heard much from users, so the package had not been looked at by me for about 18 months, until today.

What happened today? An e-mail from Hinrich Goehlmann, who found a bug in the package. Hinrich was in a hurry (apparently he’s got a book to get to the publishers), so I got the bug sorted and something back to him over lunch. I then decided to review the package rather more carefully, and the result is v1.4, on its way to CTAN now. I’ve extended the functionality a bit, added support for floatrow, tidied up the code and also fixed the bugs (I hope). I’m pleased that trivfloat is providing useful: the aim is to make users lives easier, with all of the hard work hidden away.

LuaTeX reachs 0.40

A recent announcement on the LuaTeX mailing list that LuaTeX has reached v0.40 has been expected for a while. One of the most notable, and widely discussed, changes is in the way new primitives are made available. As of 0.40, “out of the box” LuaTeX only provides one new primitive, \directlua. To get any primitives beyond those from TeX82, you then have to call Lua and get it to turn them on. The reason for this rather radical change is that it avoids any name clashes between new primitives and existing packages. So LuaTeX should, in principle, be able to replace pdfTeX as the engine of choice for most people. Of course, that is still some way off: LuaTeX is scheduled to reach version 1.0 in 2012.

achemso updated to version 3.2

I’ve just uploaded version 3.2 of achemso to CTAN, and also sent it off the the American Chemical Society. The development for v3.2 has mainly been about making using the package easier for end users. I’ve removed a lot of dependency on other support packages, so that it only uses very standard LaTeX packages (things like float and caption). I’ve also made the package cope better with older versions of xkeyval, by using only a subset of the functions provided there. There are a few bug fixes as well, plus a new environment for graphic TOC entries. Hopefully, this makes life easier for manuscript authors.

TeXworks for developers

The TeXworks program is aim at making using TeX easier for day-to-day TeX users. By stripping the interface down to a minimum, I feel it really succeeds. I’m sure that many experienced TeX developers prefer more “full featured” editors (such as WinEdt on Windows or AUCTeX on Linux). However, I find that I rarely use any of the more complex features of these richer editors, and so I’m using TeXworks for both day-to-day documents and writing LaTeX packages.

There are still a few things I’d like to have in TeXworks that are currently lacking, but I’m hoping that as the program develops it will be possible to do some user extension and add on what I’d like. For example, I’d like to be able to use hard line wrapping (with a fixed number of characters in a line) and to delete lines of text rapidly (“killing” them). What I have been able to do so far is create some customised syntax highlighting and some completion code, similar to DTX submode for WinEdt. At the moment, the syntax highlighting I’ve gone for looks like:

[dtx patterns]

# comments
red		Y	\^\^A.*

# special characters
darkred		N	[$#^_{}&]

# Guards
gold		N	%<(?:[A-Za-z0-9!\|]+|.)>
limegreen	N	%<\*(?:[A-Za-z0-9!\|]+|.)>
crimson		N	%</(?:[A-Za-z0-9!\|]+|.)>

# Macrocode
green		N	^%[\s]{4}\\(?:begin|end)\{macrocode\}

# LaTeX environments
darkgreen	N	\\(?:begin|end)\s*\{[^}]*\}

# LaTeX packages
darkblue	N	\\usepackage\s*(?:\[[^]]*\]\s*)?\{[^}]*\}

# control sequences
blue		N	\\(?:[A-Za-z@:_]+|.)

# Non-code
grey		Y	%.*

which is certainly helping me to improve my understanding of regex writing! There are a few things I can’t seem to get working quite as I’d ideally like, but for the moment I’m happy.

For auto-completion, I’ve had to make some assumptions about the beginnings of lines, to get the % characters correct:

%%!TEX encoding = UTF-8 Unicode
arg:=\Arg{#INS#}
bcode:=    \begin{macrocode}#RET##INS##RET#%    \end{macrocode}#RET#•
benv:=\begin{environment}{#INS#}#RET#%•#RET#%\end{environment}#RET#%•
bmac:=\begin{macro}{#INS#}#RET#%•#RET#%\end{macro}#RET#%•
cc:=\changes{#INS#}{•}{•}#RET#•
cmd:=\cmd{#INS#}
cs:=\cs{#INS#}
denv:=\DescribeEnv{#INS#}
dmac:=\DescribeMacro{#INS#}
dopt:=\DescribeOption{#INS#}
ecode:=    \end{macrocode}#RET##INS#%    \begin{macrocode}#RET#•
eenv:=\end{environment}#RET#
emac:=\end{macro}#RET#
m:=\meta{#INS#}
meta:=\meta{#INS#}
pkg:=\pkg{#INS#}
\Arg{#INS#}
\changes:=\changes{#INS#}{•}{•}#RET#•
\cmd{#INS#}
\cs{#INS#}
\meta{#INS#}
\pkg{#INS#}

I’d be interested to hear how other people find TeXworks for writing TeX code, and of course for any contributions to my configuration ideas.

TeXworks updated

The TeXworks program has had a few bug fixes recently, for example to get spell-checking and syntax highlighting to work together properly. For Linux users, compiling from the source is the best way to get a current build. For those of use on Windows, Alain Delmoitte is very kindly providing public builds now and then: he has updated his build to build 291. Alain is also working on a manual (in French and English) for TeXworks, available from the same site.

Beyond BibTeX: the first biber beta release

A notice in my inbox from François Charette alerted me yesterday to the first beta release of biber. This is a cross-platform (Perl) replacement for BibTeX for biblatex users. By moving on from BibTeX, there are a number of advantages. First, the problems inherent in the BibTeX code (no Unicode support, memory limitations and so on) are removed. The need for something beyond BibTeX is a well-known problem.

More importantly, biber comes with an experimental XML file format as a replacement for the .bib file type. The limitations of the .bib approach are more subtle than those of BibTeX itself. A lot of problems stem from the simplicity of the .bib format. This severely limits how much detail can be given for complex data types. For example, there is no good way to give multiple publishers and locations in the .bib format:

publisher = {{First Company} and {Second Company}},
location = {Town and OtherTown}

So which place goes with which publisher? We might assume the first with the first, the second with the second, but why not both locations for both publishers or something more complex? By starting from the biblatex experience, biber can build in this type of data from the start. Particularly in arts subjects, this looks like a great idea.

One important question is publicity. Within the LaTeX world, biblatex is still not that widely used. This is of course partly as it is still in beta. However, for biber to succeed both it and biblatex need publicity outside of LaTeX. One obvious route is to talk to the people who develop things like JabRef, BibDesk and so on. These programmes use the .bib format to store data, but can be used without ever going near LaTeX. Other ideas are I’m sure welcome!

Over all, I’m very excited by biblatex and biber. It’s clear that biblatex is a major advance for LaTeX users, and anything that makes life easier is welcome.