Re: Quranic Proposal - Rendering engines implementing Unicode

[Mete Kural <metekural at yahoo dot com>]

Salaam Nadim,

> > I agree with the phased approach, but we need to
> agree on the phases. If
> > your operating systems cannot handle fonts the way
> it is assumed by the
> > Unicode Standard, than I would agree with you that
> you need to opt for
> > kludges.
> > 
> > Just count me out.
> 
> I still don't get your reply or both
> statements/paragraphs above 

I think what Tom is trying to say here (sorry for
paraphrasing on your behalf Tom - I wasn't patient
enough) is that "if the proposed definitions for
substituting two standard harakat codes with a single
glyph (such as fatha+[the_proposed_new_tanween_code]
code sequence being defined as a sequential fathatan)
and other similar cases where a more proper way to
handle script rendering is 'added to Unicode' but then
rendering engines fail to implement Unicode properly
by not implementing these new additions to Unicode
(whether because it is more challenging to implement
or they just don't want to spend the effort to
implement it because they think it's not important for
them to support classical/Quranic Arabic, even if it
is now part of Unicode), then I am not interested in
taking part in participating in yet another set of
hacks instead of a more proper way simply because
there are already numerous hacks out there and I am
sick of them."

The changes that Tom is proposing would (if accepted)
become part of the Unicode specification. For example
the definition of fatha-[the_new_proposed_code] code
sequence being canonically equivalent to a sequential
fathatan would be part of the Unicode standard. There
are already definitions of canonically equivalent code
sequences in Unicode. An example is yeh+hamza_above
being canonically equivalent to yeh_with_hamza_above.
Rendering engines that claim that they support Unicode
"should" implement this feature of Unicode. If they
don't have the expertise to implement it or they are
unwilling to implement it they should at least allow
others to provide patches for implementing this
feature (of course this only applies to open source)
and not prevent the proper implementation of the
Unicode specification. This is because implementing
these features would not just be providing support for
classical/Quranic Arabic that they don't really care
too much about but it would also be implementing the
Unicode speficication in its entirety. Let's say the
above described feature (a new logical tanween
codepoint that triggers the rendering of contexual
tanween variants) gets added to Unicode 4.0.3 and a
rendering engine wants to support Unicode 4.0.3, then
they have to implement this feature, otherwise they
are not right in saying that they support Unicode
4.0.3.

So basically what Tom is saying (and I agree too) is
that if rendering engines will not support the
entirety of a new Unicode specification release
because of whatever reason, I don't want to work out
yet another set of hacks.

Sorry again Tom for paraphrasing for you. Please
confirm whether I represented what you tried to say
properly.

Kind regards,
Mete