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:
