>> And the main problem from my perspective is that the encoding of the >> extra non-textual signs is entirely glyph-based rather than >> semantically based. This means that it is not a long term solution >> and only wholly valid for a certain region of the muslim world and a >> certain time-frame. I'm sure Thomas agrees here BTW.
Ameen. Encoding should deal with nominal values, graphemes. Not with graphical solutions. >> By abstracting the data from the glyphs up to its real meaning, the >> appropriate glyph can be rendered (or ignored) in any region of the >> world. Indeed, this is the sanest appoach. >> It seems to me that we agree that the unicode spec needs extending, >> but we have different proposals for that. You want to, for example, >> glue two glyphs together to represent a new codepoint. This is >> because you do not want to use codepoints other than the Unicode >> ones as you say this will break compatibility. However, of all the >> instances of font renderers out there, how many will render your new >> glued-together 'codepoints' correctly? Even if they support >> OpenType? (After all, how does the opentype engine know if you want >> two sequential fathas or fatha bi-ikhfaa'?) (Backward) compatibility is a non-issue. After all, it is only a serious concern for the large mass of office quality code junk. >> I, on the other hand, want to set up a private user area that will >> allow us to >> >> 1) Start encoding the quran properly, in a semantically-based >> fashion. >> >> 2) Support current font technology and devices using that (including >> truetype and bitmapped fonts) by providing a secondary table of any >> pre-composed glyphs required. >> >> The disadvantage to this, and you've mentioned this too, is lack of >> support. And yet, with a good OpenType font, this can be beautifully >> supported even now by most Windows applications (for example). Meor >> mentioned that your sequential-fathatayn doesn't work with the MS >> renderer (if I remember correctly). Thomas suggested that he file a >> bug with Microsoft. I presume he was being tongue-in-cheek there! >> You have to pay MS money for them to register a 'bug' - then they'll >> tell you that it's a feature (and I would agree with them in this >> instance). MS should provide a platform for other engines than Unicscribe to handle PS/TTF/OTF fonts. That would be real Open Type! In the mean time, you could seriously consider alerting Paul Nelson or John Hudson that their effrts fall short of what's required. >> One are where support would be lacking is in text composition (think >> charmap) and keyboard entry of the new code points. However, keymaps >> can easily be created. >> >> I'll detail ideas on rendering the proposed encoding in another >> thread, Looking forward, Thomas Milo wa s-salaamu (this transcription is reversible, see and test: http://www.basistech.com/arabic-editor/)
_______________________________________________ General mailing list [email protected] http://lists.arabeyes.org/mailman/listinfo/general
