和文 中文
Dr. Ken Lunde
Approximately 7.5 years ago — at the end of 2002 — I commissioned the suite of Unicode CMap resources for Adobe-Japan1-x (it was Adobe-Japan1-5 at that time, and Adobe-Japan1-6 was finalized less than two years later), specifically for UTF-8, UTF-16, and UTF-32.
When I built these new Unicode CMap resources, one of the reasons was to add support for JIS X 0213:2000, which includes over 4,000 additional characters. I also considered adding the appropriate character code to CID mappings to the existing Shift-JIS and EUC-JP CMap resources, but chose not to do so, because I felt that Unicode had matured to the point that supporting these legacy encodings was not required. I still built the necessary tab-delimited tables so that I could easily and quickly add these mappings in case we received any requests to do, or if doing so became a product requirement.
Nearly eight years have passed, and in that time the use of Unicode has become even more widespread, along with the broad adoption of OpenType. Unicode is now considered the preferred way to handle text in digital form, and at least in Japan, OpenType has become the preferred font format. OpenType is closely tied to Unicode, which is a very good thing. The following is the number of requests that we received to add the JIS X 0213:2000 (which is now JIS X 0213:2004, by the way) mappings to the legacy Shift-JIS and EUC-JP CMap resources: zero.
What does this tell us?
First, this tells us that Unicode has matured, and at least in Japan, has successfully superseded the legacy encodings that have been in use, and that are still in use, which is why they are referred to as legacy encodings. Applications interoperate between these legacy encodings and Unicode, either directly or through the use of OS-supplied APIs, and act as the layer between the original text and the fonts that are used to render it. This layer is very important.
Second, considering the large number of OpenType Japanese fonts that have been released over the past decade, all of which embrace Unicode, it is clear that the format is a success.
In other words, Unicode and OpenType are clear successes.
The suite of Unicode — UTF-8, UTF-16, and UTF-32 — CMap resources intended for Japanese have gone through two major changes since their inception: 1) when Adobe-Japan1-6 was finalized in 2004, they were updated to include the additional mappings, mainly for JIS X 0212-1990 and U-PRESS, and it was at this time that the Adobe-Japan2-0 character collection and its CMap resources were decommissioned and their use deprecated, because all of its glyphs were now included in Adobe-Japan1-6; and 2) the JIS2004-savvy CMap resources were created, specifically UniJIS2004-UTF8-H, UniJIS2004-UTF16-H, and UniJIS2004-UTF32-H, along with their “-V” (vertical) counterparts.
I should also point out that it was in 2002 that the original UniJIS-UCS2-H and UniJIS-UCS2-V (this includes any CMap resource that includes “UniJIS” and “UCS2” in its name, meaning UniJIS-UCS2-HW-H, UniJIS-UCS2-HW-V, UniJISPro-UCS2-V, and UniJISPro-UCS2-HW-V) CMap resources were decommissioned, and their use deprecated in favor of the UniJIS-UTF16-H and UniJIS-UTF16-V CMap resources. The other UCS-2 CMap resources were decommissioned/deprecated at that time, and other than changing the license in the header, they have not been modified since that time, in terms of adding to or changing their character code to CID mappings. For building OpenType fonts, at least when using MakeOTF that is included in AFDKO, we recommend using the appropriate UTF-32 CMap resource, such as UniJIS-UTF32-H or UniJIS2004-UTF32-H for Japanese.
The current versions of our CMap resources can be found at our CMap Resources open source project.
Dr. Ken Lunde
Senior Computer Scientist, CJKV Type Development Adobe Systems Incorporated San, Jose, California
English 中文
7年半の経験の成果：UnicodeとOpenTypeの成功
Dr. Ken Lunde
Adobe-Japan1-x用のUTF-8、UTF-16、UTF-32を含むCMapリソース一式を作成し終えたのは2002年末、今から約7年半前のことでした。（当時は、まだAdobe-Japan1-5でしたが、それから2年以内にAdobe-Japan1-6も完成しました）。
その新しいUnicode用CMapリソースを作った理由の一つは、4,000以上の追加の文字を含むJIS X 2013:2000に対応するためです。それまであったShift-JISとEUC-JPのCMapリソースについても、文字コードからCIDへのマッピングを追加することを考えましたが、結局それはやめることにしました。Unicodeはその時点で十分整備されていたので、その旧来のマッピングは必要ないと考えたのです。ただ、もし要請があった場合とか、必要とする製品が出てきた場合に直ぐに対応できるようにと、必要となるタブ区切りのテーブルだけは用意しておくことにしたのです。
あれから8年近くたちました。Unicodeはさらに普及しOpenTypeも広く利用されるようになりました。その意味で、Unicodeは今やデジタル形式でテキストを取り扱うもっとも広く支持される方式になったと考えられます。OpenTypeがUnicodeと緊密に結びついていることは自体が良いことです。JIS X 0213:2000（現在はJIS X 0213:2004）用のマッピングを旧来のShift-JISとEUC-JPのCMapリソースに追加して欲しいという要望は、ゼロでした。
このことは何を意味しているのでしょうか？
まず、Unicodeが成熟したということ。そして、少なくとも日本においてUnicodeは、従来からずっと使われ続けたために「旧来のエンコーディング（legacy encodings）」と呼ばれるエンコーディングに取って代わるものになったということでしょう。アプリケーションソフトウェアは、そのような旧来のエンコーディングとUnicode相互の中間で動作します。直接的な方法を使う場合でもOSが提供するAPIを利用する場合でも、アプリケーションソフトウェアはオリジナルのテキスト情報とそれを表示するフォントとの中間層として機能していて、また非常に重要です。
過去10年間にわたってリリースされてきた日本語OpenTypeフォントの膨大な数、そのすべてがUnicode対応であることを考慮すれば、このフォント形式の成功ははっきりしています。
いいかえれば、UnicodeとOpenTypeとは明らかな成功だったといえます。
Unicode対応のCMapリソース：UTF-8, UTF-16, UTF-32（日本語用）に対して、これまで何回か大きな変更がなされてきました。1）Adobe-Japan1-6の2004年の開発は、主にJIS X 0212-1990とU-PRESS固有文字用にマッピングの追加を行うための改訂でした。ちょうどその当時、Adobe-Japan2-0文字コレクションとそのCMapリソースを廃止し、その全グリフがAdobe-Japan1-6に含まれるようになったことから、以後それらを利用しないことを推奨しました。2）JIS2004基準のCMapリソースを作成しました。具体的は、UniJIS2004-UTF8-H、UniJIS2004-UTF16-H、UniJIS2004-UTF32-Hおよびその縦組み用（”-V”）のものです。
また、2002年に元々のUniJIS-UCS2-HとUniJIS-UCS2-Vを廃止し（これには、”UniJIS”と”UCS2″を名前にもつすべてのCMapリソース、つまりUniJIS-UCS2-HW-H、UniJIS-UCS2-HW-V、UniJISPro-UCS2-VとUniJISPro-UCS2-HW-Vが含まれます）、以後それらを利用せず、むしろUniJIS-UTF16-HとUniJIS-UTF16-Vの利用を推奨したことにも触れる必要があります。その他のUCS-2のCMapリソースもその時に廃止し、以後は使用しないよう推奨しました。そして、ヘッダー中のライセンス条項に変更を行ったことを除けば、廃止されたCMapリソースに対しては、以後文字コードを追加したり文字コードからCIDへのマッピングを修正するというような意味での変更は一切行っていません。
OpenTypeフォントを作成するにあたって、特にAFDKO に含まれるMakeOTFを使われる場合には、適切なUTF-32 CMapリソース（例えば日本語用であれば、UniJIS-UTF32-HまたはUniJIS2004-UTF32-Hなど）をご利用ください。
CMapリソースの現在のバージョンンは、CMap Resourcesのオープンソースプロジェクトのページで参照可能になっています。
Dr. Ken Lunde
Senior Computer Scientist, CJKV Type Development Adobe Systems Incorporated San, Jose, California
English 和文
七年半的实践结论:Unicode和OpenType是成功的
Dr. Ken Lunde
大约七年半前,也就是2002年底,我（Ken Lunde）专门为UTF-8、UTF-16和UTF-32制作了一套Adobe-Japan1-x Unicode CMap 资源 (当时是Adobe-Japan1-5，在两年以内又完成了Adobe-Japan1-6)。
当时创建这些新Unicode CMap 资源时，其中一个原因是为了增加对JIS X 0213:2000新增4,000多个字符的支持，我也考虑过为已有的Shift-JIS和EUC-JP CMap 资源追加相应的字符编码与CID的对应关系，但最终选择不这么做，因为我觉得Unicode已趋成熟，不需要支持传统编码（legacy encoding）了。但我仍然创建了必要的制表符分隔表，如果我们收到任何请求或产品的需求，可以简单、快速地增加这些对应关系。
大约八年的时间过去了，在这期间随着OpenType的广泛采用，Unicode的使用也变得非常广泛。Unicode目前被认为是处理数字形式文本的首选方法，至少在日本，OpenType 已成为最受欢迎的字库格式，OpenType和Unicode紧密联系在一起是非常好的。我们收到向Shift-JIS 和 EUC-JP CMap 资源添加映射关系以兼容JIS X 0213:2000(现在是JIS X 0213:2004) 的请求是：零。
这说明了什么？
首先，这告诉我们Unicode已经完善，至少在日本，它已成功取代了过去使用的传统编码，并一直沿用至今。程序直接或通过操作系统提供的API在传统编码和Unicode中转换，扮演原始文本和字体显示之间的一个接口，这非常重要。
其次，在过去十年发布的大量OpenType日文字库，所有的字库都支持Unicode，显然该格式是成功的。
换句话而言，Unicode和OpenType的成功是显而易见的。
一套Unicode包含了UTF-8, UTF-16和UTF-32 ，从一开始日文CMap资源经历了两次重要的变化，1) 当Adobe-Japan1-6在2004年被完成时，更新内容包含了兼容JIS X 0212-1990 和 U-PRESS的新增映射，在那个时候，Adobe-Japan2-0 字符集和它的CMap 资源及其使用已经被淘汰和忽略，因为所有的字形都已被包含在Adobe-Japan1-6。2) 创建JIS2004-savvy CMap 资源，它们是UniJIS2004-UTF8-H, UniJIS2004-UTF16-H和UniJIS2004-UTF32-H, 以及相应的”-V” (vertical竖排)竖排CMap 资源。
我还要指出，在2002年，原始的UniJIS-UCS2-H 和 UniJIS-UCS2-V CMap资源（ 这包含任何名中含有”UniJIS” 和 “UCS2” 的CMap资源：UniJIS-UCS2-HW-H, UniJIS-UCS2-HW-V, UniJISPro-UCS2-V和UniJISPro-UCS2-HW-V） 已被淘汰，并且其在UniJIS-UTF16-H 和UniJIS-UTF16-V CMap 资源中的应用也被终止。在那时其它的UCS-2 CMap 资源也被淘汰或忽略，从那时开始除了更新这些CMap 资源头信息中的版权信息之外，在追加和改变编码和CID映射关系方面就没有再更新过。
对于创建OpenType字库，至少当使用AFDKO中MakeOTF时，我们建议使用恰当的UTF-32 CMap 资源来创建字库, 比如日文UniJIS-UTF32-H或UniJIS2004-UTF32-H 。
目前使用的最新CMap资源可以在CMap Resources开源项目中找到。
Dr. Ken Lunde
Senior Computer Scientist, CJKV Type Development Adobe Systems Incorporated San, Jose, California
Comments