[CSSWG] Minutes and Resolutions Telecon 2011-09-07


   - CSS3 Fonts will not be updated on /TR until jdaggett finishes more edits
   - Discussion of default text orientation of characters, conclusion that there
     should be a clearer distinction between the determination phase and the
     fixup phase.
   - Tentative Conclusion: No change to CSS3 Text wrt cpsp OT feature
   - RESOLVED: UAs may do better than the Unicode minimum for text-transform casing

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

   David Baron
   Bert Bos
   Kimberly Blessing
   Cathy Chan
   John Daggett
   Arron Eicholz
   Elika Etemad
   Simon Fraser
   Daniel Glazman
   Håkon Wium Lie
   Chris Lilley
   Peter Linss
   Edward O'Connor
   David Singer
   Steve Zilles

<RRSAgent> logging to http://www.w3.org/2011/09/07-css-irc
<glazou> Regrets from Tab, BradK, John, Cesar, Arno
Scribe: ChrisL


   fantasai: Anton's IE application
   bert: my fault, sent a message to the requests but sent it to wrong place
   (that was tpac)
   ChrisL: I sent a reminder, should be soon

CSS3 Fonts

   ChrisL: the ed is much more up to date
   jdaggett: prefer to wait a bit until more edits made
   <dsinger> Unless it is actively misleading without the edits, let's
             publish an then again
   jdaggett: much prefer we don't


   topic: tpac on sunday or not?
   plinss: spoke to Susan about that
   fantasai: We had planned to meeting elsewhere if the hotel was not available
   glazou: confirmed, we will meet Sunday and willsort out a location later
           if there is no room at the hotel

Writing Modes

   jdaggett: goes back to text-orientation. issue of default
   jdaggett: means for a string of random unichars what is the behavious in
             vertical with no extramarkup
   jdaggett: non-normative wording recommends but not clear if its normative or not
   <fantasai> Um, I don't understand why jdaggett is confused, perhaps he hasn't
              looked at the draft recently. It says very clearly that the
              orientations are unequivocally *defined* in Appendix C,
              because that's what he asked for
   <dsinger> Isn't material not explicitly marked informative considered
             therefore normative?
   <fantasai> dsinger: That is my understanding.

   jdaggett: some contextual rules. koji published a table of these
   jdaggett: spoke to eric mueller of adone who said its better for Unicode
             to have a table
   jdaggett: similar but with some important differences
   <jdaggett> http://lists.w3.org/Archives/Public/www-style/2011Sep/0003.html
   jdaggett: says to define a categoryfor each to decide the default orientation
   <jdaggett> http://lists.w3.org/Archives/Public/www-style/2011Sep/0042.html
   jdaggett: differences between Eric's proposal and current spec
   jdaggett: there is also a category called 'use font' which depends on
             whether the font has vertical metrics. not clear why that is there
   jdaggett: also some are in basic latin range
   jdaggett: hope koji will add something to clarify if this is important
   jdaggett: Unicode is the right org to maintain this
   <dsinger> Has Koji been asked to explain? Has the Unicode committee been
   szilles:support Eric's proposal
   szilles: Unicode has been aske and asked Eric to do it
   szilles: its a legitimate Uniocode activity
   szilles: issue of deciding whether its upright is independent of the
            vertical metrics
   <dsinger> ok
   fantasai: the use glyph case is for certain characters where if there is no
             alternate vertical glyph, its better to use the horizontal one
             sideways rather than upright.
   fantasai: but jdaggett said we can't check for alternate glyphs per codepoint,
             only for whether the font supports the feature at all
   fantasai: So we classify fonts as supporting or not supporting vertical
             typesetting, and assume fonts with vertical support will have
             alternate glyphs where needed
   fantasai: However, this can fail because some fonts have vertical metrics but
             lack vertical alternate glyphs for certain codepoints
   fantasai: Setting fonts without vertical support upright will would produce
             brackets that dont encase anything, looks all wrong
   jdaggett: most japanese fonts that are used in web pages have vertical metrics
   jdaggett: don't see actual fonts that have these faults
   jdaggett: CJK punctuation uses differen codepoints, so it's not a problem.
   fantasai: double quotes in Chinese are unified
   jdaggett: can't connect that to your algorithm
   fantasai: three categories - upright always, vertical always and depends
             on font
   szilles: then the font is bad and people will stop using it
   jdaggett: adding lots of mechanics that are not needed
   jdaggett: issues of fallback too, may hit a Japanese or not Japanese font.
             fallback fonts are random
   jdaggett: if you are making another proposal, we need to look at that.
   .... some discussion not on www-style
   <dsinger> But I think that the case where you hoped for a vertical font
             but got fallback should be handled?
   szilles: adobe position is that upright should not be determined by looking
            in the font. you decide upright or not then use the font infortmation
   szilles: if you correct bad fonts then you break good ones
   szilles: not clear there is an immediate need to fix bad fonts
   szilles: The author can just manually request upright
   fantasai: author does not always have that opportunity
   fantasai: A common example of a font problem is em-dashes. often no vertical
             alternates, but if typeset sideways you get the wrong positioning
   jdaggett: we are talking about the default, not what is possible and not possible.
   jdaggett: so why make the simple case complex, authors can solve with markup
   fantasai: markup does not fix bad fonts
   szilles: thought this only applied if it was set upright
   fantasai: correct behaviour is to set them upright and for all fonts to have
   jdaggett: if there are cases not covered by Erics proposal we need to flush
             them out. Can't do this on the fly
   jdaggett: need to record the examples
   szilles: put on a wiki
   fantasai: Koji and I are making a list of all the codepoints and their
   szilles: vert feature only applies to upright characters in vertical text
   szilles: not to rotated characters
   jdaggett: some ascii chars have no vertical alternates, and this sounds as
             if it is making the alternates on the fly
   jdaggett: synthesising is always problematic.
   fantasai: so its a semantic confusion. you think i am synthesising an upright
             glyph where I see it as fallback
   jdaggett: want to see a clear definition of why its a problem. need specific
             use cases
   szilles: rotation is only one way to synthesise a glyph
   fantasai: how else would you do it
   szilles: don't want the synthesis to be codified
   fantasai: distinction between chars that look upright and ones that must
             have an alternate
   fantasai: hiragana might have a different positioning for example
   fantasai: but if not alternate, its fine if its missing
   fantasai: while for parentheses, an alternate is mandatory
   jdaggett: in either case it is the same
   fantasai: not really
   szilles: these are different types of wrong
   jdaggett: common pattern in western companies is to develop japanese fonts
             in China and the shae is known but the patterns are wrong. so the
             placement of hragana is wrong and looks wrong
   jdaggett: very helpfulto have what you are now proposing, different from
             the spec as it is now
   szilles:  markup to set vertical should trigger the vert feature
   fantasai: definition of upright is that all chars are upright
   jdaggett: only apply vert feature to runs of vert text
   szilles: want synthesis so only done after upright or not has been determined
   jdaggett: please post proposal to www-style
   dsinger: good to see a comparison
   jdaggett: posted that earlier
   dsinger: good to see some more written discussion
   jdaggett: there is a lot of data on the list
   jdaggett: but little in responses
   szilles: so we have a distinction between the determination phase and the
            fixup phase
   szilles: this is an important result of todays discussion
   szilles: don't care if this is updated in the spec first or in a proposal
   jdaggett: we need more analysis on the data before updating the spec
   jdaggett: we need to talk about specific characters in specific situations
             where it breaks in vertical
   szilles: please say that on the list
   jdaggett: ok

