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

["Thomas Milo" <t dot milo at chello dot nl>]

Abdulhaq Lynch wrote:
>> Hi Mete
>>
>> first off, I respect yours and Thomas' opinions. Of course we will
>> end up having to agree to differ. In this forum really we are just
>> influencing Meor, M Yusuf et al. in the work they do - they can
>> choose whichever method they want of course, we can only give ideas.
>> I really don't mind which solution they choose (honestly!).
>>
>> I don't expect what I say here to affect Thomas and hence Unicode,
>> as Thomas already has long-thought-out, well-formed and detailed
>> plans of his own in this regard.

This is not completely true. In the course of time I picked up the
intellectually bad habit to compromise and accept bad concepts based on
arguments like 500.000.000 Elvis Presley fans can't be wrong. E.g., In my
very first designs I encoded tanween graphemically accurate as repeated
vowels. Since the 500.000.000 Elvis Presley fans decided on encoding nunated
vowels a separate graphemes (to my chagrin, because of the unnecesary loss
of the equation /yawmu-n/ = al-yawmu/ etc.), I decided that repeated vowels
could be used to encode one of the phonetical variants (sequential tanween).

Meor's luadable effort has helped me to return to my original position:
encode graphemes, not glyphs. Keep the tanween graphemically intact, this
will improve searchability. So I recently changed my position regarding
tanween according to the following formula, that I hope this community will
endorse:

tanween = <vowel> <vowel> + [optional] <modifier>

<vowel>=  fatha / dhamma / kasra
<modifier>= tamweem / sequentializer


For backward compatibility,

<vowel> <vowel> = fathatan / dhammatan / kasratan

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

>>> It doesn't depend on OpenType capability. OpenType is just one of
>>> the font technologies you can use to build fonts that can render
>>> complex Arabic. You could surely use any other technology you wish
>>> to use. Although the font technology you are using will probably
>>> have to be advanced enough to do certain things such as contexual
>>> substitutions, etc. OpenType is just one of the technologies which
>>> is able to do these.

Open Type is just a file format, applicable on existing TT and PS based font
files. Any well written parser can handle OT: Adobe uses a different engine
from MS. DecoType has again its own.

>> Thomas and yourself are dismissive of older technology. However,
>> most of the people in the world who are inclined to view the quran
>> on their PC or what-have-you cannot afford to pay MS for their copy
>> of Windows. Why should they be excluded from the solution? Who are
>> we doing this for?

This is a serious concern. The best solution would be a dedicated effort by
the open source community to build a new OT parser, so that you can deal
with problems without red tape.

>>> We are not proposing to glue two glyphs together. You can compare
>>> this non-texual character to the ZWNJ (zero width non joiner)
>>> character in a way (although they are still quite different) in the
>>> fact that they are both non-texual. I think you are confusing this
>>> with Tom's other proposal, which is to declare canonival
>>> equivalence between a fatha+fatha sequence and fathatan, and so
>>> forth.  That is a seperate issue. I think we haven't made this
>>> clear so I apologize. This non-texual character is a seperate
>>> request regardless of whether there is a request to declare
>>> canonival equivalence between a fatha+fatha sequence and fathatan,
>>> and so forth. Even if there is no canonival equivalence declared
>>> between a fatha+fatha sequence and fathatan this additional
>>> codepoint is needed.
>>>
>>
>> I do understand what you mean, I'm exaggerating a bit to make a
>> point. But the fact remains that if this proposal goes through, then
>> how can I represent two fathas side-by-side? Granted, this will not
>> come up often, but if you look at arabic grammar books, tajweed
>> books, sarf books etc it's quite possible that this would be a
>> requirement. M Yousif made this point a long time ago.

I hope you understand that nominal <vowel> <vowel> will rendered exactly
like fathatan / dhammatan / kasratan.

Regards,

t