Printing Office 2010 converted PDF in PDF-Tools

[NBachus]

We are having issues printing the pdf's generated by Officer 2010 products inside of the pxcview sample programs and through our own as well. I have attached an example file that replicates the behavior. This happens on different machines, but also works on others. Is there anything else we can be checking for versioning between machines? They are both using the save pxcview.dll, but I'm not sure if they are actually using the dll we are replacing/updating.

[John - Tracker Supp]

Can we please confirm that you have the PDF-XChange Viewer developer SDK as you have posted to another product forum (PDF-Tools) and also to the end user section ...

this is a little confusing as you say Office 2010 - so are we dealing with existing PDF documents creating use MS Word's PDF creation function and then outputting via our Viewer SDK - or are you trying to print office document formats to PDF using our Virtual print driver.

Once clarified we can assign a relevant member of our support team to assist you more specifically.

Thanks

[NBachus]

The conversion to PDF from Word or Excel is done through the internal "Save as PDF" that Microsoft is now providing since 2007. We are then sending it through the viewer and printing from there. In our program, we perform other activities before we print but have narrowed it down to this specific print function.

[John - Tracker Supp]

Can you please advise the build used of PDF-XChange and also specify one Windows OS on which you have reproduced - and also is it 32/64 bit ?so we can endeavour to reproduce here.

Thanks

[NBachus]

Known OS's having the issue:
Windows Server 2003 (32bit)
Windows XP (32bit)

PDFX Version - 4.0.200.0 (pxcview is showing 2.5.200.0) but I'm not sure if this is the version actually being used since we can't print the current version from inside of the programs. Is there a better way to definitively get the current version?

[John - Tracker Supp]

Hi,

we have managed to reproduce this - but only for certain printers/drivers combinations - please be advised that our team will endeavour to find a workaround fix and release in build 202.

Thanks for your patience.

[NBachus]

Thanks! That's the same behavior we are having too. Our PDF-Xchange printers work fine, but we also have a HP 8150 that exhibits the issue.

[John - Tracker Supp]

Yes - it's an odd one - but at least we can reproduce locally which makes the fix a whole lot easier to progress.

Cheers and have a good weekend

[NBachus]

Is there a way to predict the driver/printer combo that has the problem? There hasn't really been a pattern in our troubleshooting yet.

[John - Tracker Supp]

To be honest - I doubt it for now - at least not until we get to the point of tracing and fixing - then it may be possible.

For now we can reproduce - but anymore is just conjecture until traced.

[Ivan - Tracker Software]

I made an investigation and found where the problem is.

This document contains embedded fonts for which pxcview makes temporary fonts for printing. It removes these temporary fonts when printing is finished. Some printers don't embed fonts into the spool job and this causes problems with the temporary fonts. This is what we see in your case.

A workaround for this issue is to use the flag pxvrpf_EmbeddedFontAsCurves together with pxvrpf_UseVectorRenderer in Flags fields of PXV_CommonRenderParameters structure.

hth

[NBachus]

Ivan,

When we process it through our program with the additional flag of pxvrpf_EmbeddedFontAsCurves, we are seeing behavior on an overlay watermark becoming unreadable. Is this flag supposed to degrade this type of layer/text?

Thanks,
Nathan

[Ivan - Tracker Software]

No, I never seen such effect. This flag doesn't interact with rendering demo.
can you try to modify our C++ example to use this flag and check if the result is the same as in your app?

[Paul - PDF-XChange]

Hi NBachus,

we have a support ticket open for this item RT#1447: Printing Office 2010 converted PDF in PDF-Tools and are wondering if you have any more information on this so we can move forwarded? Ivan asked you :

can you try to modify our C++ example to use this flag and check if the result is the same as in your app?

The ticket has been set to stalled and will be closed if there is no further interaction here so do let us know if you are still having troubles.

Sincerely

[NBachus]

We figured out that the output was just because it was in postscript and the way the viewer was showing at specific sizes. As long as the bug is reported, we should be good to go.

[Paul - PDF-XChange]

Thanks NBachus,

[NBachus]

I'm trying out the recent updated version of pdf-tools, and still have this problem occurring. Can someone confirm if this bug was fixed in the updated versions?

[Paul - PDF-XChange]

Hi NBachus

I think we have misunderstood the communications here. You said:

As long as the bug is reported, we should be good to go.

and since we were unable to reproduce this here we interpreted that as leave it and move on. On re-reading this I can see now that that was probably not your intention. We cannot reproduce the issue here. Without reproducing this we cannot fix it.

Earlier in this thread Ivan asked:

can you try to modify our C++ example to use this flag and check if the result is the same as in your app?

Can you do that? I will meanwhile re-open this ticket.

[NBachus]

I'm talking about the original issue posted at the beginning, which then was reproduced by John/Ivan and Ivan then posted a workaround. The "watermark" problem lower in the topic was not actually a problem in the end. Does this help?

Thanks,
Nathan

[Paul - PDF-XChange]

so you implemented the work around but the work around has the degraded image qualkity. I believe you are asking for the issue to be fixed without that work around. Do I understand you correctly?

regards

[NBachus]

The workaround works fine. There is no image degradation. I was under the assumption the workaround was a temporary fix until the next release.

Thanks,
Nathan

[Ivan - Tracker Software]

Hi NBuchus: if you are talking about using pxvrpf_EmbeddedFontAsCurves, I'm afraid it was my mistake to call it 'workaround'.

In reality, in almost all cases embedded fonts cannot be rendered correctly using system fonts (because even when you embed, say Arial, on one machine, on another machine when you are printing, Arial font may be different version and glyphs indices may be different).
So, using the pxvrpf_EmbeddedFontAsCurves flag should be considered a rule rather than an exception.

hth

[NBachus]

Ok great to know! Thanks for the responses.

-Nathan

[Stefan - PDF-XChange]