W3C home > Mailing lists > Public > public-digipub-ig@w3.org > February 2015

i18n review

From: Heather Flanagan (RFC Series Editor) <rse@rfc-editor.org>
Date: Mon, 02 Feb 2015 08:09:45 -0800
Message-ID: <54CFA149.7040006@rfc-editor.org>
To: public-digipub-ig@w3.org
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"
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

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.


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

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

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:35:55 UTC