IRC log of i18n on 2013-12-12

Timestamps are in UTC.

15:51:16 [RRSAgent]
RRSAgent has joined #i18n
15:51:16 [RRSAgent]
logging to
15:51:26 [aphillip]
trackbot, prepare teleconference
15:51:28 [trackbot]
RRSAgent, make logs world
15:51:30 [trackbot]
Zakim, this will be 4186
15:51:30 [Zakim]
ok, trackbot; I see I18N_CoreWG()11:00AM scheduled to start in 9 minutes
15:51:31 [trackbot]
Meeting: Internationalization Working Group Teleconference
15:51:31 [trackbot]
Date: 12 December 2013
15:51:40 [aphillip]
15:51:46 [aphillip]
Chair: Addison Phillips
15:51:51 [aphillip]
Scribe: Addison Phillips
15:51:55 [aphillip]
ScribeNick: aphillip
15:52:03 [aphillip]
agenda+ RADAR
15:52:07 [aphillip]
agenda+ CSS Text
15:52:13 [aphillip]
agenda+ CSS Syntax
15:52:17 [aphillip]
agenda+ Charmod
15:52:24 [aphillip]
rrsagent, draft minutes
15:52:24 [RRSAgent]
I have made the request to generate aphillip
16:00:03 [matial]
matial has joined #i18n
16:00:19 [Zakim]
I18N_CoreWG()11:00AM has now started
16:00:27 [Zakim]
16:00:31 [aphillip]
zakim, who is here?
16:00:31 [Zakim]
On the phone I see aphillip
16:00:33 [Zakim]
On IRC I see matial, RRSAgent, Zakim, aphillip, r12a, trackbot
16:00:42 [aphillip]
16:01:01 [David]
David has joined #i18n
16:01:04 [JcK]
JcK has joined #i18n
16:01:17 [Zakim]
16:01:26 [matial]
zakim, ??p22 is me
16:01:26 [Zakim]
+matial; got it
16:01:39 [Zakim]
16:02:11 [Zakim]
16:02:20 [aphillip]
zakim, who is here?
16:02:20 [Zakim]
On the phone I see aphillip, matial, JcK, David_Clarke
16:02:21 [Zakim]
On IRC I see JcK, David, matial, RRSAgent, Zakim, aphillip, r12a, trackbot
16:02:30 [r12a]
zakim, dial richard
16:02:30 [Zakim]
ok, r12a; the call is being made
16:02:32 [Zakim]
16:03:39 [aphillip]
Topic: Agenda
16:04:01 [aphillip]
Topic: Action Items
16:04:08 [aphillip]
16:04:27 [aphillip]
close ACTION-274
16:04:27 [trackbot]
Closed ACTION-274.
16:04:39 [aphillip]
close action-273
16:04:39 [trackbot]
Closed action-273.
16:04:44 [aphillip]
close action-272
16:04:44 [trackbot]
Closed action-272.
16:05:00 [aphillip]
Topic: Info Share
16:05:08 [RRSAgent]
I have made the request to generate aphillip
16:05:27 [aphillip]
16:05:32 [aphillip]
zakim, take up agendum 1
16:05:32 [Zakim]
agendum 1. "RADAR" taken up [from aphillip]
16:05:36 [Zakim]
+ +1.253.302.aaaa
16:06:24 [aphillip]
16:06:50 [aphillip]
zakim, +1.253 is Jan
16:06:50 [Zakim]
+Jan; got it
16:07:43 [aphillip]
16:08:02 [aphillip]
zakim, take up agendum 2
16:08:02 [Zakim]
agendum 2. "CSS Text" taken up [from aphillip]
16:09:43 [aphillip]
addison: start to forward comments that are not objected to
16:10:23 [aphillip]
zakim, take up agendum 4
16:10:23 [Zakim]
agendum 4. "Charmod" taken up [from aphillip]
16:10:32 [aphillip]
16:10:42 [aphillip]
16:11:36 [aphillip]
1) In 1.3 "Background", we find: "Use of control codes for various purposes (e.g. bidirectionality control, symmetric swapping, etc.)" I am not sure what control codes are meant for symmetric swapping. The ones I know of are deprecated (U+206A and U+206B) and as far as I know are not supported by any implementation, so maybe they are not a good example.
16:12:31 [aphillip]
addison: will remove mention of symmetric swapping
16:12:59 [aphillip]
richard: that section will be significantly edtied
16:14:31 [David]
Zakim, mute me
16:14:31 [Zakim]
David_Clarke should now be muted
16:14:45 [aphillip]
13) Ibidem, the paragraph starting with " Unicode defines two types of equivalence " then mentions "canonical decomposition" without defining this term. I think that some explanation or a reference would be helpful.
16:15:00 [aphillip]
mati: needs a definition here
16:15:50 [aphillip]
16) In the table of Compatibility Equivalence, I don't understand the examples for Breaking Differences (I only see an hyphen), Circled (there should be 2 glyphs, one circled and one not circled), Squared characters (I don't distinguish 2 characters), fractions (only one glyph), Others (only one combination). It seems to me that each example should present at least 2 glyphs or sets of glyphs which are deemed equivalent.
16:17:14 [aphillip]
addison: need to clean up that table: it's not clear
16:17:26 [aphillip]
20) I would like to see some justification for Req 6 "Implementations must not normalize any wildebeest during processing, storage, or exchange except with explicit permission from the user.", especially as processing is concerned (how can we mandate what an implementation does for processing?). All the more since the preceding req praises the use of NFC.
16:20:36 [RRSAgent]
I have made the request to generate aphillip
16:21:18 [aphillip]
addison: doesn't say "don't use NFC", it says "don't alter the normalizaiton form of a document"
16:21:34 [aphillip]
mati: needs more explanation
16:21:48 [r12a]
zakim, drop richard
16:21:48 [Zakim]
Richard is being disconnected
16:21:49 [Zakim]
16:21:55 [aphillip]
23) In Req 18, like in Req 6, I have difficulty seeing how we can forbid an implementation to (de)normalize for processing. Only the app knows what it wants to achieve. Note that this req does not mention storage, while req 6 does. Is it intentional?
16:22:24 [aphillip]
[I] Implementations MUST NOT alter the normalization form of content being exchanged, read, parsed, or processed except when required to do so as a side-effect of transcoding the content to a Unicode character encoding, as content might depend on the de-normalized representation.
16:23:27 [aphillip]
mati: add a few sentences defining the requirements
16:26:10 [aphillip]
16:26:20 [aphillip]
zakim, take up agendum 2
16:26:20 [Zakim]
agendum 2. "CSS Text" taken up [from aphillip]
16:26:46 [aphillip]
16:26:56 [aphillip]
(1) In this type of document, where very fine distinctions are important to reader understanding, the use of "character" should be avoided, not used informally in some places to mean "grapheme cluster" and in other places to mean other things. This is adequately flagged in Addison's comments, but I posibly feel more strongly about it than he does.
16:27:37 [aphillip]
(2) A number of requirements or suggstions in the document require knowing the language in which the document is intended to be interpreted, sometimes down to a level of granularity that includes locale information. Since it is possible to have a document for which the language is unknown, the document should be very clear that those actions are not possible and should probably not be guessed at. There is a hint of this in the statements in Section 2.1 [CUT]
16:29:57 [aphillip]
jck: lots of places where there is very close detail for fairly narrow cases or contexts, but the generalized cases are more "hand-wavy"
16:30:35 [aphillip]
addison: corner cases don't generalize
16:31:14 [aphillip]
(3) Contrary to the assertion in the text, case distinctions can affect content, meaning, or at least document correctness. As a trivial example, consider the possibility of accidentally lower-casing sentences of German text that contain embedded nouns. In part as a consequence, the discussion in Section 2.1 about case distinctions and operations should clearly be identified as dependent on language information and impossible (or at least unwise) to appl[CUT]
16:32:56 [aphillip]
addison: don't agree that the operations shouldn't work, but the tailoring (or lack thereof) when no or limited language informatoin needs to be explicit in the document
16:32:58 [aphillip]
jck: yes
16:33:09 [aphillip]
(4) "Anonymous inline" is not defined. "Inline" really isn't either and is extensively used in places where its precise meaning is important. Similar issues occur with "Out-of-flow" in Section 5.1 and with other terms elsewhere. If the expectatation is that no one will try to read this document without having read and internalized all of the terminology in [CSS21] and [CSS3-WRITING-MODES], that should probably be made a lot more clear in Section 1.3 an[CUT]
16:34:29 [aphillip]
addison: agree should link to CSS doucments; these terms are meaningful to the CSS illuminati
16:34:49 [aphillip]
(5) The discussion of line termination is very hard to follow. It isn't clear from reading it whether CSS prefers CRLF, LF, or other forms in output or whether it intends to provide a suggestion. The document itself appears to prefer CRLF in some places and LF only in others (e.g., 4.1.2). If nothing else, I hope we can agree that switching conventions in a single document or rendering is probably a bad idea.
16:37:53 [aphillip]
jck: probably should prefer a line break form
16:38:11 [aphillip]
... they assume one understands CSS
16:38:55 [aphillip]
addison: syntax document should define these, no?
16:39:11 [aphillip]
... can do via reference
16:39:36 [aphillip]
(6) Tabs are used for two quite different things in document formatting. One is simple intention from the reference margin, for which a tab length is sufficient. The other is table layouts, for which column positions are far more relevant than a nominal width (and for which widths may not work or may require significant interpretation). The current text appears to ignore that second case.
16:40:49 [aphillip]
UAX #14 is not particularly helpful in that regard. Incidentally, the reference given is to a different version of UAX #14, with different authorship, than the document to which the link in that reference points. That would normally be trivial but, since the CSS text document says that the line breaking classes of UAX #14 must be honored and UAX #14 continues to change and (I infer from comparisons) become more specific, there is potential for the two d[CUT]
16:42:18 [aphillip]
jck: needs to be stable reference to a specific UAX14
16:43:01 [aphillip]
addison: needs to at least be looked at to ensure that intention isn't changed or that it doesn't break CSS conformity
16:43:39 [aphillip]
jck: also check UAX44 conformity
16:44:09 [aphillip]
(6) Tabs are used for two quite different things in document formatting. One is simple intention from the reference margin, for which a tab length is sufficient. The other is table layouts, for which column positions are far more relevant than a nominal width (and for which widths may not work or may require significant interpretation). The current text appears to ignore that second case.
16:47:32 [aphillip]
This property determines the tab size used to render preserved tab characters (U+0009). Integers represent the measure as multiples of the space character's advance width (U+0020). Negative values are not allowed.
16:49:22 [aphillip]
addison: suggest alternate wording?
16:49:37 [aphillip]
(7) Using 5.2 as an example (the problem seems to occur elsewhere), "this property is, at least in this version, applicable only to CJK text" should be stated right after the property is introduced in the heading, not placed in a note at the end of the section. That situation also probably makes "Applies to" in the colored box under the title misleading if not wrong: apparently, while the property can be applied to any element, it is meaningless for most[CUT]
16:50:57 [matial]
I have to leave. Bye.
16:51:08 [Zakim]
16:55:15 [aphillip]
jck: needs to be explicit about what the line-break applicability is
16:55:43 [aphillip]
(8) In the introduction to Section 6, it may be just my ignorance or fuzzy-headed-ness, but "...hyphenation may also alter the spelling of a word" and " must have no effect on ... text selection or searching" seem contradictory to me unless the intent is really to say "don't even think about searching a document after CSS rules have been been applied". The latter is a strong restriction especially given the tendency to render documents into page-imag[CUT]
16:58:00 [aphillip]
(9) Section 6.2 states that overflow wrapping "only has an effect when 'white-space' allows wrapping". Unless the negative was intended, that confuses me -- one would normally want overflow wrapping to be available to specify exactly those situations in which more conventional wrapping, such as that which 'white-space" would allow, is not helpful or available and most of the text in the section seems consistent with that assumption.
16:58:45 [aphillip]
It would probably be good to have some discussion of what is supposed to happen in the case of overflow if all forms of wrapping are prohibited. Is text truncation acceptable?
17:00:10 [aphillip]
(10) The discussion of Justification in Section 7 appears to be missing a rule / property that reflects the policies of many publishers that line text is not to be expanded past the point of ugliness in order to preserve justification. Those rules are often expressed as a percentage of expanded white space or equivalent. As an example, many publishers would consider
17:01:41 [aphillip]
jck: need some qualifying words or some substantive text about bad breaks
17:01:44 [aphillip]
addison: agree
17:02:12 [aphillip]
(11) I last sat in on a typography class around 40 years ago, but I believe that the opposite of tracking (as described in Section 8.2) is kerning. Kerning narrows letter space rather than increasing it. It is usually letter-pair-specific and may be type style specific as well. Should it be mentioned?
17:03:48 [aphillip]
addison: (discusses)
17:05:20 [Zakim]
17:05:34 [aphillip]
(12) Is there some intention and value to the centered column in "stops and commas"in Section 9.2? I find it distracting and hard to read.
17:07:54 [aphillip]
addison: make sense to me
17:08:04 [aphillip]
(14) Note that it is _very_ common to hang various members of the bullet and digit families, the latter sometimes punctuated with stops or parentheses. Those symbols and numerals are not listed in Section 9.2 and seem to not be covered in Section 9 at all.
17:11:22 [aphillip]
addison: "light" on the documentation
17:11:54 [aphillip]
... not about "bullet hang", but not clear about that?
17:12:46 [aphillip]
Topic: AOB?
17:13:36 [Zakim]
17:13:37 [Zakim]
17:13:37 [Zakim]
I18N_CoreWG()11:00AM has ended
17:13:37 [Zakim]
Attendees were aphillip, matial, JcK, David_Clarke, Richard, +1.253.302.aaaa, Jan
17:13:45 [aphillip]
rrsagent, make minutes
17:13:45 [RRSAgent]
I have made the request to generate aphillip
17:13:53 [aphillip]
zakim, bye
17:13:53 [Zakim]
Zakim has left #i18n
17:14:11 [aphillip]
rrsagent, bye
17:14:11 [RRSAgent]
I see no action items