Re: [css-ruby][css-inline] ruby offset affected by font?

Hi,

(The dropbox links no longer work, but I think I understand what the problem is anyway.)

As far as I can tell, this used to be ambiguous / insufficiently-defined in the specifications, but thanks to recent work on both css-ruby and css-inline, how things should behave is now defined (and the ambiguities you noted in CSS2.1's definition of line height have been resolved).
    
The specs are now clear that sTypoLineGap  does not affect the content area, and therefore not supposed to push the annotation away from the base.

When the gap is caused by the font having an ascender metric that is too tall for ruby's purposes, css-inline's text-edge property [1] will enable you (when implemented) to pick a different metric to calculate the content area from.

For instance, with Arial Unicode MS, it does have a very tall ascender, but using text-edge: ideographic would solve the problem.

I don't think we can automatically solve the problem beyond this, because if someone was to put some ruby on "Tiếng Việt", you would want to keep the tall ascender to keep room for the accents.

Let us know if this seems to answer the problem, or if you think we ought to be doing something more.

—Florian
P.S. Spacing can be further adjusted using margins on the ruby base or annotation.
[1] https://drafts.csswg.org/css-inline-3/#text-edges <https://drafts.csswg.org/css-inline-3/#text-edges>

> On May 25, 2015, at 23:50, Shinyu Murakami <murakami@vivliostyle.com> wrote:
> 
> (adding [css-inline] to the subject)
> 
> Thanks Xidorn and Bobby, I understand this problem is not very simple.
> 
> I found the block-axis positioning of ruby annotation boxes is basically defined in recent CSS Ruby spec:
> 
> http://dev.w3.org/csswg/css-ruby/#ruby-layout
> 
>    When a ruby structure is laid out, its base level is laid out 
>    […] as if its ruby bases were a regular sequence of inline boxes. 
>    Each ruby base container is sized and positioned to contain 
>    exactly all of its ruby bases’ margin boxes.
> 
>    […] Ruby annotations […] are aligned to each other as if they were 
>    inline boxes participating in the same inline formatting context. 
>    Each ruby annotation container is sized and positioned to contain 
>    exactly all of its ruby annotations’ margin boxes.
> 
>    Ruby annotation containers are stacked outward over or under their 
>    corresponding ruby base container, without any intervening space.
> 
> According to this spec, when all margin/border/padding are zero (i.e., margin box = content box), the ruby base box's content area and the ruby annotation box's content area must touch exactly.
> 
> It seems current browsers have almost (may not exactly) implemented this, and have still problem: the content area of an inline box is not defined in current CSS spec and UA-dependent! CSS2.1 has the following note in section 10.8.1:
> 
>    Note. CSS 2.1 does not define what the content area of an inline 
>    box is (see 10.6.1 above) and thus different UAs may draw the 
>    backgrounds and borders in different places.
> 
> and 10.6.1 says:
> 
>    The height of the content area should be based on the font, 
>    but this specification does not specify how. A UA may, e.g., 
>    use the em-box or the maximum ascender and descender of the 
>    font. (The latter would ensure that glyphs with parts above or 
>    below the em-box still fall within the content area, but leads 
>    to differently sized boxes for different fonts; the former 
>    would ensure authors can control background styling relative 
>    to the 'line-height', but leads to glyphs painting outside 
>    their content area.)
> 
>    Note: level 3 of CSS will probably include a property to 
>    select which measure of the font is used for the content height.
> 
> 
> I think this is problematic: different UAs put ruby annotations in different places.
> 
> One possible solution will be to change CSS Ruby positioning spec so that em-boxes of the ruby bases and the ruby annotations are used instead of margin boxes.
> It will work in most ruby cases. However, when ruby bases or ruby annotations have border/padding or have glyphs not fit in em-box, an additional setting for control the space between ruby bases and ruby annotations will be necessary (e.g. 'ruby-offset' property).
> 
> Another possible solution will be to define the content area of the inline box properly. CSS 2.1 has the following note in section 10.8.1:
> 
>    Note. It is recommended that implementations that use OpenType or 
>    TrueType fonts use the metrics "sTypoAscender" and "sTypoDescender" 
>    from the font's OS/2 table for A and D (after scaling to the 
>    current element's font size). In the absence of these metrics, the 
>    "Ascent" and "Descent" metrics from the HHEA table should be used.
> 
> This will be a hint to define the content area of inline box with text content.
> 
> If all browsers follow this and use sTypoAscender and sTypoDescender, the problem will be almost solved because sTypoAscender + abs(sTypoDescender) = unitsPerEm is true in most CJK OpenType/TrueType fonts. However, current browsers seem to be using "Ascent" and "Descent" metrics from the HHEA table or something UA-dependent, nevertheless "sTypoAscender" and "sTypoDescender" metrics exist.
> 
> I expect CSS spec (CSS2.2 or CSS Inline Level 3 will be the right place) define this for the content area of inline box with text content, and all browsers support it.
> 
> 
> Xidorn:
>>> I don't really know what causes the large gap of Meiryo, since I'm not that familiar with font metrics. But AFAICS, the spacing is not because of TypoLineGap.
> 
> I was wrong, TypoLineGap was not. Gecko seems to be using Ascent (yAscender) and Descent (yDescender) metrics in HHEA table in horizontal and VHEA in vertical writing modes.
> Meiryo has the following metrics:
> 
> 'head' Table - Font Header
>  unitsPerEm:          2048
> 'hhea' Table - Horizontal Header
>  yAscender:            2171
>  yDescender:           -901
> 'vhea' Table - Vertical Header
>  yAscender:            2407
>  yDescender:           -1452
> 'OS/2' Table - OS/2 and Windows Metrics
>  sTypoAscender:            1798
>  sTypoDescender:           -250
>  sTypoLineGap:             1024
> 
> sTypoAscender + abs(sTypoDescender) = 2048 = unitsPerEm (no problem if this is used). 
> (hhea) yAscender + abs(yDescender) = 3072 (this causes the large gap).
> (vhea) yAscender + abs(yDescender) = 3859 (very bad in vertical writing mode).
> 
> --
> Shinyu Murakami
> CEO & Founder, Vivliostyle Inc.
> http://vivliostyle.com
> murakami@vivliostyle.com
> 
> 
> Bobby Tung <bobbytung@wanderer.tw> wrote on 2015-05-20 20:19:09
>> 
>>> Xidorn Quan <quanxunzhen@gmail.com> 於 2015年5月20日 下午6:48 寫道：
>>> 
>>>> On Wed, May 20, 2015 at 8:49 PM, Shinyu Murakami <murakami@vivliostyle.com> wrote:
>>>> 
>>>> I guess this gap is caused by the TypoLineGap [1] value of the font metrics.
>>>> MS Mincho and IPAMincho's TypoLineGap value is 0 and Meiryo's is 1024 (1/2 of unitsPerEm 2048).
>>>> 
>>>> This value is "to compute a typographically correct default line spacing" [1] and should not used for ruby positioning.
>>> 
>>> I don't really know what causes the large gap of Meiryo, since I'm not that familiar with font metrics. But AFAICS, the spacing is not because of TypoLineGap.
>>> 
>>> I made a copy of Meiryo with TypoLineGap being 0, but it doesn't seem to have any difference on the rendering result.
>> 
>> I'd like to figure out where the problem is. Here's a sample in Chinese.
>> 
>> Figure 1, Arphic Song-Demibold
>> https://www.dropbox.com/s/lko0ocjx0h3xgde/%E7%9B%B8%E7%89%87%202015-5-19%20%E4%B8%8B%E5%8D%882%2020%2045.png
>> 
>> Works as intended. Same result with Source Sans TC.
>> 
>> Figure 2, OS X Songti TC
>> https://www.dropbox.com/s/m2cylyk9hnqbzy9/%E7%9B%B8%E7%89%87%202015-5-20%20%E4%B8%8B%E5%8D%884%2059%2039.png
>> 
>> line-height is expanded by ruby texts. 
>> 
>> Bobby
>>> 
>>> - Xidorn
> 
> 
>