- From: Thomas Phinney <tphinney@cal.berkeley.edu>
- Date: Thu, 4 Mar 2010 10:53:33 -0800
- To: Jonathan Kew <jonathan@jfkew.plus.com>
- Cc: www-style list <www-style@w3.org>
I was going to respond to Christoph's lengthy email, but virtually something quite miraculous happened. Jonathan Kew replied, AND I agreed with literally everything he wrote. Generally rather strongly. So I will only add a few points where I have something else to say. Otherwise you can just pretend I parroted JK's comments. ;) I will say that while I agree with JK's comments on direct feature support vs. abstraction, I certainly understand and agree that there is plenty of room for debate on this issue. I would however frame the debate with the idea that font formats have an awful lot of inertia, and that OpenType is very likely going to be dominant for another 15+ years. I will add that: - hlig and dlig (historical and discretionary ligatures) really need to be independent, not "levels of ligation"; in terms of what's built into fonts and what users will want to do with them. For example, in my own Hypatia Sans, 'hlig' is used for the quite archaic ct and st ligatures (a common use of 'hlig'), while 'dlig' is used for cap-to-cap ligatures that are unusual in a very different way. Implementations that don't allow them to be turned on separately are less than ideal. - when talking about numerals, I don't see any reason to support some huge list of synonyms. "Oldstyle" is by far the dominant English typographic term, so let's use it. - agreed that numeral height and width are independent, and that an increasing number of fonts may also affect numeral style via the cap-formatting (small caps, petite caps). I don't know if it matters, but folks should be aware that the default value could be any of the above, or something else entirely. - I don't see "font-variant-epoch" interacting meaningfully or consistently with different fonts and writing systems. I suppose one could turn on 'hist' and 'hlig' with a single toggle, which might also do 'onum' and 'pnum', but one needs to access the numeric stuff separately anyway. - arguably 'init' and friends ought to be on automatically for all writing systems. Besides being required for Arabic, type designers use them for script fonts outside of the Arabic context. - please don't assume that existing OpenType implementations are ideal, when it comes to combining features or taking the first available alternate. I've been involved in these decisions, for more than one major vendor, and even made some key calls personally. First, some decisions were made as far back as 2000-02, before so many possibilities had been worked out by font developers. Second, these decisions have often been driven by graphical UI considerations that simply don't apply here, like making a menu even longer or a dialog bigger, or how to present a "choose one of many" decision.... Regards, T On Thu, Mar 4, 2010 at 9:25 AM, Jonathan Kew <jonathan@jfkew.plus.com> wrote: > On 4 Mar 2010, at 13:30, Christoph Päper wrote: > >> John Daggett: >>> http://dev.w3.org/csswg/css3-fonts/ >>> >>> Included are additional properties for supporting OpenType font features, >> >> Yay! But, … >> >> 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 and also does not discriminate against AAT etc. > > 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. 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, 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. > >> 6.1 font-kerning: normal | inherit | enabled | disabled >> >> There are few properties that use generic on/off state names like ‘enabled’ and ‘disabled’. I would prefer not to see more of them, but I do not know which pair of words would be better here, ‘kern’/? perhaps. > > I'd be happy to hear alternative suggestions, although as the draft does not currently include font-kerning as one of the properties controllable via the font shorthand, I don't think the generic "enabled" and "disabled" are particularly problematic here. > >> 6.2 font-variant-ligatures: normal | inherit | <ligature-values> >> <ligature-values> = [ common-ligatures | no-common-ligatures >> | additional-ligatures | no-additional-ligatures >> | historical-ligatures | no-historical-ligatures >> ]+ >> >> This probably would be written better like this: >> >> <ligature-values> = [ common-ligatures | no-common-ligatures ] >> || [ additional-ligatures | no-additional-ligatures ] >> || [ historical-ligatures | no-historical-ligatures ] >> >> Is this grade of control really necessary or useful? 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. Personally, I think our first reference should be OT feature registry (not a particular application's interface to a subset of the registered features). > >> Table: Usefulness of combinations >> R | L A H use L A H use L A H use >> ---+-----------+-----------+----------- Legend >> o | + + + yes o + + ? - + + no R required (rlig) >> o | + + o yes o + o ? - + o no L common (liga) >> o | + + - yes o + - ? - + - no A additional (dlig) >> o | + o + ? o o + ? - o + no H historic (hlig) >> o | + o o yes o o o yes - o o ? C contextual (clig) >> o | + o - ? o o - ? - o - ? D discretionary (dlig+hlig) >> o | + - + no o - + no - - + no + enable >> o | + - o ? o - o ? - - o ? o default, normal, inherit >> o | + - - yes o - - ? - - - yes - disable >> >> I believe we can fulfill the Pareto principle (80:20) with four values besides ‘normal’: >> >> + + + ‘all-ligatures’ >> + + - or + + o ‘additional-ligatures’ >> + - - or + o o ‘common-ligatures’, ‘ligatures’ >> - - - ‘no-ligatures’ >> o o o ‘normal’ >> >> font-variant-ligation: full | most | some/partial | none | normal >> >> For finer control there still is‘font-feature-setting’. > > 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? > >> 6.3 font-variant-alternates: normal | inherit | <alternates-values> >> <alternates-values> = [ stylistic(<number>) >> | styleset(<number> [,<number>]+) >> | contextual | no-contextual >> | contextual-swash(<number>) >> | swash(<number>) >> | historical-forms >> | ornament(<number>) >> | alt-annotation(<number>) >> | ruby >> ]+ >> >> 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 don't think CSS need (or should) be limited in this way. > >> That means drop all “(<number>)” and ‘styleset’ altogether. > > No; certainly in the case of styleset, it is essential to provide a number (this maps to any of the 20 registered ss## features; whether implementations should limit it to the range 1-20 is perhaps an interested topic for discussion). Styleset features are the primary way some designers provide access to various collections of alternate glyphs. > >> >> For finer control there still is ‘font-feature-setting’. >> >> 6.3.1 Swashes >> >> I would prefer to have swashes fallback to italics, therefore: >> >> font-style: normal | italic | oblique | swash | inherit >> normal < upright < oblique/slanted < italic < swash < cursive < script >> >> That is, unless I am mistaken and swashes also worked well with upright faces. After all, there are upright italic fonts. > > And there are "roman" fonts that include optional swash glyphs; Hoefler Text as shipped with Mac OS X comes to mind. The use of swash variants is an option within a particular font face; the choice between "normal" and "italic" styles is a choice between two different faces. Swash does NOT belong here in font-style. > >> Hm, what about broken scripts, i.e. “blackletter”, “gothic”, Fraktur. > > These are separate font families. > >> >> 6.5.2 Numerals >> >> <numeral-style> = <numeral-width> || <numeral-height> >> <numeral-height> = lining | oldstyle >> <numeral-width> = proportional | tabular >> >> 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? > >> Wikipedia knows the synonyms in the antonym lists following this paragraph numerals or figures (why not ‘digits’?). Surprisingly the alternative does not feature the common antonyms ‘modern’, ‘new-style’, ‘uppercase’ etc., but only ‘lining’ and ‘titling’. >> >> Height Width >> text <> (table, tabular) proportional <> (constant) >> *non-lining <> lining (variable) <> (fixed) >> lowercase <> (uppercase) (text, textual) <> tabular >> antique <> (modern) >> old-style <> (new-style) >> billing <> titling >> ranging <> ? >> hanging <> ? Keywords in parentheses not found on WP. >> >> 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’? > > Numeral "height" and "width" are independent axes; if a font provides some but not all of the possible combinations, then the result of any given pair of features is determined by the font designer, according to the priority given to the various lookups in the font. Except where features are defined as mutually exclusive (such as the two options for width), and so later settings override earlier ones, the user agent does not care about the order of specification; it simply builds a collection of features that are applied to the chosen font. How those features interact within the font is out of scope for CSS, it is the responsibility of the font developer. > >> There seem to be several OT features related to Indian, Korean, Khmer and Syriac scripts, do none of them require exposure to CSS authors? > > > No. (Like 'init', 'medi', 'fina', 'isol' for Arabic script.) These "belong" to the script-specific shaping engine and are applied automatically to the relevant glyphs. The various script-specific specifications on the Microsoft typography site document how and where they are to be applied. > > I suppose some implementations might allow font-feature-setting to override these, but this would only be relevant in highly exceptional situations where the author deliberately wishes to "break" the normal rendering of a script. > >> 6.9 font-lang-sys: normal | inherit | <string> >> >> This property currently uses OT language tags which are not really well designed or know as far as I know. It would be better for authors to use [BCP47] and let UAs do the mapping. > > Normally, text should be tagged with its [BCP47] language code in the HTML, and the UA should map this to the appropriate OT language system, as stated in 6.9. However, the reality is that the mapping from BCP47 to OT language systems is not always clear or unambiguous, nor is the collection of language systems actually supported in fonts consistent. 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. > > JK > > > -- "The rat's perturbed; it must sense nanobots! Code grey! We have a Helvetica scenario!" — http://xkcd.com/683/
Received on Thursday, 4 March 2010 18:54:11 UTC