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