You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
what do you think about adding a method to the PdfBoxFontResolver that allows users to use their own FSSupplier?
This way it would be possible to avoid having duplicate fonts (or fonts with several subsets) in the PDF by using some sort of font-cache.
This quite easily happens if you have openhtmltopdf produce the output in a PDDocument where you also manually add some text which uses (some of) the same fonts as the html.
In this case it would be up to the implementation of FSSupplier to either load the PDFont or serve a already loaded one.
I can provide a pull-request for this.
The text was updated successfully, but these errors were encountered:
I wouldn't be opposed to a pr. However, i think i'd prefer a method on the PDF builder if that's possible. In the meantime, you may be able to get added fonts from the page resource dictionary of the pddocument.
I wasn't too keen on reordering the method parameters to keep the FSSupplier directly in the method as it would clash with the ones that use FSSupplier.
Instead I moved the PDFontSupplier from PdfBoxFontResolver to a seperate class that can be extended.
Hi @danfickle
what do you think about adding a method to the PdfBoxFontResolver that allows users to use their own FSSupplier?
This way it would be possible to avoid having duplicate fonts (or fonts with several subsets) in the PDF by using some sort of font-cache.
This quite easily happens if you have openhtmltopdf produce the output in a PDDocument where you also manually add some text which uses (some of) the same fonts as the html.
In this case it would be up to the implementation of FSSupplier to either load the PDFont or serve a already loaded one.
I can provide a pull-request for this.
The text was updated successfully, but these errors were encountered: