Re: [css3-fonts] subscript/superscript variants

This approach makes sense to me. I have had some lengthy discussions in the past about "correct" behaviors for desktop apps confronted with the same issues, so I have wrestled with these questions at length before.

(I do have the same clarification request that Tab brought up, however.)

Cheers,

T

On May 9, 2012, at 2:46 AM, John Daggett <jdaggett@mozilla.com> wrote:

> 
> [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 11:17:21 UTC