Japanese Font Embedding and File-Size Optimization

Introduction

When you try to build an invoice or delivery note with pdf-lib, the first thing most people trip over is Japanese. Alphanumerics come out fine, but the moment you try to write "請求書" you hit an error — or the text disappears entirely. Ever run into that?

This isn't a bug; it comes down to how the PDF format itself is specified. This article explains why Japanese can't be output as-is, how to embed a font to fix it, and how to do so without making the file too heavy.

Why Japanese Can't Be Output As-Is

The standard fonts have no Japanese

PDF defines a set of "standard 14 fonts" that any viewer can display. But their contents are all Latin fonts like Helvetica and Times Roman. Not a single Japanese glyph is included.

pdf-lib assumes these standard fonts, so out of the box it can't render Japanese. The glyphs for characters like "あ" or "請" simply don't exist inside the PDF.

Embedding as the solution

So what do you do? The answer is simple: bundle the Japanese font file itself inside the PDF. This is called font embedding.

Once embedded, the PDF displays identically wherever it's opened — even if the recipient's PC has no Japanese fonts installed. For documents you deliver to others, this is a real source of peace of mind.

The Problem: Embedding Makes Files Heavy

Several MB of font ride along as-is

Embedding has a pitfall. Japanese fonts contain an enormous number of characters. Include hiragana, katakana, kanji, and symbols, and it's not unusual for the font file to reach several megabytes.

Embed that as-is, and a single invoice balloons into a several-megabyte file. Once you factor in email attachments and storage, that's a problem you can't ignore.

A document actually uses few characters

Here's where you flip the perspective. The Japanese that appears on an invoice really isn't much: "請求書" (invoice), "御中" (a formal honorific), "合計" (total), "消費税" (consumption tax), plus the customer name and product names.

Out of the thousands of characters in a Japanese font, a single document uses maybe a few dozen to a few hundred. Embedding characters you'll never use is plainly wasteful.

Slimming Down with Subsetting

Extract only the characters you use

This is where subsetting comes in. It's a technique that extracts and embeds only "the glyphs you actually use" from a font.

With pdf-lib, combining fontkit and enabling subsetting at embed time turns on this optimization. The appearance is exactly the same as the full set — only the size shrinks. It's a best-of-both-worlds technique.

The payoff and a practical caveat

The effect of subsetting is dramatic. It's common for a several-megabyte PDF to drop below a few hundred kilobytes. In an import wholesale operation handling documents in bulk, this difference feeds directly into storage cost and manageability.

One caveat. Because subsetting narrows the glyphs down based on "the characters used at generation time," it doesn't suit cases where you later edit the PDF's text into different characters. But since a document is finalized once generated, this hardly ever became an issue in practice.

Conclusion

Font embedding — the hardest part of Japanese PDFs — becomes clear once you frame it as a flow: "the standard fonts have no Japanese → so embed one → but it's heavy → slim it down with subsetting."

• The standard fonts contain no Japanese glyphs
• Displaying independent of the recipient's environment requires embedding a font
• Full-set embedding makes files heavy
• Subsetting embeds "only the characters you use," slimming the file dramatically while keeping the appearance identical

Only with this technique does code-based document generation become practical. For the big picture, see Automated Invoice & Delivery-Note PDFs, and for managing the company info poured into documents, see Managing Sender and Recipient Profile Masters.