Re: Proposing UTF-21/24

From: Asmus Freytag (
Date: Mon Jan 22 2007 - 13:42:44 CST

  • Next message: Ruszlan Gaszanov: "RE: Proposing UTF-21/24"

    The very real problem with introducing additional text formats is data loss.

    Even if data *can* be translated losslessly between formats, the fact
    is, there will be one point in the pipeline that's missing the
    definition of just the one format that data happens to be in.

    That was the reason why someone earlier in this discussion pointed out
    that there is a pressure for tools and applications to support *all*
    formats. Anytime a new format gets released into the wild it adds to
    that pressure.

    Implementation-internal formats may work in closed architectures, but
    what architecture is truly closed today? Therefore,
    implementation-internal formats are by-and-large transient. Which means,
    any benefit derived from their use is offset by the cost of converting
    into and out of them (and it's the application that has to pay that cost).

    However, you may state as a law, if you'd like, that the fascination of
    creating new encoding forms is about inversely proportional to their
    utility, and that would account for the fact that even though the
    addition of a new encoding form is a net *detriment* to the overall
    users of character encodings, the process seems to have a
    self-sustaining momentum.



    This archive was generated by hypermail 2.1.5 : Mon Jan 22 2007 - 13:44:46 CST