Proposal: Change default leading algorithm

[simoncozens]

SILE currently uses the TeX leading algorithm (baselineskip/lineskip). Literally the first thing I do when starting a SILE document is pull in the linespacing package and change it to fixed baseline distance. I'm sure that TeX users will prefer the TeX system rather than the system used by literally every other typesetting package, but I wonder if it's time to prioritise getting-things-done over TeX compatibility.

[alerque]

Ya I think I'm on board with this. Let's think about how to do it gently though because it will be a huge reflow / breaking change for most documents.

I think starting with a warning whenever the TeX leading algorithm is used would be the right place to start, combined with a notice in the release notes. Once that's had some time to percolate and active users have had some lead time (pun intended) to adjust we can switch the default and include a warning the other direction for all cases where the default is used (i.e. don't warn when the document loads and sets the leading, but only warn when the bare SILE default is unchanged) so that people that missed it realize something changed behind their backs. A later release cycle could completely remove the warnings.

[OlivierNicole]

Reading this thread, I was curious to learn what TeX’s behaviour was, but it’s the only one not documented in SILE’s manual.

[alerque]

It's hard enough to keep up with documenting SILE, if documenting how TeX works were to be part of our goals we'd never come up for air. We can probably summarize...

Maybe start here for a rough outline of factors. At the end of the day it's a bit of a fudge and a guess based on the current font with compensations for what happened in the two lines being computed. Descenders in the first line and ascenders in the second line cause compensations in the leading meaning the distance might change from line to line.

[simoncozens]

It’s documented here: https://github.com/sile-typesetter/sile/blob/fa23fcd20aa05f51d5bbf96f0760c5985e0a74dd/documentation/c07-settings.sil#L166

[OlivierNicole]

Sorry, I didn’t mean to sound like saying you should document it. Thanks for the pointer!

Edit: @simoncozens hadn’t spotted that, very nice, thank you.

[alerque]

When implementing this, cf. comments here about the bs unit and making it useful when other linespacing mechanisms are loaded. At the very least adding an implementation for whatever linespace method we use as default to the dropcaps package will be required here.

[Omikhleia]

I'll be honest (seeing this is re-prioritized again, now to 0.13) - I don't think this would be a good move yet.

[alerque]

Well it hasn't landed yet, so the timing is clearly up in the air. I'd be interested in hearing any rational for why to delay / when would be a good time. But also landing this will require extra careful thought to a deprecation warning and probably shimming first and changing the default later.

[Omikhleia]

I'd be interested in hearing any rational for why to delay / when would be a good time

First, it doesn't fix anything wrong or broken, per se, and is a matter of preference.

A fixed baselineskip (in a broad sense) is even somewhat achievable with the TeX algorithm, just removing elasticity on document.baselineskip and killing document.lineskip. On a "real" text (with vertical skips, plenty of footnotes, PNG and SVG images, etc.) one doesn't get a very nice output when killing all elasticity there, but it's still decent most of the time (when one is lucky not to meet other issues and oddities... So I wouldn't even really recommend doing it).

On the same real text, none of the "linespacing" package alternative method lives up to the expectation. They all have impractical defaults and all fail sooner or later at some point. I gave up trying to tune them. But we cannot deprecate something without a working solution in mind, and they are far from being one in the current state of art. A lot of work would be required there...

I could return the question: what would be the reason to think this absolutely is something to prioritize?

[raphCode]

TeX also has the quirk that the linespacing is calculated at the moment when \par is encountered. With the default baselineskip of 1.2em this means that changing the font size within or before ending a paragraph creates unexpected results: https://tex.stackexchange.com/a/444494

This can be replicated in sile:

\begin{document}
\use[module=packages.lorem]
% \use[module=packages.linespacing]
% \set[parameter=linespacing.method, value=fixed]
\font[size=30]
abc
\font[size=10]{\lorem}
\end{document}

Here, no \par happens inside the font size 10 block, so the algorithm assumes font size 30 for all lines and spreads them apart too much:

This even happens with the linespacing package in fixed mode. I know that the fit-font or fit-glyph methods perform better, but I think it is not possible to specify the spacing in relation of the baselines with that?

Maybe the fixed linespacing can be enhanced to produce the expected result in cases like this too? Except I am missing some disadvantages or breakages.

In any case, if the default leading algorithm is changed, I would propose that it can handle cases like this too.

[Omikhleia]

@raphCode Interesting comment!

Swapping labels (it's not only documentation-related, and however addressed at one point, there are interesting topics to discuss and implement.)

[Omikhleia]

On the same real text, none of the "linespacing" package alternative method lives up to the expectation. They all have impractical defaults and all fail sooner or later at some point.

Actually known issues: #823, #882 ...

[alerque]

I just re-tarteged this at v0.15.0. We're set to break EVERYTHING there, including the default size of spaces (#1371) and indentation (#1722) which is going to reflow everyone's documents if they don't override the settings.

I'm not saying for sure we will change this, but now is a great time to give this a good think and if we do change it doing it when people will have to adjust their documents for basic metrics anyway seems like a better time than any future releases.

[alerque]

Just a side note, Typst is having some trouble with picking a default leading algorithm too:

https://github.com/typst/typst/issues/4224