## LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

 Options: Use Forum View Use Monospaced Font Show Text Part by Default Condense Mail Headers Message: [<< First] [< Prev] [Next >] [Last >>] Topic: [<< First] [< Prev] [Next >] [Last >>] Author: [<< First] [< Prev] [Next >] [Last >>]

Hello Thierry,

> The first "engine" modification of LaTeX, a few months ago, was to > request the e-TeX extensions and drop vanilla TeX. OK, done.
The original announcement about e-TeX was back over 15 years ago :) The
hyphenation patterns actually stepped things on well before the LaTeX
kernel. Practically, therefore, it has been necessary for a number of
years 'in the wild'.

> 1) Is LaTeX3 aimed to be a "TeX" free engine, that is will not run on a
> TeX (at least a e-TeX) engine in the future?

New features have been added to engines and there comes a point at which
not using them uniformly is problematic. There is no 'aim' to set out to
use particular primitives, rather new primitives offer abilities not
available in Knuth's TeX or e-TeX. As such, the team have added new
required primitives to support improved behaviours. As I mention below,
these 'new' primitives have been around for some time.

> 2) If this step is taken, can you provide on CTAN a latex2e link to the
> last TeX compatible version (for the moment, latex2e points to the
> latest latex that is, IIUC, latex3...)?

LaTeX remains LaTeX2e: there will be no stand-alone LaTeX3. Moreover,
CTAN holds the latest release, and it would be very tricky if there were
a second latex.ltx there which conflicted with the release. That said,
it is possible to arrange to use older kernel files: they are in TeX
Live or available for the Git repository for LaTeX. Probably we should
discuss directly how best to arrange this (as you do not build from TL).

> 3) What are the so crucial primitives, not present in TeX or e-TeX,
> that it is not possible to treat them as possible extensions, been
> tested against for conditional treatment inclusions, but have to be
> absolute required ones? If they do exist, and have nothing
> to do with post-processing that is printing specially in PDF (which
> should be deferred to post-processing utilities), are there change files
> to be applied to e-TeX in order to create a special engine meeting your
> requirements?

The new required primitives have been in pdfTeX for over 10 years and do
not directly relate to PDF output. They have been ported to (u)pTeX as
part of .ch files: pdfTeX itself is a stand-alone .web source. (They
have also been ported to XeTeX, but again that has a single .web rather
than using .ch files.) The issue for you is likely to be one of license
rather than any technical restriction: pdfTeX is GPL. One could
certainly start from the (u)pTeX .ch file, although it is part of a
somewhat complex chain which allows building of pTeX and upTeX along
with e-pTeX and e-upTeX.

One reason we have only recently stepped up the primitive requirement
was precisely to arrange that all 'current' engines (those in TeX
Live/MiKTeX), other than Knuth's TeX (which will not change), were
\ifincsname was already required for UTF-8 text to work well, and was
delayed as a hard requirement only as there was a need for (u)pTeX to
'catch up'.

> 4) Are the modifications so deep that for the hundreds of LaTeX related
> macros already written, they will have to be rewritten to continue to be
> compatible with LaTeX3?

Over time new code will be written to use the new programming layer, and
it relies on post-e-TeX primitives, most notable \pdfstrcmp. A lot of
LaTeX packages already use expl3 (the programming language the LaTeX
team have developed), and so are already not usable even with older
LaTeX formats if the new primitives are not available.

I hope this helps: we are cautious about new primitives but cannot avoid
the fact that engine development has continued since e-TeX was finalised
in 1999.

Joseph