W3C home > Mailing lists > Public > www-style@w3.org > November 2009

Re: [CSSWG] Minutes and Resolutions TPAC F2F 2009-11-02: font-variant ?and font feature support

From: Thomas Phinney <tphinney@cal.berkeley.edu>
Date: Thu, 12 Nov 2009 15:39:10 -0800
Message-ID: <f49ae6ac0911121539h1632a425sdf37d70bb499db6c@mail.gmail.com>
To: fantasai <fantasai.lists@inkedblade.net>
Cc: www-style@w3.org
Just a terminology clarification, re "concern about exposing alternate

In font-speak, "alternate glyphs" means just about any glyph substitution
built into the font which yields a different glyph or glyphs for the same
underlying Unicode codepoint(s). Small caps, ligatures, real
super/subscript, oldstyle figures... these are all different kinds of
alternate glyphs.

The phrase "alternate glyphs" in this write-up is clearly intended to refer
to a small subset of these features which present a specific problem. Though
it is not written here, based on previous discussion and a priori knowledge,
I expect it refers specifically to the OpenType stylistic alternates
('salt') and stylistic sets ('ssXX') features.



On Thu, Nov 12, 2009 at 3:20 PM, fantasai <fantasai.lists@inkedblade.net>wrote:

> font-variant and font feature support in CSS
> --------------------------------------------
>  jdaggett proposes adding subproperties to font-variant for allowing
>  access to the more common OpenType features. font-variant would
>  become a shorthand for
> font-variant-{ligatures,alternates,caps,numeric,position}
>  There some concern about fallback behavior for subscript and superscript
> features,
>  and winding up with either a complete loss of semantics or a
> double-sub/superscript
>  rendering.
>  John notes that OpenType has language-sensitive rendering, and proposes
> allowing
>  an explicit choice of typographic language different from the content
> language.
>  There's concern about exposing alternate glyphs from a generic mechanism
> such as
>  font-variant, because the choices are very font-specific. Proposals
> include
>  dealing with it in @font-face; and pairing the glyph set number with the
> font
>  name so that it only triggers on that font name.
>  Otherwise the WG is mostly in agreement and pressures jdaggett into
> putting his
>  proposal in the editor's draft. :)
>  <jdaggett> original proposal:
> http://lists.w3.org/Archives/Public/www-style/2009Jun/0506.html
>  <jdaggett> demo page:
> http://people.mozilla.org/~jdaggett/webfonts/features.html<http://people.mozilla.org/%7Ejdaggett/webfonts/features.html>
>  <jdaggett> experimental build:
> http://people.mozilla.org/~jkew/ot-feature-build<http://people.mozilla.org/%7Ejkew/ot-feature-build>
> ====== Full minutes below ======
> <RRSAgent> http://www.w3.org/2009/11/02-CSS-irc#T21-32-53
> Font Feature Support in CSS
> ---------------------------
> <Zakim> +Håkon Wium Lie (Opera)
> <Zakim> +Jonathan Kews (Mozilla)
> ScribeNick: dbaron
>  <jdaggett> next discussion is font feature support in css
>  <jdaggett> original proposal:
> http://lists.w3.org/Archives/Public/www-style/2009Jun/0506.html
>  <jfkthame> so i'm hearing occasional bursts of sound on the phone,
>             but lots of silence..... if you're discussing anything,
>             i can't tell
>  <jdaggett> demo page:
> http://people.mozilla.org/~jdaggett/webfonts/features.html<http://people.mozilla.org/%7Ejdaggett/webfonts/features.html>
>  <jdaggett> experimental build:
> http://people.mozilla.org/~jkew/ot-feature-build<http://people.mozilla.org/%7Ejkew/ot-feature-build>
>  jdaggett: Font feature support in CSS.
>  jdaggett: Many opentype fonts have additional glyph sets in the font.
>  <howcome> www.princexml.com also supports font features
>  jdaggett: They have variations to support various types of ways of
>            rendering text.
>  jdaggett: I'll show demos using an experimental build of Firefox.
>  jdaggett: Demo of 'font-variant: small-caps' with shrunk capitals
>            vs. small cap glyphs in the font.
>  jdaggett: Second demo with "MEgalopolis Extra" font:  alternate glyphs,
>            discretionary ligatures, alternates and ligatures.
>  (Q about whether selection works; demo)
>  jdaggett: third demo: contextual substitution of opentype fractions
>  jdaggett: fourth demo, Coluna font, old style figures by default
>            (numbers have descenders), but options for lining (no
> descenders),
>            tabular (all digits same width), lining+tabular
>  jdaggett: Some proposed extensions to font-variant; URL above ("original
>            proposal")
>  jdaggett: font-variant would become a shorthand for
>            font-variant-{ligatures,alternates,caps,numeric,position}
>  <jdaggett> http://people.mozilla.org/~jkew/ot-feature-build<http://people.mozilla.org/%7Ejkew/ot-feature-build>
>  jdaggett: In WPF, Microsoft has implemented ...
>  <jdaggett> http://msdn.microsoft.com/en-us/library/ms745109.aspx
>  jdaggett's slide shows font-variant-
>    ligatures: common, additional, historical, ...
>    alternates: normal, contextual, styleset #, swash #
>    caps: normal, smal-caps, pettie-caps, titling-caps
>    numeric: normal, lining, oldstyle, tabular, proportional, fractions, ...
>    position: normal, subscript, superscript, ruby, ...
>  fantasai: what happens if the font doesn't have a subscript variant?
>  jdaggett: you get the regular glyph
>  jdaggett: also ones for CJK alternates, need to do more research about
> them
>            to figure out what's needed
>  jdaggett: you could argue that some of these shouldn't be here ...
>  dsinger: If the font doesn't have subscript, I'll get inline figures which
>           changes the semantics
>  jdaggett: This is just saying "give me that glyph", not "change the
> baseline"
>  dbaron: Is it that the fonts have different glyphs for "when used as
>          a subscript"?
>  dbaron: And you'll still get subscript size/positioning if they don't have
>          that?
>  ChrisL & dsinger: bad failure modes are getting double-subscript or none
>                    at all
>  jfkthame: If the semantics are important, people should be using sup/sub
>            elements
>  jfkthame: The opentype features of superiors or inferiors aren't really
>            a first-class replacement for that.
>  jfkthame: If you request the feature and the font doesn't support it,
>            you'll get no change.
>  jfkthame: Intended more for footnote numbers, numeral suffixes
>  fantasai: But if we have this feature people will use it for semantic
>            subscripts (e.g. by assigning styles to <sub>)
>  fantasai: And then for somebody else who doesn't have the font, the
>            user won't see the superscript/subscript.
>  <fantasai> because the currently faking it is ugly
>  jdaggett: I'll note this as an issue and look into it.
>  jdaggett: small-caps has issue being existing value
>  alexmog: I want all my subscripts to do the typographically correct thing,
>           but I never want the effects to multiply.
>  SteveZ: small-caps has two effects ...
>  SteveZ: some of these are mutually exclusive
>  jdaggett: yes, the proposal goes into that in detail
>  (shows 0506.html)
>  jdaggett: Shows old-style numerals vs. lining numerals
>  jdaggett: Demo: swash characters in Garamond Premier Pro
>  jdaggett: ... and additional ligatures
>  jdaggett: Opentype has language-sensitive rendering.  Demo for Macedonian.
>  alexmog: yes, that looks more Macedonian.
>  jdaggett: important not to ligaturize fi in Turkish so that dotted and
>            dotless i can be distinguished
>  jdaggett: Demo: Also small-caps distinctions for Turkish.
>  jdaggett: example of lots of features at once
>  tantek: That also looks like copyfitting.
>  jdaggett: OpenType has the ability to specify a script and a language.
>  jdaggett: But it's not precisely a language, it's a language system.
>  <tantek> would be great to get a URL to the "lots of features at once"
> example
>  jdaggett: But you can display Greek in the French way of displaying Greek.
>  jdaggett: So one might want a way of choosing the typographic language
>            separately from the language.
>  fantasai: As long as the default is 'auto' and that uses the markup
> language.
>  (Turkish demo was using 'calluna' font.)
>  jdaggett: Style sets get kind of hairy, having the number.
>  <TabAtkins> http://people.mozilla.org/~jdaggett/webfonts/features.html<http://people.mozilla.org/%7Ejdaggett/webfonts/features.html>
> ,
>              page to the end
>  jdaggett: This is the argument we've been having on the list... what
>            happens in the fallback case.
>  jdaggett: You're not going to get unreadable text, you just won't get
>            what the author hoped for.
>  jdaggett: Or you could say some of these apply only to the first font
>            in the list.
>  <tantek> TabAtkins - interesting, in an old nightly of Webkit - the
>           text is *not* copyfit - so this tells me that the OpenType
>           features may be making use of some copyfitting feature somewhere?
>  ChrisL: That could have issues if you're using a font list to get good
>          Latin from one font plus good Japanese from the second font,
>          you might want properties for the Japanese font.
>  jdaggett: Doing something fancy... but that has the problem of an author
>            having trouble figuring out what happened.
>  <tantek> TabAtkins - n.m. just viewed source - each line's font-size is
>           set explicitly.
>  fantasai: Leave swash in as a keyword, so you can just get the first one.
>  <tantek> for reference:
> http://people.mozilla.org/~jdaggett/webfonts/features.html#page%2014<http://people.mozilla.org/%7Ejdaggett/webfonts/features.html#page%2014>
>  <TabAtkins> tantek: Yah, just wait a bit and we'll hit the copyfitting
>              issue.  ^_^
>  * tantek didn't know that you could put a " " (space) in an id attribute
>           and have it "work"
>  jdaggett: We could add a font-variant descriptor for @font-face that
>            would only apply the features to that specific face.
>  jdaggett: I like the idea of allowing that, but I don't like the idea of
>            requiring it.
>  howcome: There's pain to dealing with several @font-faces, but it's a
>           neat way of achieving what we want.
>  <Bert_lap> ->
> http://people.mozilla.com/~jkew/feature-samples/MEgalopolis.html<http://people.mozilla.com/%7Ejkew/feature-samples/MEgalopolis.html>
>           The multi-feature, justified example with MEgalopolis from the
> slides
>  <TabAtkins> In the font-variant-* properties, use a functional notation
>              to target it at specific fonts.
>  howcome: I'm tempted to go down the @font-face route, even if it's a
>           little inconvenient sometimes.
>  jdaggett: I think it's impractical because you'd have so many permutations
>            that it's impractical to use @font-face rules
>  <TabAtkins> font-variant-ligatures: font-face("foo",lig 1), lig 2
>  <TabAtkins> ^^^ Would activate lig2 on all fonts, but lig1 only on "foo"
> font.
>  fantasai: I'm saying a property is fine for most of these, but require
>            it in @font-face for alternate glyphs, whose values are very
>            specific to individual fonts.
>  SteveZ: In that list, there are only 2 things taking numeric values:
>          style sets and alternates.  Treating those two differently
>          from all the others makes perfect sense.
>  SteveZ: And, secondly, those are the two places where things are much
>          more font-specific.
>  SteveZ: So I would argue that I'd introduce a property: one for style
>          sets and one for alternates, where the property would take...
>  SteveZ: ... a font and a style set number that goes with that font.
>  SteveZ: So you'd match which element in the list corresponded to the
>          font actually chosen.
>  howcome: You're proposing two new properties with comma-separated values?
>  SteveZ: yes
>  TabAtkins: font-variant-ligatures: font-face("foo",lig 1), lig 2
>  jdaggett: Originally I had a functional syntax, but people said we don't
>            really have that.  I think a functional syntax would work just
>            as well.
>  dsinger: It seems like you'd only have an explosion of @font-face rules
>           if you have an explosion of styles on the page, which often
>           isn't a good thing.
>  jdaggett: @font-face is just defining one face of a family:  So you'd
>            then have to define all these variations across all faces of
>            the family.
>  SteveZ: If I want to write a description of 18th century typography in
>          English... historical ligatures, historical letterforms...
>          which I only want to use in examples.
>  dsinger: You're probably using a different font for the 18th century text.
>  dsinger: The features would be consistently off in the modern text and
>           on in the 18th c. text.
>  SteveZ: It's perfectly reasonable that I'm using an 18th c. font for
>          my body text.
>  fantasai: It doesn't matter how many features you're turning on and off.
>  SteveZ: Each paragraph would have different features on it.
>  SteveZ: Because I'm writing about typography
>  fantasai: That's a very special edge case.
>  dbaron: Writing about typography is an edge case.
>  dsinger: If you're actually showing lots of faces, that's not a failure
>           of CSS.
>  jdaggett: That's against the way CSS works, because you're forcing
>            everything into @font-face rules, and people don't have the
>            ability to change specific properties.
>  jdaggett: You've eliminated inheritance.
>  dsinger: But then you're asking for a feature in a font that you might
>           not be using.
>  ...
>  dsinger: I don't mind changing what it looks like, but I mind changing
>           the meaning.
>  jdaggett: It's not undermining fallback, it's still an "a".
>  jdaggett: 3 options, let substitution occur, (2) apply only to first font
>           (3) put feature variants into @font-face, (4) Steve's property
>           that takes family name
>  fantasai: Issue of mixing Latin font with Chinese font and choosing
>            alternatives in both.
>  jdaggett: I like the idea of allowing features to be set in @font-face,
>            but I don't like it being the only mechanism.
>  howcome: You could combine (2) and (3).
>  jdaggett: The complication that these are all shorthands:  set all other
>            values to default.
>  SteveZ: My proposing allows a list that includes fonts that aren't being
>          used... reduces that problem.
>  <ChrisL> szilles proposal does not suffer from that
>  howcome: There's basically a scripting language underlying that... similar
>           to text-replace.
>  <glazou> text-replace lalala lalala :-)
>  jdaggett: But that's all *inside* the font.
>  howcome: But you can turn those features in the font on and off using
>           this mechanism.
>  Steve: Fonts gave you that problem, even without variants.
>  ChrisL: That's how people used to do Greek in Web pages.
>  <Bert_lap> (People in India are still doing this, using fonts with Indic
>             glyphs in ASCII slots...)
>  jdaggett: I think that's all I have... I just wanted to present this.
>  jdaggett: I think there's more that needs to be hashed out.
>  ChrisL: You were demoing with a special build.
>  jdaggett: Yes, that build just has a single property demo hack to turn
>            off opentype features by name.
>  SteveZ: I'd like some action to come out of this discussion.  (1) Do
>          people think that John is on the right track?
>  ChrisL, fantasai: yes
>  <ChrisL> I'd like to see this put into the spec
>  Bert: I'm happy to see more attention to typographic features; I've always
>        wanted tabular figures; but I'm wondering why suddenly this
> attention
>        for putting every opentype feature into CSS when we still don't have
>        hyphenation and leaders.
>  jdaggett: We're not talking about every opentype feature; a fair number
>            have been omitted. We're taking some features that are more
>            abstract. Also not, e.g., not exposing multiple ways of doing
>            fractions.
>  fantasai: hyphenation's also hard because of need for dictionary
>  jdaggett: Hyphenation is a somewhat tricky problem:  language-based, and
>            all sorts of typographic rules for hyphenation.
>  ChrisL: These are orthogonal features.
>  howcome: We have hyphenation specced out.
>  Bert: Prince now has the whole-paragraph justification from TeX, but
> Mozilla
>        will have swash characters but still won't do justification right.
>  Bert: Things like proper justification and hyphens have a much bigger
> effect.
>  dbaron: those are layout features, adding to an area of CSS that's already
>          very complicated.
>  fantasai: font features are better encapsulated
>  jdaggett: And having @font-face gives us the opportunity to do more with
>            fonts now.
>  SteveZ: The other thing I'd want is getting a clear statement of how
>          things like subscripts and small-caps interact with existing
>          facilities: so that (a) we don't get semantic changes and (b) ...
>  dsinger: yep
>  jdaggett: font-variant is part of the 'font' shorthand; we don't want
>            any of this new stuff in the 'font' shorthand
>  howcome: John, if we have a property that holds the features, do you
>           see that as inherited independent of font-family?
>  jdaggett: Yes.  It makes sense for many things, e.g., tabular figures.
>  howcome: Should a randomly-named feature inherit?
>  jdaggett: I don't even have a plan for including enabling/disabling
>            arbitrary features.
>  jdaggett: I'm not keen on writing a spec for that, at least initially.
>  howcome: When I said I wanted to go down the @font-face route, I meant
>           that only for arbitrary features, not for features that we
>           standardize.
>  howcome: For the features we standardize, I think we should absolutely
>           have properties that work the normal way.
>  SteveZ: So it sounds like we're mostly in agreement.
>  ChrisL: So we can start moving this stuff into the spec?
>  jdaggett: I still don't have a sense of the alternates...
>  ChrisL: I think it's time to start moving it into a spec now.
>  fantasai: I agree with that.
>  ChrisL: exposes it to more people, get wider review
>  jdaggett: Still not confident of ...
>  dbaron: Put big red issues in the spec so people know.
>  fantasai: That's why we have class="issue" :)
>  <ChrisL> Don't let that put you off. Lets get it into the spec
Received on Thursday, 12 November 2009 23:39:45 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:40 UTC