- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Mon, 09 Mar 2009 02:26:12 -0700
- To: www-style@w3.org
Summary:
- 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 ======
Attendees:
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
bolder/lighter
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
[humming]
<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
formats
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
fonts
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
ambiguity
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
[agreed]
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
has
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
[agreed]
RESOLVED: in case of multiple listed src() in a single @font-face that are
both supported only the first is used
unicode-range
-------------
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
synthesized
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
name?
<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
returns
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