Nothing like some printer issues to forget about a worldwide pandemic...

This might be a TY question, but here goes:

I have a user that is trying to send a form to a 3rd party PDF builder with no luck...alignments are way off. SO i thought i would test in PDFX and generate an upgrade for Ty.. but still no joy. If i preview in APEX it looks good. If i then send same form to the PDFX driver and take a look, its way off, like the fonts are not correct. It is off whether i select PDFX output on its own, or preview in APEX first, then select the "print as intended" option then select PDFX.

I realize there a gazillion variables in play, but any thoughts?

Can send examples, purell, upon request

Indeed, there are a gazillion variables. But, on the bright side, unlike most software problems which may require vast amounts of code, libraries, data files, etc. to reproduce, virtually everything about this kind of problem can be contained within the print file itself, with the possible exception of the printer init file and any referenced image/include files that are referenced in the print file. So, our standard invitation is to email us copies of those files and our local expert (Ty) will be happy to examine it to figure out what the problems/solutions are.

There are two possible externalities that I can think of:

1) If you are printing on to a pre-printed form, then we probably need a scanned image of that so we can at least judge whether the output has the necessary overall vertical/horizontal spacing. (Ideally you would want to generate the form as part of the output document so as to eliminate this issue.)

2) It's always possible that there is some variation among printers. In general though, if the GDI instructions are well designed, that shouldn't be an issue. Essentially our goal is to make it look right in APEX and/or the PDF viewer; beyond that it should print right on any printer.

Hey Jack - thanks for the reply.

In this case the form does indeed contain a scanned image of the form. I can wrap all of that in a nice face mask and email to Ty to have a look.

You triggered a question, however, in that APEX does use the printer driver, what does PDFX do in this case? How does it know what "driver" to use?

TIA

Good question. Generally speaking, the PDFX driver, being a printer driver, does report to the GDI system (and APEX) all the same kinds of information that other printer drivers would. And you can tinker with those settings in the PDFX driver (resolution, paper layout, etc.) The part that's a bit murky is the hardware margin. Laser printers typically have a hardware margin of approximately 1/4", while some other printers (such as inkjet/photo printers) may not. But the driver typically doesn't report the margins per se, but the printable area. You can see that if you turn on the LP and XDEBUG traces when print something.

The problem of the hardware margin though can usually be eliminated through the use of the XORIGIN/YORIGIN directives, as long as you set them at least as far in as the largest margin you think you'll have to deal with (400 twips should be sufficient). Your form background and foreground should all adjust to that, so the result will be effectively the same regardless of the details of the printer.

The other area which can be tricky is when you use //IMAGE to print the background of the form. If you use the 0,0,0,0 (adjust to page) option, it may see convenient, but could result in slightly different sizes depending on the printer variations. But typically the font sizing is not sensitive to the paper size. So it's better to use absolute coordinates for the background image (again, be a little conservative) and then adjust the font width and VMI accordingly.

Not urgent just wanted to be sure you got my example and it didn't wind up in quarantine...

Followup:

Hate to drop a printing issue on a weekend but there's no specific rush...

I am testing APEX under the new ATE 1679.0 build vs our previous build of 1676.8. APEX appears to behave differently with the exact same .prt file b/w these 2 versions using the same printer driver. I realize that you changed the output a bit for PDF viewers but i was expecting the same output. In this case the older ATE is spot on and hte new one is 1/2 line to hi at the beginning of the form and a whole line off by the end. I was hoping that APEX would behave the same. Otherwise when a customer downloads the new version, the alignments will be off, which will cause a software update to be tied to the ATE flavor. Just making sure i am not going down the wrong rabbit hole here.

TIA - see you on the other side of the weekend. Hope the Bunny brings lots of candy.

Can you send me that print file and indicate which printer you're targeting? I suspect the issue you're reporting is related to the removal of the automatic 1/4" top and left margins that APEX was previously adding for virtual printer drivers that were not reporting any margin. (This issue would mainly only arise with virtual printer drivers like PDFX, since most "real" printers, especially lasers, do have a built-in margin that APEX will use.) If I'm right, i.e. that you're using APEX to preview a file targeting a PDF printer driver, then yes, the shifting of the APEX output to the left and top edge of the page is expected. What's not clear is how the related to the text not matching the form. Assuming the form is generated via //IMAGE, it seems that both should shift up and to the left in the same way. However, if using a set LPP value, or the new //SETVMI with negative argument to establish vertical spacing relative to the printable area of the page, removing that top margin would in fact change the printable area of the page, which would result in a slightly extended vertical motion index.

The other question is whether the problem happens when bypassing APEX and going direct to the target device?

Sent...

There are 2 parts.

Hey Cap - please let me know when u release a new update with the APEX adjustments we chatted about..

tx

Sorry - meant to add a note to this thread along with the 1679.5 update but suffered a stack overflow when I heard the refrigerator open...

ash-6.5.1679.5-w32-upd.zip
ash-6.5.1679.5-w32c-upd.zip
ash65notes.txt

No worries, thanks. I ran the program thru its paces again and it looks good.

Initially you had to create a full ATE build to get to 1679.0. Now we are at 1679.5.

Any plans on a new ATE build? or do u want me to use the updated ashw32 patch for the time being.

TIA