XUID Arrays: One Less Thing To Worry About
By ESO/José Francisco Salgado (josefrancisco.org) — ALMA antennas under the Milky Way
Five years ago, I wrote this article that described how to manage XUID arrays. Then last year, I wrote this article that suggested that XUID arrays are no longer necessary.
Anyway, there are two messages that are being conveyed in today's article.
The first message is short and sweet, and meant to be strong:Adobe advises against including XUID arrays in all new and updated font-related resources, meaning fonts themselves and their corresponding CMap resources.The good news is that omitting the XUID array represents one less thing to worry about during font development.
The second message is longer, meant to provide some background information, and describes why Adobe advises against including XUID arrays in font-related resources.
In my world, which means the development of CID-keyed fonts and fonts based on them, XUID arrays have been included in the headers of CIDFont and CMap resources. For CID-keyed OpenType/CFF fonts, only the 'CFF ' (Compact Font Format) table can specify an XUID array. The XUID array that is specified in the source CMap resources that are used to built the 'cmap' table is ignored.
For those who are not aware, an XUID array is a PostScript Level 2 and later mechanism that is used for caching between print jobs, and is composed of a DeveloperID as its first element, with the second and subsequent elements being integer values of up to nine digits—values up to and including 9999999—that are assigned/managed by the font developer. Various font development resources have steered developers to Adobe's Font XUID Registration page for the purpose of registering a new DeveloperID. Adobe's DeveloperID is 1, which explains why the first element of the XUID arrays in Adobe's CIDFont and CMap resources is the integer value 1. The minimum number of elements is two, and while the PostScript Language Reference Manual states that the implementation limit is 16 elements, some environments support only up to four. In other words, XUID arrays should include two through four elements, and the first element must be the DeveloperID of the font developer.
XUID arrays came about because the original mechanism for uniquely identifying font resources for caching purposes, the UniqueID, simply ran out of space. Although the valid range for UniqueIDs, 0 to 16777215 (2²⁴ − 1), seems like a lot, huge blocks were provided to font developers, including font tool developers, to use at their own discretion, and each legacy composite font, such as those for Japanese, consumed over 1,000 UniqueIDs. My historical notes state that each Adobe-Japan1-2–based CID-keyed font consumed 1,100 UniqueIDs. CIDFont resources specify a UniqueID via the UIDBase value, and their associated CMap resources do so via the UIDOffset value. To learn more about UIDBase and UIDOffset values, see Adobe Tech Note #5014 (Adobe CMap and CIDFont Files Specification).
As a point of reference, Adobe stopped including UIDBase and UIDOffset values in new and updated CIDFont and CMap resources over ten years ago, and the Unicode CMap resources never included a UIDOffset value.
Also as a point of reference, Adobe stopped including XUID arrays in its non-CJK fonts years ago, and it is now time to do so for CJK fonts. I therefore encourage other CJK font developers to do the same.
To this end, I plan to take the DeveloperID registration site offline in the near future. (The DeveloperID administration site is already offline, which is part of the motivation for taking the associated registration site offline, and I am in the process of acquiring the DeveloperID database.) If you do not yet have a DeveloperID, please do not register one. As stated above, the sole purpose of the DeveloperID is to serve as the first element of an XUID array, whose use is no longer recommended. For those font developers who registered a DeveloperID, I also plan to set up a new and yet unnamed open source project under the adobe-type-tools organization on GitHub that will provide a static snapshot of the DeveloperID database for reference purposes. Once that is a set up, a subsequent article will introduce it.
Any comments or concerns about the above plans are welcome.
In closing, I'd like to state that the recommendation in this particular article is nothing new, and dates back over ten years to the following OpenType mailing list post from a former colleague of mine, Thomas Phinney:
- ·"Jesus Music" ad for Myrrh Records
- ·The Future of Sex poster
- ·Food Not Bombs hypothetical redesign
- ·Linotype Ad: "Linotype vs. Intertype"
- ·Fonts Design of Childhood Memory
- ·Cher Got Sued For Font!
- ·10 Top Romantic Fonts on Valentine's Day!
- ·Moving Hands (Helena Hauff Remix) by The Klinik, official video
- ·Alibaba Supports Font Infringement Complaints
- ·XUID Arrays: One Less Thing To Worry About
游客's review on Article 免费商用中文字体有哪些？注意下，新蒂字体已不能商用。
游客's review on Article 超强视觉冲击-3D字体设计作品超强视觉冲击
游客's review on Article 20个出色的艺术字体设计作品欣赏优秀作品展
游客's review on Article 全球第一家手书数字化平台-在线书写毛笔字生成TTF字体给你全世界智慧
馬塞客's review on Article 字体疑问？1.可能是版权问题故意的。（体验版） 2、可能是字库制作时疏忽bug。
游客's review on Article 自己动手用FontCreator修改字体简单教程因为这是日本的字体，所以缺字很正常，字型的编排也是按照日本教育部标准做的。