See also: IRC log
<addison> close ACTION-170
<trackbot> Closed ACTION-170 Coordinate with richard regarding KLReq.
Action 150 publication soon
<trackbot> Error finding '150'. You can review and register nicknames at <http://www.w3.org/International/track/users>.
<addison> close ACTION-198
<trackbot> Closed ACTION-198 Write back to CSS-fonts about casefolding and normalization, allowing both with health warning (see minutes).
<addison> close ACTION-199
<trackbot> Closed ACTION-199 Seek clarification on [:Whitespace:].
<addison> close ACTION-205
<trackbot> Closed ACTION-205 Send longdesc comment to HTML-WG.
<addison> close ACTION-206
<trackbot> Closed ACTION-206 Announce to the member list for review next week with a goal of publishing for wide revew.
<addison> close ACTION-207
<trackbot> Closed ACTION-207 Comment on default direction in UA bug for WG saying "bad idea".
Addison: no content yet, but some due
r12a: New "before" and "after"
replacements may be "start" and "end" for CSS
... May work, but ruby positioning inline or bopomofo "end" may need watching
r12a: Tokyo workshop looking for papers
addison: J Daggett guest here to
... proposal was that font name matching should be normalise C+F insensitve case - some implementers are unhappy, but normalisation unlikely to be real problem.
JDaggett: Case insensitivity in
unicode is awkward. in CSS only existing insensitivity is ASCII
... Font names are not localised as families, normally.
... CJK font name matching is troublesome, as it takes into account Locale
JDagget: e.g. Japanese font designer gets correct name but other users don't
JDaggett: Downloadable fonts are named completely up to the author in @fontface
Addison: Agrees with where CSS is now, but was secretly case insensitive
Addison: Agree that if using
Unicode case insensitivity should use the same algorithm, C+F
without normalisation but watch out for combining marks, with
... caseless unicode matching is not complex.
JDaggett: Issue asking I18n WG, would like to settle on one method of case insensitive matching if performed.
Addison: Generally perform better as C+F but buffer allocation on case fold needs care, but it does anyway for UTF-8.
JDaggett: 99% of the time the ASCII would fold OK, and CJK wouldn't fold anyway.
Addison: No normalisation sensitive names will occur.
r12a: Actual font names can be case folded without normalisation
JDagget: as in version 5.1 of
... This matching should be used in general case, not just for font names.
r12a: Do user defined names become case insensitive?
JDaggett: Not for font familly names.
Addison: If CSS adds other case insensitive matching, it should follow the same pattern (C+F without normalisation)
r12a: As long they promise never to do it, I'm happy if they do it!
<addison> john: two resolutions I'd like to see
<addison> 1. C+F is preferred to C+S
<addison> 2. okay with no normalization
<addison> addison: agree with both
addison: One could compose a normative sensitive font name, but it would be bad for other reasons too.
John: Font designers are avoiding unicode names at present.
Addison: If this changes, font selection may be very difficult in other contexts
<addison> richard: okay
<addison> david: okay
<addison> JcK: seems rational
<addison> ... not expressing happiness
JcK: matching options are expanding, but this seems rational
<addison> ACTION: addison: write back to CSS about font case sensitivity matching and remove normalization (cf two resolutions in minutes) [recorded in http://www.w3.org/2013/04/18-i18n-minutes.html#action01]
<trackbot> Created ACTION-209 - Write back to CSS about font case sensitivity matching and remove normalization (cf two resolutions in minutes) [on Addison Phillips - due 2013-04-25].
<addison> richard: see the WBS request?
<addison> addison: will search it
Richard: TPAC will be in China. Dates have been brought closer
<addison> Nov 11 - 15
<addison> ACTION: addison: ensure TPAC WBS form is filed for i18n [recorded in http://www.w3.org/2013/04/18-i18n-minutes.html#action02]
<trackbot> Created ACTION-210 - Ensure TPAC WBS form is filed for i18n [on Addison Phillips - due 2013-04-25].
r12a: GEO feedback list receives
comment form infomration, but few people see them. Fewer
respond to them.
... We do get some spam, but could forward mails to the winter list.
... Would need to reword, notice to say, "comments will be public" and lose anonymity, which is better.
<addison> ACTION: richard: make wording changes and implement decision to send future feedback to winter list [recorded in http://www.w3.org/2013/04/18-i18n-minutes.html#action03]
<trackbot> Created ACTION-211 - Make wording changes and implement decision to send future feedback to winter list [on Richard Ishida - due 2013-04-25].
<addison> richard: awaiting korean translation, norbert sent some comments
<addison> ... want group to say "put this out as FPWD"
<addison> addison: support
<addison> norbert: good to get more feedback
<r12a> ok to publish
<addison> ok to publish
OK to go ahead
<aharon> no opposition.
<JcK> No objection... i.e., support
<addison> chair: WG resolution: approved Korean Layout Requirements to publish as FPWD
<addison> ACTION: richard: prepare KLReq for FPWD and usher through publication process [recorded in http://www.w3.org/2013/04/18-i18n-minutes.html#action04]
<trackbot> Created ACTION-212 - Prepare KLReq for FPWD and usher through publication process [on Richard Ishida - due 2013-04-25].
addison: there are a number of bidi topics
<addison> Guidance about bidi authoring materials: https://lists.w3.org/Archives/Member/member-i18n-core/2013Apr/0018.html
r12a: Looking for bidi recomendations to be published, after lots of work
r12a: would like them ot go live, since we've already done wide review
Aharon: Go live!
<addison> ACTION: richard: publish four bidi tutorials [recorded in http://www.w3.org/2013/04/18-i18n-minutes.html#action05]
<trackbot> Created ACTION-213 - Publish four bidi tutorials [on Richard Ishida - due 2013-04-25].
<addison> Next Steps in @dir isolation: https://lists.w3.org/Archives/Member/member-i18n-core/2013Apr/0019.html
r12a: Write up for inheriting isolation in HTML5
r12a: Proposals for how to get isolation into HTML 5, Comments received from Aharon and John. If these are addressed can it go to wide review?
<r12a> aharon: yes
<JcK> yes, definitely
yes, go with proposal A
<addison> ACTION: richard: publish html-bidi-isolation proposal for wide review [recorded in http://www.w3.org/2013/04/18-i18n-minutes.html#action06]
<trackbot> Created ACTION-214 - Publish html-bidi-isolation proposal for wide review [on Richard Ishida - due 2013-04-25].
Addison: Any HTML5 actions for this meeting?
<JcK> On bidi, there are a few others I'd like to circulate the drafts to (the IETF IDNA bidi team). Would that be ok at this stage?
<addison> ACTION: addison: double-check that all .prep items are gone to html5 [recorded in http://www.w3.org/2013/04/18-i18n-minutes.html#action07]
<trackbot> Created ACTION-215 - Double-check that all .prep items are gone to html5 [on Addison Phillips - due 2013-04-25].
Addison: We want wide review now, so comments can be addressed.