RE: [minutes] Internationalization telecon 2013-12-15

Yes: I'm going to start forwarding comments to them. I just haven't sat down and started moving the comments yet.

> -----Original Message-----
> From: Richard Ishida [mailto:ishida@w3.org]
> Sent: Monday, December 16, 2013 9:33 AM
> To: public-i18n-core@w3.org
> Subject: Re: [minutes] Internationalization telecon 2013-12-15
> 
> Chaps,
> 
>  From the minutes I don't see the status wrt sending comments to the CSS WG.
> Were any decisions taken in that respect?
> 
> RI
> 
> 
> On 16/12/2013 17:30, Richard Ishida wrote:
> > http://www.w3.org/2013/12/12-i18n-minutes.html

> >
> >
> >
> >
> > Text version follows:
> >
> >
> >
> > Internationalization Working Group Teleconference
> >
> > 12 Dec 2013
> >
> >     [2]Agenda
> >
> >        [2]
> > https://lists.w3.org/Archives/Member/member-i18n-core/2013Dec/0008.htm

> > l
> >
> >     See also: [3]IRC log
> >
> >        [3] http://www.w3.org/2013/12/12-i18n-irc

> >
> > Attendees
> >
> >     Present
> >            aphillip, matial, JcK, David_Clarke, Richard, Jan
> >
> >     Regrets
> >            felix
> >
> >     Chair
> >            Addison Phillips
> >
> >     Scribe
> >            Addison Phillips
> >
> > Contents
> >
> >       * [4]Topics
> >           1. [5]Agenda
> >           2. [6]Action Items
> >           3. [7]Info Share
> >           4. [8]RADAR
> >           5. [9]CSS Text
> >           6. [10]Charmod
> >           7. [11]CSS Text
> >           8. [12]AOB?
> >       * [13]Summary of Action Items
> >       __________________________________________________________
> >
> > Agenda
> >
> > Action Items
> >
> >     [14]http://www.w3.org/International/track/actions/open

> >
> >       [14] http://www.w3.org/International/track/actions/open

> >
> >     close ACTION-274
> >
> >     <trackbot> Closed ACTION-274.
> >
> >     close action-273
> >
> >     <trackbot> Closed action-273.
> >
> >     close action-272
> >
> >     <trackbot> Closed action-272.
> >
> > Info Share
> >
> > RADAR
> >
> >     [15]http://www.w3.org/International/wiki/Review_radar

> >
> >       [15] http://www.w3.org/International/wiki/Review_radar

> >
> > CSS Text
> >
> >     addison: start to forward comments that are not objected to
> >
> > Charmod
> >
> >     [16]https://lists.w3.org/Archives/Member/member-i18n-core/2013D

> >     ec/0006.html
> >
> >       [16]
> > https://lists.w3.org/Archives/Member/member-i18n-core/2013Dec/0006.htm

> > l
> >
> >     [17]http://www.w3.org/International/docs/charmod-norm/

> >
> >       [17] http://www.w3.org/International/docs/charmod-norm/

> >
> >     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.
> >
> >     addison: will remove mention of symmetric swapping
> >
> >     richard: that section will be significantly edtied
> >
> >     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.
> >
> >     mati: needs a definition here
> >
> >     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.
> >
> >     addison: need to clean up that table: it's not clear
> >
> >     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.
> >
> >     addison: doesn't say "don't use NFC", it says "don't alter the
> >     normalizaiton form of a document"
> >
> >     mati: needs more explanation
> >
> >     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?
> >
> >     [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.
> >
> >     mati: add a few sentences defining the requirements
> >
> > CSS Text
> >
> >     [18]https://lists.w3.org/Archives/Member/member-i18n-core/2013D

> >     ec/0009.html
> >
> >       [18]
> > https://lists.w3.org/Archives/Member/member-i18n-core/2013Dec/0009.htm

> > l
> >
> >     (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.
> >
> >     (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]
> >
> >     jck: lots of places where there is very close detail for fairly
> >     narrow cases or contexts, but the generalized cases are more
> >     "hand-wavy"
> >
> >     addison: corner cases don't generalize
> >
> >     (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]
> >
> >     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
> >
> >     jck: yes
> >
> >     (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]
> >
> >     addison: agree should link to CSS doucments; these terms are
> >     meaningful to the CSS illuminati
> >
> >     (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.
> >
> >     jck: probably should prefer a line break form
> >     ... they assume one understands CSS
> >
> >     addison: syntax document should define these, no?
> >     ... can do via reference
> >
> >     (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.
> >
> >     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]
> >
> >     jck: needs to be stable reference to a specific UAX14
> >
> >     addison: needs to at least be looked at to ensure that
> >     intention isn't changed or that it doesn't break CSS conformity
> >
> >     jck: also check UAX44 conformity
> >
> >     (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.
> >
> >     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.
> >
> >     addison: suggest alternate wording?
> >
> >     (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]
> >
> >     <matial> I have to leave. Bye.
> >
> >     jck: needs to be explicit about what the line-break
> >     applicability is
> >
> >     (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 "...it 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]
> >
> >     (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.
> >
> >     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?
> >
> >     (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
> >
> >     jck: need some qualifying words or some substantive text about
> >     bad breaks
> >
> >     addison: agree
> >
> >     (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?
> >
> >     addison: (discusses)
> >
> >     (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.
> >
> >     addison: make sense to me
> >
> >     (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.
> >
> >     addison: "light" on the documentation
> >     ... not about "bullet hang", but not clear about that?
> >
> > AOB?
> >
> > Summary of Action Items
> >
> >     [End of minutes]
> >
> >

Received on Monday, 16 December 2013 17:52:08 UTC