See also: IRC log
http://www.w3.org/International/track/actions/open
close action-467
<trackbot> Closed action-467.
close action-479
<trackbot> Closed action-479.
<r12a> http://www.w3.org/International/tests/repo/results/default-font
richard: revitalized the above
test
... haven't linked to it from anywhere yet
... shows how language affects the font selected when there is
no styling
<r12a> http://w3c.github.io/tlreq/
richard: working on tibetan
layout requirements
... one of the actions from tpac
... was update with what info I had
... do that in english
... and pass along to translate to chinese
... just completed first pass
... may be ready for fpwd
... soon-ish
... after the chinese is ready
... may notice that the styling of the tlreq looks a bit
different
... tried applying the new CR spec styling
... but a lot comes over
... asked on sped-prod to update respec
... comments need to be sent by end of november
... (rummages for link to fantasai's sample document)
<r12a> http://fantasai.inkedblade.net/style/design/w3c-restyle/2016/sample
<r12a> https://github.com/w3c/tr-design/issues
<r12a> https://lists.w3.org/Archives/Public/spec-prod/2015OctDec/0009.html
https://www.w3.org/International/wiki/Review_radar
https://www.w3.org/International/wiki/Project_radar
clreq needs links
richard: bidi, contacted by
developer working on safari
... isolation of @dir
... send tests that now break because of isolation
... helping him work through those or if they are
expected
... broken things were stuff like HEBREW<span
dir=ltr></span>HEBREW
... isolated span is neutral rather than strong
... can look like a "lost space" because of isolation
<JcK> me may have to drop off again, briefly, but without much warning
https://lists.w3.org/Archives/Public/public-i18n-core/2015OctDec/0052.html
http://www.w3.org/2014/03/timed-text-charter.html
richard: worth reviewing the
discussion of bidi in webvtt
... think they did a pretty good job
<r12a> https://github.com/w3c/webvtt/issues/227
<scribe> ACTION: addison: write back to timed text and note that we've reviewed their charter [recorded in http://www.w3.org/2015/11/12-i18n-minutes.html#action01]
<trackbot> Created ACTION-480 - Write back to timed text and note that we've reviewed their charter [on Addison Phillips - due 2015-11-19].
https://lists.w3.org/Archives/Member/member-i18n-core/2015Nov/0005.html
http://www.w3.org/International/tests/repo/encoding/legacy-mb-japanese/euc-jp/eucjp-encode-002.html
richard: encoding is into the
legacy encoding
... uses a form that sends a URL to an iframe in the test
page
... and the query part of the URL hopefully has the correct
percent encoding for the character
... in this case EUC-JP
... set an accept-charset to the form
... Edge/IE don't use accept-charset of the form
... use the tables from the encoding spec to generate expected
results
... changed actual test file
... it was in utf-8
... changed the test file to euc-jp and the tests worked
correctly on edge
... but using javascript to generate the code points
... before I spend a lot of time on this, want to share this
approach
addison: approach looks okay to
me
... maybe consider the negative cases (unmapped code
points)
issue-506?
<trackbot> issue-506 -- Possibility for a character to be interpreted differently depending on locale ⓣ -- open
<trackbot> http://www.w3.org/International/track/issues/506
<r12a> https://github.com/w3c/presentation-api/issues/218#issuecomment-156012188
richard: think backslash is a red
herring
... actual quesstion is about kanji vs. non-kanji style
... need a way to send the information about the content
... one suggestion was accept-language
addison: accept-language not helpful: it's from the user agent
jck: locale-specific font preference issue
Because the presentational variations (among other things) do matter, the ability to mark up documents and runs of text within documents with languages tags is something that the I18N WG recommends strongly. But this thread seems to be confusing the shape of the glyph with the processing that might be applied to the text.
门
門
https://code.google.com/p/android/issues/detail?id=19660
<JcK> The web interactions with ISO 646 national characters also shows up in another place although every instance of it is arguably a bug. The problem arose when the default web (mostly HTML) rule was ISO 8859-1 and folks in some countries said something equivalent to "8859-1 doesn't work for me so I will interpret it as meaning 8859-whatever-we-use-locally. There too, the problem is one coded...
<JcK> ...octet represents different abstract characters. The solution, of course, is "use Unicode; don't do that"
addison: this issue is that second screen names or maybe descriptions are displayed in your device
(a) unicode code points don't change and presentation of them does NOT change the meaning
(b) end user's expected shapes of the characters depends on the font which depends on the language
jck: see also arabic styles
(c) needs to be a way to pass the language of the content with the content
(d) accept-language is looking at it from the wrong side
(e) language negotiation is a very different thing: offer a way to request a specific language
richard: offer a way to change
the presentation
... "those few characters that have a different look and
feel"
(f) receiver has to be able to sub different font according to the language information
backslash is a red herring. avoid if possible.
<scribe> ACTION: richard: respond to presentation-api issue 506 with discussed set of comments [recorded in http://www.w3.org/2015/11/12-i18n-minutes.html#action02]
<trackbot> Created ACTION-481 - Respond to presentation-api issue 506 with discussed set of comments [on Richard Ishida - due 2015-11-19].
richard: ... and about that backslash...
richard: still workingon webvtt roundup