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

(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

Received on Monday, 25 May 2015 14:51:12 UTC