From: Andreas Stötzner (as@signographie.de)
Date: Mon Jan 07 2008 - 06:20:17 CST
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
>> http://www.mufi.info/specs/MUFI-Alphabetic-2-0.pdf.
>> 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.
A:S
>
> 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
> http://www.ewellic.org
> http://www1.ietf.org/html.charters/ltru-charter.html
> http://www.alvestrand.no/mailman/listinfo/ietf-languages ˆ
>
>
This archive was generated by hypermail 2.1.5 : Mon Jan 07 2008 - 06:23:28 CST