Re: [CSSWG] Minutes and Resolutions 2010-03-17

John Daggett wrote:

> ======
> 
> Name:    character-transform
> Value:   normal | inferior | ordinal | subscript | superscript
> Initial: normal
> 
> The values 'subscript', 'superscript', 'inferior', and 'ordinal' imply
> the appropriate variant glyph is displayed when available in the font
> (OpenType features: subs, supr, sinf, ordn).

FYI: <subs> and <sinf> should be considered functionally identical -- as 
they are in the vast majority of fonts, and as recommended by Adobe and 
Microsoft --, and I think are best addressed via a single CSS value 
'subscript'. If a font contains both <subs> and <sinf> features, then a 
decision needs to be made as to which gets precedence. In most cases, it 
won't matter, because most font developers duplicate the same lookup, 
but there are a handful of older fonts, e.g. Palatino Linotype, that 
have distinct <subs> and <sinf> positioning, and for which <sinf> gives 
better results; note, however, Adobe's position as stated below.

The definition of two separate subscript features was due to a 
misunderstanding in the early days of OpenType, when someone thought a 
distinction was necessary between reduced letters sitting on the 
baseline and reduced characters sitting below the baseline. 
Typographically, there is no recognised role for reduced characters 
sitting on the baseline, and subscript letters and numerals always sit 
below the baseline.


David Lemon (Adobe) wrote the following to the OpenType developer list 5 
July 2006:
_____

I wanted to alert other developers to a change in thinking about the 
'subs' and 'sinf' layout features.

Microsoft originally defined the 'subs' (subscript) layout feature to 
produce small glyphs resting on the font's common baseline (as shipped 
in the first versions of Palatino Linotype). Adobe discussed this with 
Microsoft, and decided to register the 'sinf' (scientific inferiors) 
layout feature, to accommodate what we had previously considered 
subscripts in our fonts.

As I trust all have heard by now, Adobe is in the process of reworking 
our OpenType fonts to reflect current best practices. We've decided to 
switch to using 'subs' for our subscript glyphs (and of course leave 
them hanging below the baseline).

Current Adobe layout applications check first for 'sinf' when a user 
requests subscripts; if it's not found, they check for 'subs'. Future 
versions plan to reverse this order. Application developers should note 
that it would be unwise to assume that the millions of fonts we've 
licensed to end users will disappear in the next few years, nor that any 
other foundries' fonts will instantaneously change.

We're backing away from using 'sinf' for subscripts because Microsoft 
now agrees that subscripts should sit below the baseline. And we're told 
that when applications are written to use the coming WPF architecture, 
they'll get only 'subs' when requesting subscripts. (Note: This 
limitation can already be seen in Quark XPress 7.)

Although I wrote 'sinf' to describe subscripts without using that word, 
Microsoft believes there's value in retaining it for inferior glyphs 
which are different from subscripts. (I'm told Bitstream has made 
several such sets.) Any font developer who includes small inferiors 
using 'sinf' that shouldn't be treated as subscripts by Adobe layout 
applications should ensure that there's a true subscript set (in 'subs') 
as well.
_____



John Hudson

Received on Tuesday, 23 March 2010 18:23:22 UTC