Re: [css-inline] i18n-ISSUE-408: Boxed characters and initial letter properties

I don't know what the rendering engines can check, but if the defined bounding box is ignored and instead the physical bounding box of the character(s) is calculated, that would do it. It would mean changing the rendering engine for such boxes.

Attached is an image showing how the alignment works for a typical text font. As can be seen in the top row, the alignment point runs right through the middle of the x-height (or, as I haven't measured it precisely, it could be the the half-way point for the cap and descender lines, which for this font is essentially identical to half-way between the baseline and the x-height).



The second row shows the behavior you want, based on converting the characters to graphical objects and then aligning those to the box.

The third line compares the two. It is apparent that the adjustments are pretty major for most characters, except for those that happen to have both ascenders and descenders (like the ffj ligature and þ). So this adjustment is the rule rather than the exception, even for Latin. Of course most other scripts will have the same problem.

So the trick is to have an option to visually align text with a box rather than rely on the underlying geometrical model.

But short of that option, it would be possible to write a number of classes to handle the alignment: cap, cap_diacritic, cap_double_diacritic, cap_triple_diacritic, ascender, descender. Each of those could have the necessary vertical offsets.  (Four would be sufficient for “pure” English texts.) 

Of course if you start adding in characters like the following (I realize the last one is really pushing things, but it is a renderable sequence):



the number of potential combinations you need to account for goes up pretty quickly. And it starts feeling very much like a kludge (because it is one).

Don't know if that helps, but it shows the problem: for almost any other typographical purpose ensuring consistency of the baseline is what matters. For the issue RIchard is addressing the rule is quite different.

Best,

Arle
 
Sic scripsit Richard Ishida ad Arle Lommel die Wed Feb 11 2015 17:05:34:
 
> I'm wondering whether something along the lines of line-height, internal to the intial letter box, could help simplify setting of the necessary space.
> 
> ri
> 
> 
> On 11/02/2015 10:40, Arle Lommel wrote:
>> I rather suspect there is no way you will avoid this problem
>> systematically. I have seen systems that have set sizing based on the
>> characters’ physical bounds (rather than the bounding box), and that
>> tends to mess things up even more. (A build of the open-source Lilypond
>> software for typesetting music had, at one point, a system for setting
>> lyrics that set spacing based on the physical height of the text lines,
>> so lines with no descenders were set too close to following lines. The
>> results were ugly, to put it mildly.)
>> 
>> In this case what is clearly going on is that CSS is considering the
>> bounding boxes of the characters as defined in the fonts. Since the
>> diacritics sit outside the bounding box for the base character, the CSS
>> model ignores them (which is what you want for /most/ typographical
>> purposes).
>> 
>> If you want to make a systematic fix you'd need a setting that tells the
>> rendering engine to ignore the bounding box and instead consider the
>> physical position of all character elements. That would require
>> rewriting the rendering engine to support this use case. That is, of
>> course, a non-trivial task.
>> 
>> -Arle
>> 
>> Sic scripsit *Richard Ishida * ad *Florian Rivoal * die Tue Feb 10 2015
>> 17:29:28:
>>> What concerned me was that the combining characters leaked outside the
>>> box.  I think that one could add enough padding to avoid this, but it
>>> is a messy job for an author, and may require different settings for
>>> each initial-letter (not all have combining characters).  With my
>>> author hat on, i'd just want to say 'make it all fit', and have
>>> combining character accounted for too. I think we'd need to fix that.
>>> 
>>> Note also that there is a gap in the English example where the beard
>>> of the type is empty (because there's no descender).