Dropcap with descenders introduces uneven lines

[Omikhleia]

Ran with docker siletypesetter/sile:v0.14.13:

\begin[papersize=a6]{document}
\use[module=packages.lorem]
\use[module=packages.dropcaps]
\dropcap[join=true, lines=4]{J}\lorem[words=50]
\end{document}

Same issue with a Q.

No font specified, so using default font Gentium Plus -- which happens to have capitals with descenders. Might occur with other fonts, though I wouldn't have noticed used most of the time fancy fonts such as Zalmann Caps ^^ i.e. fonts without descenders.

And it seems indeed that the depth being overlooked or not being taken into account somewhere:

[alerque]

Hmm, interesting bug. I typically don't use fonts with descenders in capitals for drop caps anyway but should be fixed. I'm guessing we need to fudge the glyph height to add in the descender depth before we scale it to a size that fits X lines. That depth wouldn't normally be included in those calculations, but for drop caps the total bounding box is what matters not the font-reported glyph height.

I'm a little surprise this turned up by stretching that first line leading and not by just over-running the space at the bottom and drawing on top of the 5th line.

[Omikhleia]

I'm a little surprise this turned up by stretching that first line leading and not by just over-running the space at the bottom and drawing on top of the 5th line.

Same surprise here! My guess is that the first line inherits the depth of the dropped caps, but I haven't checked that code for some time...

1. Scaling the whole glyph (height and depth) is what LibreOffice does, but it doesn't look very nice (that J or Q become much thinner than other dropped capitals).
2. We could also compute if we'd need another extra hanged lines for these cases,
   a. but scaling that would make the letter heavier and taking more space horizontally...
   b. ... unless we do not try to change the letter scale (at the risk of having a space below it)
3. Or we could account for an extra hanged line but use PDF scaling (à la "scalebox") to fit in the space vertically. That would avoid the horizontal stretching but will distort the glyph vertically... besides, it's a bit more complex!

I wonder if (2b) is not the best choice (= detect, introduce an extra line, but keep scaling and alignment unchanged, possibly with a warning for visual check)

[kyrias]

I just ran into what appears to be the same issue while trying to use the EB Garamond Initials font and was wondering if I was doing something wrong.

[Omikhleia]

@kyrias Seems to be the same issue, yes (to be real sure you could run SILE with -d all and see the red frames around frames and boxes): EB Garamond Initials has all letters, not just J and Q, with descenders below the baseline:

Interestingly in such a case, solution 1 would be better than solution 2b... So we could shape, say, a "A" (I wouldn't expect descenders here in most fonts) and if it has a depth, pick solution 1, otherwise pick 2b... Interesting coding example :)

[Omikhleia]

(But probably such initials weren't done for dropped capitals in the first place)

[kyrias]

Myeah.

---

(But probably such initials weren't done for dropped capitals in the first place)

Hm, what do you mean? They come from this bible.

[Omikhleia]

Hm, what do you mean? They come from this bible

I mean the decision to have them encoded, in that font, with such a baseline offset on all characters (or, that is, top-aligned with ascenders, it seems, looking at my image above)... That's kind of neat actually for display at the same point size as the main text, on a single line (as in my image above), but that's sort of unusual (it seems to me). Anyway, it's another case for the general issue. Even some fonts specifically designed for dropped capitals sometimes have descenders, e.g. Ehmcke-Fraktur Initialen Regular

[Omikhleia]

Self-assigning the issue, unless someone wants to give it a stab?

[Omikhleia]

Some fonts have both capitals with descenders and bigger J's:

Would need to test that one lol.