- From: Jonathan Kew <jonathan@jfkew.plus.com>
- Date: Sun, 1 Nov 2009 23:02:24 -0500
- To: Stephen Zilles <szilles@adobe.com>
- Cc: Håkon Wium Lie <howcome@opera.com>, "robert@ocallahan.org" <robert@ocallahan.org>, "www-font@w3.org" <www-font@w3.org>, "www-style@w3.org" <www-style@w3.org>
On 1 Nov 2009, at 20:54, Stephen Zilles wrote: > +1 for Rob's suggestion below from me as well. > > And, like Hakon, I am for keeping the #font-face rule behavior as it > is now. > > My only concern, however, is that turning features on or off needs > to occur in the content not just in the font descriptor. Yes, I know > that one can have two fonts that are identical except for the > feature of interest and switch fonts to effect the turning on and > off of the feature, but that seems rather a complex way to make a > temporary "binary" change. And, if there are a lot of features to > control, this could lead to a lot of font descriptors. Agreed; it seems clear to me that we should be able to switch features on and off in the content, without requiring a new font descriptor for every combination of features. It's perfectly reasonable to want certain features within just a restricted part of the content (e.g., tabular numerals within a table, but proportional ones elsewhere; decorative swashes or other alternates applied to certain spans only; a fractions feature applied just to the actual fractions, so that digits elsewhere in the text are unaffected; etc.) Things like this should not require new @font-face rules with separate family names. I'm happy to *also* allow such features to be specified within the @font-face rule. In this case, they would become defaults for the face in question, adding to (or subtracting from) the initial set of features such as canonical compositions, standard ligatures and kerning that the shaping engine should be applying by default. Any feature changes specified in the content would then be applied to this new set of defaults for the font. It would also be wrong for us to try and divide features into two classes, and insist that some can be specified only within the @font- face rule and others within the content. It's true that if an author specifies certain features in a context where the font is not known with any certainty -- e.g., system font fallback is happening -- then the results may be somewhat arbitrary; but this is no worse than the unpredictability of using system font fallback in the first place, when the exact glyphs that will appear are not known, and depend on the fonts that happen to be on the user's system. JK
Received on Monday, 2 November 2009 04:03:48 UTC