From: Antoine Leca (Antoine10646@leca-marti.org)
Date: Fri Mar 17 2006 - 04:30:56 CST
Vinod Kumar wrote:
> On 3/17/06, Antoine Leca <Antoine10646@leca-marti.org> wrote:
>
>> I never considered TUS as the ultimate truth in the matter of Indic
>> scripts, but accepting this...
>>
>> Of course, if font designers ONLY base thir work on TUS, the result
>> is unlikely to be of ultimate quality.
>> However, I do no believe this is common behaviour.
>>
> My take on this is:
>
> TUS should be an outcome of the linguistic and script specific
> knowledge.
Fully agreed. An outcome.
Not the central pivot of the human knowledge on the matter (as would be
presented in a resumed way in an encyclodepia).
> All questions, fights and solutions should be in the standard
> formation phase.
Well, things are not THAT easy.
> The font and software designer or implementor should work on
> the basis of the standard alone
I disagree. Again, the Standard is not, and cannot be, the only and ultimate
source of information for a font designer, it should learn from other ways
how the script is written, what are the most frequent combinations (to fit
the glyph advances and kernings) and similar things. Since, depending the
level of information you are digging, you can end up with a fairly thick
book for ANY book, it is vain to ask for the sum of all this information to
be present in The Unicode Standard.
Furthermore, I do not believe such informations belong to the Unicode
Standard. In fact, the mere basic rules for the behaviour of the scripts
(such as ligature formation or not) were initially envisionned as out of
scope. It seems that things vary a bit here, perhaps under the influence of
the appendix about Nagari and Tamil as presented in the 2nd book of 1.0. The
real mistake is that people ask this appendix (which initially described the
most basic rules to show how complex the rendering process could be) to be
_exact_ *and* _exhaustive_. Both objectives are far out of scope for a
Standard (as they both have debatable points), and furthermore goes to a
level of detail that delays necesarily the formation of any Standard.
> and not raise questions about lingusitic and script issues when
> designing the font or software.
Agreed in principle. But when you apply it to the current situation, it just
shows that Indic scripts rendering is a moving target (of course, this is
hardly surprising), so software designers should be prepared to update their
products to adapt to the evolution of the matter.
> If a font or software designer has reservations about the standard,
> she can raise them in the standards development process.
Yes. But see below about how to do that.
> But a font or software designer who (blindly) follows the
> standard cannot be accused of doing a wrong thing.
Unless she does NOT take to time to actually read it.
If she does read The Unicode Standard, she will notice that TUS does not
cater about rendering. It is explained in plain English on page 5 in the
introduction.
When it comes about Indic scripts rendering, there is another (industrial)
"Standard" which is much more relevant, it is the Open Type specifications.
Unfortunately, this Standard is presently in development stage, and the
draft available are not up-to-date. However, any half-serious font
developper for Indic scripts is considering the available material and
tools, and do their best to circumvent the present lacunaes.
Furthermore, here is perhaps not the most appropriate place to beg the
developpers of this Standard for their mistakes.
> The wrongs, if any, belong to the standardization process.
Sure.
> I also feel that the
> software (font) designer should exercise her script specific expertize
> and implement correct behaviour even if the standard says otherwise.
> She breaks the standard but accepts that the software is not standard
> compliant and defends her action.
Yes, I agree. Kind to you to have added it, it is worthwhile to never forget
that.
> Hopefully the standard will be corrected or improved.
Sometimes.
Sometimes else the official Standard stands as it is is (for various
reason), and developpers have to learn they have to fulfill the official,
normative, Standard (for conformance), and also to fulfill the existing
protocols for interoperability (those later are considered /de facto
standards/, with small "s" here, when they become formalized).
An example of this are Ethernet frames: the official standard (IEEE 802.3)
says something which is pretty theorical, and everybody is using another
format (former DIX "standard" a.k.a. Ethernet II), which is of course
interoperable. If you design a device only looking after the official
published standard, it is worth nothing...
Antoine
This archive was generated by hypermail 2.1.5 : Fri Mar 17 2006 - 04:37:29 CST