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: Mon, 21 Nov 2022 22:10:43 +0100
User-agent: Evolution 3.46.1

Hi all,

there has been a huge number of messages in this thread today.
Unfortunately, in my opinion, many of them contained points that are
factually wrong, fundamentally contradict any best practices for
sustainable and maintainable open source projects, or are not relevant
to this discussion. I actually wrote down my thoughts on many of them,
but I will not go through the hassle of replying to the list because I
don't think it would be productive to the discussion.
That said, if somebody really wants my replies to their messages, they
can send me a message on or off the list. But I would like to put a
warning here because this will be in some sense "unfiltered" and a
number of replies will be perceived as rude and destructive.

Instead, I would like to make my own position crystal clear and give
arguments. If people want to comment on them and have a productive
discussion please do, but let's try to keep it on point (which is to
*prefer* LuaTeX for the documentation, see the subject).

Here we go:
First, I would like to make clear that I am *not* opposed to supporting
LuaTeX and that I thank Werner for his work to make this happen. I can
see some improvements and why Werner cares about them. However, I
personally think that they are not substantial and need to be weighed
against other factors, such as sustainability and maintainability.
Which brings me to my second point, that I share Jean's concern and the
reasoning about supporting three TeX engines and appreciated him asking
if we could drop support for some as pretty much the first comment on
the merge request, less than a day after it was posted:
https://gitlab.com/lilypond/lilypond/-/merge_requests/1714#note_1161468272
(Sadly, this was shot down immediately by Werner in his comment:
https://gitlab.com/lilypond/lilypond/-/merge_requests/1714#note_1161550648
)
Third, what I do care about is what TeX engines LilyPond's configure
script looks for by default. This is simply because it determines what
engine we are going to use for the official documentation during
releases. (At this moment, I would like to interject that we had just
switched to XeTeX by default for the official documentation, so it did
not resonate well with me that this was proposed to be changed again.)
The defaults in the configure script also determine what people
compiling LilyPond from source will use unless they consciously choose
to set advanced variables. For this reason, I believe this topic
belongs on the mailing list and not in a discussion on a merge request.

Finally, I would like to add some research and numbers to two of my own
comments:

On Sun, 2022-11-20 at 12:08 +0100, Jonas Hahnfeld via Discussions on
LilyPond development wrote:
> Which makes me wonder why this [compiling LilyPond with LuaTex in CI]
> works without installing texlive-luatex?

Looking at the list of contained files in the texlive-luatex package
(https://packages.ubuntu.com/bionic/all/texlive-luatex/filelist) it
seems that this is mostly documentation, packages for lualatex, and
additional packages for plain luatex. Compiling texinfo.tex with the
LuaTeX engine apparently doesn't need any of this. And even if it did,
the package is relatively small and doesn't pull in additional
dependencies in the way that texlive-xetex does.

> And whether we can just *require* LuaTeX and stop looking for pdfTeX
> and XeTeX altogether?

I did a few measurements for the case of building the LilyPond
documentation and, in terms of speed with the "CI configuration" (no
extractpdfmark and using the Ghostscript API), LuaTeX seems to position
itself between pdfTeX, which remains the fastest, and XeTeX. So at
least in my opinion, this would be a viable path and we could just
always build with LuaTeX.

Cheers,
Jonas

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


reply via email to

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