Re: [css3-fonts] subscript/superscript variants

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

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 = m⁢c<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:


  foo {}
  sub {
    vertical-align: sub; font-size: smaller; line-height: normal;

CSS3 Etemad/Baron

  foo {}
  sub {
    vertical-align: sub; font-size: smaller; line-height: normal;
    font-variant-position: sub; /* magic */

CSS3 Daggett

  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 {
    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 */

  :root {
    font-variant-position: auto;
  sub {/* same as above */}

  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:58 UTC