Given a parsed CFF struct, how to use it in whole_font?

[ronnybremer]

When parsing a PDF, some fonts are embedded as CFF fonts (Type1C). I can successfully parse the CFF structure, however, I would need to construct a Font out of that. The function whole_font looks promising, but how do I get a TableProvider to pass in?

The CFF struct has a correct header, a single font in the fonts vector and its of type Type1.

Any advice would be appreciated.

[wezm]

CFF fonts are embedded in PDF directly (I.e. without the OpenType wrapper). The CFF table is the whole font in that context.

[ronnybremer]

Thank you for your insight @wezm. So that basically means I would need to add the OpenType wrapper and then run the result through:

  // add OT wrapper
  let font_bytes = ...
  let scope = ReadScope::new(font_bytes);
  let font_file = scope.read::<FontData<'_>>().unwrap();

I am pretty sure I tried that before, and it didn't quite work.
Since I don't have any experience with font handling, I am a bit at a loss here. What I am trying to accomplish is fixing the PDF font parsing of https://github.com/fschutt/printpdf. The crate can detect and decode embedded CID fonts perfectly, but not embedded CFF fonts.

Currently, after reading the font data as shown above, it gets a FontTableProvider form the font_file and calls allsorts_subset_browser::font::Font::new(provider).

With the returned Font structure all the character placement, text shaping and further down the road font embedding is done. Since that part is quite complex (at least to me), I was hoping to produce the same structure Font somehow with the CFF data I have.

[wezm]

What I am trying to accomplish is fixing the PDF font parsing of https://github.com/fschutt/printpdf. The crate can detect and decode embedded CID fonts perfectly, but not embedded CFF fonts.

Oh I see. By OpenType wrapper I mean the rest of the tables to make it usable as an OpenType font. You have a CFF table, the following would need to be created to make it usable as an OpenType font: cmap, head, hhea, hmtx, maxp, OS/2, maybe name & post. I think it will be somewhat non-trivial to construct a Font manually. The API in not really designed for 'interactive' construction of the structs, since many of them borrow data from an underlying slice of data.

If the goal is to render the PDF then I don't think you need most of the shaping and positioning functionality of Font, since that was already done to generate the PDF and often the shaping tables are subset out of the embedded font. I would imagine rendering the PDF would mostly be rasterising glyphs from the embedded font according to the graphics context and text in the PDF.

[ronnybremer]

I absolutely agree, I don't wanna create a Font manually, as the user of the printpdf crate can not add more text with that font to the PDF operations, as it is subsetted.

However, in order to parse the text inside of the PDF (when importing an existing PDF, so the user can add more graphical elements or fill out a form), the characters need to be mapped correctly. For regular characters (simple US-ASCII) that seems to work ok, but for anything special - form German umlauts to Cyrillic or Arabic/Asian letters - it fails at the moment. So I was hoping by reconstructing the cmap (I guess?) information, I can reverse-map those characters to their UTF-8 representation in order to be included in the resulting PDF again. Otherwise they are replaced with the \u+REPLACEMENT character.

Sorry if this feels like you are pulling the info out of my nose, but navigating this unknown space is a challenge for me and I don't really know which info might be important in this context.

[khaledhosny]

Text extraction from PDF is a rather complicated endeavor and it is not always possible to 100% recover the original text from the PDF. You need to do a combination of parsing ToUnicode from PDF font’s CMAP (not the the cmap font table), ActualText tags, and even glyphs names You might want to look into what Poppler (or other PDF reading libraries) do to extract the text. See also https://www.verypdf.com/document/pdf-format-reference/pg_0470.htm.

[ronnybremer]

Thank you for the additional context @khaledhosny! The PDF format always keeps another surprise up its sleeve. I will look more into it.

[kenmcd]

@ronnybremer
Keep in mind that many PDFs are not created perfectly.
Quite often the encoding behind the visible character shapes is completely wrong.
In that case manual editing is required.
This happens all the time when importing PDFs for editing.

FontForge can open .cff files.
And it can open a PDF and open the embedded fonts.
Most of the time you are dealing with sub-sets - which must be combined.

[ronnybremer]

Thank you for your input @kenmcd! I can fully agree, that there are many variables at play. I happen to have some PDFs which I would like to enhance with some graphical elements. Parsing them through printpdf works with some caveats. The embedded CFF fonts are ignored, the embedded CID fonts are parsed correctly. This leads to some characters being left out of the serialized PDF after I add my graphic operations. Even without any alterations on my part.

So currently I am trying to get at least the text to be parsed correctly (when associated with a CFF font). All normal chars are found and will correctly appear in the output PDF, however, all special characters have been replaced as mentioned above. I assume that this is happening because the cmap is not present at the time the text is extracted, as the reverse mapping can not happen correctly. My goal is not to provide an ultimate solution, however, CFF embedding seems to be pretty standard today and without that functionality any import of an PDF in printpdf and later saving it back as a PDF will result in a loss of the original text.

For that, I am trying to find a solution which will at least starting to work. I have never worked on that level of font processing before, unfortunately. I hope to make iterative progress but I am stuck at the beginning I guess.

[ronnybremer]

I would like to close this discussion as the following has been established.

A full font cannot be constructed from the CFF data embedded in a PDF. We have to find a way in printpdf to use the CFF data only, not relying on a full font to produce the PDF after parsing it.

Thank you both for your assistance!