Re: Advanced Font Features

Etan Wexler:
> It’s OpenType (no space in the name)

I wrote "Daimler Chrysler", I'll keep writing "Open Type" (unless  
someone convinces me of "Open-Type").

> Another font technology to keep in mind is Graphite

Yes, of course, sorry I didn't mention it.

> Cascading Style Sheets should not include a mechanism for  
> transliteration,

Funny, I was thinking about this very topic today (while trying to  
recognise patterns in Russian conjugation), but as an extension to | 
text-transform| independent from "smart fonts". I couldn't come up  
with any usable syntax (or convincing usecases). For many scripts  
there are several competing (reversible) transliteration and  
(language-dependent) transcription schemes available, especially when  
the target is roman, cf. <http://transliteration.eki.ee/>. Few are as  
simple as 1:1 replacement tables (think |strtr()|), which is only  
truely possible for alphabetic scripts anyhow.

Nevertheless, Lynx for instance does transliteration into ASCII (or  
some local 8bit superset) already, but no CSS.

> The generic interface won’t work well, as my notes will explain.

I've come to this conclusion, too. The major reason being features  
that should stay internal, i.e. always on, the others readability and  
portability.

> The better type designers have been including typographical finery  
> in their fonts for at least a few years.

The combination of artistic talent and (digital) technical knowledge  
isn't as frequent as one would hope, although it exists (e.g. in  
Zuzana Ličko). Most designers use OT etc. like most owners use their  
SUVs, not even closely to the full potential.

> Popular text‐rendering libraries and interfaces have, I believe,  
> supported that typographical finery for at least as long.

As far as I know most implementaions still lack some details or did  
until recently. The major holdback may be the user interface indeed,  
i.e. exactly what we're dealing with here.

Received on Tuesday, 22 January 2008 22:48:55 UTC