Legacy Font Formats: Type 1, PFB, EOT, and DFONT

A legacy font format is one whose original vendor has ended support, whose host platform has been retired, or which has been superseded by a format that does everything it did and more. Legacy formats still open in some tools, they still sit in archives and asset folders, and they still turn up in old build scripts, but none of them is a safe delivery target today.

This page covers the four legacy formats that people actually still encounter: PostScript Type 1, PFB, EOT, and DFONT. Each gets a full section below with its history, technical specification, file structure, and migration route.

Two Families, Not Four Independent Formats

It helps to know how these formats relate to each other before reading about them individually:

• Type 1 and PFB are the same font family. A Type 1 font is a PostScript program. PFB (Printer Font Binary) is the binary container that program ships in on Windows and DOS, and PFA (Printer Font ASCII) is the ASCII variant used on Unix and classic Mac OS. If you have a .pfb file, you have a Type 1 font.
• EOT and DFONT are both wrappers. Neither one invents a new outline technology. EOT wraps an sfnt-based TrueType or OpenType font for Internet Explorer, and DFONT wraps one or more TrueType fonts in the data fork of a macOS file. Convert either one and you are simply unwrapping the font that was inside all along.

How to Recognise Legacy Font Files

• .pfb or .pfa plus a matching .pfm or .afm file: a PostScript Type 1 font and its metrics
• .eot next to .woff and .ttf in a fonts directory: an Internet Explorer fallback from an old @font-face stack
• .dfont in /System/Library/Fonts/ or an old Mac application bundle: a data fork suitcase
• .lwfn suitcases on classic Mac OS: the Mac packaging of Type 1 outlines

The four formats side by side. Read this first, then jump to the section for whichever format you are holding.

Technical Identifiers at a Glance

What PostScript Type 1 Is

PostScript Type 1 is a font format developed by Adobe Systems and introduced in 1984 as an integral component of the PostScript page description language. For nearly four decades it was the professional standard for digital typography, powering the desktop publishing revolution and defining print quality benchmarks worldwide. The format defines scalable, resolution-independent glyph outlines using cubic Bezier curves.

Unlike modern single-file formats, a Type 1 font is a set of companion files rather than one file:

• Outline files: PFB (Printer Font Binary) on Windows and DOS, or PFA (Printer Font ASCII) on Unix and classic Mac OS, containing the encrypted glyph program
• Metrics files: PFM (Printer Font Metrics) on Windows or AFM (Adobe Font Metrics) on Mac and Unix, carrying character widths and kerning pairs
• Installation files: INF files on Windows with font installation information
• Multiple Master (MM): an advanced variant shipped between 1991 and 1999 with interpolation axes, discontinued but a direct ancestor of variable fonts

Format History

Before PostScript, digital typography ran on fixed-size bitmap fonts that consumed enormous storage, scaled badly, differed per printer, and made true WYSIWYG impossible. Professional typesetting required dedicated systems such as Linotype machines costing well over one hundred thousand dollars. John Warnock and Charles Geschke developed PostScript at Xerox PARC as a device-independent page description language, and when Xerox declined to commercialise it, the pair founded Adobe Systems in December 1982 with PostScript as the flagship technology.

Type 1 emerged from Adobe's partnership with Apple on the LaserWriter. Apple licensed PostScript in 1984, and in March 1985 the LaserWriter shipped at 6,995 dollars with 35 built-in Type 1 fonts. Combined with Aldus PageMaker in July 1985, that trio replaced six-figure typesetting systems with desktop hardware and created the desktop publishing industry.

Technical Specifications

Type 1 defines glyph shapes using third-order (cubic) Bezier curves. Each segment has a start point, an end point, and two control points, which makes cubic curves more mathematically expressive than the quadratic curves TrueType uses. Fewer points are needed to describe a smooth, complex curve, which suits flowing letterforms and serifs particularly well, and the PostScript interpreter rasterises the result at the target device resolution.

Type 1 also carries PostScript hinting for low-resolution output: stem hints keep stroke widths consistent, alignment zones snap the baseline, x-height, cap height, and ascender or descender, blue values mark key vertical positions, flex hints handle curves that sit close to straight lines, and ghost hints control spacing invisibly. All of it is less sophisticated than TrueType's grid-fitting instructions, which is why Type 1 rendered worse on screen than in print.

Font File Structure

A Type 1 font is literally a PostScript program. Its dictionary declares the font properties, and the encrypted section that follows carries the glyph programs and the Private dictionary that holds the hinting data.

%!PS-AdobeFont-1.0: MyFont-Regular 001.000
%%CreationDate: 1990:12:15 12:00:00
%%VMusage: 25000 35000
11 dict begin
/FontInfo 10 dict dup begin
  /version (001.000) readonly def
  /FullName (My Font Regular) readonly def
  /FamilyName (My Font) readonly def
  /Weight (Regular) readonly def
  /ItalicAngle 0 def
  /isFixedPitch false def
  /UnderlinePosition -100 def
  /UnderlineThickness 50 def
  /Notice (Copyright 1990 Adobe Systems) readonly def
