Re: old Latin chars

From: Andreas Stötzner (
Date: Mon Jan 07 2008 - 06:20:17 CST

  • Next message: Michael Everson: "Re: old Latin chars"

    Am 07.01.2008 um 02:30 schrieb Doug Ewell:

    > Kent Karlsson <kent dot karlsson14 at comhem dot se> wrote:
    >> The document you refered to there in turn refers to
    >> That document unfortunately does not seem up to speed with Unicode,
    >> even though it (inaccurately) states "Compliant with the Unicode
    >> Standard version 5.0".
    >> For instance, it allocates to the PUA characters that are already
    >> encoded in non-PUA, albeit as combining sequences rather than single
    >> characters.
    > MUFI has a known preference for precomposed characters. See section 2
    > of the Introduction, where they acknowledge that "Unicode is very
    > unwilling to add more precomposed characters" and concede that all of
    > their precomposed letters can be represented by sequences, but then
    > continue:
    > "Smart Font technology is needed in order to display and print
    > decomposed characters properly. At the time of writing, this
    > technology is not yet fully mature, and there are also several
    > competing technologies, such as OpenType (Microsoft), Apple Advanced
    > Typography (Apple) and Graphite (Summer Institute of Linguistics).
    > For this reason, we believe that precomposed characters will be needed
    > for some time."

    MUFI’s preference for precomposed characters is simply due to practical
    life: with precomp. glyphs in suitable fonts you are on the safe side,
    with decomposed ones not.
    MUFI is, as might be well known, not alone with this policy; other
    major projects like TITUS do it on large scale the same way.
    As a result of this, of course, a real wild life within the PUA
    reservate flourishes, urging stakeholders to struggle for space sharing
    alliances and possibly defend their claims. The process is likely to
    end up with a couple of inofficial competing standards for the private
    block. The outcome of this ungoverned experiment within the jealously
    guarded halls of encoding will surely be worth considering.
    > Note that Uniscribe 1.042 and Doulos SIL under XP -- not necessarily
    > the epitome of "smart font technology" -- will render MUFI's example
    > <006F, 0328, 0301> perfectly.

    Having a composite character fixed as such in the font is always better
    than generating it via *any* application. Available encoding space for
    more and more composites is one question. But the mere generating
    operation is one another. It may become more easily, more safely in the
    future; in shall happen *within the font* and not outside it. Who ever
    built Polytonic Greek completely and controll it trough all four
    standard font cuts may know what I am talking about.
    > The front matter of the MUFI document says, "Many aspects of this
    > recommendation may be controversial, and more than one of the
    > contributors and advisors listed above may disagree with the
    > solutions." It's not clear whether providing PUA code points for
    > precomposed letters is one of those aspects.
    The use of the PUA for precomposed letters as such has been very little
    disputed among Mufers, as far as I know.


    > I don't mean to be a MUFI detractor in general; they have worked hard
    > to provide a solution for representing many as-yet unencoded letters.
    > I'm only addressing the issue with precomposed letters.
    > --
    > Doug Ewell * Fullerton, California, USA * RFC 4645 * UTN #14
    > ˆ

    This archive was generated by hypermail 2.1.5 : Mon Jan 07 2008 - 06:23:28 CST