I've been writing a PPTX exporter, and I wanted the font to travel with the file. When the person opening it doesn't have the font installed, the text falls back to some default and the line breaks drift.
PPTX can carry fonts. The part is called a fntdata file, and from the spec and a few open source implementations I pieced together that it should be an EOT wrapper (Embedded OpenType) around the TTF. Before writing any real code I ran one slide through four variants to see which one the renderer would honor.
The setup: one chart slide that uses VT323, a font I did not have installed on this computer. I rendered each variant to PDF with LibreOffice 26.8.0.3 and ran pdffonts to see which font actually got drawn.
| What I put in the file | Font in the PDF |
|---|---|
| Nothing | Fallback fonts (FrankRuhlHofshi-Bold, LinuxLibertineG) |
EOT with Flags 0, plus embedTrueTypeFonts="1" on the presentation |
VT323-Regular |
The raw TTF as the fntdata, plus embedTrueTypeFonts="1"
|
Fallback, silently ignored |
EOT with Flags 0, no embedTrueTypeFonts attribute |
Fallback, silently ignored |
Only the second row worked, the one where both pieces were present. In the other two attempts the text fell back to a substitute font, the same outcome as embedding nothing at all.
The same slide, converted to PDF by LibreOffice 26.8.0.3. Top: nothing embedded. Bottom: EOT with Flags 0 plus embedTrueTypeFonts="1".
A few details that cost me time:
- The EOT header is the version 0x00020002 layout from the W3C submission. Flags 0 means no MicroType Express compression and no XOR. I couldn't find a public compressor for MicroType Express, so uncompressed it is.
- LibreOffice's own PPTX export writes the same thing (EOT, Flags 0, TTF appended as is), and it also writes
embedTrueTypeFonts="1". Its import code only reads the embedded font list when that attribute is true, and always treats the data as EOT. That matches what the table shows. - I opened a real fntdata from Apache POI's test data. Its header says Flags 0x5, which is subset plus compressed, so whatever Office writes is not what I'm writing. I can't prove that file came from PowerPoint itself, so I'm only using it as a header reference.
- Variable fonts need care. I pinned the weight to make a static instance, then rewrote the name table so the family name in the font, the family name in the EOT header and the
typefaceattribute all matched.
On size, the font is the expensive part. Pretendard Regular after deflate, which is roughly what the zip does to it:
| Characters kept | Size |
|---|---|
| Whole font | 1,117,566 bytes |
| All 11,172 Hangul syllables plus ASCII and Latin-1 | 931,592 bytes |
| The 2,350 common Hangul syllables plus ASCII and Latin-1 | 233,993 bytes |
| Only the 30 characters used on the slide | 4,619 bytes |
I went with the 2,350 set. On a test over 41 themes with 177 layouts each, the subset lost zero characters out of 64,465 (font, character) pairs. The catch is that if the recipient types a syllable outside those 2,350, only that character falls back to the default font. Microsoft's documentation says the same about subset embedding, that it limits editing.
Here is what I did not check. I don't have PowerPoint on this computer, so everything above is LibreOffice behavior. I don't know whether PowerPoint accepts an uncompressed EOT. Comments in one open source project say a raw TTF makes Windows PowerPoint fall back to Calibri, and the same comments mention PowerPoint rejecting a whole file as corrupt after an XOR obfuscation attempt on a font part. Those are their observations, not mine, so I'm keeping the feature off by default until someone opens the file in PowerPoint on a machine without the font. Keynote and PowerPoint for the web are also untested.
If you've opened an uncompressed (Flags 0) EOT fntdata in Windows or Mac PowerPoint on a machine without the font, did it load the font, or did it quietly fall back?
This post was written with AI assistance and checked by me against my experiment notes.
