W3C home > Mailing lists > Public > www-style@w3.org > April 2011

Re: [css3-text] script-specific functionality

From: John Hudson <tiro@tiro.com>
Date: Wed, 06 Apr 2011 15:53:28 -0700
Message-ID: <4D9CEEE8.1080601@tiro.com>
To: Håkon Wium Lie <howcome@opera.com>
CC: www-style@w3.org
Håkon wrote:

>   - other languages may have other notions of text-transform. For
>     example, Wikipedia notes that:
>       Also similar to case is recent usage in Georgian, where some
>       authors use isolated letters from the Asomtavruli alphabet
>       within a text otherwise written in Mkhedruli in a fashion that
>       is reminiscent of modern usage of letter case in the Latin,
>       Greek, and Cyrillic alphabets.
>       http://en.wikipedia.org/wiki/Letter_case

>   - there are plenty of use cases for typographic transforms. For
>     example, you would want to automatically convert '«' into '"'. Or
>     "'" into "’". This is another argument for finding a generic
>     mechanism instead of a keyword-based approach.

>   - consider adding a generic mechanism for glyph transforms. The tr///
>     operator in Perl could give us inspiration without taking us all
>     the way to regular expressions. For example, we could have:
>        text-transform-range: "'" "’", "a-z" "\FF41-\FF5A"'
>   - consider if the glyph substitutions in question can be described
>     in other languages. For example, I believe that Opentype Features
>     can be used to describe the mappings in question, no?

I'd like to clarify whether we're talking here about [buffered] 
character-level transformations or glyph-level transformations. Although 
it is frequently possible to simulate character transformations at the 
glyph level, this is usually avoided in OpenType, with character-level 
transformations being preferred both because they are faster than glyph 
transformations and because there's something a bit icky about using 
e.g. the glyph for an uppercase character to display a lowercase 
character. In general, OT developers are encouraged to keep a clean 
distinction between character and glyph processing, and the OTL shaping 
engine model presupposes character processing as input to GSUB and GPOS 
processing (contrast with AAT and Graphite in which far more layout is 
implemented at the glyph level).

Received on Wednesday, 6 April 2011 22:54:01 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:45 UTC