Re: i18n review

Thanks Heather. My feedback was just identifying some gaps:

The primary gap I could identify is in page styling. Running heads and
footers are addressed, as is page-progression, but nothing about
widows/orphans or page breaking generally. This is probably the most
relevant for ereaders specifically.

This is extremely minor, but I also wondered if there should be more
specific discussion of user-agent behavior relative to layout semantics.
There's mention of double-click to highlight a word (which requires
understanding of word boundaries), but not triple-click that highlights a
paragraph (which may vary among writing systems).

Finally, I wonder if quotations (as in blockquote behavior) needed any
special consideration. There are typographic conventions for blockquotes in
Latin text (indented block), but I didn't see a mention here. Are there
non-Latin traditions for laying out long quotations that are different from
the current default of an indented block?

Of the three, I think only the first one is really significant enough for
this group to consider expanding on.

Liza



On Mon, Feb 2, 2015 at 11:09 AM, Heather Flanagan (RFC Series Editor) <
rse@rfc-editor.org> wrote:

> -----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 21:28:04 UTC