Vadim Plessky <[EMAIL PROTECTED]> writes:
> On Sunday 24 March 2002 05:52, James A. Crippen wrote:
> | I recently heard from Ken Lunde at Adobe that new versions of the
> | official Adobe CMaps are being released, one by one. The UCS2 and
> | UTF8 CMaps are being replaced with a series of UTF{8,16,32}
> | automatically generated from UTF32 CMaps.
> |
> | Mr. Lunde has made mappings for Adobe-Japan2-0, Adobe-Korea1-2, and
> | Adobe-CNS1-4 CMaps available with the new UTF encodings. The others
> | will are forthcoming later this spring/summer.
> |
> | Also the Adobe-Japan1 CMap is being upgraded to Supplement 5, aka
> | Adobe-Japan1-5. This will "probably" include the additional
> | characters used in the Hiragino fonts distributed with Apple's MacOS X
> | 10.1, as well as other revisions. ISTR a figure like 5000 new glyphs
> | being added, but my memory might be incorrect. The additional glyphs
> | will include a large number of Unicode's Latin Extended-[AB], IPA
> | Extensions, Spacing Modifiers, Combining Diacriticals, etc, thus
> | bringing Adobe-Japan1 closer to being a complete Unicode mapping for
> | the Latin, Greek, and Russian alphabets, as well as serving the
> | needs of Japanese fonts and typesetting.
>
> So you suggest we should use Adobe-Japan1 encoding to render Russian
> glyphs?.. What's wrong with current AFII encoding?
No, no, no. JIS X 0208 has for a long time (20 years or so?) included
the basic Russian (not all Cyrillic, just Russian) and Greek
alphabets, mostly because there was lots of extra space at the time
the standard was developed so some enterprising standards author
decided that they'd be useful (or perhaps they're a carryover from
some other industry standard; I don't remember exactly).
Anyway, since the two alphabets have existed in Japanese character
sets for 20 years or more, their availability has come to be expected
by users. But they're not really useful for anything but the most
basic Russian or Greek, since for one the Russian isn't full Cyrillic
(including letters like those in Bulgarian, Serbian, etc), and for
another the Greek lacks diacritics. The idea is that the Adobe-Japan1
encoding with revision 5 will include *more* of the Cyrillic and Greek
alphabets that are available in Unicode, as well as IPA, Latin
Extended, etc. It will include many more characters in Unicode which
will improve conversion back and forth. It will also standardize many
characters which are currently available only in 'gaiji' form,
included in non-standard or semi-standard extension font sets from
various Japanese font foundries. Instead of users having to go
through lots of hoops to use these gaiji characters and instead of
having to use multiple fonts they will instead be available in a
single encoding.
This has nothing to do with Russian or Greek users. It just improves
the availability of such scripts in the world of Japanese font users,
particularly those involved in document design, desktop publishing,
typesetting, and similar endeavors (those that use PostScript
CID-keyed fonts).
Japanese CID-keyed fonts will probably tend to remain distributed in
Adobe-Japan1 encoding rather than switching to Unicode-based encodings
because Adobe-Japan1 includes *much* more glyphs needed for high
quality Japanese typesetting (eg, vertical forms, kanji ligatures,
ruby variants, etc). Many of these will never be included in Unicode
because they are considered to be 'presentation forms' that should be
handled by display and printing software rather than encoded
separately.
A prime example of 'presentation forms' unacceptable for Unicode
inclusion is that of ruby characters. These are variants of ordinary
glyphs (usually of hiragana and katakana characters) that have a
slightly heavier weight and sometimes a slightly shorter vertical
size. They are fine tuned for use at small point sizes, like 7 or 8
point, and are used in annotating kanji characters for uncommon
readings, or in educational materials where the reader is not expected
to know the reading of the kanji. As far as their actual letterform
is concerned, they are no different than their more ordinary
counterparts. Unicode would consider them to be a different font, not
uniquely encoded characters. But when considering quality typesetting
it is very useful to have ruby forms included in the same font they
are to be used with. So the Adobe-Japan1 encoding includes (or will
include, anyway) such variant forms.
Variant kanji (itaiji) are another issue. The Unicode developers wish
to encode only the minimum amount of kanji necessary for all
kanji-using languages and for round-trip conversion between other
established encodings. This means that many variant forms of kanji
are reduced to a single form to be included in the Unicode encoding.
However in many Japanese works, particularly historical ones and for
certain personal names, variant forms of some kanji are preferable to
their more common forms. Adobe-Japan1 (and Japan2) include some
variants that are not available in Unicode.
Why should any of this matter for XFree86? Because someday someone
will want to (and *should*) write an application that provides similar
functionality to Adobe's FrameMaker and PageMaker programs. These
will require support for PostScript/OTF CIDfonts in Adobe's Asian
encodings... And besides, many Asian fonts are of extremely high
quality (because of the huge amount of work necessary to develop
them), and supporting them fully and correctly is a great advantage to
Asian users.
Apologies for the long winded reply. I guess I kind of ranted, but I
felt that I needed to make the issue clear.
Further apologies for not making any progress on testing and
documenting the CID-keyed font support. I've been pretty distracted
lately and haven't been able to get back to it... Too many other
things have been pushed on my stack.
'james
--
James A. Crippen <[EMAIL PROTECTED]> ,-./-. Anchorage, Alaska,
Lambda Unlimited: Recursion 'R' Us | |/ | USA, 61.20939N, -149.767W
Y = \f.(\x.f(xx)) (\x.f(xx)) | |\ | Earth, Sol System,
Y(F) = F(Y(F)) \_,-_/ Milky Way.
_______________________________________________
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts
