i18n review

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Hello all,

Sorry I couldn't make it on the call today!  Here my initial thoughts
regarding the i18n WG's text layout page.  The short, short version:
it's worth promoting, but it needs more coverage.

I think Liza is going to add more to this summary when she has time.

"Improving text layout and typography on the Web and in eBooks"
<https://www.w3.org/International/wiki/Improving_typography_on_the_Web_and_in_eBooks>
is something that the DPUB community should be aware of as they think
about both the tools in the publication process and the reader software
consuming non-English language material.  The "Improving text layout"
page is more of an index, almost an FAQ, that provides pointers to
specific areas in the detailed documentation (e.g., Indic layout,
Japanese layout, Hangul layout).  There is a notable lack, however, in
language groups covering Arabic, Hebrew, Cyrillic, etc.  The W3C is
aware of the lack and looking for volunteers to help tighten up the
gaps.  A useful action out of DPUB could be to help prioritize language
groups (are there any particular script gaps that are causing specific
difficulty) and helping find experts to help fill the holes.

Unfortunately, I don't know enough about non-Latin scripts to suggest
specific areas where DPUB should be targeting in the existing layout
guides; what I see is the gap introduced by a limited number of layout
guides.

In a slight tangent from the W3C, I do want to point people to the
recent IAB (Internet Architecture Board) statement on identifiers and
Unicode 7.0.0.

<https://www.iab.org/documents/correspondence-reports-documents/2015-2/iab-statement-on-identifiers-and-unicode-7-0-0>

The i18n program of the IAB recently identified a problem within Unicode
7.0.0 that has significant ramifications around anything that has to be
able to compare characters across scripts.  It's a solid write up, and
while I don't know if it immediately applies to most publishers, it
definitely applies to anyone who has to handle string comparisons.  It's
going to be something that the RFC Series has to worry about when we
move away from the ASCII-only model and has to support authors using
characters that do not decompose as one might expect.

- -Heather


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2
Comment: GPGTools - http://gpgtools.org

iQEcBAEBAgAGBQJUz6FIAAoJEER/xjINbZoGWsUIALwJJ6e/nU6S+S1t7FViKgjU
BG60yHD9fQkOCo0IILB6DuPGPTQe10i2N7bCoNgDr8EIV3KmNiO8J2N247aDtg85
+i7yKlOYrpQ79pvu1o2RJGNg1zcGPmusEe5WZEdUKV0PpxRyCM1Y8wdhMfo1jpn+
zDJydkxhvL7E7qSmR+NrzEECKnwtKDSugOWvEqyjCRG9JOzTnpLjN170IfU4I8/m
mMgdoRY/9qdIxJ9us6OWGM0JLWg7tDX55Du9+AJC6mHQRUuXCdPumUOj8cq3FPPP
QexucjK9sVgntYDhcEd/hBmeWW2Oa02QyNhC+bKpoRhYXmdZMMf8g6dNpT+6VYk=
=5kfD
-----END PGP SIGNATURE-----

Received on Monday, 2 February 2015 17:03:26 UTC