From: "Peter Constable" <[EMAIL PROTECTED]> > > > 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.
