I'm happy to announce that my contribution to TUG 2012, the next TeX Users Group International conference, has been accepted. Please find the title and abstract below.

Star TeX, the Next Generation

In 2010, I asked Donald Knuth why he chose to design and implement TeX as a macro-expansion system (as opposed to more traditional procedure calls). His answer was that:

1. he wanted something relatively simple for his secretary who was not a computer scientist,
2. the very limited computing resources at that time practically mandated the use of something much lighter than a true programming language.

The first part of the answer left me with a slight feeling of skepticism. It remains to be seen that TeX is simple to use, and when or where it is, its underlying implementation has hardly anything to do with it.

The second part of the answer, on the other hand, was both very convincing and arguably now obsolete as well. Time has passed and the situation today is very different from what it was 50 years ago. The available computing power has grown exponentially, and so has our overall skills in language design and implementation.

Several ideas on how to modernize TeX already exist. Some have been actually implemented. In this talk, I will present mine. Interestingly enough, it seems to me that modernizing TeX can start with grounding it in an old yet very modern programming language: Common Lisp. I will present the key features that make this language particularly well suited to the task, emphasizing on points such as extensibility, scriptability and multi-paradigm programming. The presentation will include reflections about the software engineering aspects (internals), as well as about the surface layer of TeX itself. Most notably, I will explore the possibilities of providing a more consistent syntax to the TeX API, while maintaining backward compatibility with the existing code base.

Hello, I'm happy to announce the release of DoX v2.2. DoX is a set of extensions to the Doc package, for LaTeX2e class and style authors.

New in this release: the ability to create new control-sequence based documentation items (for instance LaTeX lengths).

Hello,

I'm happy to announce the release of FiNK 2.2. FiNK is the LaTeX2e File Name Keeper. New in this release: FiNK is now compatible with the memoir class.

Grab it here

I'm pleased to announce that my article entitled "Classes, Styles, Conflicts: the Biological Realm of LaTeX" has been published in the TUGboat journal, Volume 32 N.2.

There is also a live video recording of the presentation. See http://www.lrde.epita.fr/~didier/resear ... rna.10.tug

I'm happy to announce FiXme version 4.0

#### WARNING: this is a major release containing many new features and heavy
#### internals refactoring. FiXme 4.0 comes with unprecedented flexibiity,
#### unrivalled extensibility and unchallenged backward-INcompatibility.


What's new in version 4.0
=========================
* Support for collaborative annotations
suggested by Michael Kubovy
** Support for "targeted" notes and environments
(highlighting a portion of text), suggested by Mark Edgington.
** Support for "floating" notes
(not specific to any portion of text), suggested by Rasmus Villemoes.
** Support for alternate layout autoswitch in TeX's inner mode
suggested by Will Robertson.
** Support for automatic language tracking in multilingual documents
** Support for themes
** Extended support for user-provided layouts
** Support for key=value argument syntax in the whole user interface
** New command \fxsetup
** Homogenize log and console messages
** Heavy internals refactoring


Description
===========
FiXme is a collaborative annotation tool for LaTeX documents. Annotating a
document refers here to inserting meta-notes, that is, notes that do not
belong to the document itself, but rather to its development or reviewing
process. Such notes may involve things of different importance levels, ranging
from simple "fix the spelling" flags to critical "this paragraph is a lie"
mentions. Annotations like this should be visible during the development or
reviewing phase, but should normally disapear in the final version of the
document.

FiXme is designed to ease and automate the process of managing collaborative
annotations, by offering a set of predefined note levels and layouts, the
possibility to register multiple note authors, to reference annotations by
listing and indexing etc. FiXme is extensible, giving you the possibility to
create new layouts or even complete "themes", and also comes with support for
AUC-TeX.

FiXme homepage: http://www.lrde.epita.fr/~didier/softwa ... .php#fixme

I'm happy to annouce the first public version of the DoX package for LaTeX2e.

