W3C home > Mailing lists > Public > www-style@w3.org > May 2012

[css3-fonts] subscript/superscript variants

From: John Daggett <jdaggett@mozilla.com>
Date: Wed, 9 May 2012 02:46:26 -0700 (PDT)
To: www-style list <www-style@w3.org>
Cc: www-font@w3.org
Message-ID: <759671046.4391029.1336556786739.JavaMail.root@mozilla.com>

[cc'ed to www-font]

One of the unresolved issues in the CSS3 Fonts spec is the issue of
what to do about fallback behavior for subscript/superscript variants
in the 'font-variant-position' property.
 
I'd like to propose that:

  * fallback occurs across a given text run rather than per-character

  * the 'font-variant-position' property is defined independent of 
    the existing use of the font-size/vertical-align properties to
    synthesize subscripts/superscripts

Background

User agents currently support subscripts and superscripts by
explicitly shrinking the font size and adjusting the baseline, via the
user agent stylesheet rules for the sub and sup elements.  The same
size and offset value is used for all content contained within these
elements.

  sub {
    vertical-align: sub;   /* shifts the baseline down */
    font-size: smaller;
    line-height: normal;
  }

  sup {
    vertical-align: super; /* shifts the baseline up */
    font-size: smaller;
    line-height: normal;
  }

OpenType fonts enable the use of subscript/superscript glyphs where
the glyphs are designed within the same em-space as normal characters
and are drawn as any other character is (i.e. with no shift in the
baseline).  This allows type designers to design glyphs specifically
suited for this purpose, ones explicitly intended to match the
underlying default glyphs.

Synthesizing subscripts/superscripts

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.  The result is that '2' will have a
subscript/superscript variant  but '[2]' may or may not depending upon
the font used.  Fonts include size/offset metrics explicitly for
synthesizing subscript/superscript glyphs.

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)

Here's what these three alternates look like for a selection of fonts
that support subscript/superscript variants (testcase here [1]):

  http://people.mozilla.org/~jdaggett/tests/subsupermetrics.png

The fonts used are Calibri, Segoe UI and Gabriola which ship with Windows 7,
Minion Pro from Adobe and Whitney from Hoefler & Frere-Jones.

The variations here illustrate a couple simple points:

  * the offset of the variant glyph varies across font

  * the offset/size of synthetic glyphs based on font
    metrics does not always match the offset/size of the
    variant provided with the font

While in some cases the subscript/superscript metrics are simply based
on a set of default metrics (e.g. Minion), the Whitney case here
illustrates the careful tailoring of these metrics to compensate for
the fact that the resizing of glyphs reduces their effective weight,
the size is larger and the offset less for the synthetic glyph
compared to the designed variant.

This is why I think it's important that fallback behavior be used for
the entire text run included in a subscript/superscript element, rather
than for the specific portions that lack supported variant glyphs. 
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.

Structural vs. typographic subscripts/superscripts

Ideally, it would be nice to allow the use of subscript/superscript
glyphs to "just work", such that user agents could support them in
user agent style sheets.  This is tricky because the existing method
of supporting subscripts/superscripts is basically structural, they
are supported by explicitly manipulating the linebox model.  This
means that non-text content (e.g. images) is supported, as is nesting.
 The use of subscript/superscript variants is basically typographic,
there's no manipulation of the linebox.

Last year, fantasai and dbaron sketched out a proposal for trying to
make the fallback work with the existing mechanism [2].  The proposal
imagines that 'font-variant-position' (called 'magic' as a proxy name
in the proposal) working in combination with 'font-size' and
'vertical-align'; when the value for 'font-variant-position' matches
'vertical-align' and variant glyphs exist, it attempts to use an
inverse tranform to figure out the position and size from the parent.

The proposal relies on the subscript/superscript metrics matching the
variant glyphs which turns out to be a poor assumption, as the
examples above illustrate.  But I think it's possible to imagine a
similar proposal that attempts to fallback back per text-run to
existing behavior when a font lacks variant glyphs or the element
contains nesting without relying on the subscript/superscript metrics.

I think it would be better to keep this as a separate,
typographic-only property that doesn't interact with
font-size/vertical-align behavior.  The set of use cases is limited to
situations where the only content in the subscript/superscript is text
and the linebox is not affected, even in the case where synthesis is
required.  That way existing content that relies on the structural
manipulation of the linebox to place images and text together will be
unaffected.

Regards,

John Daggett

[1] http://people.mozilla.org/~jdaggett/tests/subsupermetrics.html
[2] http://lists.w3.org/Archives/Public/www-style/2011Apr/0391.html
Received on Wednesday, 9 May 2012 09:46:57 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:53 GMT