17:07:10 RRSAgent has joined #css 17:07:10 logging to http://www.w3.org/2011/03/09-css-irc 17:07:18 RRSAgent, this meeting spans midnight 17:07:33 meeting: CSS ftf day 3 17:07:43 chair: peter/daniel 17:07:52 I have made the request to generate http://www.w3.org/2011/03/09-css-minutes.html Bert 17:08:23 bradk has joined #css 17:09:22 smfr has joined #css 17:09:44 sylvaing has joined #css 17:10:26 topic: css3 fonts 17:10:28 http://dev.w3.org/csswg/css3-fonts 17:10:56 Kazutaka has joined #CSS 17:11:43 hober has joined #css 17:12:18 ScribeNick: fantasai 17:13:11 jdaggett: There are some recent edits that I wanted to go over, based on comments that were made at previous F2F and on www-style 17:13:28 jdaggett: We'll go through those, then at the end there's some discussion that needs to happen wrt WOFF. 17:13:49 alexmog has joined #css 17:14:00 jdaggett: Overview: css3-fonts expands font properties from CSS2.1 and adds definition for @font-face which allows fonts to be downloaded, and add supports for OpenType font features, which are exposed via font-variant 17:14:09 howcome has joined #css 17:14:20 jdaggett: Font features are ways of selecting alternate glyphs or alternate ways of showing text using data that's contained in OT fonts. 17:14:32 jdaggett: Covers superscripts subscripts, alternate glyphs, ligatures, etc. 17:14:44 szilles has joined #css 17:15:13 jdaggett: It let's you select which (of multiple variant glyphs for given set of codepoints) is chosen 17:15:27 jdaggett shows stylistic() 17:15:55 jdaggett: Because the argument to stylistic() is specific to the font, a lot of people in the group felt we needed a way to associate that value with the font that had that feature. 17:16:03 http://dev.w3.org/csswg/css3-fonts/#font-feature-values 17:16:21 jdaggett: Because of that, we added the @font-feature-values rule 17:16:38 jdaggett: For each of the font-specific alternate types, you define a set of name-value pairs for a given font 17:16:57 jdaggett explains the rest of @font-feature-values 17:17:27 basically, you create an @-rule associated with a font name 17:17:35 and then within that block you define name-value pairs 17:17:53 the same name can be used in multiple @-rules, associating different values with the same name depending on the font 17:18:12 then in the declaration, stylistic() takes the name, and maps to the appropriate value depending on the font actually in use 17:20:02 howcome: Do we need the comma between the name-value pairs? 17:20:06 fantasai: technically, no 17:20:41 jdaggett: I think it makes it easier to read 17:22:08 jdaggett: I had swash: delicate 1, flowing 2; but since the cascading behavior is different from what you'd expect from that, WG wanted to change the syntax 17:22:28 fantasai: The cascading behavior is as if "swash" was an element name, and the name-value pairs were property-value declarations. 17:23:27 fantasai: There was another proposal that made this clearer (by adopting element { property: value; } syntax) at the expense of adding more braces 17:24:56 jdaggett shows more examples from the spec that illustrate the cascading behavior, which collects all name-value mappings across style sheets (redeclaring same name overrides, just like property-value declarations) 17:25:31 johnjan has joined #css 17:25:46 TabAtkins_ has joined #css 17:27:34 jdaggett shows some other func() font feature notations that use @font-feature-values rule 17:28:30 more discussion of comma 17:28:37 howcome thinks it's unnecessary typing 17:29:21 fantasai notes that counter properties don't use commas 17:31:01 dbaron notes that he always gets that wrong even though he implemented it 17:31:09 howcome: commas used to be used to denote alternates 17:31:33 Tab: But that's not true anymore 17:31:45 Tab: e.g. text-shadow, background 17:31:54 Some discussion of syntax 17:32:15 howcome feels it's unclear that the name-value pairs are additive, suggests being more verbose and using separate @ rules for each pair 17:32:23 jdaggett notes that this is possible if that's wanted 17:32:32 several feel that's excessive typing and don't want to require it 17:33:24 arno has joined #css 17:34:49 jdaggett shows the Greek coin example 17:35:13 bz has joined #css 17:35:51 http://www.tktype.com/chartwell.php 17:37:39 jdaggett notes for the future that having selectors for picking out patterns to alter the font-features of would be nicer than having to use spans 17:37:49 but this example is rare enough that for now this doesn't seem to be a problem for us to solve 17:39:51 some questions about how OT features work 17:39:52 http://dev.w3.org/csswg/css3-fonts/#font-feature-settings-prop 17:39:55 jdaggett explains 17:40:55 jdaggett reviews some updates to the font-feature-settings syntax 17:41:07 jdaggett: There's a set of registered OpenType features. 17:41:12 jdaggett: All of them will be CSS identifiers 17:41:24 jdaggett: It's technically possible to define an OpenType feature that, e.g. starts with a 3 17:41:47 jdaggett: For those cases that we want to escape, you can add the optional ot- prefix 17:42:12 jdaggett: For these tags I haven't put in any syntax definitions 17:43:37 jdaggett explains the escaping mechanism e.g. 3cap feature would have to be written as ot-3cap 17:43:58 jdaggett: For boolean features, just placing the feature name will set it to 1 (on) 17:44:29 (ot-3cap and \3cap are thus the same.) 17:44:32 jdaggett: Also the author can be explicit with functional notation, wihch allows integers, but can also use "on" and "off" 17:45:01 dbaron: You don't need the ot- prefix for escaping, since you can just escape the number 17:45:28 Tab: Why aren't we just using quoted strings? 17:45:33 ot-3cap and \33cap are the same 17:45:36 er 17:45:39 ot-3cap and \33 cap are the same 17:45:40 (Correction: ot-3cap and \33 cap are thus the same.) 17:46:15 jdaggett^: There was also the question of e.g. attr() function, which could conflict with an OT feature 17:47:07 jdaggett: You're not just giving the feature name, you have to give a value, too. 17:47:49 Arron suggests: "3pix" 1 17:48:02 "3pix" 1 17:49:14 fantasai asks what would happen if a font format defined features that took string values 17:49:21 plinss: use a comma to separate mapping pairs 17:49:27 e.g., font-feature-settings: "smcp", "swsh" 2 17:49:58 jdaggett: for this, I think commas don't make sense 17:50:20 "c2sc" 1, "3piX" 1 17:50:24 Steve: It would be nice if the pairing notation was the same in both places 17:50:32 jdaggett: For the name value pairs we are always defining a name and a value 17:50:39 jdaggett: For this in most cases you just want the tag name 17:51:25 jdaggett: So you wwant "smcp", "swsh" 2 17:51:46 plinss: The comma separates features settings, so that you can distinguish between a feature name and a value 17:52:30 steve says something, several people disagree 17:52:31 Steves asks whether given @swash flowing 1;, you could do font-feature-settings: swsh(flowing) or font-feature-settings: "swsh" flowing 17:53:33 jdaggett: So what if I say "iatl" for which we have no feature settings 17:53:49 dbaron: That seems like extra code to support the non-recommended way of doing something 17:53:54 s/iatl/ital/ 17:54:49 Steve: I just want to make sure we make a conscious decision. 17:54:51 jdaggett: That means the author has to know which CSS property maps to which opentype feature name. 17:55:12 jdaggett: I just want to make sure everyone wants to have a non-functional notation, which is different from above 17:56:55 several: Yes. Those are CSS-defined. This is an open-ended set of potentially non-identifiers. 17:57:29 Luke: It's not clear that this is impossible to parse, it's just that you are introducing a whole bunch of these .. 17:57:40 Luke: We can't have a nice enum of whatever this type is 17:58:10 Luke: Instead of a simple arbitrary string, you have this extra syntax thing 17:58:25 fantasai: You have to parse arbitrary idents for counters anyway 17:59:09 hyatt has joined #css 18:00:05 Simon: I think you should figure out a way of not using ot-, or use it all the time. Having it be optional is weird 18:00:31 alt 1: font-feature-settings: smcp, swsh 2; 18:00:49 alt 2: font-feature-settings: "smcp", "swsh" 2; 18:01:26 alt 3: font-feature-settings: smcp swsh(2); 18:01:45 alt 2 and alt 3 may require ot- prefixes 18:02:02 s/2/1/ 18:02:17 alt 4: font-feature-settings: ot-smcp, ot-swsh(2) 18:03:15 this sets smcp to 1 and swsh 2 18:04:02 Steve: I don't understand why each of the pieces are being proposed 18:05:15 howcome: If it's just a low-level feature as an escape hatch in the baseline, why is the syntax that important? 18:05:34 glazou: It's about finding the most elegant syntax that avoids problems for the future 18:05:48 stearns_ has joined #css 18:05:58 glazou has joined #css 18:07:23 stearns_ has left #css 18:07:25 fantasai: Font families are either idents or quoted strings 18:07:29 macpherson has joined #css 18:07:40 fantasai: Why not do that here, where both 1 and 2 are possible? 18:07:43 stearns_ has joined #css 18:07:49 Arron: I like that 18:07:55 plinss is concerned about this 18:08:13 dbaron: We have the future-proofing problem for counters and everal other things already 18:08:26 plinss: With strings you avoid potential conflicts with expansions in either CSS or the fonts 18:08:38 +1 to fantasai (let author use quotes or not, as fits best) 18:08:43 Jay has joined #CSS 18:08:47 plinss: Also this avoids authors being confused about whether they need to quote something or not 18:09:30 alt 5: either 1 or 2 is valid 18:09:58 plinss: It's safer to always require it to be quoted. 18:10:13 plinss: This is an obscure rarely-used feature. It's simpler and easier to maintain if you always have to quote it 18:10:26 plinss: This avoids any potential problems ever. 18:10:43 jdaggett: I define on and off to be 1 and zero 18:10:48 plinss: That's fine. 18:11:01 jdaggett: And you're ok with assumption of 1 as default value 18:11:10 plinss: Yes, no problem. Those are all very clean CSS ways of doing things. 18:11:40 plinss: Our default design should be to avoid any possible conflicts with future CSS keywords 18:12:03 plinss: For something obscure like this, we really have no good reason to go against that. 18:12:28 (The "ot-" prefix should probably be on the property name, not on the values...) 18:12:37 plinss: The ot- prefix is very complex because you parse an ident then have to reparse to break it down, I don't want to introduce that, especially not for something obscure like this 18:14:45 Bert: The quotes are redundant. They're parseable without. 18:15:06 Bert: And if you put this in an attribute, e.g. in HTML you have to double-quote. 18:15:13 Bert: That's why we didn't put quotes in font-family 18:15:14 cslye_ has joined #css 18:15:47 Tab: The issue here is that once you go beyond idents, you have to start escaping, and that's very confusing for authors. 18:16:14 cslye_ has joined #css 18:16:24 Tab: Very few people understand escaping rules 18:17:00 Bert argues for arbitrary unquoted strings 18:17:51 vehement disagreement 18:18:22 jdaggett: I will write up the proposal and post to the mailing list 18:18:29 fantasai: I would like to do something that gets a WD published. 18:18:39 http://dev.w3.org/csswg/css3-fonts/#vertical-position-prop 18:19:18 RESOLVED: jdaggett will write up alt 2 into the spec, mark as open issue whether quotes are required 18:19:27 jdaggett moves on to vertical-position 18:20:17 jdaggett explains how superscripts and subscripts are currently implemented: the vertical alignment is adjusted, and the font size shrunk down 18:20:46 jdaggett: This has some problems. The typographic color is affected, since a typographic superscript or subscript is not used 18:20:53 jdaggett: And because of the vertical alignment, the line height is affected 18:21:04 jdaggett: So we have this feature 18:21:27 jdaggett: This property behaves as a shorthand, resetting font-size and vertical-align (to inherit and initial) 18:21:37 jdaggett: You effectively null out those property definitions 18:21:50 jdaggett: For older clients that don't support this feature, they will still use the default adjustement to font size 18:22:12 jdaggett: shows example 18:22:51 dbaron: There's also the second fallback case, of where the font doesn't support it 18:23:02 jdaggett: For that we put in synthesizing rules 18:23:30 Alex: Doesn't this still use smaller size 18:24:41 jdaggett: Yes. If those glyphs are missing, you don't get them. But you at least get a superscript. And you don't affect the line height. 18:25:09 dbaron: This seems to be the first time we have a shorthand that sets both inherited and non-inherited properties together. I'm a little concerned about that. 18:25:48 dbaron: Also, I'd like something that works for the default UA style sheet 18:26:12 if only the old styling is used (vertical-align: sub) does a new implementation use the new synthesizing rules that do not affect line height? 18:26:38 steve explains his proposal 18:26:47 dbaron: Third proposal -- 18:26:59 dbaron: Make vertical-position a non-inherited non-shorthand property 18:27:13 dbaron: Then say that any text inside an element with vertical-position set 18:27:28 dbaron: you ignore the vertical-align value on the element that had vertical-position set 18:27:56 dbaron: And you recompute the font size based on the ratio of the font-size of the element with vertical-position set to its parent 18:28:26 dbaron: if you have nested vertical-position, you ignore it on the nested one 18:29:03 dbaron: Then you can use it in a UA style sheet, and if the author nests superscripts you no-op it 18:29:20 fantasai, Steve: But the point was to have nested subscripts to work 18:29:45 It still doesn't really work with nested subscripts. 18:29:48 jdaggett: In your (Steve)'s proposal, the line height is affected 18:30:09 Steve: My thinking is that I have a subscript, and if my font has subscript characters, I want to use them 18:30:18 Steve: If it doesn't have a character in the font, then I'd like reasonable fallback 18:30:39 Steve: So my goal is to think about what would the fallback require, and then say how I can then go back and enable the font feature to be used 18:30:45 Steve: and in fact mixed with fallback 18:31:00 Steve: Say my subscript is 1a, and the font only has 1 as a subscript 18:31:16 jdaggett: My concern is that you're still affecting the line height 18:31:39 Steve: How do I make sure there's enough room for the subscript if we don't adjust the line-height? 18:32:37 jdaggett: The whole point of the font's glyphs is that they're designed to fit in with the rest of the text so you don't need to change the line height 18:33:30 Simon: Do fonts have glyphs for all their characters as superscripts? 18:33:44 (Something like: 'vertical-position: superscript', IF the font has superscript glyphs AND the the elt has 'vertical-align: super', sets a hypothetical inherited 'font-size-multiply' property to (parent-size/own-size) and ignores 'vertical-align') 18:33:46 jdaggett: No. Usually only a small subset. If the glyph is missing, the UA synthesizes whatever is missing 18:35:25 some confused discussion 18:36:39 howcome: Why couldn't we key off 'vertical-align' and just have a setting that says "be smart" 18:38:33 ('vertical-position: smart' means, if 'vertical-align' and 'font-size' are set in certain ways and the font has the necessary glyphs, then ignore the properties and use those glyphs.) 18:39:35 Fantasai: keep the computed values, but change the used values. 18:40:06 dbaron: You need to worry both about children that are nested sub/supers, and children that aren't. 18:41:05 fantasai: [draws some superscripted] 18:41:36 fantasai: You have the baseline of the element 18:42:24 fantasai: And pick one of the baselines in this box. There's a different concept between what baseline you're aligning the text to, and what you expose as the text's "baseline" outside. 18:42:52 fantasai: So text has an "alphabetic" and a "superscript" baseline. 18:43:20 fantasai: When this feature is turned on, for the children, rather than aligning the children's alphabetic to the parent's alphabetic, align the children's alphabetic to the parent's superscript baseline. 18:43:47 fantasai: And font-size is still inherited, so it'll shrink down as you drop, but the used value of font-size is based on the parent, so they'll be the right size when they're rendered. 18:44:06 szilles: So what jdaggett is concerned about it, what is the line-height for the text? 18:44:34 fantasai: The used value of the font-size is based on the parent. It *looks* like you're shifting up, but you're really just using a different glyph. 18:44:50 fantasai: It's only when you start nesting that you'll mess with the line-height. 18:45:11 dbaron: I think there's a second related problem here. 18:45:22 dbaron: It's that we're using "font-size:smaller", which isn't what we want. 18:45:26 If you don't have the OpenType glyphs, the synthesized version can run into line height problems as well 18:45:34 dbaron: jdaggett says there's a metric that says not only where the superscript baseline is, but how large it is too. 18:46:21 dbaron: if font-size had keywords for "superscript size", etc. 18:46:30 Bert: MathML has a concept of a "script size". 18:47:02 dbaron: If you combine the superscript baseline of a font with the superscript size, will you get something within the bounds of the font, so you don't bump the lineheight? 18:47:31 jdaggett: It *should*, but not guaranteed. 18:47:59 dbaron: We can ignore the problem of alternate glyphs for a moment, and just look at the sub/sup problem with synthesized/font-size stuff... 18:48:09 dbaron: Then we'll solve the linebox problem, but not the weight problem. 18:48:45 dbaron: And perhaps the alternate glyphs oslution will fall out of what we come up with. 18:49:00 dbaron: This depends on the superscript characters actually matching the reported superscript metrics, or else this all falls apart. 18:49:36 szilles: There are two categories: 1) fonts that behave like David wants them to behave, and 2) fonts that don't. 18:49:58 szilles: Which group should we design towards? Either one may be broken in some case. 18:50:56 cslye: I've looked at some Adobe fonts, and it looks like they're all "broken" - they use the same superscript baseline, which means they probably don't match the character size. 18:51:19 szilles: I propose that we record an issue for this. 18:53:57 jdaggett: My problem is that most of these proposals are fairly hairy. 18:54:52 szilles: [suggestion about making font-size and vertical-align compute to two values, one for normal text and one for sub/super text] 18:55:22 jdaggett: I suggest I just put in a grave note about this being hairy, so we have some text about this in a WD. 18:55:49 szilles: I recommend that the note point out that this is trying to solve the "line-heights get changed by sub/superscript" problem. 18:56:02 szilles: Also that this being a shorthand "messes up" inheritance. 19:14:23 jdaggett: Next topic is font matching algorithm 19:14:29 jdaggett: This isn't totally completed 19:14:38 jdaggett: There are things that still need to be investigated, will talk about that later 19:14:41 jdaggett: 19:14:55 jdaggett: This is the world we live in today. *shows lsides of four 'u's* 19:15:01 jdaggett: You see normal, italic, obld, and bold italic 19:15:33 jdaggett: The way we're going is this way *shows slide of lots of 'u's with multiple weights, some of which have italics, and some of which have narrow* 19:15:42 jdaggett: This is the design of the Univers font 19:16:12 jdaggett: If you go back and look at CSS2.1 algorithm, it says 'first match on this, then match on this' 19:16:20 jdaggett: It's not fully describing the process that needs to happen 19:16:30 jdaggett: For each of the axes within this family, you're narrowing until you have only one choice 19:16:47 jdaggett: e.g. if you have font-stretch: normal, then you narrow to normal stretches 19:17:03 jdaggett: Then if you say font-style: normal, you filter out the italic faces 19:17:18 jdaggett: And if you say normal weight, then you select the normal weight within that 19:17:39 jdaggett: if you select condensed italic bold, then you narrow like this *demonstrates by highlighting characters* 19:18:08 jdaggett: Sometimes if the appropriate weight or italics is missing, the UA synthesizes them 19:18:45 jdaggett: But in the font world you can have families like this *shows a slide of 'u's that fill in only random parts of the font weight/stretch/italic chart* 19:18:55 jdaggett: I tried to make the rules as simple and straightforward as possible 19:19:56 jdaggett: DirectWrite does some fancy grouping, where it takes fonts that have families that specify a style in the family name 19:20:03 jdaggett: And it will remove the style names and create its own families 19:20:12 jdaggett: Both IE9 and FF4 put in hacks to work around, 19:20:25 jdaggett: if an author says I want "Gill Sans", which is typically available on OS X 19:20:48 jdaggett: Via DirectWrite you would wind up wth a family that had only Gill Sans Ultra Bold 19:21:13 jdaggett: Instead of saying very vague terms about you match this and then you match that... 19:21:20 jdaggett: ... 19:21:25 jdaggett projects the algo 19:21:47 howcome: Are we going to have to change our implementations? 19:22:04 jdaggett: Where there wer ambiguities in the original spec, you may need to change your implementation. I think for the common cases it will not be necessary. 19:22:20 jdaggett: For most families that exist on most platforms, it's a very simple choice. And those choices will not be affected. 19:22:40 jdaggett: The choices that will be affected are when someone creates an incongruous family via @font-face 19:23:23 jdaggett: Right now the choices in such cases that result in random choices 19:23:36 howcome: It would be good if we could have test cases 19:24:00 jdaggett: That's the intention. To put in rules here so that I can write tests and point to what they're testing. 19:24:29 jdaggett: jkew pointed out the first line in rule 4 19:24:41 jdaggett: Not all of the faces in a family will have the same character 19:25:01 jdaggett: There's a question of, do you first say "what are all the faces that have a specific glyph" and then match after that 19:25:10 bradk has joined #css 19:25:27 jdaggett: UAs typically select a face and then find out whether the glyph is there or not. 19:25:55 jdaggett: But you have problems, e.g. Arial has some faces (e.g. italic) that don't have all the characters in other faces 19:25:57 sylvaing has joined #css 19:26:20 so UAs typically select the face, and then if the glyph isn't present in that face, they fall back to the next *family* 19:26:22 jdaggett: So you might select bold italic, and since the glyph isn't there, you fall back to a different font instead of falling back to another variant of Arial that has the glyph 19:26:42 jdaggett: I put rules here that you select font-stretch similar to the way you'd select the weight 19:26:52 Steve: So sort of the nearest reasonable value 19:26:55 jdaggett: yes, but not precisely 19:27:05 jdaggett: Here, for example, the normal face is the family to the left 19:27:17 jdaggett: You can specify style values that are in between some of these families 19:27:28 jdaggett: The rule I wrote up in the text is to always go away from 'normal' 19:27:36 jdaggett: So it may not be the next closest nearest neighbor 19:27:47 jdaggett: We might end up picking something further away 19:27:53 Steve: that's true in weights as well 19:28:04 Arron: You're trying to show visual change 19:28:06 jdaggett: right 19:28:14 jdaggett: I also put in rules that you don't synthesize 19:28:23 jdaggett: That's marked as an issue 19:28:35 jdaggett: I would prefer that we keep synthesis as effects, and not part of the selection process 19:30:45 jdaggett: If you have a font style choice of italic and there's no italic, per CSS rules you technically should be falling back 19:30:58 jdaggett: But in implementations today you don't do that, so these rules match reality 19:31:16 jdaggett: We have 'normal' 'italic' and 'oblique' 19:31:31 jdaggett: But typically, whether there is italic or oblique depends on the kind of font 19:31:41 jdaggett: Current UAs don't distinguish italic and oblique 19:31:59 jdaggett: So what I've written here is that UAs are allowed to do this, but for @font-face rules they must distinguish 19:33:12 ... 19:33:29 jdaggett: There was some confusion over this where some people were interpreting oblique as the synthesized face, but that's not the case. 19:33:36 Bert: This is a change from CSS2.1 19:33:56 jdaggett: It's a change from the wording of the CSS2.1 spec, but not from implementations 19:34:16 jdaggett: In implementations, you couldn't specify italics and get normal. 19:34:25 howcome: It would be good to get a list of changes. 19:34:34 (relative to CSS 2.1) 19:35:39 jdaggett points out sentence that uses actual value of font-size instead of computed, that it should be removed 19:35:57 Bert thought it was removed already from 2.1, dbaron suggests maybe we forgot this occurrence 19:37:04 (15.7 "font-size" in CSS 2.1 says "On all other properties, 'em' and 'ex' length values refer to the computed font size of the current element. On the 'font-size' property, these length units refer to the computed font size of the parent element.On all other properties, 'em' and 'ex' length values refer to the computed font size of the current element. On the 'font-size' property, these length units refer to the computed font size of the parent element.") 19:37:04 jdaggett: I also changed the behavior for small-caps, since this is no longer a separate font face with a different name, but part of the main font family, and UAs don't associate unrelated fonts via "small caps" in the name 19:38:46 jdaggett notes that the system font fallback is very UA-defined, might involve multiple fonts, might depend on codepoint or encoding or language, so has clarified that 19:39:07 jdaggett also added a last resort representation for missing glyphs 19:39:15 jdaggett: This leads to character handling issues 19:39:26 jdaggett: In Unicode you're not dealing with just a single character, but a cluster 19:39:37 jdaggett: It could be something very simple like an a with an umlaut 19:39:48 jdaggett: the exact way that we match this hasn't been defined, and we need to define this out more 19:40:08 jdaggett: I haven't put this in here, but I think what we need to do is map the entire grapheme cluster together 19:40:18 jdaggett: and if we don't have a font that matches all of those, then go back and do character-by-character 19:40:36 jdaggett: The thing that's bad right now is that CSS2.1 requires that you use combining characters from the first font even though the base character is from a different font 19:40:56 jdaggett: I added also that PUAs don't fall back to the system font fallback 19:41:07 sgalineau has joined #css 19:42:04 jdaggett also added an escape clause for U+FFFD 19:42:30 jdaggett: Another issue is how to deal with variation selectors 19:42:46 jdaggett: The idea of a variation selector is that for a given Unicode code point, you want to be able to specify a particular representation for that character 19:42:53 jdaggett: There are a lot of ambiguities here 19:43:16 jdaggett: There are a lot of debates within people designing Unicode about whether these should be separate characters, or glyphs that are variations of a single character 19:43:35 jdaggett: The variation selector was to indicate that if possible, you should display a particular character with a particular variation 19:43:46 jdaggett: This comes up a lot in Chinese and Japanese where over time the glyph representation has changed 19:44:00 jdaggett: In particular for people's names or place names, they're registered one way, an dyou want to be able to capture that. 19:44:14 jdaggett: You want to specify with a Unicode codepoint what the ideal representation you're looking for is. 19:44:45 jdaggett: So that I can show it on my screen with my fonts, and mail it to you and you can't see it because you don't have that ofnt, but you send it to someone else and they can see it 19:44:58 jdaggett: There's a question here of how you do fallback. 19:45:02 stearns has joined #css 19:45:47 jdaggett: If you say "I want to display in this font", and a character with a variation selector whose glyph doesn't exist in that font shows up, what do you do? 19:45:51 jdaggett shows an example 19:48:30 arno has joined #css 19:49:46 in this case there are several variants that are different 19:49:52 and several variants that are the same 19:50:22 jdaggett: So do you want to fall back to a different font? Or show the default glyph? What if the default glyph is the same as the variant glyph? 19:50:42 Steve: This would be a good topic for the workshop in June 19:51:02 jdaggett: I think you would need to talk to people designing fonts. 19:52:37 jdaggett: If you go across fonts, you're not guaranteed to get something right 19:52:51 jdaggett shows some more examples 19:53:25 jdaggett: Here we're using a gothic font. 19:53:38 jdaggett: The second line uses a variation selector, takes the glyph from another font 19:53:47 (serif font) 19:53:57 jdaggett: This one it's not subtle, the variation is a structural difference. 19:54:06 jdaggett: But for an author to go from this, to this, it's a little incongruous 19:54:16 jdaggett: My point is that nothing is cut and dry here. 19:54:22 jdaggett: There are authors who would rather have the exact glyph 19:54:33 jdaggett: And there are authors that would rather have the font match 19:55:13 kojiishi: IVS is primarily for place name and people name 19:55:28 kojiishi: Using the wrong variant is very impolite 19:55:34 kojiishi: especially for peoples' names 19:56:56 some argument between Koji and John about intended behavior of IVS 19:58:21 jdaggett: If you fall back to a font that has slightly different style, then you may not be able to pick out stylistic differences, particularly if face is gothic face 19:58:47 Steve: What I've heard you say so far is there are reasonable cases for saying that you want to preserve font integrity and perhaps do what we would do today 19:58:53 Steve: Let's just deal with IVS 19:59:12 Steve: There are two options. 1. treat as request for specific thing, and fall back if not there. 19:59:25 Steve: 2. Use this thing if it's there, otherwise use the thing this is a variation of 19:59:48 Steve: You've given good examples where one of those approaches is the one that's desired and others where the other approach is desired 20:00:03 Steve: That suggests to me that have a property to control that would be a useful way for author to say which is more important. 20:00:51 jdaggett: To define that fallback occurs to the system font, and have to analyze the cmap to find this, that UAs are required to find this font on the system, that's a lot of wrk 20:00:54 work 20:01:02 jdaggett: There's how fallback works within fonts, and another of system font fallback 20:01:10 jdaggett: We don't specify system font fallback 20:01:22 jdaggett: Is that something that prevents UA from doing something intelligent? No. Just undefined. 20:01:44 Steve: What occurs to me is that if I make the property have the default value of today's behavior 20:02:15 jdaggett: The default behavior in FF4 is, if we have a font in the font list that supports the default character, then we will use the default character if the variation selector is not defined. 20:02:30 jdaggett: This requires the author to specify a font that has the variation they want. 20:02:45 jdaggett: Practically, they have to do this anyway because the system font is unlikely to have the variation they want 20:02:55 macpherson_ has joined #css 20:03:03 Steve: My proposal is the property does today's behavior by default. 20:03:09 jdaggett: There is no defined behavior today. 20:03:24 Steve: This will not be the first time we define default by defining what is 20:03:37 Steve: Could use property to trigger more refined behavior 20:04:24 Steve: Could search for IVS, and if it's not there redo search for default glyph 20:05:00 Steve: I don't think this is that complicated 20:05:10 jdaggett: It is, doing this as system font fallback is complicated 20:05:16 fantasai: So don't define it for system font 20:05:49 jdaggett explains that this doesn't work 20:06:06 Steve: You go looking through sequence of listed fonts, and if you find an IVS you use it. 20:06:19 Steve: If you don't find it, you start over for the base character, and that one hits the system font fallback 20:07:30 jdaggett: But koji says Unicode people want to get the IVS if it's there in the system font 20:07:35 plinss: Time. 20:07:47 jdaggett: There are a lot of issues here, and I don't think there's a simple answer here. 20:08:03 jdaggett: There's a lot of complexity here and we can't decide one way or the other 20:08:22 Steve: I would like for us to make IVS work, and avoid code points or other subterfuges that would have even worse side-effects. 20:08:46 kojiishi: If you modify the spec to include normalized shapes for font fallback? 20:09:09 kojiishi: What's the philosophy behind dealing with grapheme clusters? 20:09:21 jdaggett: The behavior for grapheme clusters will be distinct from IVS 20:09:35 jdaggett: Because of the internal structure of the way the selectors are defined, there has to be more with what goes on 20:09:51 jdaggett: They should try to work similarly, but you have a whole bunch of variation selectors that point at the default. 20:10:11 jdaggett: So the way this works is going to be slightly different. 20:11:23 fantasai: Can we file a bug against Unicode? 20:11:52 fantasai: Request that new variation selectors can only be registered if the registrant can explain how their glyph is different from all the other glyphs 20:12:13 jdaggett: If a UA is getting a font from the server, by default it will not take fonts that are on a different server. 20:12:22 jdaggett: This prevents people from using a font from another site on their site 20:12:31 jdaggett: Helps fulfil requirements on some font licenses 20:12:46 jdaggett: There's a large issue if this should be by default requiring same-origin 20:13:30 jdaggett: In