end readonly def
/FontName /MyFont-Regular def
/PaintType 0 def
/FontType 1 def
/FontMatrix [0.001 0 0 0.001 0 0] readonly def
/Encoding StandardEncoding def
/FontBBox {-180 -250 1000 850} readonly def
/UniqueID 4567890 def
currentdict end
currentfile eexec
[binary encrypted data follows...]
[512 zeros for cleartext padding]
...encrypted CharStrings and Private dict...
cleartomark

Features and Limitations

• 256 glyphs maximum: a hard constraint that forced multiple fonts for any comprehensive character set
• No Unicode support: platform-specific encodings created interoperability problems
• Multi-file dependency: outline and metrics files had to travel together
• Platform fragmentation: PFA plus AFM on Mac, PFB plus PFM on Windows
• Weak encryption: eexec offered minimal protection while complicating archival
• No web support: browsers never supported Type 1 at any point

Usage and Applications

Between 1985 and roughly 2010, Type 1 dominated book publishing, magazine production, newspaper prepress, commercial offset printing, corporate branding, advertising design, typesetting bureaus, and PostScript RIP workflows driving imagesetters and platesetters.

From 2010 to 2023 it survived in narrow niches: document archives that needed exact original rendering, print service bureaus supporting legacy customer files, specialised CAD, GIS, and engineering software, older PostScript RIP systems still in operation, foundry catalogues that were never converted, and government or academic archives with strict format preservation rules.

Today there is no active workflow where Type 1 belongs. Adobe Creative Cloud dropped it in 2023, macOS Big Sur and later make installation difficult or impossible, Windows 11 prioritises OpenType, browsers never supported it, and iOS and Android never did either.

Advantages and Disadvantages

Migrating from Type 1: Deprecation and Document Updates

Migration is no longer optional. Adobe ended Type 1 support across Creative Cloud in January 2023, so files that reference Type 1 fonts now open with missing-font warnings, or fail to open at all, in current versions of Photoshop, Illustrator, and InDesign. macOS and Windows are steadily reducing Type 1 compatibility as well. Moving your library to OpenType keeps archived projects editable and future-proofs the workflow.

A full migration has three phases. First, inventory your Type 1 files: look for .pfb and .pfm pairs on Windows, or .lwfn suitcases on macOS, and note which projects use each family. Second, convert or replace each font using the methods below. Third, and most easily missed, update existing documents so they stop pointing at the old fonts.

# Convert a single Type 1 font to OpenType CFF
fontforge -lang=ff -c 'Open($1); Reencode("unicode"); Generate($2);' myfont.pfb myfont.otf

# Python API, useful for batch work over a whole library
import fontforge
font = fontforge.open("myfont.pfb")
font.encoding = "unicode"
font.generate("myfont.otf", flags=("opentype",))
font.close()

Conversion Quality Checklist

• Verify outline integrity: compare converted glyphs against the original at several sizes
• Check metrics accuracy: test character widths, sidebearings, and vertical metrics
• Validate kerning pairs: confirm every pair transferred from the AFM or PFM
• Test character encoding: verify Unicode code point assignments
• Inspect hinting: check whether PostScript hints survived the conversion
• Review metadata: confirm name, version, and copyright strings
• Test in production: open real documents with the converted fonts before committing
• Validate licensing: confirm you hold conversion rights for each family

Tools and Resources

• FontLab: professional font editor with comprehensive Type 1 import
• Glyphs: Mac-native font editor with Type 1 support
• FontForge: free, open-source font editor for Windows, Mac, and Linux
• AFDKO: Adobe Font Development Kit for OpenType, free and command-line driven
• TransType: FontLab's batch font converter
• Windows font migration guide: moving legacy Windows font libraries to OpenType

PFB Compared With PFA

Both files carry identical outline data. The difference is purely how that data is encoded and which platform expected it.

Why PFB Needs a Paired Metrics File

The Type 1 architecture separates shape from spacing. The PFB or PFA holds the glyph outlines and hints. The PFM or AFM holds character widths, kerning pairs, and vertical metrics. Windows will not use the font without both, and losing the metrics file means losing every kerning pair the foundry ever set. This split is the single most common cause of broken legacy font installs, and it is exactly what OpenType eliminated by putting everything in one file.

PFB Segment Structure

A PFB file is a sequence of segments, each introduced by a two-byte marker. The alternating ASCII and binary segments are what make PFB a container rather than a plain PostScript file.

AFM Metrics File Structure

AFM files are plain text in a key-value format, which makes them easy to inspect and to diff when you are auditing a legacy library.

