- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 07 Sep 2011 18:18:39 -0700
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- 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 ======
Present:
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
Administrative
--------------
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
TPAC
----
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
asked?
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
alternates
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
behaviour
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
based
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