cpsp and text-transform

   <glazou> http://lists.w3.org/Archives/Public/www-style/2011Sep/0058.html
   <glazou> http://www.microsoft.com/typography/otspec/features_ae.htm#cpsp
   glazou: fantasai you raised the issue
   fantasai: yes.
   szilles: thought we were trying to avoid property interactions
   jdaggett: cpsp is capital spacing, and in InDesign its enabled if you set
             all caps on a selection. slightly widens the spacing
   jdaggett: as default spacing is for mixed case
   jdaggett: problem is that applying text transform won't give the effect if
             text is already in caps. regularly pointed out. should be
             intrinsic to the font, e.g. in kerning tables
   <jdaggett> http://kltf.de/downloads/ATypI2007-CrossingBorders-kltf.pdf
   jdaggett:seep.28 of that ATypI presentation
   jdaggett: slide shows standard spacing, and cpsp, and contextual kerning
   jdaggett: spacing is really intrinsic to the font,not a feature
   jdaggett: not clear if we should support this feature; better to add to
             font-variant as an exclusive value to stop people using with
             small caps. to avoid feature interactions
   * glazou is lost
   jdaggett: hoping to hear more typophile opinions. on the top of my head
             its not a good idea
   fantasai: so tentative resolution is this is not an issue
   jdaggett; yes. people can always use lower level features to tweak this

text-transform and Greek

   <glazou> http://lists.w3.org/Archives/Public/www-style/2011May/0602.html
   fantasai: Greek has special behavior when it is in all-uppercase
   fantasai: If dropping accents it's complicated. it's not just 'remove all
             the accents'. E.g. vowel combinations might drop diacritics and
             gain others.
   fantasai: unicode tablesare for single letters not for wholewords
   fantasai: whole words drop accents, but capitalizing the first letter doesn't
   fantasai: this behavior seems to not be in Unicode, so we should not require
             it, but we could allow it
   howcome: could so this with a character mapping
   fantasai: can't do it with a character mapping, you'd need a dictionary
   glazou: from a users perspective it should certainly be allowed to do better
   jdaggett: slippery slope to allow UAs to do their own thing
   glazou: we should accept what native Greek users want
   glazou: Unicode works with characters and glyphs, not words
   szilles: line break rules are word based
   <fantasai> szilles, actually, the UAX14 line break rules are character-pair
   ChrisL: Unicode has some problems with Greek already
   action: Chris to contact Unicode about the greek uppercasing issue
   <trackbot> Created ACTION-362

   fantasai: ok great but that won't help this spec in the short term
   fantasai: preference is to have what is in Unicode as a minimum bar and
             allow better
   jdaggett: concurr with minimum bar, uneasy on extending
   glazou: not only browsers render html/css
   jdaggett; happy if they hit that minimum bar
   glazou: fantasai you should add both suggestions

   jdaggett: don't like the "if and only if" language
   fantasai: please post wording proposals, every time you complain about
             this section, I try to fix it, and then 3 months later you look
             at it and say you're still unhappy.
   ACTION: jdaggett to post wording proposals
   <trackbot> Created ACTION-363
   RESOLVED: UAs may do better than the Unicode minimum for text-transform

Received on Thursday, 8 September 2011 01:22:42 UTC