From: Peter Constable (petercon@microsoft.com)
Date: Tue Mar 01 2005 - 00:35:40 CST
> From: unicode-bounce@unicode.org [mailto:unicode-bounce@unicode.org] On
> Behalf Of UList@dfa-mail.com
> > Other options are to use stylistic set
> > features or 'aalt' (to select alternate glyphs one character at a time).
>
> But is there any coding method to select "stylistic set" features or
> "aalt"
> variations from a Web page?
>
> Or any method planned?
Unfortunately, no: AFAIK there is no convention solution for representing font features within HTML or CSS. One issue in overcoming that is that different font technologies have different approaches to font features.
> I assume that exposing an OT feature to CSS (hopefully) or XML (?) would
> be a
> matter for Microsoft to determine (possibly with the W3), and would not
> involve Unicode.
It is, indeed, a W3C issue, not a Unicode issue.
> Are "locl" (I am BTW assuming this means "local") features something
> formally
> defined in the OpenType registry of OT language-system tags? Or user-
> definable?
Neither. It is a feature in the registered list of OpenType *feature* (not language-system) tags. (See http://www.microsoft.com/typography/otspec/ttoreg.htm for further info on OpenType Layout tags.)
> If "locl" does have to be defined in the Registry, does it seem reasonable
> that the Registry could contain many long lists of obscure variants for
> ancient languages like this?
If you mean lists of glyph variants, then no, that's not how it works. The 'locl' feature is defined in the OTL tag registry to have a particular purpose and to be used *in general terms* in a particular way. It is up to an individual font developer to decide what glyph substitutions she wants to have take place using the 'locl' feature in the context of a given OTL script and language-system.
If, on the other hand, you mean an enumeration of language/writing systems representing distinct sets of typographic conventions, then that has been the idea. We are still relatively early in the evolution of this stuff, so I think we've yet to discover whether there are scenarios for which this doesn't quite meet the need.
> Also is there any formal or informal cooperation between the OpenType
> registry
> of OT language-system tags -- including "locl" -- and the Unicode
> Consortium
> (which I seem to think is coming up with/involved with some kind of
> language
> tag list??) -- or the W3 -- or some other international standard?
Possibly, though not necessarily.
> Or for compatibility in Web page coding, will other smart font
> technologies be
> able (legally and otherwise) to make use of the Microsoft list?
AAT and Graphite do not have any mechanism that corresponds to OT's language-system tags. While I was working with SIL before coming to MS, I had suggested to the Graphite team an approach for incorporating language-specific typographic support (one that would also work for AAT). AFAIK, nothing has happened in that regard for either of those technologies. Those technologies could, of course, use some other approach to this issue from the one I had in mind.
> > The choice between LTR and RTL requires certain things to be done by the
> > app and certain things to be done in the font. The app should take care
> > of selecting the line direction (whether its control mechanism is a
> > formatting setting or Unicode bidi control characters), and applying
> > bidi mirroring to mirrored character pairs (per Unicode character
> > properties). Then, for the RTL runs of text, a feature should be applied
> > to select RTL variants of glyphs for non-mirror-paired characters. In
> > OpenType, the 'rtla' feature should be used for this purpose.
>
> Oh -- I get it! (Maybe...)
>
> I can define a glyph in OT as a "mirror" of another glyph -- and when the
> app
> tells OT it has detected a Unicode direction-override codepoint, OT will
> then
> swap in the "mirror" glyph.
Let's consider three kinds of scenarios:
- a character like "o" (in a mono-width-stroke font or one with vertical stress) is already symmetric and requires no substitution
- a character like "(" for which there is another Unicode character that is its mirror (the UCD defines a list of these and their mirrored pairs): these can be substituted by the application in character space before glyph processing within the font occurs
- a character like "k" which is not symmetric and which doesn't have a mirrored-pair character (of course, I've used modern Latin characters, but really we want to be thinking in terms of a script such as Greek or Old Italic that did get written in more than one direction): in a RTL context, you may want to use glyphs designed like its vertical-axis mirror (or, perhaps, a 180° rotation). For this, the 'rtla' feature could be used to substitute the RTL alternate glyph when the text is in a RTL run.
> So my pairs of LTR/RTL language tags would not be necessary.
No, not as OTL language-system variants or something comparable.
> *But* I wonder if/when RTL functionality would ever be implemented by
> Microsoft for Greek script...
We will design our shaping engine so that an app can apply the 'rtla' feature, at which point it's up to an app and font vendors to make use of that for something like Greek.
> You see with short lines of inscription text (what we're dealing with),
> you
> could actually "type it backwards", that is, type:
>
> ESARHP KEERG YM
You could, though I think that would not be the preferred thing to do, ultimately.
> And use a "Cretan Doric RTL" language tag to select the reverse glyphs in
> the font.
Nope; not a good idea, IMO.
Peter Constable
This archive was generated by hypermail 2.1.5 : Tue Mar 01 2005 - 00:37:59 CST