Re: Visarga, ardhavisarga and anusvara -- combining marks or not?

From: Asmus Freytag (
Date: Mon Sep 07 2009 - 18:28:43 CDT

  • Next message: Asmus Freytag: "Re: Request clarification on disunification based on different character properties"

    On 9/7/2009 3:07 PM, verdy_p wrote:
    > "Asmus Freytag"
    >> The second is the radical solution: reclassify every single
    >> character from Mc to Lo where there isn't any compelling
    >> reason (in rendering or processing) to consider that
    >> character actually "combining" in function, not just in name.
    >> The advantage of this approach is that it would be very
    >> visible and direct. Treating an "Lo" character by using the
    >> support for graphically combining characters in a
    >> renderer is obviously wrong, so you might expect a
    >> pressure on *all* implementations to get that corrected.
    >> The downside, of course, is that it's impossible to predict
    >> what uses the gc=Mc classification has been put to by
    >> actual implementations, outside of simple rendering issues.
    >> You are correct in calling such an approach destabilizing,
    >> no matter how appealing it would be, otherwise. For
    >> the same reason, UTC is correct to continue to be
    >> consistent with past practice in assigning Mc to any new
    >> characters that are analogues to existing Mc characters.
    > This solution would be much too radical.
    Thanks for agreeing with me on this.
    > But the main problem you'll have is that it would change how many other uses,...
    > My opinion is that this radical change is absolutely not needed. The standard just needs to say that gc=Mc
    > characters should be treated like gc=Lo for rendering, ...
    And having a character behave like an "Lo" does not preclude ligation
    and a number of other context-dependent rendering behavior appropriate
    for the character and the script. The biggest difference is that it
    doesn't imply that a base character, or worse, a specific base
    character, is required to be present.

    The latter assumptions built into some rendering engines, is what
    started this whole discussion.


    This archive was generated by hypermail 2.1.5 : Mon Sep 07 2009 - 18:31:11 CDT