Re: Defined Private Use was: SSP default ignorable characters

From: Kenneth Whistler (kenw@sybase.com)
Date: Wed Apr 28 2004 - 19:04:47 EDT

  • Next message: smontagu@smontagu.org: "Re: New contribution"

    > >Oh? How does the existing PUA fail to support a picture font adequately?
    > >
    > >
    >
    > My point is that, according to what Ken has written, the PUA can be used
    > for a picture font only if not only the end users but also the software
    > developers have come to a specific agreement about that picture font and
    > the identity of each character in it.

    Nonsense.

    > He seemed to reject my suggestion
    > that developers might sensibly support the PUA apart from such specific
    > agreements with end users, by supporting default character properties
    > for each PUA character and allowing the glyph to be specified in the font.

    It is my understanding that that is precisely what most rendering systems
    do right now with PUA characters.

    What you *cannot* expect a generic system to do, for example, is
    support casing rules for a bicameral script that you have
    defined a bunch of characters for in PUA code points. For *that*
    kind of behavior, you have to have an "agreement" with the implementing
    software, because it represents behavior beyond the "default character
    properties for each PUA character". For *that* kind of behavior, you
    have to have one of the following:

       1. Implementation-provided API's that a user* can use to convey
          to the implementation behavioral requirements for particular
          characters in PUA space.
          
          *user: user of the implementation (which may or may not be
          an "end-user", depending on which level the implementation
          is externalizing the API)
          
       2. A standard protocol for conveying PUA character behavior,
          and an "agreement" by some piece of software to read a
          particular definition that you provide and to customize
          its behavior accordingly.
          
       3. Custom-written add-on software that builds PUA character
          behavior on top of what an implementation provides by default.

    The fact that attaining #1, #2, or #3 is difficult and/or expensive
    to do is why expecting some property-based solution for the PUA to
    automagically fix up PUA-based textual implementations is wrongheaded,
    in my opinion.

    > Agreed, but only if the PUA works in the kind of way which you and I
    > envisage. If it works as Ken envisages, which is very close to saying
    > that it doesn't work at all, you would be wrong to expect any support
    > for any of the properties you have listed, because applications should
    > not even try to support PUA characters of which they have no specific
    > knowledge.

    What seems to be repeated, deliberate misrepresentation of my
    position on this is getting rather tiresome.

    --Ken



    This archive was generated by hypermail 2.1.5 : Wed Apr 28 2004 - 19:33:53 EDT