[CSSWG] Minutes and Resolutions Tokyo F2F Fri: Fonts


    - Discussed font-weight: bolder/lighter and jdaggett's proposal
      to just step up/down the numerical scale rather than tracking
      the actual weights available. WG seems to want to move in that
      direction, jdaggett will write up and ping absent members.

    - Discussed issue with font-weight: bolder/lighter definition in 2.1.
      jdaggett proposed stepping up/down a set of numerical mappings for
      bolder/lighter that avoids need to reference font data.  He will
      write up this proposal and send to www-style.

    - Discussion of mapping fonts into family groupings, especially
      constraints under Windows.

    - Discussed proposed addition of @font-alias to allow a single font
      family name to be aliased to a set of names

    - RESOLVED: local() doesn't require quotes, format() does

    - RESOLVED: format() is authoritative. User agents should never download
                or use formats they don't support as indicated by format().

    - RESOLVED: in case of multiple listed src() in a single @font-face
                that are both supported only the first is used

    - RESOLVED: the effective unicode range is the intersection of the font cmap
                 and unicode-range within the bounderies of unicode-range

    - RESOLVED: unicode-range initial value should be 0-U+10FFFF

    - Discussed name to use for cross-platform lookup of font faces by name

====== Full minutes below ======

    David Baron
    John Daggett
    Elika Etemad
    Sylvain Galineau
    Chris Lilley
    Håkon Wium Lie
    Anne van Kesteren
    Mike Smith
    Steve Zilles

<RRSAgent> logging to http://www.w3.org/2009/03/06-css-irc
Meeting: Cascading Style Sheets (CSS) Working Group F2F Tokyo
Date: 05 March 2009
Chair: Chris

Scribe: Anne

