Saved PDF size different between 32bit and 64bit drivers

[codeJockey]

Hello -

We are experiencing a strange problem on some 32-bit client machines when rendering PDFs. We are printing Crystal reports to the virtual PDF driver (v4, newest release), using the "append" feature to concatenate multiple reports into a single PDF. When printing on a 32-bit client the process takes quite a bit longer to generate the aggregated PDF and also results in much larger file sizes. When examining the generated files, the 32-bit version contains many instances of embedded fonts that the the 64-bit version contains only a single instance. Both versions used the exact same settings, including "Fonts.EmbedAll = FALSE".

Additionally, it appears that the multiply-embedded fonts in the generated PDF aren't actually in the source Crystal report, and we are at a loss to explain where they came from. If instead of using PDFXchange, we export to PDF using Crystal's viewer application, the "mystery font" (MS-UI Gothic, to be precise) does not appear in the output, regardless of platform. If we modify a font in the source report and re-gen the PDFs, the new font shows up a single time in both the 32 and 64 bit versions, and MS-UI Gothic continues to show up once in the 64-bit and multiple times in the 32 bit version.

The only examples of this that we currently have contain customer-sensitive data. I will have our QA team gen PDFs that are more generic and I will send them along. In the meantime, any thoughts or ideas of what we might try would be appreciated.

Regards,
Scott

[Stefan - PDF-XChange]

Hello Scot,

As a first thought: are the 32 and 64 bit apps using the same build of our libraries?

Best,
Stefan

[codeJockey]

Hi -

Our application is a 32bit application. Both the 32bit & 64bit client machines are running the same version of our compiled application. Also, they both have the same version of the redistributable installed, as found here: www.docu-track.com/PDFX4SA_sm.zip.

-Scott

[codeJockey]

Please find attached some sample PDFs. One created via PDFXpress on a 32 bit machine, one created via PDFXpress on a 64 bit machine and one created via the Crystal viewer (to show that it doesn't contain the mystery font).

[codeJockey]

We think we have an idea of the root cause of the problem. It appears that if the source document sent to the virtual PDF printer contains Multi-Byte characters, the 64-bit version of the driver adds a single instance of the MS-UI Gothic font and the 32-bit version adds an instance for every other PDF appended (i.e. if 64 documents are sent to the PDF driver in Append mode, 32 instances of the font will be in the output PDF). If no multi-byte chars are present in the source documents, then everything works fine & the Gothic font is not present at all in the output PDF.

[Stefan - PDF-XChange]

Thanks Scot,

I have passed findings to the guys (ticket #623), and will update you on the investigation.

Best,
Stefan

[Stefan - PDF-XChange]

Hi Scot,

I just received the news from the dev team, that this has been located and fixed.
The fix would be available in the next build.

Best,
Stefan

[codeJockey]

That's great news. What is the ETA of the next build?

[Stefan - PDF-XChange]

No ETA yet, but it would be the non beta 2.5, so as long as we are happy with the stability, and have addressed most of the reported issues, we should release that, so I would say (this is just an estimate and it's up to the dev team to give the exact dates) maybe a week or two.

Best,
Stefan

[codeJockey]

Is there any way we could get a more definitive date for the release? We have our own release coming up soon and would like to get this fix in if at all possible.

Thanks,
Scott

[Lzcat - Tracker Supp]

Build 189 is avail and it should fix this issue.
Please check and coem back with testing results.