RE: [css3-writing-modes] text-orientation: upright for fonts without vertical metrics (was RE: Western vertical texts

I found one more use case:

4. Private characters with house-made font (Gaiji; authors create a font that only contains characters they want.) Such fonts tend not to have vertical metrics because of software limitation and lack of knowledge in the font creator.

I noticed, if code points are CJK but the font lacks vertical metrics, Mac WebKit assumes it's a square glyph and use horizontal advances as vertical advances. It only works for CJK code points and therefore will not work for PUA.

This and use case #3 from Ambrose makes me think that "4. bounding box" isn't a good option, along with its too tight layout in English as in this screenshot[1].

In East Asian fonts, ascent + descent are usually 1em, so option 2 and 3 are very similar.

[1] http://lists.w3.org/Archives/Public/www-archive/2012Mar/att-0008/text-orientation-upright-pitch.png

Regards,
Koji

-----Original Message-----
From: Koji Ishii 
Sent: Sunday, March 04, 2012 4:56 PM
To: 'Ambrose LI'; www-style; Eric Muller
Subject: [css3-writing-modes] text-orientation: upright for fonts without vertical metrics (was RE: Western vertical texts

Thank you Ambrose and Eric. Allow me to re-summary the issue and also change the subject to reflect it better.

The issue is how UA should render text-orientation: upright for fonts without vertical metrics.

=== ISSUE SUMMARY ===
Layout engines usually need "advance" and "bearing" for each glyph. It is also sometimes called "ABC" width[1], where A is left side bearing, and A+B+C is advance.

In OpenType fonts with vertical support, these are in vhea, vmtx, and optional vorg tables. The spec defines "OpenType(tm) vertical fonts require both a vertical header table ('vhea') and the vertical metrics table discussed below[2]." However, these tables are not available in most non-East Asian fonts today, and UA needs to synthesize them.

Current spec does not mention this behavior, so I suppose it's UA dependent. This issue is to confirm if it's okay to do so, or if we were to define one, which one.

=== USE CASES ===
There are three use cases:
1. Most non-East Asian fonts use this logic to render text-orientation: upright because they lack vertical metrics today, so non-East Asian users with upright settings will see this issue.
2. Sometimes Latin fonts are put in top of font list in East Asian documents. Since this is font-dependent issue, such East Asian documents will see this issue.
3. Some (many?) Chinese fonts lack vertical metrics.

For #3, I'm not clear how common it is, and how much people would like support such fonts in UA. For example, 4 out of 11 Mac OS X 10.6 bundled Chinese fonts don't have these tables[3], which looks pretty common to me. But they also lack vertical alternate glyph table as well, and therefore authors need to use Unicode Vertical Forms code points[4] to get it right (and the webkit bug was about webkit unable to display such code points correctly.)

For such fonts, this issue also applies to text-orientation: mixed-right as well, so this issue has bigger impact. I'm kind of back and forth how well such fonts should be supported in CSS.

=== POSSIBLE OPTIONS ===
1. Keep it UA dependent. This requires no actions to the spec.
2. Use 1em height, and distribute spaces evenly to top/bottom bearings.
3. Use ascent + descent as advance, ascent - top-bounding-box as top-side-bearing.
4. Use bounding-box-height as advance, and 0 for top/bottom-side-bearings.

NOTES:
i) #2 is similar to what text-combine does, and works best for old Chinese fonts (use case #3.) It also works best for using Latin fonts within East Asian vertical flow (use case #2.) It might look reasonable for many Latin fonts but there might be problems in some fonts according to Ambrose[5].
ii) #2 and #3 gives mono-spacing, while #4 gives proportional pitch.
iii) While #4 is the only option to give proportional pitch, it's often too tight. Bearings are designed for good spacing, making them always 0 usually results in too tight layout.
iv) Current Mac WebKit, the only implementation of text-orientation, uses #4.

Does this summary all the issues and covers all what we discussed?

[1] http://msdn.microsoft.com/en-us/library/windows/desktop/dd374094(v=vs.85).aspx
[2] http://www.microsoft.com/typography/otspec/vmtx.htm
[3] https://bugs.webkit.org/show_bug.cgi?id=65082#c9
[4] http://www.unicode.org/charts/PDF/UFE10.pdf
[5] http://lists.w3.org/Archives/Public/www-style/2012Mar/0040.html

Regards,
Koji

-----Original Message-----
From: Ambrose LI [mailto:ambrose.li@gmail.com]
Sent: Friday, March 02, 2012 3:15 PM
To: Koji Ishii
Cc: Eric Muller; www-style
Subject: Re: Western vertical texts

2012/3/2 Koji Ishii <kojiishi@gluesoft.co.jp>:
>> From: Ambrose LI [mailto:ambrose.li@gmail.com]
>>
>> No, I don't think he said make it UA dependent. He said vertical 
>> writing in Latin text should be treated as tate-chu-yoko partly 
>> because UA considerations support this behaviour.
>
> Oh, sorry, probably my English skill problem. He said the use case 
> difference is marginal and wanted to "give room for implementations,"
> which I understood UA dependent.
>
> If the use case difference is marginal, I do not see a good reason for 
> WebKit Mac to change the already implemented behavior.

Oh, sorry, I missed that part. I guess he did say UA dependent then, for the specific use case of text-orientation:upright plus fonts that do not have vertical metrics. Please ignore my previous comment.

I'm not sure if the use case for text-orientation:upright and fonts that do not have vertical metrics is really "marginal" though. I doubt most Chinese fonts have proper vertical metrics.

> I also wonder how good "always use 1em height" is for Latin upright 
> text.

I suppose this depends on what we are using this for and what we are expecting. The em is pretty much an arbitrary unit in Latin fonts.
Usually it should look reasonable, but in some fonts (especially calligraphic fonts) there might be problems. That said, the chance of setting vertical text with these fonts is, I suppose, probably fairly small.

>
>
> Regards,
> Koji



--
cheers,
-ambrose <http://gniw.ca>

Received on Wednesday, 7 March 2012 01:03:03 UTC