Re: Representative glyphs for combining kannada signs

From: Antoine Leca (
Date: Fri Mar 17 2006 - 04:30:56 CST

  • Next message: Asmus Freytag: "Re: Script L"

    Vinod Kumar wrote:
    > On 3/17/06, Antoine Leca <> 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

    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.


    > 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

    > Hopefully the standard will be corrected or improved.

    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...


    This archive was generated by hypermail 2.1.5 : Fri Mar 17 2006 - 04:37:29 CST