The doc package provides LaTeX developers with means to describe the usage and the definition of new macros and environments. However, there is no simple way to extend this functionality to other items (options or counters for instance). The dox package is designed to circumvent this limitation.

For many of my lectures, I use the Listings package for typesetting code excerpts, and include them in Beamer blocks. Providing nice shortcuts for doing that is not trivial if you want to preserve control over Listings options, and add a new one for the block's title. Here is a way to nicely wrap a call to \lstinputlisting inside a Beamer block.

First, let's use the xkeyval package to create a "title" option:

\define@cmdkey[dvl]{lst}[@dvl@lst@]{title}{}

Next, a low-level listing input command. This macro takes 4 arguments: an overlay specification, a title for the block, a list of options passed to Listings, and a file name for input:

%% \dvlinputlisting{overlay}{title}{lstoption=,...}{file}
\newcommand\dvlinputlisting[4]{%
  \begin{block}#1{#2}
    %% #### WARNING: I need this hack because keyval-style options
    %% mess up the parsing.
    \expandafter\lstinputlisting\expandafter[#3]{#4}
  \end{block}}

And now, you can define all sorts of specialized versions for different languages. For example, here is one for Common Lisp code. The block title is "Lisp" by default, and a "lisp" extension is automatically added to the file name:

%% Language-specific shortcuts:
%% The title option is used for the beamer block's title.
%% All other options are passed to listings.
%% \XXXinputlisting<overlay>[title=,lstoption=,...]{file}
\newcommand<>\clinputlisting[2][]{%
  \def\@dvl@lst@title{Lisp}%
  \setkeys*[dvl]{lst}{#1}%
  \edef\@dvl@lst@options{language=lisp,\XKV@rm}%
  \dvlinputlisting{#3}{\@dvl@lst@title}{\@dvl@lst@options}{#2.lisp}}

Which you could call like this:

\clinputlisting<2->[title={Example 1}, gobble=2]{ex1}

As you can see, "title" is an option for the Beamer block, and all the others are dispatched to Listings. Cool.


Now, things are getting more complicated when you want nice shortcuts for inline environments, because nesting Beamer blocks with listings doesn't work. Fortunately, I figured out a trick based on the Verbatim package to simulate that. The idea is to store the contents of the listing environment in a temporary file, and use \lstinputlisting as before to include it. Clever right ?
:-)
Here is a generic environment for doing that. In the opening, we read the environment's contents and store it in the file \jobname.dvl. In the ending, we call our previous macro \dvlinputlisting on that file (actually, on a dynamically created argument list called \@dvl@args:

\usepackage{verbatim}
\newwrite\lstvrb@out
\def\@dvllisting{%
  \begingroup
  \@bsphack
  \immediate\openout\lstvrb@out\jobname.dvl
  \let\do\@makeother\dospecials\catcode`\^^M\active
  \def\verbatim@processline{%
    \immediate\write\lstvrb@out{\the\verbatim@line}}%
  \verbatim@start}
\def\@enddvllisting{%
  \immediate\closeout\lstvrb@out
  \@esphack
  \endgroup
  \expandafter\dvlinputlisting\@dvl@args}

And now, we can define all sorts of specialized versions for every language we're insterested in. Again, here is one for Common Lisp.

\newenvironment<>{cllisting}[1][]{%
  \def\@dvl@lst@title{Lisp}%
  \setkeys*[dvl]{lst}{#1}%
  \edef\@dvl@lst@options{language=lisp,\XKV@rm}%
  \xdef\@dvl@args{{#2}{\@dvl@lst@title}{\@dvl@lst@options}{%
    \jobname.dvl}}
  \@dvllisting}{%
  \@enddvllisting}

Which you can use like this:

\begin{cllinsting}<2->[title={Example 1},gobble=2]
  (defun foo (x) (* 2 x))
\end{cllisting}

Don't forget that frames containing code excerpts like this are fragile!

I'm happy to announce the next edition of CurVe, a LaTeX2e class for writing curricula vitae.

What's new in this version:
** Support for itemize environments, suggested by Mirko Hessel-von Molo.
** Added some documentation about vertical spacing problems in |bbl| files, suggested by Seweryn Habdank-Wojewódzki.

I'm happy to announce the next edition of CurVe: version 1.14.

CurVe is a Curriculum Vitae class for LaTeX2e. This version adds support for Polish, and an option to reverse-count bibliographic entries.

Enjoy !

Some time ago, I was thinking about the generation of PostScript and/or PDF from TeX documents (I will speak indifferently of TeX and LaTeX). Knowing that several options are available, I was wondering which solution people preferred. This question triggered a thread on comp.text.tex from which I relate some interesting excerpts here. In order to clarify the debate, I have tweaked or modified several of the quotations. This is a personal manipulation which does not involve the original authors. For that reason, I don't associate them directly to the text below. Warning: the first person comments below are not all mine!

A last note: some arguments about the quality of the available visualization tools appeared in the thread. I have excluded them from the debate, since the central question was the quality of the rendering, not the ergonomy of the tools that handle them.

Participants (besides myself): LEE Sau Dan, George N. White III, David Kastrup, Mike Oliver, H.S. (??). Thanks to them for their comments.

Options

Direct approach:

TeX -> (tex)    -> DVI -> (dvips) -> PostScript
TeX -> (pdftex) -> PDF

Indirect approaches:

TeX -> (tex) -> DVI -> (dvips) -> PostScript -> (ps2pdf) -> PDF
or:
TeX -> (pdftex) -> PDF -> (pdf2ps) -> PostScript

And note that it is also possible to generate PDF from the DVI file...

Direct or indirect approach ?

pdftex does not necessarily generate the same layout as tex. pdftex allows more flexibility in adjusting the character spacing, etc, and hence may break lines differently than Knuth's tex. It doesn't occur that often, though.

pdftex can produce visually more even margins (by allowing some glyphs to protrude), which in turn allows you to use slightly narrower gutters in multi-column layouts. Not only does this save trees, it also gives effectively longer lines and so reduces the number of bad breaks, rivers, etc. This is especially helpful if you are trying to use a CM-based font in a layout originally intended for Times-Roman.

One has to remember that if you want to use the direct approach, you won't be able to use target-specific additions in your source file, or will need different versions of parts of it (perhaps in conditionals) according to the target language. For instance, it is impossible to use pstricks with pdftex because pstricks is PostScript-specific (but see pdftricks...).

If your required packages vary according to the target language (e.g. you want hyperref for PDF output, but not for PostScript), you will most certainly have problems compiling your document in a single directory tree. That's because the aux files will vary according to your target language. So either you make clean before changing your target, or you compile (outside of the source tree) in different subtrees. This can be somewhat cumbersome, although a simple use of Makefiles and of the TEXINPUTS environment variable makes this process quite easy.

This only real disadvantage that remains is that you have to
compile your document entirely twice (once for
each target language), so it takes more time than with one of
the indirect approaches.

So bear in mind that a direct approach might give slightly different documents.

Cons the PDF to PS conversion

PostScript Level 3 supports PDF with minimal translation. Older printers with Level 1 interpreters often choke on PS files created from PDF, and there are sometimes problems with Level 2 printers. In some circles PDF has a bad reputation based on bugs in early software and problems rendering PDF using old rasterizers. When a PDF file is translated to PS, the driver generally just loads PS code to define the PDF primitives. With current rasterizers this PS code is fairly simple, but with older rasterizers the code is considerably more complex and almost sure to give problems under stress.

The following arguments come from people programming PostScript directly, which is not supported with pdftex:
EPS -> PDF conversion means a loss of the PostScript elegance. Compact, repetitive code gets expanded, and hence file size gets inflated.

This is about using Postscript source translated to PDF, and the converting the PDF document to PostScript.
Compact Postscript code (such as fractals) will be expanded in this final Postscript file, thanks to PDF's Turing-incompleteness. This means an inflated final file size.

But if you need PDF output, you can't cope with its Turing-incompleteness, right?

However, some people note that:
The lack of support of literal Postscript code and EPS figures (yes, I know epstopdf) is irritating. I'm switching most of my drawings, etc. to METAPOST for its elegance, and it's good news to learn that pdftex can include METAPOST figures directly (as long as I don't insert literal Postscript with the 'special' command in METAPOST).

Pro TeX -> DVI -> PS / PDF

EPS or EEPIC are not supported by pdftex. METAPOST is supported though.

However, unless you have a tightly controlled source of EPS figures, the conversion from EPS to PDF is a tricky step, and can require tweaks (and even bug fixes to the conversion tool) to deal with the idiosyncracies in individual files. This is much easier to get right and to debug if you convert each EPS to PDF separately than if you have problems with a document level conversion.

So this might eventually turn into an argument in favor of the direct approach.

Pro TeX -> PDF -> PS (throwing DVI away)

But note that you can produce DVI with pdftex: use the command \pdfoutput=0

TeX has information that gets discarded in the DVI file but which can be used by pdftex. Information available to TeX macros can be put into \specials for dvips, but pdftex can also get information from TeX's internals.

Some people object:
You still haven't specified which particular \specials are causing problems. I have been using the hyperref package for some time. With this package, I can insert document infos such as author, title, etc (displayed in Acrobat Reader when you pop up the Document Info window (Ctrl-D in some versions)). The dvips driver of hyperref will insert appropriate pdfmark operators so that ps2pdf can generate it in the final PDF file. When you use pdftex instead (thus using the pdftex driver of hyperref), the macros are defined in such a way that the same info is generated on the output PDF file directly. In either case, the document info are there in the final PDF. The same is true for hyperlinks, crossreference likes, PDF form entry fields, etc. Also thumbnails and bookmarks.

PDF -> PS conversions are needed by many more people that use TeX, while conversions involving DVI files are only useful to a limited audience. There are more and better tools for PDF -> PS than for DVI -> anything. As a case in point, the most common tool for DVI -> PS is dvips, which is based on a raster graphics model and so can have problems (even when using scalable outline fonts) if the PS file is scaled.

dvips lays out the page using a raster grid determined by the resolution you specify. Sure, -Ppdf sets a high resolution, but if you need to scale a PS file created with dvips this causes problems. Y&Y's (commercial) dvips one does produce scalable PS.

About the quality of the tools, some people object:
Tools for DVI -> PS conversion are very good, stable and versatile. (e.g. the embedded T1 fonts contain only the glpyhs actually used in the document.)

This is an emotional and ironic argument that might be considered as not so relevant:
If all the programs with 'dvi' in their names stopped working, a few mathematicians would be annoyed but would soon learn to use PDF. If all the programs that work with 'pdf' files stopped working, CNN would cover the disaster 7/24. If we all stop using dvi files, a big whack of TeX code can be discarded and the people who have been maintaining programs with 'dvi' in the names can get back to solving more important problems.

Pro direct PostScript

I believe there are more tools that rely on Postscript technology than PDF. pstricks, EPS diagrams, etc. come to mind. (Yes, epstopdf is helpful. But how about pstricks? I sometimes do \special{"{some Postscript code}"} for some special effects that wouldn't be achieved easily otherwise.) Until pdftex can support Postscript specials, many users would stay with DVI+EPS. But that would be a big project.

Unclassified

PDF files tend to have more predictable rendering times than PS files, so typesetter operators avoid PS files that aren't created by well-known applications (Photoshop, Illustrator) which produce flat PS code similar to PDF.

Conclusion

My personal conclusion (everybody can make his own): PDF is bound to be used on a wider scale than PostScript. A direct PDF rendering seems to be of better quality than the PostScript equivalent. Given its features, PDF is more comfortable to use on-line.

The main argument against pdftex is the impossibility to use PostScript code (and others) in the source (however, METAPOSTmight be a good alternative for figures). As soon as one is not limited by these constraints, and a fortiori if the use of PostScript is limited to printing, the TeX -> PDF -> PS solution seems to be a good choice.