- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Fri, 15 Feb 2013 14:07:30 -0800
- To: "www-style@w3.org" <www-style@w3.org>
CSS3 Fonts ---------- - Reviewed updated wording for case-sensitivity of font name matching. - Discussed use of OpenType language tags - Discussed use of OpenType script tags - Discussed italic synthesis in vertical writing -> open issue. - RESOLVED: Publish WD of CSS3 Fonts ====== Full minutes ====== Overview of Sizing Issues ------------------------- SimonSapin: Issue discussed at TPAC wrt multi-col SimonSapin: Algorithm there has an idea of an unknown "available width", and I think it doesn't make sense SimonSapin: I tried to talk with Håkon and Bert, via email, F2F SimonSapin: but seems we don't understand each other glazou: Seems like adding to agenda is a good idea szilles: Would also like to add exclusions update to agenda SimonSapin: Related issue is that we have two different definitions for min-content and max-content SimonSapin: One is sizing, and one in box module, and they are not compatible SimonSapin: Discussed at TPAC... but still have two. <TabAtkins> plinss: I'll be back in a sec, but when jdaggett is done, I'd like to go through the remaining Counter Style issues and request LC. Fonts ----- jdaggett: First topic is case-sensitivity of font family names jdaggett: Talked about this yesterday jdaggett: I put last night wording into spec to define the exact algorithm to be used <jdaggett> http://dev.w3.org/csswg/css3-fonts/#font-family-casing jdaggett: Would like to take a second to resolve on this jdaggett: Points at default caseless matching algorithm in Unicode spec jdaggett: You case-fold each string jdaggett: Use case mappings defined by C/F statuses in CaseFolding.txt jdaggett: Noted there is no normalization, no locale-specific behavior jdaggett: Another paragraph explains to authors where they should be careful jdaggett: Most people won't be affected smfr: Maybe 2nd paragraph should be a note fantasai: Think the last sentence of 1st paragraph should be a note jdaggett: Want to make sure implementers don't use the wrong pre-written methods TabAtkins: Pulling it out into a note would actually make it more obvious fantasai: The normative requirements are already expressed in the paragraph, above. You're just pointing out that it's easy to screw up; this isn't a normative requirement, it's informative helpful advice jdaggett: Implementations MUST NOT use platform routines that they don't understand. [discussion of normative, informative, notes, etc] jdaggett: Another issue is wrt default [?] <jdaggett> http://dev.w3.org/csswg/css3-fonts/#language-specific-support jdaggett: This deals with language-specific features jdaggett: Question is, whether UAs should by default always use the default system, or use heuristics to guess language fantasai: You defer to the "document language" rules. fantasai: If it's unknown, use default. Don't guess jdaggett: HTML5 explicitly says that if it's not specified, it's unknown. [...] jdaggett: So if it's not known, what do we do? fantasai: Is the language a required param to the API calls? jdaggett: No. fantasai: Then don't pass a language. fantasai: If the author wanted lang-specific features, should have put a lang tag <SimonSapin> HTML "language of a node" http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#language ... [discussion of mapping ISO lang codes to OpenType lang systems] jdaggett: For most things, you can map. If you want to override, you can also override Glenn: ... script ... jdaggett: This is given by character code glenn: Opentype Indic have two scripts defined, one for older tables and one for newer tables glenn: Since we don't have a way for authors to define script specifically, we have a gray box here.. glenn: I would suggest treating the whole problem space is jdaggett: So define default script as well as default language? glenn: You need three tags to generate the tables that apply glenn: script, language, feature jdaggett: We have a set of properties dictating... glenn: For a given set of features, leaves script and language as parameters glenn: If you want to fully handle this mapping, then you need to define all three of these glenn: Do you have language for dealing with script tag? jdaggett: what's explained to me is that in general, script tag can be inferred from the codepoint jdaggett: Some issue with different versions of indic, but for given implementation, you're picking one and using that one jdaggett: Using one or the other glenn: I'm aware of one implementation, because I did it, in XSL:FO, allow to specify script identifier based on ISO script identification system glenn: So I happen to implement the ability to allow author to specify variants in order to select between old indic vs. new indic glenn: If you look for indic fonts, some built for first version, some for second, some to support both jdaggett: Those tables can be looked up jdaggett: You're sort of overspecifying by pushing out into author space glenn: Just want to make sure script tag mapping is discussed jdaggett: I thought it was just an implementation detail, didn't need to be author-facing jdaggett: Think I might leave this open, since nobody else is speaking up glenn: I agree with fantasai that you should defer to document language at first order glenn: We should make sure there's a well-defined mapping between the tag sets glenn: Also begs question of lang tags for non-OT fonts, not sure we need to get into that jdaggett: Think we need to make sure it works for OT, implementers can fill in the dots for other formats. fantasai: Would like to point out "Users agents are required to infer the OpenType language system from the value of the ‘lang’ attribute" fantasai: Should just defer to document language, not specify how it's found. <Bert> -> http://www.w3.org/TR/selectors/#lang-pseudo Selectors text about what is an element's language <jdaggett> http://www.w3.org/Style/CSS/Tracker/issues/70 <jdaggett> http://lists.w3.org/Archives/Public/www-style/2008Sep/0197.html jdaggett: I went in to fonts spec and put in prose to handle all the cases, but never cleared out the issue jdaggett: Has to do with certain combinations of say question marks, what the semantics of that are jdaggett: In the spec, a number of statements about this jdaggett: Was a conflict with the way the syntax spec was worded, but that's ironed out before lunch jdaggett: So, unless anyone sees anything here, I'd like to close this issue jdaggett: Can always raise another issue if there's something specific to handle jdaggett: Think we've fixed all the problems in this issue SimonSapin: Think Syntax solves the parsing-related issues dbaron: Might be worth sending something to Zack RESOLVED: Close ISSUE-70, ping Zack about this <jdaggett> http://www.w3.org/Style/CSS/Tracker/issues/71 <jdaggett> http://lists.w3.org/Archives/Public/www-style/2008Nov/0077.html jdaggett: Spec now has prose to talk about this jdaggett: Gecko implementation doesn't implement 'unicode-range', so part of reason for difference in behavior [...] jdaggett: Think most issues have been dealt with in the spec jdaggett: Can open new bugs if more specific things are found fantasai: if dbaron's happy, I'm happy dbaron: Fine with closing it. May some point look at the text and comment jdaggett: Font loader issues, but defer that... want WebApps people to comment on some of those things jdaggett: Other than the language issue, I did make one change... [some discussion about error handlers] jdaggett: You have to load content, and start laying it out, to assess whether you need to download a font jdaggett: Could start loading a font via JS, but, then that's your own problem jdaggett: Is there a scenario you're concerned about? glenn: Is there a way to register to handler using onerror attribute? jdaggett: Yes, there are both event handler attributes plus you can use the event handler name glenn: So element directly attach to font loader, would that be body? jdaggett: document jdaggett: This is all in the spec <jdaggett> http://dev.w3.org/csswg/css3-fonts/#font-style-matching jdaggett: Section I want to look at is cluster matching jdaggett: I put in some wiggle room for specific scenario that sometimes occurs jdaggett [quotes spec] jdaggett: This is a compat issue with the way Arial has implemented Arabic in the past jdaggett: Where they have Arabic glyphs in the default face, but not the italic face jdaggett: So if you say italic Arial, you get fallback in some browsers jdaggett: This allows creating synthetic italics jdaggett: Avoid searching all faces jdaggett: The added wording, "The only exception ..." Bert: Default face is the roman face? jdaggett: What you would select if you had all font properties set to initial value jdaggett: Unless there's other issues to bring up, would propose publishing another WD jdaggett: Was hoping this would be LC, but I'm uncomfortable with the way font loader is right now, and want WebApps people to look it over first jdaggett: It's an unusual section for a CSS spec b/c defines API with scripting behavior jdaggett: So would like to have other people review it jdaggett: But that is my intent, review things, then go to LC jdaggett: Hopefully within this month fantasai: There's an issue raised on italics and vertical text that probably warrants some discussion as well jdaggett: Think we shouldn't deal with that in this level jdaggett: From your post, Koji, don't see that there's a clear desired behavior <jdaggett> http://koji.ec/archives/7 jdaggett: In vertical text runs, when you say "italic", most Japanese fonts don't have an italic face, so what is produced is a synthetic oblique face jdaggett: There were two issues in the mail he wrote jdaggett: One is, what is the right way to do synthetic italics for Latin in vertical jdaggett: UAs always oblique to the right. If not right for RTL, could add ways of obliquing to the left jdaggett: Tricky one is what to do about vertical text runs, where the obliquing is distinctly different jdaggett: If you look at the picture jdaggett: 1 is what you get by default jdaggett: different processors will give you different results, depending on what you want to do jdaggett: I think Koji said IE10 does 6 and Webkit does 8 jdaggett: From my perspective of just defining what italics should map to, I think 8 is correct jdaggett: However, maybe patterns in Japanese publishing where e.g. 3 or 4 are considered the norm jdaggett: However, I think they require a different property to solve correctly jdaggett: Might be a good feature to allow shear transforms on individual glyphs jdaggett: But don't think we should do this in this level jdaggett: Fact that there are 8 different renderings jdaggett: Shows there is a deeper issue, can't be solved by us declaring which one is right jdaggett: Can take an action to get more opinion on this jdaggett: Don't think we'll get a good sampling of opinion on www-style plinss: Where do these renderings come from? Koji: I did it by transform Koji: This picture is generated by transforms Koji: But tested what actual results are in other implementations jdaggett: Problem in spec is inconsistency among browsers, not sure we should be looking at other implementations jdaggett: Koji says we should define what synthetic italic looks like plinss: Is italic used with japanese glyphs? jdaggett: Not common, but it happens jdaggett: For Japanese text, if you have italics, and don't oblique it, people file bugs plinss: Is it every correct to oblique the text? jdaggett: If there's a pattern of text obliqued, should investigate/do something about that jdaggett: but not for this level <dbaron> to my eyes, the difference between 2 and 8 is very subtle <dbaron> (but I do now see it) jdaggett: I would like more evidence from printed matter that there's one pattern that's always used fantasai: CSS3 Fonts requires synthesizing italics, question here is, if used in vertical text, then what do you synthesize? jdaggett, szilles: just leave it undefined jdaggett: Disagree that this blog post is enough to make a decision on the right default fantasai: Even if we add a property for this, what would be the initial value? dbaron: Experimentation might lead to a bunch of UAs being willing to switch to another's behavior because it's better. jdaggett: I'll see if there's more published examples of this being used consistently, but unless that comes back with a solid answer of "you always do this"... szilles: Also have problem that this is Japanese, what about Chinese fantasai: The preferred slant is derived from the more cursive forms of Han characters, so would be consistent with Japanese. ... koji: If I specify italic, want consistent behavior across browsers. jdaggett: If there's variation... koji: There is variation in typographic world. koji: Pick an interoperable consistent default behavior. jdaggett: It's not a commonly used feature. Might be just accident of implementation. koji: Can add features in future. Want the baseline behavior to be consistent. koji: My preference is to use 6, because it's what word processors do and people are used to it jdaggett: Would prefer not to standardize on what a publisher would not do koji: Publishers want more controls, fine to do in Level 4 jdaggett: Think this needs more research fantasai: Assume there is a variety of needs. What is the default? szilles: It's UA-defined. kawabata-san and koji are not happy with this kawabata-san: Is there a difference in slanting between LTR or RTL? jdaggett: Today there is not. Could argue that this is not ideal behavior. jddaggett: Existing behavior for synthetic obliques is consistent. glenn: italics don't apply to Arabic anyway jdaggett: It's an artifact of word processors fantasai: Some precedent for italics in Hebrew though fantasai: Following the logic of RTL, where synthetic slant is always consistent, why not make writing mode also stay consistent. koji: I'm happy not to make conclusion here, happy to publish WD, as long as this is kept as an open issue. <dbaron> the right side of http://www.huji.ac.il/ shows what looks to me like Italic style in Hebrew <fantasai> RTL italics discussion: http://typophile.com/node/49385?page=2 <dbaron> (and it's an image, too) <fantasai> Chinese mixing fonts in Roman/Italics pattern: http://fantasai.inkedblade.net/style/scans/Princeton%20East%20Asian%20Library%20-%20ZhongGuoYin__Xue%202005.4%20001.png RESOLVED: Publish WD jdaggett: Please review the draft, particularly wrt functionality szilles: Meaning correct definition of the functionalities there, not what's missing fantasai: No new features. But if things are unintentionally undefined, should be an issue <jdaggett> fantasai: that's a simple mixing of brush styles <jdaggett> fantasai: comparing it to roman/italic is an oversimplification <jdaggett> feedback on faux oblique from nat at adobe: <jdaggett> In my opinion 斜体 is totally different from italic, or even oblique, in usage and applicability to Latin typographic convention. <jdaggett> "In InDesign we keep them totally separate." <jdaggett> "There is no italic in Japanese, no need to faux oblique with Japanese using slant, in fact only slanting is wrong, so just don't do it." <jdaggett> "Use 斜体 instead which scales, rotates, and shears with precise settings." <koji> I agree with Nat. The point here is, if publishing industry doesn't need italics at all, and if all word processor vendors/users requires it, why don't we suffice word processor users in level 3, and pursue publishing industry in level 4? <jdaggett> if there's consistent behavior that is in common use then we can use that <koji> An example HTML file at http://dl.dropbox.com/u/8812114/italics-vertical.htm <koji> jdaggett: yes, I'll collect actual examples from word processor market to get to you <jdaggett> we need actual use cases from users <jdaggett> not just testcases that use the feature <br type="tea"/>
Received on Friday, 15 February 2013 22:08:01 UTC