W3C home > Mailing lists > Public > www-style@w3.org > February 2003

Re: Smart-font features

From: Chris Lilley <chris@w3.org>
Date: Sun, 2 Feb 2003 17:47:16 +0100
Message-ID: <1851138710078.20030202174716@w3.org>
To: www-style@w3.org, Sharon_Correll@sil.org

On Sunday, February 2, 2003, 2:52:14 AM, Sharon wrote:



Sso> On 01/31/2003 07:07:37 PM "Christoph Päper" wrote:
>>Sounds to me as if you were looking for CSS's @font-face construct and its
>>children: <http://www.w3.org/TR/CSS2/fonts.html#font-selection>.

Sso> Thanks, I'll check that out.

That construct (and its XML equivalent) is certainly where such
additions would reside, but there is nothing comparable there in the
current version of CSS. @font-face holds font descriptors -
information about a particular font. The style properties on the other
hand are requests for particular styling. So the two go hand in hand -
one contributing to a list of requests and the other contributing to a
database of ways to satisfy those requests.


Sso> On 01/31/2003 06:31:33 PM Tom Gewecke wrote:
>>Could you give an idea or point to anything online which describes more
>>specifically what is meant by these Graphite "features" that might need to
>>be activated by markup?

Sso> Some examples can be seen at
Sso> <http://developer.apple.com/fonts/Registry/index.html#Type0>, which
Sso> describes Apple's feature registry.

Sso> The Graphite documentation doesn't discuss the concept of features much,
Sso> but our main paper on the Graphite Description Language does describe how
Sso> to program them (graphite.sil.org, link "Graphite Description Language",
Sso> page 20). Here are some ideas that we've discussed or experimented with in
Sso> Graphite-enabled fonts so far:

Sso> - letter shape variations (eg, three forms of uppercase eng, alternate bowl
Sso> shape for letters like g, Cyrillic E needed for Mongolian)

The case of glyph variants (which could include contextual variants
such as end of word swash forms) is currently poorly addressed. It is
typically done in SVG by creating very small fonts and pointing to
them from a small span of text, or by using an altglyph.

Sso> - presence/absence of diacritics (eg, Hebrew)

This is an important case, for Arabic too.

Sso> - alternate diacritic positioning (eg, Vietnamese, certain forms
Sso> of Arabic)

I am imagining that the same mechanism that takes care of letter form
variations could take care of this too. Do you mean different
positioning of the same diacritic on different letters 9eg lower or
higher or to one side, to avoid hitting parts of the base letter) or
do you mean alternate writing styles for a given base letter and
diacritic?


Sso> - independent diacritic manipulation (on/off)

You mean, on a case by case basis on individual characters?

Sso> - ligature formation
Where-possible/mandatory-only/off ?

Sso> - ligature manipulation
Sso> - case modifications (eg, small caps, title case)

Small caps can be expresses already (although it is seen as a glyph
manipulaton not a character case manipulation). Titling numerals vs
old-style numerals is not currently addressed.

Sso> - alternate ways of representing tone (tone letters vs. superscripts)

Do you have examples of that? I am not familiar with it.

Sso> - fraction format (1/2 vs. ½ vs. the form with a truly horizontal line)

Yes. Currently done (if at all) using altglyph or as a per-font
choice.

Sso> - show/hide invisible characters

Like wordprocessor/editor showing tabs, paragraph breaks etc?

Sso> - show underlying data (eg, don't reorder in Indic scripts)

That one also seems to be primarily an editor case (or to help when
writing educational materials or examples for Unicode conferences ;-)

Sso> - expanded mode

I am not sure what you are referring to here. Condensed and expanded
formas of a font family are already describable in CSS2 (font-stretch,
which in retrospect I wish we had a better name for).

Sso> - fancy typography (eg, line-end swashes)

Yes.

Sso> - alternate/experimental orthographies
Sso> - transliteration

Some of these are starting to get into an area where it is debatable
whether it is the glyphs or the characters that should change. I mean,
it would presumably be possible to write a smart font for Inuit
languages that used Inuktitut letterforms but was switchable to Latin
(well, Danish) letterforms for Greenlandic; but that might encourage
people to use the Latin orthography exclusively and rely on the font
to provide the correct glyphs.

This is perilously close to the common
and very bad usages of latin letters to represent greek 9"Symbol font"
or Cyrillic or etc "this web page will only display correctly with
font Blah". Indexing, searching, spell checking and text to speech
should also be considered when deciding what characters are the most
applicable.

On the other hand I do understand the value of being able to display
one of two different orthographies on the same tezxt, just by making a
small stylesheet change.

Sso> As you can see, many of these are binary-valued features, eg
Sso> "show invisible characters" or "hide invisible characters". But
Sso> something like the alternate forms of the uppercase eng would
Sso> have three possible values, corresponding to the three forms
Sso> (that we know of!).


-- 
 Chris                            mailto:chris@w3.org
Received on Sunday, 2 February 2003 11:47:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:19 GMT