Hallo,
we are in a test phase for the following project: Generate lots of
PSFs with renderX's XEP and let them print on demand by a service
provider specialized on this.

The PDFs are printed on a highly automated basis. The problem is, that
the service provider complains about that our PDFs contain some
unknown error. That leads to a huge vertical shift of the printed
output in a way that only approx. the two centimeters of the PDF is
printed at the top of the paper sheet. Horizontally the PDF is
shifted, too, but only a couple of millimeters.

If you open the PDF in an Acrobat Reader or in Acrobat professional,
everything seems fine. The document is fully visible.

If I open one PDF in a simple text editor, I find the following box
definitions:
/MediaBox [-14.173 -14.173 1010.381 637.795]
/CropBox [-14.173 -14.173 1010.381 637.795]
/BleedBox [-14.173 -14.173 1010.381 637.795]
/TrimBox [0 0 996.208 623.622]

Those definitions seem o.k. to me.

The service provider is still checking the issue and trying to ind the
reason. They found out that if one opens the PDF in Illustrator and
just saves it again, without any modification, the resulting PDF is
printed o.k.

They say that within the PDF there is an origin defined somewhere, and
in our PDFs this origin seems to be set wrong.

The XEP support list is not really heldful, so I would like to ask
here if somebody knows
- if there is really some kind of origin defined somewhere in a PDF
- if so, where this origin is stored and
- how it could possibly be influenced/changed.

For me it seems logical that the origin is defined implicitly by the
TrimBox. The first two values in the TrimBox say "0 0" and I would
suppose that that's the origin.

Any help would be appreciated.

Regards,

Christian Kirchhoff

Hi,

On 13 Mar 2007 09:48:17 -0700 ckirchho@directmedia.de wrote:

> The service provider is still checking the issue and trying to ind the
> reason. They found out that if one opens the PDF in Illustrator and
> just saves it again, without any modification, the resulting PDF is
> printed o.k.
> 
> They say that within the PDF there is an origin defined somewhere, and
> in our PDFs this origin seems to be set wrong.

Can you provide an example file? Maybe generate one empty w/o
meaningful content, if you can't disclose information on the existing
PDFs?
(Just in case the caveat: don't attach it but put it on webspace and
refer to the URL)

-hwh

Hallo,

thanks for this offer. You can download an exemplary pdf from
http://www.zenodot.de/downloads/9783866401365_Cover.pdf

Even the specialists that took a closer look on the PDF said that it
is 100% correct, but still the service provider has to manually repair
each  PDF before the can put it in the print pipeline...

Other PDFs, without extra bleeding, don't seem to contain this
problem, because they can be printed just fine. It's just happens with
those PDFs that contain extra bleeding...

Best regards,

Christian Kirchhoff