# `import_fonts` Import edited fonts from a directory using a JSON manifest ## Usage > pdftl `` `import_fonts` `` `[manifest=]` `output` `` ## Details The `import_fonts` operation reads a JSON manifest (generated by [`export_fonts`]()) and overwrites the corresponding internal PDF font structures with the edited assets from a directory. It automatically handles: - Binary Font stream injection if MD5 hashes differ (safe skip on unmodified files). - Character metrics updates based on the 'width_sync_mode' parameter. - Re-compilation of sidecar ToUnicode JSON maps back to compliant PostScript CMaps. - /FontDescriptor property edits from the sidecar's `descriptor` block. - /CIDToGIDMap restoration, from either `"Identity"` or an explicit `.cid2gid.json` sidecar. - Type 3 glyph procedure reconstruction (including inline images) from a `.charprocs` file. If both `.json` and `.ps` files exist for a given font's /ToUnicode map, an error is raised to prevent ambiguity. The user must delete or rename one of them first. `encoding_cmap` edits are limited: the only supported change is switching a Type0 font's /Encoding between /Identity-H and /Identity-V. Any other value written into `encoding_cmap` is rejected with a warning, and /Encoding is left untouched — there is no general mechanism here for re-encoding into an arbitrary CMap. ### Width Sync Modes Each font's unified JSON sidecar (`font_{obj_id}_{gen_id}_{name}.json`) has a top-level `width_sync_mode` field, defaulting to `auto` on export. This controls how `import_fonts` reconciles the PDF's /Widths (or /W for CID fonts) with any edits: - `auto` (default): Reads the true metrics out of the edited font binary (if its MD5 changed since export) and writes those into the PDF. If the binary is unchanged or unreadable, falls back to `manual` behavior using any `width.pdf` values present in the sidecar mappings. - `manual`: Writes the `width.pdf` values from the sidecar mappings directly into the PDF, ignoring the font binary. - `patch_font_metrics`: Dynamically patches the font binary's horizontal metrics table in-memory to match the sidecar's `width.pdf` values, and writes the patched stream directly into the PDF (leaving workspace files untouched). - `squash_font_vectors`: Dynamically rescales the font binary's glyph outlines in-memory to visually fit the sidecar's `width.pdf` values, and writes the squashed stream directly into the PDF (leaving workspace files untouched). - `preserve`: Leaves the PDF's existing /Widths untouched entirely. `patch_font_metrics` and `squash_font_vectors` require the embedded font file to be present in the directory; without it, no width sync occurs for that font. For both of these modes, the in-memory binary edit is only ever best-effort: if it can't be applied (an unresolvable CID-to-GID mapping, no character codes in the font actually matched, or a malformed/unreadable font program), `import_fonts` still writes the sidecar's `width.pdf` values into /Widths or /W directly, so a requested width edit is never silently dropped even when the font program itself couldn't be patched. ### Format-Specific Limitations When employing `squash_font_vectors`, be advised that this mode relies on direct, affine coordinate scaling which is only structurally supported for TrueType outline representations (`glyf` tables). For OpenType-CFF (CFF/CFF2) and classic Adobe Type 1 fonts which do not possess a standard TrueType `glyf` table, the operation degrades silently to `patch_font_metrics` mode—meaning the font binary's internal character metrics will be updated correctly in-memory to prevent layout mismatches, but the visual glyph outline vectors will remain unscaled. ## Examples > Import edited fonts from 'my_fonts/' and save. ``` pdftl in.pdf import_fonts my_fonts output out.pdf ``` **Tags**: in_place, fonts, import, replace *Source: pdftl.operations.export_import_fonts* *Read online: [https://pdftl.readthedocs.io/en/stable/operations/import_fonts.html](https://pdftl.readthedocs.io/en/stable/operations/import_fonts.html)* *Type: Operation*