StartFontMetrics 4.1
Comment Generated by FontForge
FontName MyFont-Regular
FullName My Font Regular
FamilyName My Font
Weight Regular
ItalicAngle 0
IsFixedPitch false
UnderlinePosition -100
UnderlineThickness 50
Version 001.000
EncodingScheme AdobeStandardEncoding
CapHeight 700
XHeight 450
Ascender 800
Descender -200
StdHW 76
StdVW 88

StartCharMetrics 256
C 32 ; WX 250 ; N space ; B 0 0 0 0 ;
C 33 ; WX 333 ; N exclam ; B 130 0 241 700 ;
C 65 ; WX 667 ; N A ; B 14 0 654 700 ;
C 66 ; WX 667 ; N B ; B 90 0 610 700 ;
EndCharMetrics

StartKernPairs 150
KPX A V -50
KPX A W -40
KPX A Y -55
KPX V A -50
EndKernPairs

StartComposites 12
CC Aacute 2 ; PCC A 0 0 ; PCC acute 200 180 ;
EndComposites

EndFontMetrics

Working with PFB Files

The conversion route is the same one described in migrating from Type 1, with two PFB-specific points worth repeating:

• Always import the metrics file too. Open the PFB and its AFM or PFM together in the editor, otherwise the exported OTF will carry outlines with no kerning.
• Export as OpenType CFF, not TrueType. CFF keeps the original cubic Bezier curves, so the conversion is effectively lossless. Converting to TTF forces a quadratic approximation.

What Embedded OpenType Is

EOT (Embedded OpenType) is a Microsoft webfont container created in 1997 for Internet Explorer. It packages an existing TrueType or OpenType font with additional metadata that supported the early web embedding rules and helped align font distribution with the licensing expectations of that era. It is best understood as a legacy bridge format: it adds no typographic capability of its own, it simply made webfont delivery practical before cross-browser standards existed.

• Tied exclusively to Internet Explorer's webfont pipeline
• Wraps and references standard sfnt-based font data
• Historically paired with Microsoft server-side tooling such as WEFT
• Replaced by WOFF and then WOFF2 in every modern web stack

Format History

Before standardised webfont formats, authors were limited to system fonts and image-based text. Brand typography could not be guaranteed across user machines, non-Latin coverage was inconsistent, and designers resorted to raster text assets that hurt both accessibility and performance. Microsoft's answer was EOT.

Internet Explorer supported downloadable fonts far earlier than other engines. Rather than serving raw TTF or OTF, EOT provided an IE-recognised wrapper carrying embedding metadata aligned with font licensing flags, optional obfuscation-style mechanisms and origin-binding patterns, and a predictable server configuration for IE-only delivery.

Once WOFF 1.0 emerged as a vendor-neutral standard adopted by multiple browser engines, EOT's unique value collapsed. WOFF removed the need for IE-specific packaging, cross-browser delivery became the default expectation, and tooling and CDNs standardised on WOFF and later WOFF2.

Technical Specifications

• Underlying font: TrueType or OpenType, sfnt-based
• Container goal: Internet Explorer compatible web embedding
• Compression: lighter-weight historical approaches, far weaker than WOFF2 Brotli compression
• Metadata: embedding-related fields and IE-specific structures
• Scope: designed entirely around Internet Explorer's font pipeline

EOT does not change outlines or shaping rules. The browser still renders the same glyph data from the embedded sfnt font. The only real difference is that Internet Explorer expected the EOT wrapper to validate before it would load the font.

EOT File Structure

Tooling generates EOT from a TTF or OTF master rather than editing EOT directly, which is why recovering the original outlines from an EOT file is a straightforward unwrapping operation.

Embedding Model and Licensing Flags

EOT was shaped by licensing concerns that were unusually strong when webfonts were new. It aimed to provide a more controlled distribution path than serving raw font files: it aligned with the embedding permissions present in font metadata, encouraged domain-specific usage patterns in legacy IE deployments, and reflected a transitional era before shared webfont standards existed.

Advantages and Disadvantages

Working with EOT Files

If you are maintaining an old codebase, you will still find the IE-era @font-face pattern below. It is worth recognising so you can safely delete the EOT branches.

/* Old IE-compatible stack. Do not write new code like this. */
@font-face {
  font-family: 'BrandSans';
  src: url('/fonts/BrandSans.eot'); /* IE9 Compat Modes */
  src: url('/fonts/BrandSans.eot?#iefix') format('embedded-opentype'),
       url('/fonts/BrandSans.woff2') format('woff2'),
       url('/fonts/BrandSans.woff') format('woff');
  font-weight: 400;
  font-style: normal;
  font-display: swap;
}

