- From: Koji Ishii <kojiishi@gluesoft.co.jp>
- Date: Sat, 17 Mar 2012 04:57:07 -0400
- To: Brad Kemper <brad.kemper@gmail.com>, Eric Muller <emuller@adobe.com>
- CC: Ambrose LI <ambrose.li@gmail.com>, www-style <www-style@w3.org>
Thank you Eric and Brad for the feedback.
Now I'm leaning to make option 3 as a spec from possible options[1]:
> === 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.
Please let me know if anyone objects.
Here's a long version.
Eric preferred it be UA dependent[2], but if I understand correctly, he wants so because option 2 is good for East Asian but it's not good for other scripts. Fortunately, 1em = ascent + descent in East Asian fonts as far as I investigated, so option 3 should suffice his requirements.
Ambrose suggested em is pretty much arbitrary in Latin fonts[3]. It supports that option 3 supersedes option 2.
Fantasai suggested proportional upright is preferable[4], and I agree with that. I looked for upright examples where non-uppercases are used. As fantasai pointed out, it's not easy to find one, but I got a couple of lowercase examples ("job fair"[5] and "Sarb banner vertical"[6]) and one punctuation (FARMER'S[7].) All of the three are proportional and it's unfortunate to give up these use cases.
But authors would have to use letter-spacing property or some other technique to look good with option 4. From that, and from the fact that supporting Chinese fonts without appropriate vertical metrics is also important, I think option 3 gives the best choice.
Also, please keep in mind that what I'm trying to define here is for when the font doesn't provide vertical metrics, and you can have proportional upright layout using fonts with appropriate vertical metrics (if such one exists though.)
Note that I looked into WebKit behavior further. Right now, Mac Safari and Mac Chrome has its internal table to define whether a code point is East Asian or not, and use width as advance if the code point is East Asian (assuming square glyphs.) If not, they use bounding box. This is option 5, but I guess we probably don't want to spec this behavior out.
[1] http://lists.w3.org/Archives/Public/www-style/2012Mar/0129.html
[2] http://lists.w3.org/Archives/Public/www-style/2012Mar/0116.html
[3] http://lists.w3.org/Archives/Public/www-style/2012Mar/0040.html
[4] http://lists.w3.org/Archives/Public/www-style/2012Mar/0102.html
[5] http://www.4imprint.com/group/568/Tradeshow-Banners-and-Display-Accessories/product/100355-FC/Drapery-Banner
[6] http://www.signagecheshire.co.uk/gallery.php?galleryid=banners
[7] http://www.roadsidepeek.com/roadusa/southeast/sesign/seneonsign/index2.htm
Regards,
Koji
Received on Saturday, 17 March 2012 08:57:41 UTC