[CSSWG] Minutes Tucson F2F 2013-02-05 Tue PM I: Fonts

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