From: Philippe Verdy (verdy_p@wanadoo.fr)
Date: Fri Mar 26 2004 - 16:51:02 EST
From: "Peter Constable" <petercon@microsoft.com>
> > > What is clear is that there's no way to enable these features
> explicitly in
> > plain-text files, if there's no standard format control in Unicode to
> enable
> > these OpenType font features. May be these could become new
> "characters" to
> > allocate in plane 14?
>
> This sounds suspiciously like "courtyard codes". (Wonders to self: Are
> "Philippe Verdy" and "William Overington" aliases for the same person?
> :-)
I can ensure you that this is not the same person (look at the country of origin
detected in the IP address if you are still not convinced).
> > What I mean here is that there's currently no defined way to convey in
> > plain text files the intended rendering "features" that are now common in
> > OpenType fonts and engines.
>
> Nor should there be, any more than there should be ways in plain text to
> indicate typeface, point size, style, etc. There is a class of
> representations for such information called "rich text", and such
> representation has been and will very likely continue to be beyond the
> scope of plain text.
Note that I was not speeking strictly about style, but about the way to mark the
text to allow or disallow some script features. This remains something optional
for the renderer, and this can be ignored as well without breaking the encoded
text. What I mean here is a set of format controls which help to the
interpretation of the text by renderers.
Yes of course we could define all these at the "rich text" format level (for
example in CSS if it has such functions to select alternate rendering options).
But when I look at what OpenType "features" perform (I don't mean the content of
the associated extra GSUB/GPOS tables which is not what I mean here) it looks
like they are designed to be used for particular languages or scripts, in a way
that can be used across multiple font designs.
So a font may implement a feature and another may not. This looks very similar
to a sort of meta-tagging within the middle of the text to add semantics to it,
which can then be used by various renderers and fonts to adapt its style on the
fly.
This was already the case when language tags were added to Unicode. And OpenType
can now include language-specific features which can be triggered by the
presence of these tags. But in reality, most font features implemented today are
not performed at the language level but with a finer grained level after the
language level). And there's no similar way to tag the text with these features.
Please don't consider this was a proposal, just a question about the feasibility
of applications that need to use such script-specific features, as part of their
regular text processing, without even needing it at the graphic level (when I
look at some OpentType features, their 4-character labels may become part of the
text-level processing, without even needing any glyph processing in the
application using these tags.
So reread my question (this was not a RFE) like this: are there semantics in
these feature tags (yes, just the 4-letters IDs of these tags, not the content
of the GSUB/GPOS tables to which they may be mapped in a specific font) which
would need a way to represent them as format controls within the plain-text
stream?
I think that such semantic exists for these, which may be used or left unused in
some presentation by a renderer, but may have its own application for plain-text
handling (without any glyph processing). I suggested that they may be encoded in
plane 14, possibly among language tags, but this was just a suggestion if they
ever need to be encoded somewhere.
This archive was generated by hypermail 2.1.5 : Fri Mar 26 2004 - 17:26:21 EST