W3C home > Mailing lists > Public > www-style@w3.org > June 2015

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

From: Xidorn Quan <quanxunzhen@gmail.com>
Date: Thu, 4 Jun 2015 18:09:15 +1200
Message-ID: <CAMdq69_O-Yjg_MbkT5YgtaRCrPc-dxMJ4j0NSmnSKsNFHw-P1g@mail.gmail.com>
To: Shinyu Murakami <murakami@vivliostyle.com>
Cc: www-style list <www-style@w3.org>, Bobby Tung <bobbytung@wanderer.tw>
On Tue, May 26, 2015 at 2:50 AM, Shinyu Murakami <murakami@vivliostyle.com>
wrote:

>
> I think this is problematic: different UAs put ruby annotations in
> different places.
>

This does seem to be problematic.

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.
>

IIUC, the ascent and descent here are different things, and are not related
to sizing content box.

The metrics used to calculate the height of content box is "maximum
ascenter and descender", which enables the content box to cover all
characters in a font, while "ascent and descent" in OS/2 are used to align
the em-box. Which means, sTypoAscender + abs(sTypoDescender) = unitsPerEm
should probably always be true in all fonts, and doesn't actually make
sense for content box sizing.

I'm not sure why Meiryo has such a large max ascender and descender.
Probably it includes some very tall characters? If it intends to produce a
large default gap between lines by using such large max ascender and
descender, I rather think it is the fault of the font creator.

But anyway, I agree that ruby annotations' position being a impl-dependent
behavior seems to be a problem.

- Xidorn
Received on Thursday, 4 June 2015 06:10:24 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:54 UTC