Re: Smart-font features

On 02/02/2003 10:47:16 AM Chris Lilley wrote:

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

Yes, that was my impression when I looked at it.


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

In this particular case I'm talking about alternate writing styles. (Basic
glyph collision avoidance is usually a fundamental part of the font
behavior--collision should never be "right"!) Vietnamese has a unique way
of combining the circumflex with the acute and grave accents. Instead of
the acute or grave sitting on top of the circumflex, they are off to the
side slightly ("pointing" at the side of the circumflex).


>Sso> - independent diacritic manipulation (on/off)
>
CL>You mean, on a case by case basis on individual characters?

This particular case is one that is less likely to be needed to mark
specific ranges of data; more likely the behavior would be set globally
based on the user preferences.


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

Something like that. Apple lists required/common/rare, and a I suppose none
is also an option.


>Sso> - case modifications (eg, small caps, title case)
>
CL>Small caps can be expresses already (although it is seen as a glyph
CL>manipulaton not a character case manipulation). Titling numerals vs
CL>old-style numerals is not currently addressed.

Yes, small caps is supported--practically the only thing that is. Maybe
that's because it's relatively easy to implement at the application level.
But it is also possible, and I think reasonable, to implement this behavior
in the font.


>Sso> - alternate ways of representing tone (tone letters vs. superscripts)
>
CL>Do you have examples of that? I am not familiar with it.

This happens in IPA, for instance. The tone letters are vertical bars with
horizontal strokes attached to them to show the level of tone. The letter
for medium tone looks something like "-|", and there are tone contour
letters that look something like "/|" or "^|". The equivalent information
can be shown with superscript numbers. And many orthograpies use diacritics
for tone--acute, grave, macron, etc.


>Sso> - show/hide invisible characters
>
>Like wordprocessor/editor showing tabs, paragraph breaks etc?

Yes, could be. I used this in a demonstration of Tamil to show underlying
viramas that disappear in the rendering due to the presence of ligatures. I
don't know if that is useful in real life, but it made a nice demo. :-)


>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 ;-)

Yes, I would expect so.


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

Yes, this is probably equivalent to stretch. I mentioned it because someone
has implemented a Graphite font for Neo-Sumerian Cuneiform, and he created
a feature to "kern out" the glyphs horizontally.

With a font registry, an application can know that, say, stretch is
equivalent to a given feature number, so if the data is marked with
"stretch", it can set up the rendering engine accordingly. OpenType and
Apple have feature registries, but so far Graphite doesn't.


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

In practical terms, generating a transliteration is rarely as
straightforward as simply replacing glyphs. It's common for the
transliteration to need information in the encoded form that is not
required for the original script (Romanized Hebrew is this way, for
instance). So in real life, it may not be practical to use features for
transliteration very often.

Received on Tuesday, 4 February 2003 12:10:44 UTC