[WIP] Support subsetting CFF2 fonts for use in PDFs

[devongovett]

Basically we have to convert CFF2 to CFF1 to enable PDF viewers to work with CFF2 fonts. This means generating some info from other places in the font since it no longer exists in CFF2 (e.g. font names, etc.). Also, we have to generate a static instance of any variations applied by re-encoding charstrings after applying the blend operator.

Still to figure out: how to remove overlapping subpaths from glyph outlines since CFF2 allows them, but CFF1 does not. CFF2 switched from the even-odd to the nonzero winding rule. This will require some additional processing on the glyph paths...

Also need to apply the same blend logic to subroutines.

[devongovett]

That would require the PDF spec to be updated to support CFF2. Currently, CFF fonts are embedded directly in PDFs without the SFNT wrapper. That's not possible with CFF2 since they do not work standalone. Also, there is lots of legacy software out there (e.g. printer drivers) that renders PDFs that will never be updated.

There is a section in the OpenType spec about static instance generation here: https://www.microsoft.com/typography/OTSpec/otvaroverview.htm#InstanceGen.

[twardoch]

@devongovett is right. In a way, the fact that the CFF table inside an OTF could often be directly embedded inside a PDF as a bare CFF font was a "lucky coincidence" (it was of course more than that but the way PostScript outlines were added to OpenType was an odd solution).

Today, OpenType has a large series of glyph storage flavors (CFF2, CFF, glyf+gvar, glyf, SVG, sbix, CBDT, EBDT) and only a small subset can be passed directly into a PDF (CFF, glyf). Subsetting is often performed on the way, and that step now needs to be extended to handle more general conversion (CFF2 to CFF with blend applied, glyf+gvar to glyf with deltas applied, SVG to PDF paths, the PNGs inside sbix and CBDT into appropriate PDF image formats).

Removing overlaps should be performed for both CFF2- and glyf+gvar-derived font outlines when the font resource is prepared for PDF inclusion. A library such as Clipper could be used in this step. There are JS ports of Clipper and there Python package booleanOperations shows how Clipper can be used in font processing:

• https://sourceforge.net/p/jsclipper/wiki/Home%206/
• https://github.com/mathisonian/JsClipper
• https://github.com/Doodle3D/clipper-js
• https://github.com/typemytype/booleanOperations

Note that PDFs are rendered directly in PDF rasterizers built into printers and imagesetters, or are converted to PostScript, using code that will likely never be updated, and some font rasterizers inside existing printers have problems with overlapping font outlines.

So this step is really needed. Ideally, common "PDF font prep" libraries should emerge in a variety of languages that will perform instantiation of variable fonts, overlap removal, subsetting, and possibly also outline flavor conversion and proper handling of the color font flavors.

[twardoch]

PDF is used in far more scenarios than just "PDF viewers", PDF renderers often use rasterizers other than FreeType, and in many cases, they're built into hardware devices (printers and imagesetters) for which there are often no ways to update their software.

[twardoch]

Perhaps PDF will be updated to better handle variable fonts and maybe CFF2 support will be added (though I haven't heard anything), but I think that adoption of newer, possibly partially backwards-incompatible PDF will be rather slow, due to the widespread implementation of older PDF standards in expensive hardware (printers, copiers, imagesetters).

[Pomax]

@devongovett this PR is pretty out of date, but it keeps forcing its way into my PR mentions (for reasons not even github can explain). Would it be possible to close it?

[Pomax]

After talking to github support, it turns out that apparently there is something wrong, and Github is, and I quote "not interested in fixing it right now" so can you please close this PR @devongovett and then reopen it if that still makes sense? Because Github is literally not interested in fixing their backend =(

[devongovett]

It's just sitting here. No one is commenting but you. So I don't know how there would be any notifications about it. You can also just unsubscribe from this thread or from the whole repo if you want. Not sure how closing it would help given that there are no comments.

[Pomax]

That's literally the bug, before I was commenting on it this PR was just firmly lodged in my PR's "mentioned" list, and the github engineers looked at that, went "that's weird, that shouldn't be there anymore, but we're not going to fix it" for years now. So it's getting really annoying =(

If it's just a parked PR for future reference, then closing it and creating a new PR off of the same branch that references this one with a #90 in the first comment should hopefully not be too much trouble, but would solve a five-year-long problem that GitHub apparently can't fix.

And unsubscribing either from the PR or the entire repo sadly does nothing (we've already tried that) - according to GitHub there is something wrong with how it's stored in the GitHub databases and nothing I can do through the website gets it out of my PR list (including deleting every comment I made so that I'm not "part" of the comment thread anymore). So really the only person who might be able to help here is someone with the power to close this PR, because GitHub engineering has made it clear they don't intend to help resolve this bug in their system.