Re: [css3-fonts] subscript/superscript variants
Thomas Phinney <[email protected]> Wed, 9 May 2012 04:16:41 -0700
| Newsgroups | gmane.comp.web.fonts,gmane.comp.web.css.general |
|---|---|
| Message-ID | <[email protected]> |
This approach makes sense to me. I have had some lengthy discussions in the p= ast about "correct" behaviors for desktop apps confronted with the same issu= es, 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 <[email protected]> wrote: >=20 > [cc'ed to www-font] >=20 > 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. >=20 > I'd like to propose that: >=20 > * fallback occurs across a given text run rather than per-character >=20 > * the 'font-variant-position' property is defined independent of=20 > the existing use of the font-size/vertical-align properties to > synthesize subscripts/superscripts >=20 > Background >=20 > 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. >=20 > sub { > vertical-align: sub; /* shifts the baseline down */ > font-size: smaller; > line-height: normal; > } >=20 > sup { > vertical-align: super; /* shifts the baseline up */ > font-size: smaller; > line-height: normal; > } >=20 > 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. >=20 > Synthesizing subscripts/superscripts >=20 > 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. >=20 > This gives three alternates for subscripts/superscripts: >=20 > (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) >=20 > Here's what these three alternates look like for a selection of fonts > that support subscript/superscript variants (testcase here [1]): >=20 > http://people.mozilla.org/~jdaggett/tests/subsupermetrics.png >=20 > The fonts used are Calibri, Segoe UI and Gabriola which ship with Windows 7= , > Minion Pro from Adobe and Whitney from Hoefler & Frere-Jones. >=20 > The variations here illustrate a couple simple points: >=20 > * the offset of the variant glyph varies across font >=20 > * the offset/size of synthetic glyphs based on font > metrics does not always match the offset/size of the > variant provided with the font >=20 > 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. >=20 > 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.=20 > 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. >=20 > Structural vs. typographic subscripts/superscripts >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > Regards, >=20 > John Daggett >=20 > [1] http://people.mozilla.org/~jdaggett/tests/subsupermetrics.html > [2] http://lists.w3.org/Archives/Public/www-style/2011Apr/0391.html >=20