lilypond-devel
[Top][All Lists]
Advanced

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

Re: Prefer luatex for documentation


From: Luca Fascione
Subject: Re: Prefer luatex for documentation
Date: Sat, 19 Nov 2022 22:50:29 +0100

Luatex is always available with modern tex distros (say at least 5 yrs
probably more). In fact pdftex _is_ luatex...

I feel texlive is a stable enough bet for people...

L

On Sat, 19 Nov 2022, 22:15 Jonas Hahnfeld via Discussions on LilyPond
development, <lilypond-devel@gnu.org> wrote:

> On Sat, 2022-11-19 at 10:19 +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?
> 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).
>
> > 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? Reading through the
> 'microtype' package documentation, it reads as if all of this comes
> from pdfTeX...
>
> > The microtype feature yields (a) less underfull lines (i.e., less
> > lines with overly large inter-word spaces), (b) less hyphenation, and
> > (c) a better 'grayness' of the pages, thus increasing legibility.
> > While (c) is not a big issue with technical documentation, (a) has
> > quite an impact IMHO, and (b) is valuable since 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...
>
> 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.
>
> Jonas
>
>


reply via email to

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