Re: Regulating PUA.

From: vunzndi@vfemail.net
Date: Sun Jan 21 2007 - 19:09:53 CST

  • Next message: vunzndi@vfemail.net: "Re: Regulating PUA."

    I agree with Adam -- while it would have been acceptable to designate
    diffrent types of PUA at the time they were first established, to do
    so now would be going against the designation already given.

    It is not accurate to consider the PUA points as undefined, they are
    by designated as user defined. To change this to something else would
    be like for example taking the unicode block of Arabic characters and
    putting it somewhere else, then saying the original Arabic block code
    pionts, must be used for something else. those people who never use
    Arabic on their computer might not notice the difference, but the
    difference would still be there. Not redesignating codepoints, and
    especially large blockks is essential to long term compatability.

    PUA are also called "coperate use areas" so some coperate entity can
    decide to use these points any way they wish knowing that unicode will
    not use them for something else, Linux, and I presume Apple and
    Microsoft all do this extensvely, in this way all three are unicode
    compatable, though not mutally compatable.

    Of course unicode could suggest such uses for the at present un
    roadmap parts of unicode (basically planes 3-14), but nature the
    original PUAs should not be changed.

    Furthermore, some existing sets of PUA characters, being over 65536 in
    number, already cover plane 15 and part of plane 16. Some of us would
    be delighted if there was more PUA space.

    John Knightley

    Quoting Adam Twardoch <list.adam@twardoch.com>:

    > If you define part of the PUA as non-character PUA in future, what will
    > you do with applications and uses that currently use those PUA
    > codepoints for character purposes? Will these applications and the
    > existing documents suddenly become Unicode non-compliant?
    >
    > Many years ago, the Unicode consortium made a decision to declare a
    > certain part of the encoding space "private", which implies that the
    > consortium will not interfer with people?s use for this space. Now,
    > suddenly starting to retroactively regulate this space would make no
    > sense, and would go against the principle.
    >
    > A.
    >
    >
    > Ruszlan Gaszanov wrote:
    >> Unicode standard currently allows PUA (private use areas) for
    >> whatever anyone might want to use it. This tends to create
    >> problems, since, sometimes PUA code points are used for
    >> process-internal purposes and other times - for storing
    >> non-standardized character data. Because there is no way for users
    >> with a need to represent non-standardized character data to know
    >> which PUA code points some application might use for
    >> process-internal purposes and there is no way for an application
    >> designer which PUA code points someone might chose for encoding
    >> non-standard characters, this can various create issues.
    >>
    >> So, why don't we split the PUA into character-PUA (reserved for
    >> representing non-standard characters) and non-character-PUA
    >> (reserved for process-internal uses)? For instance, we define the
    >> ranges of BMP PUA, which are known to be used by popular
    >> applications and the entire Plane 16 as non-character PUA, while
    >> reserve the rest of BMP PUA along with Plane 15 for encoding
    >> private characters exclusively. This way there would be no more
    >> confusion.
    >>
    >> Also, if we define Plane 16 code points as reserved for
    >> process-internal use, we will no longer need to be able to
    >> interchange those code points, so future encodings schemes for that
    >> purpose could save an extra bit. Ruszlán
    >>
    >>
    >>
    >>
    >
    >
    > --
    >
    > Adam Twardoch
    > | Language Typography Unicode Fonts OpenType
    > | twardoch.com | silesian.com | fontlab.net

    -------------------------------------------------
    This message sent through Virus Free Email
    http://www.vfemail.net



    This archive was generated by hypermail 2.1.5 : Sun Jan 21 2007 - 19:11:47 CST