font-weight: bolder/lighter

    <jdaggett> http://people.mozilla.org/~jdaggett/mplustest.html
    jdaggett: In Cambridge we discussed bolder and lighter
    <jdaggett> http://www.w3.org/Style/CSS/Tracker/issues/61
    jdaggett: It's a frustrating discussion, because of platform restrictions
              and lack of [cool] fonts
    jdaggett: m+ (Japanese Open Source font) supports seven weights
    jdaggett: 300 is equal to 200, 700 is equal to 600
    jdaggett: the issue in Cambridge was, given a line of text, given font
              fallback, multiple fonts can be used, then with nested elements
              with bolder, bolder, bolder, what should happen?
    Chris: if you have a value already from an inherited context [... scribe
           missed ...]
    jdaggett: where do you make the determination?
    jdaggett: am I simply doing incremental steps of boldness or am I picking
              a font somehow and resolving the calculation at that point
    jdaggett: of course the computed value comes in because it becomes funny
    dbaron: computed value can be 1) just a weight, 2) a pair of a weight and
            a number (number indicates times bolder written), 3) a weight plus
            a sequence of bolder/lighter steps
    Steve: when I say bolder and there are at least two weights in the font,
           I'm at the lighter of the two, I'm in a span that has a bolder,
           what should I expect?
    jdaggett: euh, the bolder one
    Steve: it changes the number
    jdaggett: Bert proposed that you calculate a number based on the first font
    jdaggett: the reason I brought up m+ is that there a number of gotchas
              with that
    jdaggett: [missed]
    <ChrisL> (Chris demonstrates some tests with ZalamanderCaps, a font with
             six weights)
    jdaggett: if I say my body is 400 and I go to bolder
    jdaggett: then you get 500, but then if you have a fallback font that has
              400 and 700 you end up with 400 again
    jdaggett: In the real world, most platform fonts are just 400/700
    jdaggett: I suggest we simply iterate through 100/400/700/900 for
    howcome: you can still use the absolute values if you really know things
    howcome: this is just for the relatives
    Chris: good point
    Steve: there are some 400/600
    jdaggett: I don't know of those, Japan has some 300/600
    <ChrisL> not so worried if its just the relatives. As long as higher
             quality results are not excluded
    jdaggett: will still do the right thing
    howcome: is the rounding defined?
    jdaggett: yes
    howcome: sounds reasonable
    jdaggett: you get a consistent computed value
    <ChrisL> wights in zalamander:
    <ChrisL> ultrabold 800
    <ChrisL> bold 700
    <ChrisL> semibold 600
    <ChrisL> regular 400
    <ChrisL> light 300
    <ChrisL> extralight 250
    Steve: Hixie's distinction goes away, right?
    dbaron: yes
    dbaron: this probably addresses the use case for bolder/lighter better and
            is much simpler
    <ChrisL> critical difference is that you can do bolder/lighter without
             knowing the current font family
    jdaggett: I will write this out
    dbaron: I think you might want to ping Hyatt directly
    dbaron: I think Opera might do that as well
    dbaron: they basically maintain a sequence of +ses and -ses
    [discussion about Hixie's test and the complexity of the model]
    Chris: might be useful to make duplicate test with different fonts
    jdaggett: In some of the edits made by the other editors they wanted to
              allow non-multiples of a 100
    <ChrisL> agree that weights cannot be compared over families
    jdaggett: 600 in one font vs 650 in another font is not consistent
    Steve: the relatives are not for people who care about typography
    [scribe notes they are also for default style of elements]
    dbaron: I don't think authors know the difference between bold and bolder
            or think bolder is more bold than bold
    [joke about adding boldest]
    jdaggett to write up text for his proposal.

Grouping fonts into font families

    jdaggett: I made a post to www-style
    jdaggett: in response to "CSS font selection is broken" (not exact subject)
    jdaggett: the way things work on Linux/Windows is unfortunate
    <dbaron> http://lists.w3.org/Archives/Public/www-style/2009Mar/0041.html
    [people are quoting from the e-mail]
    <ChrisL> Thomas Phinney's arguments are good but his conclusion does not
             follow from his arguments
    [jdaggett is performing a recap of the e-mail on the whiteboard]
    jdaggett: in opentype, font family can have platform-specific variations -
              localisations, and windows/mac variations so the semantics are
              platform dependent
    jdaggett: hence Arial and Arial Black, two families on windows and one family
              on mac
    jdaggett: thus MS have a "preferred family"  but CSS only allows selecting
              by style, width and weight
    jdaggett: opentype 1.5 has wwsfamily
    <ChrisL> wpf has a hash table classification of *known* fonts (only)
    dbaron: If I and JD disagree JD is right
    jdaggett: there is a possibility in the future that Microsoft might ship
              fonts with broader families
    Chris: everyone with a photoshop will have a certain set of fonts and
           communities around photoshop will start using them, etc.
    * anne fails
    Steve: [missed]
    jdaggett: the first point is that we don't define what a given name maps
              to on a given platform
    jdaggett: on any given platform there will be plethora of different font
    jdaggett: but we can give guidelines
    jdaggett: for OT/TT we suggest that you do certain things
    Steve: the important part for me was that it's an abstraction, not a direct
    jdaggett: we can suggest a path to goodness
    jdaggett: I disagree with your second point
    jdaggett: with the exception of optical size I don't see a lot of variations
              even within Adobe families that somehow would be helped with this
    jdaggett: I'm a little sceptical even with optical size
    Steve: I understand... in some magical way...
    jdaggett: the flipside of this, after the break I want to talk about the
              specifics of the @font-face mechanism and local faces
    jdaggett: via that mechanism you can separate things out...
    jdaggett: it's going to be so rare; there will be font foundries that define
              fonts with their own set of axes
    jdaggett: ... the only thing that we can do is that we put in some kind of
              string that we can somehow match against the style name
    jdaggett: which is suicide
    jdaggett: localization issues, semantics could change, accidental matching
    jdaggett: using local with the default name is a much more robust mechanism
    jdaggett: let's take a break and then talk about @font-face
    howcome: comments from MS?
    SG: no, I don't work with the Windows team on fonts, but with IE
    SG: and there's a huge back compat

@font-face src local() and @font-alias

    <dbaron> jdaggett: in css3-fonts, descriptors now have default values
    jdaggett: two @font-face rules defined; normal and bold
    jdaggett: each @font-face rule defines a single face
    jdaggett: I'm not implying this [see whiteboard photo if someone makes one]
              is a use case
    Chris: I think it is
    jdaggett: there is no way to have a magic attribute that sucks in a bunch of
    jdaggett: Michael Day wants aliasing of font families
    jdaggett: what I'm saying is that essentially having a variable that equals
              a bunch of fonts
    jdaggett: is not a good way to do things
    jdaggett: if you want Arial to be just like Helvetica you'd have to
              enumerate the four faces
    <ChrisL> _DSC2181
    [discussiong about MD's proposal]
    <ChrisL> JD proposes @font-alias to group font families
    <ChrisL> _DSC2182
    * anne wonders if he should attempt to minute
    * anne decides to minute the outcome
    jdaggett asserts that mixing complete families and individual faces gives
    ChrisL: to point into a zip file with multiple faces you would want a
            fragment identifier to index into the zipfile
    ChrisL: @font-face is designed to point to a face (and give info about it)
            not to a family
    howcome: just to try to connect here, can we put @font-alias into a draft
    jdaggett: there is a variable proposal, which would do exactly that
    howcome: not clear whether that will make it and it's far more complex
    howcome: I think @font-alias is just for browser style sheets
    [scribe thinks the CSSWG should not add features just for browser style sheets]
    jdaggett: I think it is useful for author style sheets too
    jdaggett: so you don't have to write everything out
    howcome: if we see font families expand @font-alias might be useful, but
             I don't want authors to have to use this
    howcome: we are seeing font families expand so we need to be able to do this
    jdaggett: so @font-alias gives a convenient shorthand
    jdaggett: with large corperations that use lots of fonts and if they are
              doing things cross platform you need to use a lot of fonts
    AvK: is font-family the only property it takes?
    [simplifying syntax]
    @font-alias "my font" "test", "test", "test";
    [discussion about parsing rules for font-family]
    ACTION John to specity @font-alias per 6 March 2009 minutes

local() syntax issue

    jdaggett: should local require quotes or not?
    jdaggett: I put in that quotes are optional
    jdaggett: with format() they are required
    Chris: why?
    jdaggett: because a fixed list is used
    AvK: why do we have format?
    jdaggett: it's for future safety
    <ChrisL> to avoid downloading something you know you don't support
    jdaggett: we also need it for platform sensitivity
    jdaggett: for certain fonts you need to identify what information the font
    jdaggett: so e.g. truetype-aat is skipped over on Windows
    <ChrisL> _DSC2183
    Anne: Spec should say that if the UA doesn't support the format() annotated,
          the user agent must not use the font.
    RESOLVED: local() doesn't require quotes, format() does
    RESOLVED: format() is authorative
    i.e. if the user agent does not support the format listed it will not use
      the font (and should probably not waste bandwidth either)

src semantics

    jdaggett: src defines load fallback, not character fallback. order is the
              first font to load succesfully
    <ChrisL> _DSC2184
    jdaggett: in case of multiple listed src() in a single @font-face that are
              both supported only the first is used
    RESOLVED: in case of multiple listed src() in a single @font-face that are
              both supported only the first is used


    jdaggett: the way I have unicode-range is defined right now is that
              unicode-range has the implicit value of the full Unicode range
    <ChrisL> unicode-range initial value should be 0-U+10FFFF
    jdaggett: In WebKit unicode-range intersects with the supported values of
              the font
    <ChrisL> http://www.w3.org/TR/charmod/#C077
    jdaggett: within the bounderies of unicode-range
    <ChrisL> "C077 [S]  Specifications MUST NOT allow code points above U+10FFFF.
    Anne: e.g. if you have a font with 2,3,5 and unicode-range 1-4 the
          intersection would be 2,3
    <ChrisL> CSS 2.1 is correct: "If the number is outside the range allowed
             by Unicode (e.g., "\110000" is above the maximum 10FFFF allowed
             in current Unicode), the UA may replace the escape with the
             "replacement character" (U+FFFD)."
    Steve: for big fonts being specific about what is in the font is useful to
           avoid wasting bandwidth
    RESOLVED: the effective unicode range is the intersection of the font cmap
              and unicode-range within the bounderies of unicode-range
    RESOLVED: unicode-range initial value should be 0-U+10FFFF

type of local() name

    jdaggett: there's no ideal name that works on all platforms
    jdaggett: on the Mac you'd use the postscript name
    jdaggett: all fonts on a mac have a postscropt name, either real or
    jdaggett: what I have now is that all platforms allow lookup via the
              full name
    howcome: you want to support having style in the name of the family
    jdaggett: the name you have here uniquely describes the font within a family
    discussion of whether this is portable across platforms
    [shouting, minute taker gets lost]
    [excited shouting, for those wondering]
    <ChrisL> fullname is family plus style except for the regular, where style
             is omitted
    jdaggett: postscript name doesn't necessarily match the name in the style
    <ChrisL> so, you would need to specify it twice, fullname and postscript
    <ChrisL> (cl hears both yes and no)
    jdaggett: there are OTF fonts where the full name under Windows is the
              postscript name
    jdaggett: but on the Mac it is the normal full name
    <ChrisL> so the postscriptname should go first, followed by the fullname
             (if different to postscript name)
    <ChrisL> _DSC2185
    jdaggett: yes
    jdaggett: authors would use local() because they can control individual
              faces and you cannot do that with font-family
    SG: font-family only allows the generic family, not a specific face
    howcome: why not use the font filename?
    jdaggett: with this nomenclature you have the hope of matching cross
              platform, with file names it fails
    Steve: the API is that you give the system a name and use the first it
    howcome: I'm afraid different systems will react differently
    jdaggett: with unicode-range and local() you can create interesting
              combinations that will work across platforms
    howcome: my experience is different
    jdaggett: that is because fonts are not cross platform
    jdaggett: this is inherently platform specific
    howcome: I think that's why we shouldn't do it
    Anne: font-family is also platform specific
    howcome: we should not expand on that
    [rehashing of unicode-range and other arguments]
    howcome: does local() and font-family work the same?
    jdaggett: no, but in some cases it will
    Steve: anything which varies on one of the descriptors, must be specified
           by @font face not font-family
    Chris: we don't want people to use font-family: "Helvetica Bold Italic"
    * anne needs a break
    howcome: I'm ok with this as long as it is interoperable
    <ChrisL> I wonder if a font-size descriptor plus src would let us get at
             optical variants
    Anne: the spec can give advice
    jdaggett: of course
    Steve: I don't want API descriptions in the spec
    Anne: if that's the reality it seems better to specify reality
    Anne: e.g. ARIA does that too
    Steve: as long as it is clear that it is one way of doing it

Font spec roadmap

    jdaggett: for the roadmap of this spec I'd like to get what's in the spec
              now solid
    jdaggett: and by the end of this month hopefully get a WD out
    jdaggett: and then work on exposing opentype features and some of the
              other issues regarding better typography
    jdaggett: with hopefully a draft for the June F2F
     Steve: I did say that I would prefer that the REC not have API based
            descriptions in the informative note.
    Steve: What I really meant was that the mapping of the local name to the
           font name tables ought to be specified in terms of the font format
           specifications (without having to invoke that APIs)
    Steve: And that the API information should suggest a way to implement that
           mapping but that not being the only way to implement the mapping

Received on Monday, 9 March 2009 09:26:57 UTC