[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
- To: General Arabization Discussion <general at arabeyes dot org>
- Subject: Re: Proposal for the Basis of a Codepoint Extension to Unicode forthe Encoding of the Quranic Manuscripts
- From: Abdulhaq Lynch <al-arabeyes at alinsyria dot fsnet dot co dot uk>
- Date: Tue, 21 Jun 2005 20:11:59 +0100
- User-agent: KMail/1.8.1
> 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