2011/8/22 Shriramana Sharma <samj...@gmail.com>: > On 08/22/2011 08:24 AM, Peter Constable wrote: >> >> I'm not saying that there shouldn't be_some_ software that can do >> what you expect. But there will likely be some different views on >> what ought to be included within that "some". > > Peter, given that both AAT and Graphite have provisions for assigning custom > properties including BC to PUA characters, it seems Uniscribe is the only > one missing out. Those advocating RTL PUA areas seem to reject AAT and > Graphite as "hacks" or "wow *one* application" [*].
I don't know really if AAT allows storing custom character properties for PUAs. Graphite has some provisions, but its not technically documented as a directional character property, in the sense given by Unicode, because Graphite also works at the level of glyph id's and not the level of code points and characters. In addition, your statement about Uniscribe is incorrect. This concerns in fact OpenType in a more general way. But I suspect that the strong opposition given by Peter Constable is not really about how or if OpenType can integrate some table to convey the direction property of PUAs, but that he is more concerned about how the Uniscribe implementation is layered in its architecture. I don't think that even the Uniscribe API (in Windows) has to be modified. In fact when Peter says that the Bidi processing and the OpenType layout engine are in separate layers (so that the OpenType layout works in a lower layer and all BiDi processing is done before any font details are inspected), I think that this is a perfect lie: At least the Uniscribe layout already has to inspect the content of any OpenType font, at least to process its "cmap" and implement the font fallback mechanism, just to see which font will match the characters in the input string to render. If it can do that, it can also inspect later a table in the selected font to see which PUAs are RTL or LTR. And it can do that as a source of information for BiDi reordering, which does not reorders characters really, but assign them ordering indices that are then also later tuned with the help of knowledge of other characters properties. In fact these indices are also marked with additional attributes (for example when a character is multipart, each part becoming a separate glyph that reorders differently fro mthe other part, such as with some Indic vowels). There's already a strong intrication of the glyph reordering and the BiDi reordering. Glyph reordering is also font dependant (it depends on the presence or not of some features). All this intrication needs to be part of the OpenType layout engine (in Windows, Uniscribe is not the only one layout engine, even if it is used in full or part). Uniscribe is in fact structured in several layers in its API, and the application using Uniscrieb can implement the BiDi algorithm separately, including between those layers (for example after Uniscribe's text segmentation). Some complex cases (notably managing the line breaks when formatting paragraphs) requires these separate layers of processing, in which the BiDi algorithm will be intricated (the BiDi algorithm does not really reorder the characters for a complete text, it computes an even/odd indicator (based on Bidi embedding levels), that helps determine runs of characters that share the same RTL or LTR resolved direction. But those runs can be splitted (notably by linebreaks, whose position highly depends on the metrics of glyphs, and the OpenType substitutions of default glyph id's (from the cmap) by ligatures or by alternate forms, some of which being mandatory for specific scripts, some not and only selected in a dictionary way by the application (that enables some features specifically, or select a precise alternate). -- Philippe.