15:52:43 <RRSAgent> RRSAgent has joined #i18n
15:52:43 <RRSAgent> logging to https://www.w3.org/2018/03/08-i18n-irc
15:52:48 <Zakim> Zakim has joined #i18n
15:52:52 <addison> trackbot, prepare teleconference
15:52:55 <trackbot> RRSAgent, make logs world
15:52:58 <trackbot> Meeting: Internationalization Working Group Teleconference
15:52:58 <trackbot> Date: 08 March 2018
15:53:06 <addison> Chair: Addison Phillips
15:53:17 <addison> Agenda: https://lists.w3.org/Archives/Member/member-i18n-core/2018Mar/0000.html
15:53:26 <addison> agenda+ Agenda
15:53:30 <addison> agenda+ Action Items
15:53:34 <addison> agenda+ Info Share
15:53:38 <addison> agenda+ Radar
15:53:54 <addison> agenda+ What Time is This Meeting At?
15:54:06 <addison> agenda+ Recommended characters and possibly RFC5981bis
15:54:18 <addison> agenda+ Unicode-XML and Bidi Controls
15:54:39 <addison> agenda+ IMSC visiting us!
15:54:51 <RRSAgent> I have made the request to generate https://www.w3.org/2018/03/08-i18n-minutes.html addison
15:57:57 <JcK> JcK has joined #i18n
16:00:55 <nigel> nigel has joined #i18n
16:01:27 <JcK> present+ JcK
16:02:03 <Bert> present+
16:02:05 <addison> present+
16:02:09 <xfq> present+ Fuqiao
16:02:20 <stpeter> present+
16:03:20 <r12a> agenda+
16:03:26 <addison> agenda?
16:03:29 <r12a> agenda+ Encoding
16:03:35 <r12a> agenda?
16:03:43 <nigel> Present+ Nigel
16:04:17 <pal> pal has joined #i18n
16:05:38 <addison> zakim, take up agendum 1
16:05:38 <Zakim> agendum 1. "Agenda" taken up [from addison]
16:05:41 <addison> agenda?
16:05:53 <JcK> No
16:06:16 <addison> zakim, take up agendum 8
16:06:16 <Zakim> agendum 8. "IMSC visiting us!" taken up [from addison]
16:06:43 <nigel> -> https://github.com/w3c/imsc/issues/236 IMSC Issue 236
16:07:20 <addison> scribenick: stpeter
16:09:08 <stpeter> r12a: background ... ISMC uses Unicode characters, glyphs come out of fonts, rendering algos/engines are needed for complex scripts at times before glyphs are assigned; important in this discussion to be clear on terminology of character/codepoint vs. glyphs
16:09:33 <stpeter> JcK: are you talking about single code points or multiple that might result in a single grapheme?
16:09:46 <stpeter> r12a: single code points for this discussion
16:10:31 <r12a> https://www.w3.org/TR/ttml-imsc1.0.1/#recommended-unicode-code-points-per-language
16:11:19 <Katy> Katy has joined #i18n
16:12:07 <addison> q+
16:12:10 <stpeter> pal: purpose is to provide guidance regarding subtitles; enhance chance that if author chooses text it will be supported by the user agent and properly rendered
16:12:45 <addison> ack addison
16:12:52 <stpeter> pal: the intent is not to disallow certain code points or to require a rendering engine to not render certain code points
16:13:05 <stpeter> addison: I think this is an extremely tricky thing to specify
16:13:26 <stpeter> addison: first, implementers might see this as a required set, the only thing they have to support, etc.
16:14:03 <stpeter> addison: for example, you wouldn't necessarily have enough code points to properly render Arabic
16:14:10 <stpeter> pal: actually we have the common code points
16:14:29 <stpeter> addison: doesn't deal with the need for more glyphs in your font
16:14:40 <stpeter> pal: that's why worded in terms of code points, not glyphs
16:15:02 <stpeter> addison: naive implementation would have glyph per code point
16:15:07 <stpeter> pal: should we add a note about that?
16:15:45 <stpeter> addison: most people build a system there's an instance of it for Arabic users or whatever script is in play
16:15:53 <r12a> q+
16:16:15 <stpeter> addison: second point, CLDR has sets of characters like this by language (exemplar sets)
16:16:33 <stpeter> addison: it might be helpful to reference CLDR instead of defining your own
16:17:08 <stpeter> pal: we do reference CLDR - recommended set is a union of CLDR and ???
16:17:10 <addison> ack r12a
16:17:25 <stpeter> r12a: I'm worried about implementers too, but this section is about authors
16:17:46 <stpeter> r12a: my worry is that implementers won't see this as clearly
16:18:42 <stpeter> r12a: make it clear that this is a guide for a minimum set and for real support you should go further
16:18:49 <addison> q+
16:19:24 <stpeter> r12a: also make it clear that implementers need to enable the display of the following sets of characters, not selecting those sets of characters
16:19:33 <stpeter> pal: output document should only contain those characters
16:19:49 <stpeter> addison: output document is displayed somewhere and needs to be displayed faithfully
16:20:01 <stpeter> addison: depends on how system that receives it is implemented
16:20:13 <stpeter> addison: shaping engine etc.
16:20:26 <stpeter> pal: annex is intended to be used by validator implementation
16:20:52 <stpeter> pal: validator that sees a character that's not in the recommended character set can flag a warning
16:20:59 <stpeter> addison: is this really a good idea?
16:21:02 <behnam> behnam has joined #i18n
16:21:20 <stpeter> pal: what's a bad idea is showing unsupported characters
16:21:59 <stpeter> pal: realistically no implementation is going to support all Unicode code points
16:22:25 <stpeter> addison: some implementations support everything but rather obscure code points (plane 2 Chinese, ancient scripts, etc.)
16:22:31 <r12a> q+
16:23:17 <stpeter> addison: what I see happen is trying to legislate fairly narrow character sets, whereas many rendering systems are more capable
16:23:36 <stpeter> pal: this is targeting not just browsers but embedded systems like TVs
16:23:55 <stpeter> pal: also, this has already proved useful
16:24:50 <stpeter> addison: implementers do have font and space limitations, but it's a slippery slope when recommending subsets of characters
16:24:55 <addison> ack r12a
16:25:18 <stpeter> r12a: I understand the intent, my concern is in how we describe that to people
16:25:32 <stpeter> r12a: e.g., if we said "these are the safe characters to use" makes more sense to me
16:25:48 <nigel> q+ To ask what action we can take to address the remaining concerns.
16:26:06 <stpeter> r12a: this comes across as "these are the Hebrew (etc.) characters you should support" but these sets tend to grow to support new code points
16:26:21 <stpeter> pal: this is why we reference CLDR
16:26:49 <stpeter> r12a: unfortunately CLDR is not a panacea - it's missing things
16:26:58 <stpeter> pal: so let's fix CLDR
16:27:00 <RRSAgent> I have made the request to generate https://www.w3.org/2018/03/08-i18n-minutes.html addison
16:27:17 <stpeter> pal: not displaying a character is way worse
16:27:55 <stpeter> r12a: the crux is specifying a safe set of characters for authors without implying that implementers should limit the sets of characters they support
16:28:06 <JcK> q+
16:28:15 <stpeter> pal: what about starting the annex with that text?
16:28:25 <stpeter> r12a: that's the kind of thing I was looking for
16:28:49 <pal> q+
16:28:50 <addison> ack nigel
16:28:51 <Zakim> nigel, you wanted to ask what action we can take to address the remaining concerns.
16:29:27 <stpeter> nigel: the struggle here is understanding exactly what the concern is and coming up with a proposal to address the concern
16:29:34 <stpeter> nigel: this discussion is helping
16:29:43 <stpeter> nigel: any other concerns we can surface here?
16:29:45 <addison> ack JcK
16:31:00 <stpeter> JcK: I'm concerned about where this might be leading; displaying the wrong character is much worse than displaying parts of a string and not other parts (for instance)
16:31:20 <stpeter> JcK: part of the concern is that there are many edge cases which can't be handled by this kind of approach
16:32:19 <stpeter> JcK: e.g., if you get text in Hebrew script but another language then you might not have the right code points to display things properly
16:32:56 <addison> ack pal
16:32:56 <stpeter> JcK: there are traps here about writing this particular language with this particular script, but not other languages
16:33:33 <stpeter> pal: I captured another concern earlier about cautioning implementers that one code point != one glyph
16:34:08 <stpeter> r12a: if you're dealing with a complex script like Myanmar, there are more difficulties
16:34:40 <stpeter> addison: when people go font shopping, they can be satisfied with an inferior font and the rendering engine doesn't have the glyph that's necessary
16:34:48 <stpeter> pal: that's true regardless
16:35:36 <Katy> q+
16:35:37 <stpeter> r12a: that's part of my concern - we shouldn't let implementers off the hook and stymie forward progress (yes, these are embedded systems that aren't updated often)
16:35:48 <stpeter> pal: hard to phrase this in a technical document
16:36:09 <nigel> q+
16:36:16 <stpeter> addison: these things tend to ossify into a lowest common denominator or institutionalizes some particular set of characters
16:36:26 <addison> ack addison
16:36:54 <stpeter> pal: I think we're safe in the sense that systems support all of Unicode - we're not trying to create a chokepoint for code points
16:37:14 <stpeter> addison: not at document level but at the validator and authoring tool levels
16:37:28 <stpeter> pal: that's why we don't reference a particular version of CLDR for instance
16:37:34 <addison> ack Katy
16:38:04 <stpeter> JcK: the fact that CLDR exists does not imply that CLDR is correct
16:38:34 <stpeter> Katy: even defining a list of safe characters can vary quite wildly
16:39:03 <stpeter> Katy: to clarify, managing author expectations is difficult here
16:39:31 <stpeter> Katy: not just glyph display but processing and the like
16:40:46 <stpeter> nigel: maybe clarify for authors that you can't just get a glyph but there is more complexity - there might fallback fonts and such (not just safe characters)
16:40:54 <stpeter> nigel: is there a document we can reference?
16:41:00 <addison> q+
16:41:16 <stpeter> nigel: an informative document about rendering different characters correctly?
16:41:19 <addison> ack nigel
16:41:22 <r12a> q+
16:41:56 <stpeter> addison: a different place to look might be the various font standards, which have introduced language codes that are supported
16:42:10 <nigel> I heard r12a and katy express support for adding a note to explain that correct rendering of scripts goes beyond mapping code points to glyphs in a font
16:42:11 <stpeter> addison: there might be standardization there to look at - a different way of accomplishing the goal here
16:42:14 <addison> ack addison
16:42:17 <addison> ack r12a
16:42:21 <pal> q+
16:43:01 <stpeter> r12a: two questions: (1) the safe list here is presumably based on lowest common denominator for various devices?
16:43:17 <stpeter> pal: tables were built using a study of TV and motion picture content
16:43:34 <stpeter> pal: collecting all code points that were used in that context
16:43:45 <stpeter> r12a: (2) why are we not just referencing CLDR?
16:44:23 <stpeter> pal: there are longstanding issue against CLDR to add flag for text commonly appearing in subtitles
16:44:23 <addison> q?
16:44:34 <stpeter> q+
16:45:09 <nigel> q+ to note that ossification is not a feature of the list of characters but a wider issue
16:45:09 <stpeter> r12a: I think what would help is to add some text cautioning against ossification
16:45:52 <stpeter> pal; [summarizes feedback received so far]
16:45:58 <addison> ack pal
16:46:03 <stpeter> s/pal;/pal:/
16:46:37 <addison> ack stpeter
16:46:37 <stpeter> pal: we can try to formulate text along those lines and come back for further feedback
16:47:30 <stpeter> stpeter: why not attack the problem at the CLDR level if they aren't properly supporting text needed in subtitles?
16:48:05 <r12a> q+
16:48:11 <stpeter> pal: everyone's goal is to move this to CLDR
16:48:18 <stpeter> addison: we'd be happy to support that as well
16:48:42 <stpeter> addison: we do have a liaison agreement
16:49:33 <stpeter> pal: subtitles and captions are becoming a global requirement and there are unique needs here; great example is musical note character
16:49:34 <addison> ack nigel
16:49:34 <Zakim> nigel, you wanted to note that ossification is not a feature of the list of characters but a wider issue
16:50:04 <stpeter> nigel: this point about ossification is a tricky one; e.g., if you deploy player code to a device, updates might not be available
16:50:39 <stpeter> nigel: e.g., a downloadable font could be possible, but more work is needed to support the right characters
16:50:45 <stpeter> nigel: how do we phrase this?
16:50:54 <stpeter> addison: good question
16:50:55 <addison> ack r12a
16:51:01 <r12a> https://github.com/w3c/imsc/issues/236#issuecomment-367713408
16:51:44 <stpeter> r12a: that link has some suggested text but it might not be exactly what we need here - encourage folks to re-read
16:52:02 <stpeter> pal: I'll try to craft text based on the terms we used in this call today
16:52:22 <stpeter> addison: would you like us to say something to the CLDR folks?
16:52:26 <stpeter> pal: +1
16:52:29 <stpeter> nigel: +1
16:52:50 <stpeter> pal: I plan to propose text soon for review by folks here
16:53:18 <stpeter> addison: any concerns about supporting the CLDR trac?
16:54:29 <stpeter> JcK: I'm nervous because it would be great to get down to one standard instead of two; at the same time, CLDR has been criticized for being opaque to folks with actual language expertise and not just character coding expertise
16:55:00 <stpeter> addison: I'll take an action to focus it on the issue at hand
16:55:11 <addison> action: addison: write to cldr on WG behalf about Trac 8915 including wording about getting exemplars right
16:55:13 <trackbot> Created ACTION-699 - Write to cldr on wg behalf about trac 8915 including wording about getting exemplars right [on Addison Phillips - due 2018-03-15].
16:55:36 <stpeter> pal: I will let you know when the proposed text is ready
16:55:54 <addison> action: addison: make pal's new draft part of homework
16:55:56 <trackbot> Created ACTION-700 - Make pal's new draft part of homework [on Addison Phillips - due 2018-03-15].
16:56:08 <stpeter> addison: anything else on this topic?
16:56:27 <addison> agenda?
16:57:01 <addison> zakim, take up agendum 5
16:57:02 <Zakim> agendum 5. "What Time is This Meeting At?" taken up [from addison]
16:57:28 <Katy> +1
16:57:41 <stpeter> r12a: typically don't change time until UK changes to Summer Time
16:57:58 <stpeter> addison: in favor
16:58:07 <Bert> (So no change for me then? That's good :-) )
16:59:08 <r12a> rrsagent, draft minutes
16:59:08 <RRSAgent> I have made the request to generate https://www.w3.org/2018/03/08-i18n-minutes.html r12a
16:59:11 <RRSAgent> I have made the request to generate https://www.w3.org/2018/03/08-i18n-minutes.html addison
16:59:19 <addison> zakim, who is here?
16:59:19 <Zakim> Present: JcK, Bert, addison, Fuqiao, stpeter, Nigel
16:59:21 <Zakim> On IRC I see nigel, JcK, Zakim, RRSAgent, addison, xfq, stpeter, r12a, koji, bigbluehat, sangwhan, fantasai, dbaron, trackbot, Bert
16:59:24 <addison> present+ pal
16:59:33 <addison> present+ Katy
16:59:46 <RRSAgent> I have made the request to generate https://www.w3.org/2018/03/08-i18n-minutes.html addison
17:00:57 <r12a> rrsagent, draft minutes v2
17:00:57 <RRSAgent> I have made the request to generate https://www.w3.org/2018/03/08-i18n-minutes.html r12a
17:02:03 <r12a> s/<JcK> No//
17:02:14 <r12a> s/<addison> trackbot, prepare teleconference//
17:02:20 <r12a> rrsagent, draft minutes v2
17:02:20 <RRSAgent> I have made the request to generate https://www.w3.org/2018/03/08-i18n-minutes.html r12a
17:03:40 <addison> zakim, bye
17:03:40 <Zakim> leaving.  As of this point the attendees have been JcK, Bert, addison, Fuqiao, stpeter, Nigel, pal, Katy
17:03:40 <Zakim> Zakim has left #i18n
17:25:17 <stpeter> stpeter has joined #i18n
18:08:12 <stpeter> stpeter has joined #i18n
18:12:43 <stpeter> stpeter has joined #i18n
21:08:37 <stpeter> stpeter has joined #i18n
22:52:11 <stpeter> stpeter has joined #i18n