@font-face {
  font-family: 'BrandSans';
  src: url('/fonts/BrandSans.woff2') format('woff2'),
       url('/fonts/BrandSans.woff') format('woff');
  font-weight: 400;
  font-style: normal;
  font-display: swap;
}

• Remove EOT sources from every @font-face rule
• Keep WOFF2 first and WOFF second for maximum coverage
• Drop the EOT generation step from the build so you stop shipping dead bytes
• If you only hold the EOT, convert it back to TTF or OTF to recover the original outlines, then regenerate WOFF2
• Check the browser compatibility guide for web fonts before changing any production font stack

What a Datafork Font Is

DFONT, the macOS Datafork Font, is Apple's 2001 way of packaging TrueType fonts. Classic Mac OS stored font resources in a file's resource fork. DFONT stores the same data in the data fork instead, so the file behaves like an ordinary file on the Unix-style filesystem underneath Mac OS X. That single change is the entire point of the format.

A DFONT is still fundamentally a TrueType font, or a collection of them, in a Mac-specific container:

• TrueType outlines, quadratic curves, stored in the data fork
• May hold one face or several related faces in a single suitcase
• A Mac-only wrapper, not natively recognised on Windows or Linux
• Used mainly for system and bundled UI fonts on early Mac OS X
• Deprecated in favour of TTF and OTF, or TTC where a collection is genuinely needed

Format History

Classic Mac OS used a dual-fork filesystem where every file could carry both a data fork and a resource fork. Font suitcases leaned on this heavily: outlines, metrics, and bitmap strikes lived in the resource fork, suitcases grouped Regular, Bold, and Italic together, and the Finder and Font Manager understood the structure natively. It worked well inside the Mac ecosystem and not at all outside it.

The technique was a repackaging exercise. Apple took the TrueType data that would have lived in a resource fork suitcase and moved it into the data fork with a structure that preserved suitcase-style grouping. Nothing was lost when copying across filesystems, standard Unix tools could handle the files, the Font Manager could still expose multiple faces from one file, and existing resource fork suitcases could be converted without losing information.

Technical Specifications

DFONT is not a separate outline technology. It holds standard TrueType data, so the same sfnt tables you would find in a .ttf file are present inside the suitcase.

File Structure and the Suitcase Concept

A suitcase font holds multiple related faces as a group. In DFONT the suitcase lives entirely in the data fork, each face is represented by a standard TrueType font inside the container, macOS Font Book exposes each face separately in the interface, and the file typically carries Mac type code and creator metadata.

Converting a DFONT to TTF means extracting the underlying sfnt data and saving it as standard .ttf files, one per face.

Typography Features and Limitations

DFONT introduces no typographic capability of its own. Any advanced features come from the TrueType or OpenType tables inside the suitcase, and many system DFONT files are relatively simple UI fonts with minimal feature sets.

Advantages and Disadvantages

Working with DFONT Files

On non-Mac platforms DFONT is usually not recognised as a font file at all and must be converted first. The standard workflow is to extract the DFONT from the old macOS installation or app bundle, convert it to TTF producing one .ttf per face, then optionally convert to OTF or WOFF2 for web and advanced pipelines. The macOS font migration guide covers the full toolchain.

# After converting DFONT to TTF:

# List the tables present
ttx -l MyLegacyFont.ttf

# Dump cmap and naming information
ttx -t cmap -t name MyLegacyFont.ttf

# Show which OpenType features survived
otfinfo -f MyLegacyFont.ttf

# Subset and emit a web-ready WOFF2
pyftsubset MyLegacyFont.ttf \
  --flavor=woff2 \
  --layout-features+=liga,kern \
  --unicodes="U+0020-007F" \
  --output-file="MyLegacyFont-web.woff2"

Every legacy format on this page has exactly one sensible destination for desktop use and one for the web. Find your source format in the table, then follow the workflow below it.

Migration Workflow

1. Inventory: list every legacy font file and which projects reference it. Include companion metrics files for anything Type 1 related.
2. Check the licence: confirm that conversion and, for web use, self-hosting are permitted. The font licence governs this, not the file format.
3. Prefer the vendor version: if the foundry sells an OpenType release of the same family, buy or claim it rather than converting. It will have proper feature support.
4. Convert what remains: use FontForge, FontLab, Glyphs, AFDKO, or the Font-Converters converter for straightforward jobs.
5. Verify: compare outlines, metrics, kerning, and encoding against the original before you trust the result.
6. Update documents and stylesheets: swap font references in templates, style guides, and @font-face rules. This is the step most migrations skip.
7. Archive the originals: keep the legacy files read-only for 6 to 12 months in case an old document must be reproduced exactly.

@font-face {
  font-family: 'BrandSans';
  src: url('/fonts/BrandSans.woff2') format('woff2'),
       url('/fonts/BrandSans.woff') format('woff');
  font-weight: 400;
  font-style: normal;
  font-display: swap;
}