W3C

Internationalization Working Group Teleconference

26 Sep 2013

Agenda

See also: IRC log

Attendees

Present
aphillip, jdaggett, Richard, johnKlensin
Regrets
Felix, DavidClarke
Chair
Addison Phillips
Scribe
Addison Phillips

Contents


Agenda

Action Items

<r12a> http://www.w3.org/International/track/actions/open

action-251?

<trackbot> action-251 -- Addison Phillips to Contact the epub folks and see if they will write to html asking about ruby -- due 2013-09-05 -- OPEN

more important is probably to get the Digital Publications folks to show that there is a real need for ruby to the potential implementers

<trackbot> http://www.w3.org/International/track/actions/251

close action-258

<trackbot> Closed action-258.

<scribe> ACTION: addison: change the teleconference time per action-258 [recorded in http://www.w3.org/2013/09/26-i18n-minutes.html#action01]

<trackbot> Created ACTION-261 - Change the teleconference time per action-258 [on Addison Phillips - due 2013-10-03].

close action-259

<trackbot> Closed action-259.

<scribe> ACTION: addison: cancel tpac room reserveration, notify lists that we won't formally meet but richard will be around [recorded in http://www.w3.org/2013/09/26-i18n-minutes.html#action02]

<trackbot> Created ACTION-262 - Cancel tpac room reserveration, notify lists that we won't formally meet but richard will be around [on Addison Phillips - due 2013-10-03].

Info Share

richard: when I'm at TPAC, the web platform docs guys want to talk about nav between translated pages
... ITS 2.0 went to PR
... CSS ruby module was published as WD

(a hearty round of cheers)

RADAR

http://www.w3.org/International/wiki/Review_radar

<r12a> nothing with deadline or of note this week

'Tr' defaulting behavior in Vertical Text

addison: visitor john daggett

<jdaggett> http://www.unicode.org/reports/tr50/japanese.png

john: vertical text layout has distinct characters that can have mixed orientations

<r12a> johnD: vertical layout has mixed orientations for characters

<jdaggett> http://dev.w3.org/csswg/css-writing-modes/#text-orientation

<r12a> ... there is not necessarily a definitive orientation for a given character

<r12a> ... UTR50 defines default orientations

<r12a> ... for use when there is no markup or other indication available

<r12a> ... question is: for a given code point what's the best default?

<r12a> ... in some cases it's clear, latin is rotated, kanji is upright

<jdaggett> http://www.w3.org/TR/2011/WD-css3-writing-modes-20110531/#vertical-typesetting-details

<r12a> ... in writing modes the situation was not too clear, so it was proposed to define a Unicode property

<r12a> ... as new codepoints are added the Unicode Consortium will maintain the data

<jdaggett> http://www.unicode.org/Public/vertical/revision-11/VerticalOrientation-11.html

<r12a> ... this led to UTR50 which defines the vertical orientation property

<r12a> ... if the author has not set a text orientation property explicitly, the user agent will use the UTR50 properties to determine orientation

<r12a> ... there are two T (transform) values

<r12a> ... Tu needs a different glyph

<jdaggett> http://www.unicode.org/reports/tr50/#vertcal_alternates

Tu 3001 、 IDEOGRAPHIC COMMA Tu 3002 。 IDEOGRAPHIC FULL STOP

those are examples

<r12a> ... it's not just orientation

Tr 3008 〈 LEFT ANGLE BRACKET Tr 3009 〉 RIGHT ANGLE BRACKET Tr 300A 《 LEFT DOUBLE ANGLE BRACKET

<r12a> Tr needs transformation but that transformation is a rotation

<r12a> ... in OpenType layout is typically done the same way for Tu and Tr - they are laid out upright and a feature causes substitution to create needed glyph

<r12a> ... most fonts will cover the Tu and Tr codepoints

<jdaggett> http://lists.w3.org/Archives/Public/www-style/2013Sep/0501.html

<r12a> ... however, the spec allows optional fallback for Tr (only) codepoints

# For Tr characters, which are intended to be either transformed or # rotated sideways, the UA may assume that appropriate glyphs for # upright typesetting are given in the font and render them upright; # alternately it may check for such glyphs first, and fall back to # typesetting them sideways if the appropriate glyphs are missing.

<r12a> ... two problems: [1] it's optional behaviour, but there's actually only one way that's right

<r12a> ... it's not like alternative algorithms for say justification

<r12a> ... determining the ability of the opentype features to deal with this is not straightforward

<r12a> ... it's not a good idea to do layout operations on a glyph out of context

<r12a> ... there may be stylistic contexts based on adjacent characters

<r12a> ... unicode is defining an informative property, but the mechanics of the fallback mechanism is not what unicode is defining

Vertical_Orientation (vo) property value, one of the following: U – Upright, the same orientation as in the character code charts R – Rotated 90 degrees clockwise compared to the code charts Tu – Transformed typographically, with fallback to Upright Tr – Transformed typographically, with fallback to Rotated

Tr Same as Tu except that, as a fallback, the character can be displayed with the code chart glyph rotated 90 degrees clockwise.

<r12a> ... existing fonts already provide alternates and the data is in the font

<r12a> ... if the font doesn't have an alternate, we should view it as a font problem

<r12a> addison: i have run into this in my day job in vertical text in Kindle, and it was a problem

<r12a> ... some of our fonts don't have a complete set of rotated glyphs

<r12a> ... in order to get the right results without manual styling we had to provide a fallback in the layout for those cases

<r12a> johnd: it's equally wrong for Tu text if you don't have the right glyph

<r12a> ... if we were talking about a large number of code points this may be a different discussion

<r12a> ... and i'm not sure about the accuracy of some cases in UTR50

<r12a> ... eg the semicolon is displayed upright in Chinese

<r12a> addison: this is not a normative spec, so it can be adapted to solve problems

<r12a> johnd: what has been specified in writing=modes is optional behaviour, and the complexity of the machinery requirements doesn't seem necessary given the extent of the problem

<r12a> addison: we had to do fallback behaviour in kindle for corner cases - when you exceed a font capability you fall back to chinese or other fonts

<r12a> ... we had complaints about glyphs not being properly rotated

<r12a> johnd: i'd like to know more about the specifics of that example

<r12a> addison: it may indeed by a quirky character, but a font can't have every glyph in it, so if you leave out something then people will complain

<r12a> addison: this is a useful introduction, i think we need to have koji's viewpoint

<r12a> ACTION: addison to provide further information about issues he encountered wrt to font glyph rotation issues [recorded in http://www.w3.org/2013/09/26-i18n-minutes.html#action04]

<trackbot> Created ACTION-264 - Provide further information about issues he encountered wrt to font glyph rotation issues [on Addison Phillips - due 2013-10-03].

QA Translate Flag (any unfinished business??)

<r12a> still waiting for comments from Felix

<r12a> if not received by tomorrow morning, proceed to wide review

<r12a> felix can submit comments with others

addison to send announcement tomorrow (Friday)

Publish Ruby Use Cases as WG Note

http://www.w3.org/TR/ruby-use-cases/

<r12a> http://www.w3.org/TR/2013/WD-ruby-use-cases-20130910/Overview.html

richard; can we publish as WG Note

<scribe> chair: any objections?

addison: support

JcK: ok

richard: sent email out and have had no comments

<r12a> Agreed: publish Ruby Use Cases Doc as WG Note

<scribe> ACTION: richard: publish Ruby Use Cases as WG-Note [recorded in http://www.w3.org/2013/09/26-i18n-minutes.html#action05]

<trackbot> Created ACTION-265 - Publish ruby use cases as wg-note [on Richard Ishida - due 2013-10-03].

Authoring HTML: Handling RTL Scripts

AOB?

<r12a> r12a: some comments from Mati i'll integrate, but we should move it soonish to review

<Najib-ma> Reading it diagonally.

<Najib-ma> A general remark.

<Najib-ma> In the arabic exemple, choosing significative words would be less confusing.

<Najib-ma> For exemple in the first examples one cannot see which arabic text is actually the attribute value and which one is the element value.

<Najib-ma> I suggest for example (line breaks here for readability)

<Najib-ma> <p class="myclass" title="عنوان">

<Najib-ma> عربية

<Najib-ma> </p>

<Najib-ma> where the attribute value is the translation of the word "title" and the <p> content is the word Arabic

<Najib-ma> More specific comments in a separate mail.

<Najib-ma> /That's it, Thanks

addison: thanks Najib! will look for the email

<r12a> email would be good, najib

<r12a> please send asap, thanks

<Najib-ma> Ok

<Najib-ma> By friday

<r12a> najib, also see mati's comments

<Najib-ma> I have to reply to

<r12a> Meeting Adjourned

Summary of Action Items

[NEW] ACTION: addison to provide further information about issues he encountered [recorded in http://www.w3.org/2013/09/26-i18n-minutes.html#action03]
[NEW] ACTION: addison to provide further information about issues he encountered wrt to font glyph rotation issues [recorded in http://www.w3.org/2013/09/26-i18n-minutes.html#action04]
[NEW] ACTION: addison: cancel tpac room reserveration, notify lists that we won't formally meet but richard will be around [recorded in http://www.w3.org/2013/09/26-i18n-minutes.html#action02]
[NEW] ACTION: addison: change the teleconference time per action-258 [recorded in http://www.w3.org/2013/09/26-i18n-minutes.html#action01]
[NEW] ACTION: richard: publish Ruby Use Cases as WG-Note [recorded in http://www.w3.org/2013/09/26-i18n-minutes.html#action05]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.138 (CVS log)
$Date: 2013/09/26 17:50:00 $