CID The
CID-keyed font (also known as
CID font,
CID-based font, short for
Character Identifier font) is a font structure, originally developed for
PostScript font formats, designed to address a large number of
glyphs. It was developed to support pictographic East Asian character sets, as these comprise many more characters than the Latin, Greek and Cyrillic writing systems. Adobe developed CID-keyed font formats to solve problems with the OCF/Type 0 format, for addressing complex Asian-language (
CJK) encoding and very large character sets. CID-keyed internals can be used with the
Type 1 font format for standard CID-keyed fonts, or
Type 2 for CID-keyed
OpenType fonts. CID-keyed fonts often reference "character collections," static glyph sets defined for different language coverage purposes. Although in principle any font maker may define character collections, Adobe's are the only ones in wide usage. Each character collection has an encoding which maps Character IDs to glyphs. Each member glyph in a character collection is identified by a unique character identifier (CID). Such CIDs are generally supplemental to other encodings or mappings such as
Unicode. Character collections are uniquely named by registry, ordering and supplement, such as "Adobe-Japan1-6." The registry is the developer (such as Adobe). The so-called "ordering" gives the purpose of the collection (for example, "Japan1"). The supplement number (such as 6) indicates incremental additions: for a given language, there may be multiple character collections of increasing size, each a superset of the last, using a higher supplement number. The Adobe-Japan1-0 collection is 8284 glyphs, while Adobe-Japan1-6 is 23,058 glyphs. CID-keyed fonts may be made without reference to a character collection by using an "identity" encoding, such as Identity-H (for horizontal writing) or Identity-V (for vertical). Such fonts may each have a unique character set, and in such cases the CID number of a glyph is not informative; generally the
Unicode encoding is used instead, potentially with supplemental information. CID-keyed fonts internally have their character sets divided into "rows," with the advantage that each row may have different global
hinting parameters applied. In theory it would be possible to make CID-keyed OpenType versions of western fonts. This would seem desirable for some such fonts because of the hinting advantages. However, according to Adobe, much of the software infrastructure (applications, drivers, operating systems) makes incorrect assumptions about CID-keyed fonts in ways that makes such fonts behave badly in real-world usage. Adobe
ClearScan technology (as from Acrobat 9 Pro) creates custom
Type1-CID fonts to match the visual appearance of a scanned document after optical character recognition (OCR). ClearScan does not replace the fonts with system fonts or substitute them by Type1-MM (as in Acrobat 8 and earlier versions), but uses these newly created custom fonts. The custom fonts are embedded in the PDF file (this is mandatory). In Acrobat DC, it is no longer called "ClearScan" but instead "Recognize Text - Editable Text & Images", and it is now possible to edit the text.
Compact Font Format Compact Font Format (CFF, also known as Type 2 or CFF/Type 2 font format) is a lossless compaction of the Type 1 format using Type 2 charstrings. It is designed to use less storage space than Type 1 fonts, by using operators with multiple arguments, various predefined default values, more efficient allotment of encoding values and shared subroutines within a FontSet (family of fonts). The so-called PostScript or Type 1 flavor of
OpenType fonts, also called OpenType CFF, contains glyph outlines and hints in a CFF table. CFF fonts can be embedded in
PDF files, starting with PDF version 1.2. It is the usual approach to representing a Type 1 font within PDF.
CID-keyed fonts can be represented within CFF with Type 2 charstrings for CID-keyed OpenType fonts. A Type 1 font can be losslessly converted into CFF/Type2 format and back.
Multiple Master Multiple master fonts (or
MM fonts) are an extension to
Adobe Systems'
Type 1 PostScript fonts. Multiple master fonts contain one or more
masters—that is, original font styles, e.g. a light, a regular and a bold version—and enable a user to interpolate these font styles along a continuous range of
axes. While Multiple Master fonts are not common in end user fonts anymore, they still play an important role when developing complex font families.
OpenType PostScript glyph data can be embedded in OpenType font files, but OpenType fonts are not limited to using PostScript outlines. PostScript outlines in OpenType fonts are encoded in the Type2 Compact Font Format (CFF).
OpenType conversion When Adobe converted PostScript Type 1 and Type 1 multiple master fonts to OpenType CFF format, they were made based on the last Type 1/MM versions from the Adobe Type Library fonts. In addition to file format change, there are other changes: • All alphabetic fonts had 17 additional characters included: the euro (some had already gotten this in Type 1), litre, estimated, and the 14 Mac "symbol substitution" characters. Symbol substitution was a scheme used on macOS to deal with the fact that the standard "ISO-Adobe" character set omitted certain characters which were part of the MacRoman character set. When one of these 14 characters was typed in a Type 1 font with standard encoding, both ATM and the printer driver would get a generic glyph in the Times style from the Symbol font. In the OpenType conversion, these characters were built into every font, getting some degree of font-specific treatment (weight and width). • Fonts that had unkerned accented characters had additional kerning to deal with accented characters. • Font families that included separate Type 1 expert fonts or Cyrillic fonts have these glyphs built into the "base font" in their OpenType counterparts. • Multiple master fonts were converted to individual OpenType fonts; each font consisting of a former Multiple Master instance. For many
Adobe Originals fonts, particularly those designed by
Robert Slimbach, Adobe did some degree of redesign along with the conversion to OpenType. The typeface Helvetica Narrow was not converted to OpenType, because the Type 1 original was a mathematically squished version of Helvetica, rather than an actually designed condensed typeface. This was originally done to conserve ROM space in PostScript printers. As a result of the above changes, Adobe no longer guarantees metric compatibility between Type 1 and OpenType fonts. However, Adobe claims the change is minimal for Adobe (not Adobe Originals) fonts, if: • Text is written in English • The formatted text contains only non-accented characters • Only characters that were present in the old fonts are used, without the former Symbol substitution characters • Applications are used which base line spacing solely on point size or leading, and not on the bounding box of the font
Original Composite Font Original Composite Font format (which uses a Type 0 file structure) was Adobe's first effort to implement a format for fonts with large character sets, debuted with
PostScript level 2. Adobe then developed the CID-keyed font file format which was designed to offer better performance and a more flexible architecture for addressing the complex Asian-language encoding and character set issues. Adobe does not document or support OCF font format. OCF font metrics are described in Adobe Composite Font Metrics file.
Adobe Font Metrics, Adobe Composite Font Metrics, Adobe Multiple Font Metrics Adobe Font Metrics (AFM),
Adobe Composite Font Metrics (ACFM),
Adobe Multiple Font Metrics (AMFM)
files contain general
font information and font metrics information for the font program. These files are generally used directly only in
Unix environments. An AFM file provides both global metrics for a font program and the metrics of each individual character. The metrics of a multiple master font are described by one AMFM file, which specifies the control data and global font information, plus one AFM file for each of the master designs in the font. An ACFM file provides information about the structure of a composite font. Specifically, the global metrics of the composite font program and the global metrics of each of its immediately descendent font programs. ACFM file does not associate with a base font, but act as the top-level structure of a composite font. The character metrics of individual characters in the composite font are described completely by one of more associated AFM files. The formats are sufficiently similar that a compliant parser can parse AFM, ACFM, and AMFM files.
Printer Font ASCII Printer Font ASCII (PFA) is a pure
ASCII version of a Type 1 font program, containing in particular a font's glyph data. It is pure
PostScript code without any sort of wrapper, and can be copied in full into a PS file to define the font to the PS interpreter. PFA is the preferred format for Type 1 fonts used in UNIX environments, and usually carries a ".PFA" file name extension. Though these files syntactically can contain arbitrary PostScript code, they usually follow a rather rigid formula in order to allow readers that are less than full PostScript interpreters to process them (for example to subset the font). The first section of the file is called the
clear text portion, and begins constructing those data structures that define the font in the PostScript interpreter; the information here are things Adobe in the 1980s were comfortable having public, and much of it would be present also in the companion AFM file. The last two operators in the clear text portion are currentfile eexec (encrypted exec), which instructs the interpreter to switch to reading the current file as an encrypted stream of instructions. The following encrypted portion is again PostScript code for finishing constructing the font data structures—a lot of it consists of charstrings, which is rather a kind of
bytecode, but at the font definition stage those are merely data stored in the font—even if that code is encrypted (which produces arbitrary byte values) and then hex-encoded to ensure the overall ASCII nature of the file. The data structures created here are marked noaccess to make them inaccessible for subsequent PostScript code. The final action in the encrypted portion is to switch back to reading the file normally, but since eexec would read ahead a bit it was impossible to know at exactly which character normal processing would resume. Therefore, PFA files end with a trailer of 512 zeroes followed by a cleartomark operator that throws away any operands that might have ended up on the stack as a result of interpreting those zeroes starting from a random position.
Printer Font Binary Printer Font Binary (PFB) is a binary PostScript
font format created by
Adobe Systems, usually carrying ".PFB" file name extension. It contains a font's glyph data. The PFB format is a lightweight wrapper to allow more compact storage of the data in a PFA file. The file consists of a number of blocks, each of which is marked as ASCII or binary. To recreate the corresponding PFA file, one takes the ASCII blocks verbatim and hex-encodes the binary blocks. The binary blocks are those which make up the encrypted portion of the font program.
LaserWriter Font LaserWriter Font (LWFN) is a binary PostScript
font format used on
Classic Mac OS, conceptually similar to the Printer Font Binary format but using the macOS
resource fork data structure rather than a custom wrapper for the font data. It contains the glyph data for one font. LWFN is the file
type code for this kind of file. It would not carry any extension, and the file name would be an abbreviation of the PostScript name of the font, according to a 5+3+3+... formula: the name is read as being in
CamelCase and split into subwords, up to 5 letters are kept from the first subword, and up to 3 letters of any subsequent subword. Palatino-BoldItalic would thus be found in the file PalatBolIta.
Printer Font Metric Printer Font Metric (PFM) is a binary version of AFM, usually carrying ".PFM" file name extension. It contains font metric information. The PFM format is documented in the Windows 3.1 "
Printers and Fonts Kit" help file (PFK31WH.HLP). Some details are also covered in the Windows 3.1 "
Device Drivers Adaptation Guide" help file (DDAG31WH.HLP). Both of those documents are part of the Windows 3.1 Device Development Kit (DDK), which is still available (October 2008) to MSDN subscribers.
.INF .inf (INFormation) files contain application-specific information in plain ASCII text, such as font menu names for Windows and DOS-based applications. When a font is installed in Windows, the ATM Installer software takes the AFM and the INF file as input and generates the required PFM file at installation time. The AFM and INF files are not installed in the user's system.
.MMM .MMM files are used for the metric data needed by multiple master fonts for the Windows environment.
.OFM .OFM is the extension used by
OS/2 for its version of binary font metrics file, starting from version 2.1. ==Support for Microsoft Windows==