Re: Prefer luatex for documentation

[Werner LEMBERG]

>> 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.  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.

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).

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.

>> The main advantage of using luatex is complete microtype support;
>> this was activated recently in `texinfo.tex`, and XeTeX doesn't
>> support it in its entirety, lacking font expansion.
> 
> But pdfTeX does support font expansion, right?

Yes.

> Reading through the 'microtype' package documentation, it reads as
> if all of this comes from pdfTeX...

Yes, font expansion (the so-called 'hz algorithm' originally suggested
by the famous typographer Hermann Zapf) started with pdftex.  It was
actually the PhD thesis subject of the original pdftex author, Han The
Tanh.  Luatex supports that, too.

>> [...] it is always a good thing to avoid hyphenation with keywords
>> and the like because there might be misunderstandings whether the
>> hyphen is part of the keyword or due to the line break.
> 
> Do you have an example for this? As I wrote on the merge request,
> I've been looking through the PDFs you provided, and it's really
> hard to find places where this actually makes a difference...

Well, everything typeset with `@code` is only hyphenated after a real
hyphen; right now, keywords not written with typewriter can only be
found in links, most likely in links to the IR.  Attached is an
example of a 'See also' section from NR section 1.4.2 – as can be
seen, the number of hyphens with luatex gets reduced from 5 to 3,
which I consider an improvement.  Note that I have already tried in a
bunch of previous commits to make the PDF output look better with
pdftex, too (for example, using ragged-right 'See also' sections and
an automatically generated list of hyphenation exceptions for
camel-case keywords).

> 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.


    Werner