lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Prefer luatex for documentation


From: Jonas Hahnfeld
Subject: Re: Prefer luatex for documentation
Date: Sun, 20 Nov 2022 12:08:08 +0100
User-agent: Evolution 3.46.1

On Sun, 2022-11-20 at 05:09 +0000, Werner LEMBERG wrote:
> > > In https://gitlab.com/lilypond/lilypond/-/merge_requests/1714 I
> > > suggest that we prefer luatex for building the documentation. 
> > > What do people think?
> > 
> > What I'm missing here is the bigger picture: Are we going to
> > continue adding support and switching between TeX engines one after
> > the other?
> 
> Luatex would be the final engine to support.

In my opinion, this is a very naive statement with respect to software.
Just to put things into perspective, LuaTeX 1.00 was released in 2016
which is "only" 6 years ago. I see no reason to assume that there won't
be yet another engine (LuaTeX is already the fourth, if I count
correctly), maybe even starting as a fork of one of the existing ones,
which could happen quite fast. Once again, my question is: What is the
plan here?

> It's the most sophisticated one and under active development,
> contrary to both pdftex and xetex, which are both in maintenance
> mode.
> 
> > If we prefer LuaTeX, should we stop looking for XeTeX? (As
> > mentioned in the merge request, we want pdfTeX because it's fast
> > and included by default in Ubuntu's texlive-bin / the Docker
> > images).
> 
> I replied that from a philosophical point of view I would like to
> continue with support for all three engines.

That's not the same: The user can always set TEX and LATEX variables to
use their favorite engine. What I'm asking about is what configure
should look for automatically, which is implicitly the same as "what do
we recommend using".

> However, on a practical level, the PDF outlines are bad with pdftex
> if there are non-ASCII characters.  This is not a limitation of
> pdftex but a limitation of `texinfo.tex`, which doesn't provide
> support for that, unfortunately (someone™ could contribute this,
> since the maintainer don't want to add it by himself).

If PDF outlines are really the only inferior thing about pdfTeX (and it
already features full microtype support), then IMHO we should really
just spend our time fixing that one issue instead of complicating our
lives with multiple TeX engines...

> For me it's fully ok if pdftex gets used for testing.  However, for
> the generation of the PDF documentation that gets provided to the
> user, luatex (or xetex) is preferable.

Yet, your merge request also uses LuaTeX during CI testing. Which makes
me wonder why this works without installing texlive-luatex? And whether
we can just *require* LuaTeX and stop looking for pdfTeX and XeTeX 
altogether?
> > 
> > 
> 

> > So in general I have the feeling that this doesn't bring us much,
> > but just keeps adding more checks to our configure and more choices
> > / configurations to test on a somewhat regular basis.  I'm not
> > really in favor.
> 
> I disagree with that conclusion, but if you feel that we really,
> really must disable xetex support in favor of luatex, let's do it.

This is not what I'm saying. I have been asking what the plans are and
stating that the incremental improvements I see with LuaTeX are not
worth looking for and testing yet another engine. You keep saying that
you want to support everything, which in my opinion is not sustainable,
but are fine with dropping XeTeX which you only asked me to install for
the documentation build less than a month ago?

To make a general remark here: Proposals are more convincing if they
are made with a proper motivation following stable positions. Just
changing mind every few weeks is a bad driver for change IMO.

Jonas

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

[Prev in Thread] Current Thread [Next in Thread]