Re: [css3-fonts] opentype font feature support

Jonathan Kew:
> On 4 Mar 2010, at 13:30, Christoph Päper wrote:
>>> http://dev.w3.org/csswg/css3-fonts/
>> 
>> the draft properties are very close to OT features. That is not really a good thing, since those are not coherently or consistently designed. In many cases a more abstract approach is more author-friendly (…)
> 
> I agree that the design of the OT features are not always ideal; nevertheless,
> this is the dominant font technology in the market, now and for the foreseeable future, so I think we have little choice but to look primarily (not exclusively) at this if we hope to see these capabilities implemented broadly and consistently.

There certainly should be guidance how CSS properties relate to OT features, but this by no means requires 1:1 relationships.

> Attempting to create some kind of "abstract" approach that does not rely heavily on the existing implementation technology seems to me a recipe for unending debate,

This CSS facade to OT inner workings is necessary for the everyday user of CSS who is more likely to know one or two things about typography than anything about low-level font technology.

> and for confusion among font developers and users who will struggle to understand the complex mapping between CSS's abstract model and the actual fonts in their hands.

OT font developers should not have to care about CSS. CSS authors should not have to care about OT (or AAT or whatever).

>> 6.2 font-variant-ligatures: normal | inherit | <ligature-values>
>> 
>> In which cases does ‘hlig’ not imply ‘dlig’ and where does ‘dlig’ not imply ‘liga’? 
>> I read Adobe Indesign(?) only allows the user to switch on and off “discretionary ligatures”, which combines ‘hlig’ and ‘dlig’.
> 
> It's interesting that earlier, you're asking for something more "abstract", divorced from the particular implementation technology; but now referring to a specific implementation for guidance.

I’m arguing against the threepart on/off-mapping and just provided one example of a major player in this field who seemed to believe one of the distinction was unnecessary. Of course, if Thomas Phiney says this was not a good choice, then that’s a major voice agaist. Still, I don’t like the ‘no-’ keywords.

What about this (‘inherit’ left out):

  font-variant-ligatures: <ligature-value> [<ligature-value> [<ligature-value>]]
  <ligature-value> = none | auto | normal

‘none’ disables, ‘auto’ (or some better keyword) enables and ‘normal’ uses the font’s default.
If one value is present it is used for common, additional and historic ligatures.
If two values are present the first is used for common, the second for additional and historic ligatures.
If three value are present, guess what.

‘font-variant’ may take the value ‘ligatures’ which means “font-variant-ligatures: auto none”, otherwise it resets to the default ‘normal’ (or ‘normal none’?).

If you want we can put commas between the values.

> Personally, I think our first reference should be OT feature registry

I disagree, obviously. It’s a major point of reference, though.

> (not a particular application's interface to a subset of the registered features).

I agree, it was just an example that I recently came across. Nevertheless, existing UIs to access typographic icing provide some kind of insight to what authors will expect to be able to do.

>> I believe we can fulfill the Pareto principle (80:20) with four values besides ‘normal’:
>>    L A H
>>    + + +             ‘all-ligatures’
>>    + + -  or  + + o  ‘additional-ligatures’
>>    + - -  or  + o o  ‘common-ligatures’, ‘ligatures’
>>    - - -             ‘no-ligatures’ 
>>    o o o             ‘normal’
> 
> I'd be interested to hear from font designers whether the ligature features they implement are viewed as always fitting into this kind of strict hierarchy, where each "level" is expected to imply the use of all lower levels as well. Or are "historical" and "discretionary" ligatures potentially orthogonal choices?

Me too. (Please note that I didn’t claim this would cover all cases, but enough.) At least we got one font developer saying that ‘hlig’ does not necessarily imply ‘dlig’. Although this might not prove to be enough to hit 20% of use cases, I won’t argue strongly any more for the hierarchic model I proposed earlier.

>> 6.3 font-variant-alternates: normal | inherit | <alternates-values>
>> 
>> Now this part I don’t like at all. It lumps too much together with too many numbers. CSS is not designed to allow modifications on a per character level.
>> We should go with the usual OT suggestion and assume that the first alternative variant in a font is the preferred one.
> 
> I interpret this suggestion in the feature registry as just that: a suggestion, primarily aimed at applications that are unwilling to extend their user interface to allow explicit selection from a set.

I interpret it primarily as a design guide for font developers who should put the preferred variant first, because some implementations will use that.

> I don't think CSS need (or should) be limited in this way.

So you actually would people have put tags around each character they want to use a glyph variant for? You could do so with twenty-odd classes, but what a mess that would be!

If you don’t want that, how do you expect this part of CSS be applied to markup languages / DOMs?

The selectors are one part of the problem here, the other is differences in fonts. CSS should be as semantic as possible. If the underlying technology can only provide arbitrary codes then these shouldn’t be featured prominently in CSS, but left to properties like ‘font-feature-setting’, or in this case perhaps to ‘@font-face’ descriptors.

>> That means drop all “(<number>)” and ‘styleset’ altogether.
> 
> No; certainly in the case of styleset, it is essential to provide a number (…).

Of course. That’s why I had to conclude the value be dropped if the numbers went to draft feature heaven.

> Styleset features are the primary way some designers provide access to various collections of alternate glyphs.

Simply put, CSS must not use an arbitrary external system like this. If OT features don’t cover it, font vendors should come up with a more complex description system for stylistic sets. That CSS could use.

Until then, ‘font-feature-setting’ – as much as I’d hate to lose simple access to these variants.

>> 6.3.1 Swashes
>> 

I will respond on swashes and ‘font-style’ in a separate mail as soon as I’ve made up my mind about it. For now I’ll only say that it would be really nice if ‘swash’ could work linewise, i.e. as an alternative (or addition) to justified alignment it would automatically activate as many swashes as possible to reach the available line width, but not more so no new line breaks would occur.

>> 6.5.2 Numerals
>> 
>> In <numeral-height> ‘oldstyle' is a common, but not an adequate term.
> 
> Why is it not adequate? I think it is the most widely used/understood term for this design feature; why not use it?

The opposite is not ‘newstyle’. It’s not really old style since lining figures have been used before and “oldytyle” is still in use. “oldstyle” may be understood as +variable-width +variable-height, not just +variable-height. “old” is derogative in this case.

>> Since not all of the 4 <numeral-style> variants may be available, the last matched should probably be used – or should a mismatch reset to default ‘normal’?
> 
> How those features interact within the font is out of scope for CSS, it is the responsibility of the font developer.

OK, if it “just works” it’s fine with me. If I understand it correctly, though, CSS authors can’t choose whether they consider height or width of the numerals more important. They have to trust the font makers.

>> 6.9 font-lang-sys: normal | inherit | <string>
>> 
>> This property currently uses OT language tags which are not really well designed or known as far as I know. It would be better for authors to use [BCP47] and let UAs do the mapping.

<string> probably would not be restricted to a single language code, but be a (comma separated) list ordered by preference.

> There will be cases where users need to select an alternative "best fit" language system according to what is actually available in their chosen fonts, and it is not possible for browsers to handle this reliably by mapping from BCP47 codes.

Then this would be a OT-specific property, something we should avoid. I will send another mail with a quick statistics check on the available language tags.


I value your responses highly, but whereas I was arguing for author-friendliness, the three of you who have disregarded most of my points, i.e. Thomas Phinney, Jonathan Kew and Adam Twardoch, seem too close to the font and browser developer side on this. You all know OT far better than me, but how many CSS authors do?

Received on Saturday, 6 March 2010 13:51:25 UTC