We're seeing some differences with PDFX9 between both printing to a printer and APEX. I have attached a screenshot of PDFX versus APEX (note printing to a printer looks identical to APEX). I have also attached the GDI print file as gs12.zip. No one reported this with PDFX3/5. Can't easily go back to 5 to verify the difference, though.

I'm not sure what we need to look at changing.

Thanks in advance!

I'm not sure if this is good news or otherwise, but I see no relevant differences in the APEX rendering of your document under 6.4 with PDFX5 vs 7.0 with PDFX9.

You didn't say just which differences were bothering you most (perhaps it's just that the fact that there are any differences), but the three issues I see are:

• APEX is displaying with a slightly larger left margin, causing the image to be shifted slightly to the right. This has actually been a long standing issue with APEX and PDF, caused by a difference in the way virtual printer drivers (like PDF) handle margins vs real printer drivers. In both cases they are reporting to APEX a hardware margin of something like 1/4". But it's being virtualized by the former, which can't really know what the true printer hardware margin will be until you select a real printer. I probably could figure out how to back that out, but it gets pretty confusing, and didn't really seem like it bothered anyone that much.
• The APEX font rendering apparently doesn't do kerning like PDF does. I'm not sure there's anything we can do about that. A-Shell isn't trying to control the kerning itself, leaving it to the Windows GDI default settings. But there may be a way to override the behavior based on some query-able attribute of the printing device. But as with the margin, it doesn't seem to significantly detract from its use as a previewer. Note that it doesn't affect the font size or overall positioning, just the inter-character spacing.
• The cross-hatch effect is much bolder in PDF than in APEX. As with the kerning, we're not doing anything special with this effect, other than requesting one of the standard Windows GDI options, so it comes down to the final rendering in the output driver (PDF vs APEX vs HP Laserjet vs...) to finalize the effect.

I agree with you that ideally the output should be the same regardless of the output device, but obviously between the differences in driver implementations as well as in the devices themselves are going to inevitably result in some differences. The question is how much difference we can tolerate or how much similarity we can actually enforce. I think there's pretty good conformity between APEX and most actual printers, because the printer drivers are all based on the same Windows GDI. But PDF is kind of a worst case since it's all based on a completely different graphic language, requiring another layer of translation between Windows GDI and postscript.

Or am I just missing the real issue here?

Sorry, forgot to mention the cross-hatch as the problem as it makes the document unreadable. In my brain that was obvious; another, area of difference we can't solve!

We'll never solve that problem. But we can probably find a workaround for the cross-hatch issue by translating the effect to something else more transparent when in preview mode.

It's the PDFX generated PDF that has the un-readable cross-hatch. Not the preview mode, but maybe I'm misunderstanding what you mean by that.

Sorry, that's my dyslexia (or age) kicking in. But I guess the same strategy could be used in reverse.

Did we come up with a solution to this without changing our code? I'm not exactly sure what to change our code to, to prevent this from being possible in the first place.

No. I was thinking I'd play around with the cross-hatch effect to see if there was a way to tone it down so that it is readable in PDFX9. But then I didn't get to it. I'll circle back to it this afternoon.

Thanks.

Ok, I obviously had it backwards before, i.e. was looking at the preview and not the actual PDF viewer result. It does seem to have changed with each version of PDFX...

PDFX3:


PDFX5: (Printer 2012)


PDFX9: (Printer Standard)


Proposed workaround:


It seems like a straightforward bug in the driver, but apparently this effect is dependent on some lower levels of something and I'm not getting a good sense that there's going to be a fix coming down the pike anytime soon. And it would require updating every workstation. So instead, I suggest the proposed workaround shown above. (This would require an A-Shell update, but hopefully that's not quite as traumatic. And hopefully you didn't really have your heart set on the cross-hatch effect.) Let me know if that works for you and I'll put it in the next update.

It works for me. I'm not certain where we are on moving to 7.0. I think in a holding pattern a little waiting for a little dust to settle.

Is this going to be an ATE update?

Right - I wasn't thinking clearly about the fact that the //PDFX and //GDI commands only run on the Windows side, so yes, it's "only" an ATE (or A-Shell/Windows) update. You should be able to use the Help > Check For Updates, but alternatively here's the direct link:

ATE: ate-7.0.1753.3-web-upd.exe

I installed this on one end-users machine. This one is resolved. Thanks!

Weird issue, but I'm glad the workaround was acceptable.