[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Proposal for the Basis of a Codepoint Extension to Unicodeforthe Encoding of the Quranic Manuscripts



>> 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/)