Combination of Documents with embedded fonts

[axelerator]

We combine a background document with a letter - This document contains text in an embedded font. By it's own it looks just fine - after the merge single characters are missing and replaced by a box.

[boazsegev]

Thank you for submitting this issue and helping improve the CombinePDF library.

I would really love to help you with this one, and I'd be thankful for any information you could provide to help me locate and resolve the issue.

I would love it if you could post some sample code and maybe a two demo files that will allow me to reproduce the issue on my machine.

I'm assuming you're using the the latest combine_pdf gem, version 0.2.7.

Also, I know that merging some PDF files might cause conflicts with named resources (i.e. fonts). For this reason, pages have a "safe" copy flag that attempts to rename the resources referenced by that page (using page.copy(true))...

I'm wondering if you're stumping the original page object and whether you tried making a "safe" copy for the stamp (if you're using the PDF#stamp API, it isn't invoking a safe copy on your behalf).

Any information will help,
Have an amazing day!

[axelerator]

Thx for your quick response, I can reproduce the problem with these files:

fg = CombinePDF.load("foreground.pdf");
fg.pages[0] << CombinePDF.load("background.pdf").pages[0]; 
fg.save 'combined.pdf'

I the footer you should be able to see the missing 'L' and 'f' and 'I' characters.

Dropbox links for the pdf, because github doest let me upload these to repos I dont have write access to.

https://www.dropbox.com/s/8qj0s9w4v3stzfv/background.pdf
https://www.dropbox.com/s/0koy87ensm04ksh/foreground.pdf

[boazsegev]

Thank you for the code and example files.

Hmmm.... just a few thoughts:

1. I can see the font being switched when the pages are stumped together. two fonts in both files are obviously conflicting, sharing the same name-space.
2. Both PDF files were produced with Prawn. When the files share the same authoring tool, the risks of named resource's are naturally higher... especially because some authoring tools (not just prawn) name their resources in sequential numbering (i.e. /font1, /font2 etc')....

I tried using a safe copy :

fg = CombinePDF.load("foreground.pdf");
fg.pages[0] << CombinePDF.load("background.pdf").pages[0].copy(true); 
fg.save 'combined.pdf'

This confirmed my suspicion, since (on my machine) using a safe provided me with the expected results.

I'm not closing this issue since I'm not sure if the fact that the current API shouldn't be made clearer.

I'm reluctant to enforce the safe copy flag as the default, since it's very intrusive, but perhaps there should be a way to automatically identify conflicts rather than have the developers (who shouldn't be expected know anything about the PDF file structure) deal with these questions...? On the other hand, this might impact performance when looping over a longer document, causing the tests to be performed so many times (resource names are page specific).

[axelerator]

Using copy to create a safe copy did the job. Thanks!

I cannot judge how big the impact of make safe copy the default would be, since I don't know about the PDF spec. Maybe a short mention of this in the README is enough to point the people into the right direction, since it's really hard to tell where to look when this occurs.

[boazsegev]

Okay, I automated the process. CombinePDF will now review the data and automatically attempt to detect conflicts. This means that even without using the copy method, CombinePDF will create the correct type of copy (safe or regular) before stamping one page on top (or under) another.

Thank you for pushing me to do this 👍🏻👍🏻👍🏻

[boazsegev]

Resolved in version 0.2.8