- From: Christoph Päper <christoph.paeper@crissov.de>
- Date: Thu, 10 May 2012 13:41:51 +0200
- To: www-style list <www-style@w3.org>
- Cc: www-font <www-font@w3.org>
John Daggett: > I'd like to propose that: > > * fallback occurs across a given text run rather than per-character This seems reasonable at first, but it differs from other font fallbacks: When some character is missing from a font (i.e. there’s not even a related glyph to synthesize from), a substitute may betaken from a different font, but the surrounding glyphs still use the nominal font (if supported of course). What cases do we actually want and need to support with this property? > * the 'font-variant-position' property is defined independent of > the existing use of the font-size/vertical-align properties to > synthesize subscripts/superscripts It would be great if that was possible. > There are, however, a couple downsides to this model. Fonts typically > only define these glyphs for a small subset of characters available in > the font. The numbers 0-9 are supported but lowercase and punctuation > characters are frequently not. Has someone researched whether OT fonts that cover the related Unicode code points – see incomplete table below – are more likely to support the font features ‘subs’ and ‘sups’ (or vice versa)? Synthesis might be improved if that wasn’t the case. sup-lower sup-upper sub-lower sub-upper 0 2070 2080 1 00B9 2081 2 00B2 2082 3 00B3 2083 4 2074 2084 5 2075 2085 6 2076 2086 7 2077 2087 8 2078 2088 9 2079 2089 + 207A 208A - 207B 208B = 207C 208C ( 207D 208D ) 207E 208E a 1D43 1D2C 2090 b 1D47 1D2E c 1D9C d 1D48 1D30 e 1D48 1D31 2091 f 1DA0 g 1D4D 1D33 h 02B0 1D34 i 2071 1D35 1D62 j 02B2 1D36 2C7C k 1D4F 1D37 l 02E1 1D38 m 1D50 1D39 n 207F 1D3A o 1D52 1D3C 2092 p 1D56 1D3E q r 02B3 1D3F 1D63 s 02E2 t 1D57 1D40 u 1D58 1D41 1D64 v 1D5B 2C7D 1D65 w 02B7 1D42 x 02E3 2093 y 02B8 z 1DBB > This gives three alternates for subscripts/superscripts: > > (1) the subscript/superscript variant glyph > (2) a synthesized glyph using the subscript/superscript > metrics from the font > (3) a synthesized glyph using fixed size/offset values > (i.e. what user agents do today) > > http://people.mozilla.org/~jdaggett/tests/subsupermetrics.png Judging from that sample, (1) always looks better than (2) and (2) never looks worse than (3), which is not surprising at all. > This may lead to inconsistencies between subscript/superscript > placement depending upon the content but it's better than having the > position of glyphs vary within a given subscript/superscript. For something like “a<sub>1</sub> + … + a<sub>n-1</sub>” I’m not sure people would want to have (only) the latter part fall back, because the font supported subscript digits, but not roman letters. I certainly would expect the one-digits to look the same. > The use of subscript/superscript variants is basically typographic, > there's no manipulation of the linebox. That’s why it’s possible most of the time to apply them algorithmically, without explicit markup (i.e. ‘sup’ and ‘sub’), but implicit markup (e.g. ‘abbr’, ‘math’ and ‘lang’) can help a lot. Mme. ⇐ M<sup>me</sup> Acme(TM) ⇐ Acme<sup>TM</sup> (Acme™) 1st, 2nd, 3rd, 4th ⇐ 1<sup>st</sup>, 2<sup>nd</sup>, 3<sup>rd</sup>, 4<sup>th</sup> H2O ⇐ H<sub>2</sub>O NOx ⇐ NO<sub>x</sub> YCbCr ⇐ YC<sub>B</sub>C<sub>R</sub> 2 Cl- + Ca2+ ⇐ 2 Cl<sup>−</sup> + Ca<sup>2+</sup> E = mc^2 ⇐ E = mc<sup>2</sup> (E = mc²) 9.80665 kg·m·s^-2 ⇐ 9.80665 kg·m·s<sup>-2</sup> (kg·m·s⁻²) 1 lbf. ⇐ 1 lb<sub><i>F</i></sub> 10bin + 10_10 + Ah ⇐ 10<sub>bin</sub> + 10<sub>10</sub> + A<sub>h</sub> log_e(a), log10(a) ⇐ log<sub>e</sub>a = ln a, log<sub>10</sub>a = lg a a<sup>-</>b<sup>*</>c<sup>+</>d<sup>?</>e<sup>!</> = a{0}b{0,}c{1,}d{,1}e{1} n/a ⇐ NP<sub>Nom, Sg, f</sub> n/a or lim_(n→0) ⇐ lim<sub>n→0</sub> n/a or ∏_(i∈ℙ) ⇐ ∏<sub>i∈ℙ</sub> n/a ⇐ ∑<sub>i=1</sub><sup>∞</sup> = ∑<sup>∞</sup><sub>i=1</sub> n/a or C14, C-14 ⇐ <sup>14</sup>C ? n/a ⇐ <sup>235</sup><sub>92</sub>U It’s usually the font developer’s job to create complex substitution tables for that (although maybe for ‘calt’ or the like rather than ‘subs’ and ‘sups’), but I don’t think it’s totally unreasonable for CSS to prescribe some on the higher level – or introduce something akin ‘@text-transform’. math, abbr {font-variant-position: auto;} would then be all most authors needed, except when they use ‘sub’ and ‘sup’ elements: CSS1, CSS2 <foo>H<sub>2</sub>O</foo> H<sub>2</sub>O ⇩ foo {} sub { vertical-align: sub; font-size: smaller; line-height: normal; } CSS3 Etemad/Baron <foo>H<sub>2</sub>O</foo> H<sub>2</sub>O ⇩ foo {} sub { vertical-align: sub; font-size: smaller; line-height: normal; font-variant-position: sub; /* magic */ } CSS3 Daggett <foo>H<sub>2</sub>O</foo> H<sub>2</sub>O ⇩ foo {} sub { vertical-align: sub; font-size: smaller; line-height: normal; } @supports ( font-variant-position: sub ) /* module dependency */ { sub { vertical-align: inherit; font-size: 100%; line-height: inherit; font-variant-position: sub; } } CSS3 Päper <foo>H<sub>2</sub>O</foo> ⇩ foo { font-variant-position: auto; /* magic */ } sub { /* backwards compatibile, possibly ugly: */ vertical-align: sub; font-size: smaller; line-height: normal; font-variant-position: none; /* do nothing */ } sub { /* not backwards compatible, nicer looking */ font-variant-position: sub; /* optional: forces subscript if ‘auto’ fails */ } H<sub>2</sub>O ⇩ :root { font-variant-position: auto; } sub {/* same as above */} <foo>H2O</foo> ⇩ foo { font-variant-position: auto; } My point is, an author should not need to enable ‘subs’ and ‘sups’ (and other character-centric OT features, see ‘font-variant-alternates’) manually except where semantically absolutely necessary; they should be applied automatically where reasonable, either by the font or by the typesetting software. This is one area (of several) where the Open Type (or Open Font) Format isn’t user-friendly, so we shouldn’t copy it verbatim. Nevertheless, authors should still be able to apply these features manually. PS: I have the feeling this feature is primarily intended for bicameral (and primarily horizontal) scripts, especially the roman one, so I ignored others for the sake of simplicity.
Received on Thursday, 10 May 2012 11:41:59 UTC