I converted a 4-page brochure PDF to HTML and the headline font survived while the body text came out in something else. Same page, same words, different typeface. A font license flag such as fsType is one possible explanation, but in this file it was not the cause, and the real one was easy to check.
What I converted
The sample is a public brochure from the Wikimedia Commons file "Evaluating Wikipedia" (Wiki Education Foundation and others, CC BY-SA 3.0). I cut the first 4 pages out of the 8-page original, which came to 1,180,300 bytes. Everything below is from this one file, on my M4 Mac, run once, in Chromium 149.
For the conversion I used ImgIng (https://imging.ai/), which runs in a desktop browser, is labelled Beta, and processes the file locally. After it finished, the headings still looked like the PDF. The body paragraphs did not.
Where the font went
The result panel told me about it. It listed a font substitution for pages 2 to 4, and a second line saying the PDF carries a font stream the browser cannot use directly, so a safe replacement was used. I am paraphrasing here, because the panel is in Chinese.
In the HTML, 509 text elements were set in Arial, sans-serif. The body face in the PDF was a serif, so the change was easy to see once I looked for it.
Listing the fonts inside the PDF
To see what the source actually contained, I listed the embedded fonts with PyMuPDF and read each one's OS/2 table with fontTools. This is the complete output for the sample:
RMLRZN+NewsGothicBT-Bold TrueType ttf fsType = 4
RMLRZN+ArialMT TrueType ttf fsType = 8
RMLRZN+PlantinMTStd-Regular Type1 cff fsType = None
RMLRZN+NewsGothicBT-Demi TrueType ttf fsType = 4
RMLRZN+NewsGothicBT-Roman TrueType ttf fsType = 4
Four of the five are TrueType subsets. The fifth, PlantinMTStd, is Type 1, and the OS/2 table, where fsType lives, does not exist in that kind of font file. That is why the last column says None.
Reading the output against the result
The ImgIng output had four inlined fonts: the three NewsGothicBT cuts and ArialMT. Those four are exactly the TrueType ones. Plantin was the one that never got inlined, and the 509 elements on Arial, sans-serif are its text.
So the fsType values (4 and 8) were not the reason anything changed, because those fonts went through. The font that fell back is the one with no fsType to read. In this sample the split followed the font type. I had no font with fsType 2 in it, so this says nothing about restricted fonts.
What I would check before converting
My working assumption, drawn from this one file, is that a Type1 line in the PDF's font list marks a font likely to change in the HTML, and a TrueType line marks one likely to survive as a subset. Listing the fonts is quicker than converting and then hunting for the wrong typeface on page 3.
A subset only holds the characters used in the PDF, so an inlined font is good for showing that page and not much else. If the typeface matters for your page, one thing worth looking at is whether the file you export the PDF from can output TrueType or OpenType fonts. I have not tested re-exporting the brochure that way, so I cannot say it fixes this sample.
Limits
One 4-page file, one machine, one run. Other PDFs may split differently, and I did not test other converters on this font. The page-1 cover image also came out odd in my run, which is a separate problem and not part of the font story.
Top comments (0)