See also: IRC log
aphillip: action items
... did not get a lot of action items done
<r12a> http://www.w3.org/International/track/actions/open
aharon: did not make any progress on bidi html5 improvements note
Norbert: action 149 in about 3 weeks
ahphillip: action 150 becoming pressing, but have not had chance
aphillip: no progress on action 170
richard: document is pretty much ready for review
aphillip: no progress on
174
... no progress on 183
... will talk about 194
<aphillip> close ACTION-195
<trackbot> Closed ACTION-195 Send Richard notes about IE behaviour wrt direction.
aharon: sent notes on IE for action 195 today
richard: no chance to get to action 196
richard: mlw workshop went well, well done Felix and colleagues
<fsasaki> kudos to r12a for *his* work! not only in the previous workshops but also in rome
richard: breakout to discuss personal names, mark davis was there...
how to handle personal names, ontologies
aphillip: unicode conference call for papers is now
aphillip: is this (UTC 1600) a good time?
richard: until when?
aphillip: indefinitely
matial: not good for me after summer time comes in
<aphillip> mati: -1, prefer same wall time rather than same utc time
<aphillip> richard: 1500 utc
richard: prefer same wall time
<fsasaki> +1
<fsasaki> actually, both fine by me
aphillip: resolved to move to 1500
<aphillip> ACTION: addison: move meeting to 1500 utc following change to summer time [recorded in http://www.w3.org/2013/03/21-i18n-minutes.html#action01]
<trackbot> Created ACTION-197 - Move meeting to 1500 utc following change to summer time [on Addison Phillips - due 2013-03-28].
<aphillip> ... for first meeting in april
aphillip: move to 1500 not next week but the following week
<aphillip> http://lists.w3.org/Archives/Public/www-international/2013JanMar/0347.html
aphillip: c+s may not match
<aphillip> example: a font with a german name such as heiß wouldn't match HEISS because C+S case fold is only "heis"
aphillip: the concern is that you want your case-folded names to match the other token, and both have to be case-folded the same way...
you have to know that you have to allocate a little more storage for the case-folded version...
<fantasai> fantasai: Is the concern that the casefld will be incorrectly implemented, or that it won't match when correctly implemented?
a little spurios, since other factors can change the length anyway
JcK; worrying about this particular case "borders on the irrational"
<fantasai> Norbert quoting Jonathan: should require normalization if doing casefold
<fantasai> ?: Trying to do casefold without normalization is all sorts of trouble.
<fantasai> JcK: Maybe right rule is to normalize and casefold for comparison, even if the string is not normalized itself
JcK: maybe the right rule is to normalize around case folds
<fantasai> ?: A little more complicated, but certainly more reliable
<fantasai> aphillip: Would be remarkable use of normalization simply because not used anywhere else
<fantasai> JcK: Should either not casefold at all or normalize and casefold
<fantasai> aphillip: Don't think we want to change recommendation of which casefold to use
<fantasai> aphillip: Second quesiton is whether to normalize
<fantasai> aphillip: efficiency more problematic for normalization than casefolding
<fantasai> aphillip: We've brought it up with Selectors, other things, een told enough times we're not going to get normalization
fantasai: in all other cases, you
had to have normalization span the entire platform
... not sure that this can even been done
... in this particular case, it's not about interaction of css
with some other Web technology but about interaction of CSS
with font files via intermediary agent of OS font APIs
you could require normaliza and case fold, and it would have no effect on the rest of platform
<fsasaki> scribe: fsasaki
addison: conclusions?
... need to understand the rules for common font format
... there seem to be limitations
fantasai: normalization and case
folding makes most sense to me
... in this particular case
addison: nothing against
including normalization
... objections against case folding should go away too
jck: thinking of the argument for
normalization we had for IDN
... These strings are very short, I don't see an efficiency
problem
addison: so probably both
normalization and case folding are the right thing to do
... there should be a special note saying here is the limited
case where we are having normalization
<JcK> In particular, these are comparisons for very short strings, not operations on very large blocks of text. For such short strings, The efficiency loss is trivial and the comparisons will work much more predictably
<aphillip> ACTION: addison: write back to CSS-fonts about casefolding and normalization, allowing both with health warning (see minutes) [recorded in http://www.w3.org/2013/03/21-i18n-minutes.html#action02]
<trackbot> Created ACTION-198 - Write back to CSS-fonts about casefolding and normalization, allowing both with health warning (see minutes) [on Addison Phillips - due 2013-03-28].
<aphillip> https://lists.w3.org/Archives/Member/member-i18n-core/2013Mar/0023.html
addison: this is about space
skip, text decoration for underlining
... above link is summary of what I got back from them
... one of discussion topics: some langauges don't use
spaces
... so if you want to (scribe missed)
fantasai: reading comment esp.
from markus
... propose to do something simple
... do something for languages that have spaces
... if the language has no spaces, you don't want to create a
gap
... one thing I didn't understand: how do I specifiy other than
linking to CLDR query page?
addison: defined elsewhere, like the regex one
fantasai: does the regex include entire Z category?
norbert: javascript has its own ws category
<aphillip> ACTION: addison: seek clarification on [:Whitespace:] [recorded in http://www.w3.org/2013/03/21-i18n-minutes.html#action03]
<trackbot> Created ACTION-199 - Seek clarification on [:Whitespace:] [on Addison Phillips - due 2013-03-28].
fantasai: proposal is to skip all characters in unicode category z
addison: minus the vertical white space
fantasai: the word separater characters are:
<fantasai> space (U+0020), the no-break space (U+00A0), the Ethiopic word space (U+1361), the Aegean word separators (U+10100,U+10101), the Ugaritic word divider (U+1039F), and the Phoenician Word Separator (U+1091F)
<fantasai> plus whatever is regex White_Space
fantasai: that is the current
proposal
... we can skip e.g. over blank
... do we also skip over visible spaces like U+1361?
richard: skipping over blank might be an issue too
addison: there are joining items in punctuation you might not want to skip either
norbert: e.g. within numbers
<aphillip> foo<a0>:
<aphillip> 1<a0>000
discussion on underlining in Ethopian word spaces
<Norbert> http://www.unicode.org/reports/tr44/#White_Space
<r12a> fantasai, do you know that you just dropped off the call?
<fantasai> "conference is restricted" :/
<matial> me too
<fantasai> So any conclusions on text-decoration-skip?
<fantasai> The definition I have is the one above
<aphillip> I will circle back to unicore
<fantasai> the open question is what to do with the visible word separators
<aphillip> and we will take up again next week
<fantasai> ok
<aphillip> yep
<aphillip> norbert: looking for end-to-end language negotiation example that uses script codes
<aphillip> ... or other subtags defined by bcp 47
<aphillip> richard we have some
<r12a> http://www.w3.org/International/getting-started/characters
<r12a> look at the chinese version
<aphillip> norbert: please send examples to list
<aphillip> richard: see above
<r12a> http://www.w3.org/International/getting-started/characters.zh-hant.php?changelang=zh-hant