Move font subsetting from render to output

[simonberger]

The major part of the font processing is now triggered from the output instead of the render step.
The needed chars are collected from text output calls to CPDF instead of walking the frame tree another time. This also moves all work to CPDF.

Todos:

• Testing
  • This is covering decimal list bullets
  • Multiple embedded fonts are working
  • It is working with arabic font shaping of RTL Language Support #2107 - No reason for it to not work
• Just do font subsetting when the option is activated
  • Maybe we want to activate it by default now as the performance overhead should be low.

Addresses: #750

[simonberger]

@bsweeney please have a look at this. It worked well in short examples. But I had no run with multiple fonts and I might overlook things I don't know yet. ;)
Other limitations are listed above.

[bsweeney]

I ran this through my test gauntlet and didn't notice any issues.

I do think we should tweak the way we do this to behave similar to how PDFLib does it. For PDFLib the specifies the font subsetting preference when adding a font to the document. PDFLib handles the actual determination of the characters for the subset. For CPDF we would have to make a few changes to what we have so far:

• Add a new argument to CPDF::selectFont (bool subset) to indicate if subsetting should be enabled for the font.
• Add a new key to the font options to indicate if it is subsetted.
• Modify CPDF::addText to check if the font subset option is true. When the option is true register the passed-in text for subsetting for the font.
• Subsetting can now be determined based on the font option rather than if a subset exists.
• Update the CPDF::o_font "out" action to modify the BaseFont value per section 5.5.3 of the PDF specification. This section indicates that the font name for subsetted fonts should be six characters followed by a plus followed by the font name, e.g. ABCDEF+DejaVu-Sans-Normal.

There are two reasons to make this change:

• To better align with the PDF specification where subsetted fonts are concerned.
• Provide a better user experience for subsetting text placed through direct access to the CPDF instance (i.e. the user just has to indicate that the font is subsetted, they don't have to register the text since CPDF will take care of it).

This is what I was thinking about earlier, but probably didn't sufficiently explain myself. Thoughts?

---

FYI, I added a commit to your branch to add support for honoring the font subset option in PDFLib.

---

And, finally, I do think with this update that font subsetting works more consistently. As such we should go ahead and set the default font subsetting option to true.

[bsweeney]

Once we finish up with this I'll return to the RTL branch so we can finish that up.

[simonberger]

Your requested changes are making sense. I'll implement them.

[simonberger]

In detail I did the following changes which should cover all your points:

• selectFont gets an additional parameter isSubsetting which is true by default.
  • The calls coming from the adapter are reading the dompdf option.
  • The calls from other CPDF methods selecting the defaultFont if none is available now have enabled subsetting.
• Collecting subsetting data happens directly in CPDF addText instead of the adpater.
• A tag SUB[A-Z][A-Z][A-Z]+ is added in front of the font name. It is increased by fontnum starting with SUBAAB and has plenty of space (26^3).
• The dompdf subsetting option is now TRUE by default.

[simonberger]

Unicode and file suffix detection are now taken into account early to never collect text data unnecessarily.

[bsweeney]

look good