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

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



> The thing is that the contemporary Qur'an printings are almost completely
> render-able today with Unicode using a character-based (not glyph based)
> encoding scheme, only a few mode codepoints need to be addded that's it.
> The XML elements and other such high level semantics we are talking about
> address what is beyond the rendering, i.e. text analysis. So the rendering
> problem is almost solved, IMHO.
>
 Hi Mete

one problem is that the rendering problem has been 'almost solved' for a long 
time now.

The other is that this solution, as I understand it, depends on OpenType 
capability font rendering to work.

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.

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.

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'?)

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

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,

wassalaam
abdulhaq