LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Arno Trautmann <[log in to unmask]>
Reply To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Date:
Sun, 6 Mar 2011 19:47:06 +0100
Content-Type:
multipart/signed
Parts/Attachments:
text/plain (4 kB) , signature.asc (4 kB)
Philipp Stephani wrote:
> Am 06.03.2011 18:18, schrieb Arno Trautmann:
>>
>> I find this horrible. It would be easy if the standard engine would be
>> luaTeX with pdf output and other machines could be used as pdflatex3 or
>> similar.
> 
> I agree that LuaTeX with PDF output is the most (only?) sensible choice,
> but if the L3 team chooses to support legacy engines and output formats,
> I have no objection to the proposed syntax with command line switches.

I.e. latex3 as default for luatex + pdf + latex3 and everything else
with switches? That would be fine for me, too.

> The main latex3 program will probably have to be a Lua wrapper script
> anyway because of the things the engines won't do: re-running the engine
> when needed, formatting error messages, computing the correct command
> line arguments for the engine.

Sounds sensible.

>>> an so forth (with --xetex ignoring --dvi for the obvious reasons).  Does
>>> a similar scheme make sense for a hypothetical 'latex2x'? (I'm going
>>> with 'x' for 'extended', and also for 'like LaTeX2e, but clearly a bit
>>> further along. Of course, there would need to be some defaults for the
>>> above - I guess I'd favour pdfTeX in PDF mode at present.
>>
>> For l2x (I like the name!), I'd stick with the names as they are.
> 
> I don't know. I'd like to see latex2x using LuaTeX as default engine,
> too. Since today LuaTeX already supports everything that pdfTeX and
> XeTeX has (and much more), I see no point in using the old engines any
> more if there is no need for backward compatibility. The only point for
> pdfTeX is that LuaTeX is still beta, but since L2e will stay, I don't
> see many problems here; LuaTeX is stable enough, and the l2x manual can
> contain an appropriate warning.

Stability cannot be a point here as l2x will never be considered a
stable format. (At least I hope so, in contrary to l2ε)
Before starting, it should be clear who would be the users/testers of
l2x – is a manual needed? l2x does not do anything more than 2ε + expl3
does and both are well documented …

>>> Second question: anything else that should be included that is not in
>>> the combined 'release' material (expl3, xparse, xtemplate, xcoffins)?
>>> These do load various bits and pieces (for example, graphicx), but I'd
>>> like to at least add fixltx2e to the above.
>>
>> As Philipp suggested, fontspec for luaTeX and XeTeX engines. Maybe even
>> xltxtra for XeTeX and some lua packages for luaTeX? But that is no
>> LaTeX3 stuff anymore …
> 
> expl3 already loads the luatex package. Maybe Heiko should be made a
> honorary member of the L3 team, then the L2x format could include the
> whole oberdiek bundle...

If they are useful and often used? In the end, it should be rewritten
and added to the kernel, no?

> fontspec is written by Will who is a member of the L3 team, so that
> would be no problem. It would essentially be NFSSv3 for LuaTeX.
> xltxtra replaces kernel macros such as \textsuperscript, I think that is
> not something we want by default.

Yes, right.
One question here: Having fontspec loaded in the format, what happens if
a package \Requires fontspec? Is it loaded again? Or can loading then be
prevented?

> fontspec loads luaotfload which depends on luatexbase. Currently there
> are some conflicts between luatex and luatexbase that should be fixed.
> Other packages by MPG would be nice, too, e.g. luacode.

Indeed!

> If we think even further, the L3 team might choose to lift several
> popular and high-quality packages to semi-official status by including
> them in the format, e.g. Philipp Lehman's packages, mathtools, the
> oberdiek bundle, xcolor, TikZ, siunitx...

I was thinking about this, but that would go too far. At least for a
short-term test version, that would be too much packages.
For long-term considerations, they would be nice to have in the format –
but this would blow up the size strongly, wouldn't it? We could imagine
a "plain LaTeX" format without them and a "bloated LaTeX" including … ;)

> Fixltx2e has already been mentioned and would probably the first
> candidate for inclusion in the format.

Yes.

Cheers
Arno



ATOM RSS1 RSS2