PDF Type 1 Font

Type 1 is Adobe's original outline font format, defined in the PostScript Language Reference Manual and used extensively in PDF 1.x documents. Type 1 fonts use cubic Bézier curves for glyph outlines and may be embedded as font programs in the /FontFile stream. They have been largely superseded by TrueType and OpenType but remain common in legacy PDFs and professional print workflows.

PDF Type 1 fonts are the original font format defined by Adobe for PostScript and adopted as one of the core PDF font types. Type 1 uses cubic Bézier curves (the same as PostScript paths) to describe glyph outlines, with a compact binary encoding optimised for PostScript rendering. Though largely superseded by OpenType and TrueType in modern workflows, Type 1 fonts remain prevalent in legacy PDFs, academic publishing (LaTeX), and archival documents.

Type 1 fonts are "simple fonts" in PDF terminology — they use single-byte character codes (0–255) and map codes to glyph names via a font encoding. This limits them to at most 256 distinct characters per font instance, requiring separate font faces for extended character sets.

Type 1 font structure in PDF

A Type 1 font dictionary in PDF contains:

<strong>/Subtype /Type1</strong> — Identifies the font type. <strong>/BaseFont</strong> — The PostScript name of the font (e.g., /Helvetica, /Times-Roman, /Courier). <strong>/Encoding</strong> — Either a predefined encoding name (/WinAnsiEncoding, /MacRomanEncoding, /StandardEncoding) or a differences array that modifies a base encoding. The encoding maps byte values (0–255) to glyph names. <strong>/Widths</strong> — An array of character widths (in glyph space units, 1/1000 of the font unit) for character codes from /FirstChar to /LastChar. Used for text layout calculations. <strong>/FontDescriptor</strong> — A font descriptor dictionary with font metrics (ascent, descent, cap height, stem widths, bounding box, flags) and the /FontFile stream. <strong>/FontFile</strong> — The embedded Type 1 font program. A Type 1 font consists of two segments: the ASCII portion (plain text PostScript code defining font metadata and procedures) and the encrypted binary portion (the charstrings — the glyph outline descriptions in a compact, encrypted format called the charstring language).

The 14 standard PDF fonts (Helvetica, Times, Courier, Symbol, ZapfDingbats and their variants) are Type 1 fonts that PDF viewers are required to have built-in. They do not need to be embedded — a PDF can reference them by name and rely on the viewer to supply them.

Type 1 charstrings and rendering

Type 1 glyph outlines are described in the charstring language — a stack-based language that encodes Bézier curve segments, line segments, and control commands as a compact sequence of bytes. Type 1 charstrings use cubic Bézier curves (as do PostScript paths), with commands like:

<code>rmoveto</code> — move the current point <code>rlineto</code> — draw a straight line <code>rrcurveto</code> — draw a cubic Bézier curve <code>endchar</code> — end the glyph definition <code>seac</code> — build an accented character from two base characters (a Type 1-specific compositing mechanism) <code>callsubr</code> — call a subroutine (Type 1 uses subroutines to share common outline segments across glyphs)

The charstring program for each glyph is stored in the font's CharStrings dictionary, indexed by glyph name (e.g., /A, /ampersand, /uni0041). This glyph name indexing is why Type 1 fonts require an encoding that maps character codes to glyph names — the rendering engine looks up the glyph name from the encoding, then finds the glyph outline in CharStrings.

<strong>Type 1 encryption</strong> — The binary portion of a Type 1 font (the charstrings) is encrypted using a simple linear feedback shift register algorithm. This was Adobe's original attempt to protect font IP, but the algorithm was quickly reversed and is now publicly documented in the <a href="https://adobe-type-tools.github.io/font-tech-notes/pdfs/T1_SPEC.pdf" target="_blank" rel="noopener">Type 1 Font Format specification</a>.

Type 1 in LaTeX and academic publishing

Type 1 fonts remain the dominant font format in academic publishing because LaTeX's default font stack (Computer Modern, Latin Modern, KOMA-Script fonts) was designed as Type 1. LaTeX's <code>pdflatex</code> engine embeds Type 1 fonts in its PDF output. This means most academic PDFs from physics, mathematics, and computer science journals contain Type 1 fonts.

The transition to OpenType in LaTeX is gradual: <code>lualatex</code> and <code>xelatex</code> engines support OpenType natively, and OpenType versions of Latin Modern are available. But enormous archives of legacy academic PDFs contain Type 1 fonts, so PDF processors must continue to support them.

<strong>Type 1 limitations for modern Unicode</strong> — Because Type 1 fonts are limited to 256 characters per instance, LaTeX workflows that need accented characters or broader Unicode coverage must either use encoding tricks (like T1 encoding, which rearranges the 256-character space to include more European characters) or use separate font instances for different character ranges. This is handled transparently by LaTeX's font encoding system, but it produces PDFs with multiple embedded Type 1 font instances for a single typeface. See <a href="/glossary/pdf-cmap" target="_blank" rel="noopener">PDF CMap</a> for how ToUnicode CMaps handle text extraction for these fonts.

Frequently asked questions

What are the 14 standard PDF Type 1 fonts?

The 14 standard PDF fonts are: Times-Roman, Times-Bold, Times-Italic, Times-BoldItalic; Helvetica, Helvetica-Bold, Helvetica-Oblique, Helvetica-BoldOblique; Courier, Courier-Bold, Courier-Oblique, Courier-BoldOblique; Symbol; ZapfDingbats. PDF viewers are required to have these fonts built-in (or metric-compatible substitutes), so PDFs can reference them without embedding. In practice, viewer implementations use substitutes (often URW fonts in open-source viewers, or system fonts in commercial viewers), which can cause subtle rendering differences. For consistent appearance, modern best practice is to embed all fonts rather than relying on the standard 14.

Should I embed Type 1 fonts in PDF documents?

Yes, for any PDF intended for distribution or archiving. Without embedding, the PDF relies on the viewer having the font available, which may not be the case — particularly for non-standard Type 1 fonts or when viewing on systems without the font installed. PDF/A requires font embedding as an absolute requirement. Even for the standard 14 fonts, embedding ensures consistent metrics and avoids the subtle rendering variations introduced by viewer substitutes. Modern PDF export workflows embed all fonts by default. Only un-embedded Type 1 fonts in legacy documents created before embedding was standard practice are commonly encountered.

How do Type 1 fonts differ from Type 3 fonts in PDF?

Type 3 fonts (the /Subtype /Type3 in a font dictionary) are PDF-defined fonts where each glyph is defined by an arbitrary PDF content stream — not a compact charstring program. A Type 3 glyph definition can include any PDF graphics operations: paths, images, shading, colour changes. This makes Type 3 fonts extremely flexible (they can represent full-colour glyphs, for example) but also means they are not portable in the same way as Type 1 or TrueType fonts — they are essentially inline glyph definitions tied to the document. Type 3 fonts cannot be reliably subset-embedded for reuse, and many PDF processors have limited or broken Type 3 support. They are generally avoided in modern PDFs except for specialised use cases like colour emoji rendering in legacy workflows.