• Font
  • Family
  • Foundry
  • Designer
  • Sample
  • Article
  • Help

The results from a 7.5-year experiment are in: Unicode and OpenType are successes!

Date:2010-04-13 15:39:46| Standard|Browse: 101|Source: Adobe Blogs|Author: Hua Gu
  • Follow FontKe on Wechat to get Zcode
  • Scan the Qrcode to participate in the SVIP lottery
Introduction和文 中文Dr. Ken LundeApproximately 7.5 years ago — at the end of 200

和文 中文

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 中文


Dr. Ken Lunde


その新しい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を利用する場合でも、アプリケーションソフトウェアはオリジナルのテキスト情報とそれを表示するフォントとの中間層として機能していて、また非常に重要です。



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")のものです。


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 和文


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包含了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

  • Follow FontKe on Wechat to get Zcode
  • Scan the Qrcode to participate in the SVIP lottery
Relevant font designer
Relevant font foundry
The results from a 7.5-year experiment are in: Unicode and OpenType are successes! Comments
Guest Please obey the rules of this website. Unclear?
The results from a 7.5-year experiment are in: Unicode and OpenType are successes! Latest comments
No relevant comments
Recommended comments