Re: Quranic Proposal

[abdulhaq <al-arabeyes at alinsyria dot fsnet dot co dot uk>]

Dear Thomas

thanks for the prompt reply.

If ACE doesn't deal with the tajweed related markings, but the rendering is 
done entirely based on the unicode, then surely that implies that all 
tajweed related signs and distinctions must be encoded?

This would mean the acceptance of items 1 - 6, 9, 10, 11 and 12. If you don't 
want them in the unicode standard, then they will have to be dynamically 
inserted by the rendering algorithm, which as I am saying is very prone to 
error.

Do you see what i mean?

wassalaam
abdulhaq

On Saturday 12 June 2004 19:02, Thomas Milo wrote:
> Dear AbdulHaq,
>
> Our ACE does not deal with tajweed or ant aspect of text, it just renders
> the Unicodes. Therefore, you just spotted a typo. You are right in stating
> that the encoding must be utterly meticulous, to avoid any such
> representations of the real text.
>
> ACE does provide for automatic adjustment of the size of the fatha and
> fathatan where the underlying connection is stretched (madd, or keshideh).
> ACE also handles calligraphic alternatives when shaping of the skeleton.
>
> Kind regards,
>
> Thomas
>
> ----- Original Message -----
> From: "abdulhaq" <al-arabeyes at alinsyria dot fsnet dot co dot uk>
> To: "General Arabization Discussion" <general at arabeyes dot org>
> Sent: Saturday, June 12, 2004 7:47 PM
> Subject: Re: Quranic Proposal
>
>
> Dear Thomas
>
> I found the pdf of the results of the ACE engine very impressive indeed,
> particulary the way it provides variant renderings of the same ayat.
>
> I'd like to make just two points about the unicode issue and I hope you
> and Muhammad don't mind me making them as I feel they are important and
> relevant.
>
> 1) Dynamic changing of `alaamaat
>
> I noticed, in the last ayat of the pdf for instance (2:48), that the
> tajweed signs relating to the dammatayn were reversed between the two
> renderings of the ayat. In the first rendering the dammatayn over the word
> عدل is correct as this is pronounced, as I'm sure you know, with إخفاء
> i.e. for those who don't know tajweed, the sound of the nuun is blended
> into the sound of the waaw. However, in the second rendering we see the
> dammatayn that indicates إظهار i.e. the making clear of the the full
> pronounciation of the nuun. This is incorrect. There are similar mistakes
> relating to both the fathatayn and kasratayn.
>
> The reason I mention this is not to pick holes in ACE but to point out
> that the dynamic alteration of these glyphs in line with the rules of
> tajweed is prone to mistakes. This sub-point is also relevant to my second
> main point below.
>
> Another example of the difficulties of dynamic glyph creation in the area
> of tajweed is in the pronounciation of هاء الكناية such as you mentioned
> in an
>
> earlier email:
> >U+06E6 is not a contextual variation of U+06E7, but a word-final only
> >trailing small yaa' which is used to mark the long pronunciation of short
> >kasra of the pronominal suffix {-h} in cases where the preceding syllable
> >has a short vowel. To mark prolongation of the short damma in final
> >position under similar conditions, U+06E5 small waw is used in the same
> >manner
>
> While this rule is generally true, there are some exceptions for instance:
>
> سورة الزمر : 7 يرضه لكم
>
> there are three other exceptions in Hafs also, according to
> المفيد في علم التجويد, حياة علي الحسيني 1997
>
> and she is regarded as an expert in this science.
>
> My point being that if we leave the insertion of this glyph to a rendering
> algorithm then it will have to be able to recognise particular ayats of
> qur'aan! Surely this is asking too much?
>
>
> 2) Verification
>
> My second point is that in order to obtain official verification of the
> authenticity of the encoding of the qur'aan, the text will have to be
> certified by a scholar. However, how can we expect a scholar to certify an
> algorithm?
>
> I pray that you take this email in the spirit in which it is intended as I
> have the highest respect for the work you have done on ACE and also in
> other areas.
>
> wassalaam
> abdulhaq
>
> On Saturday 12 June 2004 15:12, Thomas Milo wrote:
> > Dear Mohammed,
> >
> > I accept your apology, let's get back to work and deal with the matter
> > point by point.
> >
> > As I feared, my first memo about this proposal was a but crude as it was
> > not set up as a diplomatic document. I have the impression it backfired
> > because of that.
> >
> > Mete, thanks for explaining my sudden appearance on this list. I am
> > seriously interested in designing coverage of the Qur'an in Unicode
> > terms, no more, no less.
> >
> > I propose to go through the list of missing characters and glyphs step
> > by step.
> >
> > I was inpressed by the quality of your proposal and the level of detail
> > that you address in it. I did give the proposal proper attention,
> > thought a bit more about it and came to the conclusion that, from all
> > the apparent defects in Unicode that this proposal enumerates, the
> > floating superscript alif is the only thing that is not covered by
> > either Unicode or font technology.
> >
> > I occurred to me that the desired visual behaviour of superscript alif
> > is analogous to that of floating hamza, like in which we are already
> > working on:
> >
> > Let me explain. For instance, word-initial stand-alone hamza as in Q2:61
> > /bi aayaati/ should be encoded بِءَایَـٰتِ with U+621 for stand-alone
> > hamza instead of the present work-around using U+654 بِــَٔایَـٰتِ .
> > This is necessary in order to maintain textual integrity and analogy
> > with Q2:99 /aayaati-m/ ءَایَـٰتِۢ. For this new contextual behaviour is
> > needed that will also resolve the problem with laam-hamza-alif that you
> > mention in your proposal: e.g., Q3:190 /la aayaati-n/ لَءَایَٰتِِ. As a
> > result the word /aayaat/ will have the same codes, regardles any
> > prefixes, just like /banaat/ بَنَات, /bi banaat/ بِبَنَات and /la
> > banaat/ لَبَنَات.
> >
> > As far as Unicode is concerned, earlier analysis already indicated that
> > a new hamza is necessary [a complication is that U+621 is already
> > solidly in use for Persian and other languages, that expect
> > non-connecting behaviour of isolatd hamza. Therefore a new floating
> > hamza character must be proposed] but the special behaviour of
> > superscript alif is totally predictable - it is triggered by preceding
> > fatha - and therefore remains in the domain of rendering. Both hamza and
> > superscript alif can get optional support by a calligraphic madda
> > (keshideh), this will produce the required effect as seen in the most
> > widely spread editions of the Qur'an.
> >
> > This analogy means that the projected new contextual behaviour for hamza
> > U+621 (or rather is proposed new replacement character) gets an
> > additional selling point for convincing rest of the industry. The issue
> > of hamza and superscript alif is a technical challenge for font
> > technology that falls outside the domain of Unicode. We are already
> > designing this new behaviour.
> >
> > t
> >
> > _______________________________________________
> > General mailing list
> > General at arabeyes dot org
> > http://lists.arabeyes.org/mailman/listinfo/general
>
> _______________________________________________
> General mailing list
> General at arabeyes dot org
> http://lists.arabeyes.org/mailman/listinfo/general
>
> _______________________________________________
> General mailing list
> General at arabeyes dot org
> http://lists.arabeyes.org/mailman/listinfo/general