PDF’s look/act differently in GS and other programs than Adobe apps

wrote:

We broker online printing, and often get PDFs from customers. Unfortunately, whenever we use ImageMagick or PDFLib (which both use GhostScript) to alter the file or create thumbnails, etc, they come out differently than what is shown in Photoshop or Acrobat Reader, etc.
In fact, I can view the original PDF in Linux based PDF viewers like KGhostRead and KPDF and they’ll display the PDF differently than even Abobe AcroRead for Linux (which shows what it looks like in Photoshop.)

Can you describe the differences you’re seeing?

I’ve noticed that with PDF files in CMYK colourspace, viewing them (which requires a conversion to RGB colourspace, obviously) changes things quite a bit. Somewhere deep in the GhostScript documentation, I discovered the ‘-dUseCIEColorSpace’ switch which, when turned on, gives more accurate CMYK -> RGB conversions. This defaults to ‘Off’ (and hence seems to be off also in any app using the GhostScript libraries, which includes just about everything running under Linux except Adobe Reader) to render faster. I haven’t (yet) figured out how to get it to default to ‘On’ for more accurate colourspace conversions in all apps using the libraries. If you can, use the ‘gs’ command with that switch instead of relying on ImageMagick, etc. Moreover, ISTR that ImageMagick always puts out PDFs in RGB by default, so *any* work with a press-ready CMYK PDF will result in a conversion to RGB colourspace if you use ImageMagick.

Of course, if your problem isn’t with colours, then none of the above will help you….

John-Paul Stewart wrote:

wrote:

We broker online printing, and often get PDFs from customers. Unfortunately, whenever we use ImageMagick or PDFLib (which both use GhostScript) to alter the file or create thumbnails, etc, they come out differently than what is shown in Photoshop or Acrobat Reader, etc.
In fact, I can view the original PDF in Linux based PDF viewers like KGhostRead and KPDF and they’ll display the PDF differently than even Abobe AcroRead for Linux (which shows what it looks like in Photoshop.)

Can you describe the differences you’re seeing?

I’ve noticed that with PDF files in CMYK colourspace, viewing them (which requires a conversion to RGB colourspace, obviously) changes things quite a bit. Somewhere deep in the GhostScript documentation, I discovered the ‘-dUseCIEColorSpace’ switch which, when turned on, gives more accurate CMYK -> RGB conversions. This defaults to ‘Off’ (and hence seems to be off also in any app using the GhostScript libraries, which includes just about everything running under Linux except Adobe Reader) to render faster. I haven’t (yet) figured out how to get it to default to ‘On’ for more accurate colourspace conversions in all apps using the libraries. If you can, use the ‘gs’ command with that switch instead of relying on ImageMagick, etc. Moreover, ISTR that ImageMagick always puts out PDFs in RGB by default, so *any* work with a press-ready CMYK PDF will result in a conversion to RGB colourspace if you use ImageMagick.

Of course, if your problem isn’t with colours, then none of the above will help you….

Well that’s good stuff to know! For probable later use.
Unfortunately, colors aren’t the problem.
The two main symptoms are, it will rotate the image 180-degrees, and "shrink" the visible image down as it shows a previously invisible blank, white background layer or something causing a white border. Well, seemingly invisible in Adobe products but seems to be there in non-Adobe products like Ghostscript.

Thanks!
Liam

wrote:

…
and "shrink" the visible image down as it shows a previously invisible blank, white background layer or something causing a white border. Well, seemingly invisible in Adobe products but seems to be there in non-Adobe products like Ghostscript.
…

Try -dUseCropBox with GS (see Ghostscript’s DOC\Use.htm). Adobe Reader uses the CropBox by default, while GS defaults to using the MediaBox.

SaGS wrote:

wrote:

…
and "shrink" the visible image down as it shows a previously invisible blank, white background layer or something causing a white border. Well, seemingly invisible in Adobe products but seems to be there in non-Adobe products like Ghostscript.
…

Try -dUseCropBox with GS (see Ghostscript’s DOC\Use.htm). Adobe Reader uses the CropBox by default, while GS defaults to using the MediaBox.

Hey wow, that works! That’s half my problem solved!
(I guess what I’ll need to do, since this whole thumbnail creation process is automated with PHP scripts, is pre-process the PDF’s with GS using that switch, THEN run ImageMagick’s "montage" to create the thumbnails.)

Now, if only there was a fix for flipping the image 180 degrees. =/ Maybe some combination of acroread -toPostScript and GS with the box switch….

Thanks for the reply!
-Liam

wrote:

SaGS wrote:

wrote:

…
and "shrink" the visible image down as it shows a previously invisible blank, white background layer or something causing a white border. Well, seemingly invisible in Adobe products but seems to be there in non-Adobe products like Ghostscript.
…

Try -dUseCropBox with GS (see Ghostscript’s DOC\Use.htm). Adobe Reader uses the CropBox by default, while GS defaults to using the MediaBox.

Hey wow, that works! That’s half my problem solved!
(I guess what I’ll need to do, since this whole thumbnail creation process is automated with PHP scripts, is pre-process the PDF’s with GS using that switch, THEN run ImageMagick’s "montage" to create the thumbnails.)

Now, if only there was a fix for flipping the image 180 degrees. =/ Maybe some combination of acroread -toPostScript and GS with the box switch….

So I try GS’s -sDEVICE=pdfwrite to remake the PDF as a new PDF, so I can then use acroread -toPostScript to fix the rotation problem, and it creates a blank PDF, but at the right dimensions. =)
Interestingly, I try -sDEVICE=epswrite and it rotated the PDF… 90 degrees to sideways. =) That’s funny weird.

Well, I’ll keep playing.
Thanks for the help, guys!
-Liam

"" wrote in
news::

Now, if only there was a fix for flipping the image 180 degrees. =/

"Psutils" is useful for situations like this. You can use "pstops" to rotate ps by 90 or 180 degrees.

http://knackered.knackered.org/angus/psutils/pstops.html

wrote:

Now, if only there was a fix for flipping the image 180 degrees. =/ Maybe some combination of acroread -toPostScript and GS with the box switch….

Why can’t montage be used for that? You can flip with ‘montage -flip’ or rotate with ‘montage -rotate 180’ depending on the exact nature of the problem.

John-Paul Stewart wrote:

wrote:

Now, if only there was a fix for flipping the image 180 degrees. =/ Maybe some combination of acroread -toPostScript and GS with the box switch….

Why can’t montage be used for that? You can flip with ‘montage -flip’ or rotate with ‘montage -rotate 180’ depending on the exact nature of the problem.

True, but the problem is, it doesn’t happen on EVERY PDF we need to add to the set.

See, what happens is a designer will put a couple dozen JPGs, PDFs, EPSs and TIFs in a folder and starts the PHP script. The script then runs montage on the whole directory of files.
So if I add a rotate switch to montage, it’ll rotate every image regardless, and that’s not good.

Now that I’m thinking about it, it looks like preprocessing the PDFs in the folder with a -dUseCropBox switched GS will be a universally good thing, but since only about half the PDF’s we submit get rotated around in the montage process and we don’t until after it’s done… we can’t do any global rotation to all PDFs before doing a montage.

We need to find some way to get GS (or whatever program) to recognize that a PDF is going to rotate erroneously. =/
May be impossible.

Thanks for the reply!
Liam

wrote:

John-Paul Stewart wrote:

wrote:

Now, if only there was a fix for flipping the image 180 degrees. =/ Maybe some combination of acroread -toPostScript and GS with the box switch….

Why can’t montage be used for that? You can flip with ‘montage -flip’ or rotate with ‘montage -rotate 180’ depending on the exact nature of the problem.

True, but the problem is, it doesn’t happen on EVERY PDF we need to add to the set.

Ahh…I see…that makes things dramtically more complex. You’ll have to start looking into what causes the unwanted rotation.

Is it rotation or flipping? If it’s flipped rather than rotated then I’d suspect the MediaBox might be to blame. Check some of the PDFs (in any text editor or even ‘less’). Common PDFs have something like:

/MediaBox [0 0 612 792]

for U.S. Letter-size paper. I think it’s possible, however, to have non-zero starting points and/or negative ending points which might result in images being treated oddly. I don’t know off hand how well

/MediaBox [0 792 612 0]

or

/MediaBox [0 0 612 -792]

would be handled. Either may well result in an inverted image in GhostScript. (I’m just speculating at the moment….)

So-called press-ready PDFs may also have TrimBox and CropBox. Likewise, odd numbers in one of those *might* result in an inverted image.

Sorry I really can’t offer anything more than speculation. (But since I’m not seeing too many other responses…maybe speculation is better than nothing.)

John-Paul Stewart wrote:

wrote:

John-Paul Stewart wrote:

wrote:

Now, if only there was a fix for flipping the image 180 degrees. =/ Maybe some combination of acroread -toPostScript and GS with the box switch….

Why can’t montage be used for that? You can flip with ‘montage -flip’ or rotate with ‘montage -rotate 180’ depending on the exact nature of the problem.

True, but the problem is, it doesn’t happen on EVERY PDF we need to add to the set.

Ahh…I see…that makes things dramtically more complex. You’ll have to start looking into what causes the unwanted rotation.
Is it rotation or flipping? If it’s flipped rather than rotated then I’d suspect the MediaBox might be to blame. Check some of the PDFs (in any text editor or even ‘less’). Common PDFs have something like:
/MediaBox [0 0 612 792]

for U.S. Letter-size paper. I think it’s possible, however, to have non-zero starting points and/or negative ending points which might result in images being treated oddly. I don’t know off hand how well
/MediaBox [0 792 612 0]

or

/MediaBox [0 0 612 -792]

would be handled. Either may well result in an inverted image in GhostScript. (I’m just speculating at the moment….)

So-called press-ready PDFs may also have TrimBox and CropBox. Likewise, odd numbers in one of those *might* result in an inverted image.
Sorry I really can’t offer anything more than speculation. (But since I’m not seeing too many other responses…maybe speculation is better than nothing.)

No no, speculation is good!
For example SaGS speculation above about the CropBox fixed half the problem. The speculation about using pdftk (while I’ve only been able to play with it on my own PC and as yet unable to install it on the server) has yielded some additional info, and the speculation about the PDF versions has increased my knowledge a little bit… so speculation is great. =)

Unfortunately it’s not flipping, but rotating.
What it is, is it’s generally only happening on the "back" image of a two-sided product (business card, post card, etc.) The front and back images are two different files, not two pages of the same file.

Evidently someone will design the back, and then flip it upside down so that when it’s laid out on the "flat" for printing, it’s in the right orientation.

However, in this thumbnail creation process, it’s SUPPOSED to stay upside down, but GS is flipping it back right-side-up. So when you open it in any Adobe product it displays upside-down which is correct, but GS and other PDF readers are shoing it in the originally designed right-side up.
If it was happening to ALL back side PDFs I could set it up so that GS flipped the image before it then ran montage. But it’s not always happening. =/

I’m hoping to be able to get this pdftk installed on the server, and see if outputting the metadata I can find a common link, like a particular application or version or something I can rely on to determine GS flipping or not.

Anyway, thanks for the replies!
-Liam

wrote:

What it is, is it’s generally only happening on the "back" image of a two-sided product (business card, post card, etc.) The front and back images are two different files, not two pages of the same file.
Evidently someone will design the back, and then flip it upside down so that when it’s laid out on the "flat" for printing, it’s in the right orientation.

However, in this thumbnail creation process, it’s SUPPOSED to stay upside down, but GS is flipping it back right-side-up. So when you open it in any Adobe product it displays upside-down which is correct, but GS and other PDF readers are shoing it in the originally designed right-side up.
If it was happening to ALL back side PDFs I could set it up so that GS flipped the image before it then ran montage. But it’s not always happening.

Hmm…there’s two different ways one could generate an upside down PDF.

One is to have the creating application draw everything upside down on that page. I’d expect that to render correctly everywhere.

The other is to draw right side up, and then use the PDF ‘Rotate’ operator to rotate the entire page in the PDF rendering engine. It’s possible that GS is ignoring that rotate directive. Can you grep the files for ‘Rotate’ to see if there’s any correlation between it and the problematic files?

John-Paul Stewart wrote:

…
The other is to draw right side up, and then use the PDF ‘Rotate’ operator to rotate the entire page in the PDF rendering engine. It’s possible that GS is ignoring that rotate directive. Can you grep the files for ‘Rotate’ to see if there’s any correlation between it and the problematic files?

Good point. But Ghostscript, at least recent versions (just tried with
8.52), do honor the /Rotate setting. I’d suggest the OP to verify the
GS version used, and if the problem gets solved by an update. If using GPL Ghostscript, the latest version is 8.50 (released in December, see http://www.cs.wisc.edu/~ghost/doc/GPL/gpl850.htm). Note: not sure if GS had any bugs dealing with /Rotate, and if yes, exactly when these were fixed; in particular I don’t know if 8.50 is OK, but I hope it is (it’s not that far from the 8.52 I tested).

If this does not fix the problem, it would be a great idea to put a sample PDF somewhere publicly accesible and post the URL here.

SaGS wrote:

John-Paul Stewart wrote:

…
The other is to draw right side up, and then use the PDF ‘Rotate’ operator to rotate the entire page in the PDF rendering engine. It’s possible that GS is ignoring that rotate directive. Can you grep the files for ‘Rotate’ to see if there’s any correlation between it and the problematic files?

Good point. But Ghostscript, at least recent versions (just tried with
8.52), do honor the /Rotate setting. I’d suggest the OP to verify the
GS version used, and if the problem gets solved by an update. If using GPL Ghostscript, the latest version is 8.50 (released in December, see http://www.cs.wisc.edu/~ghost/doc/GPL/gpl850.htm). Note: not sure if GS had any bugs dealing with /Rotate, and if yes, exactly when these were fixed; in particular I don’t know if 8.50 is OK, but I hope it is (it’s not that far from the 8.52 I tested).

If this does not fix the problem, it would be a great idea to put a sample PDF somewhere publicly accesible and post the URL here.

Huh, I checked my "gs -version" and get:
GNU Ghostscript 7.07 (2003-05-17)
According to yum that’s the latest version.
GPL Ghostscript… sounds like I should change/upgrade to that… but, before I do, if I compile GPL GS on top of the existing GNU GS, will that cause problems? Kinda want to avoid any softaware that will end up stopping this box from working… and we don’t have a test server to try it on first. =/

Any suggestions?
(I don’t even know why I have GNU instead of GPL on it.)

wrote:

Huh, I checked my "gs -version" and get:
GNU Ghostscript 7.07 (2003-05-17)
According to yum that’s the latest version.

Are there other gs-* packages available? In Debian, there’s an old "gs" transition package and newer gs-gpl and gs-esp packages available. Perhaps your distro has something similar?

wrote:

…
Huh, I checked my "gs -version" and get:
GNU Ghostscript 7.07 (2003-05-17)
According to yum that’s the latest version.
GPL Ghostscript… sounds like I should change/upgrade to that… but, before I do, if I compile GPL GS on top of the existing GNU GS, will that cause problems? Kinda want to avoid any softaware that will end up stopping this box from working… and we don’t have a test server to try it on first. =/

Any suggestions?
(I don’t even know why I have GNU instead of GPL on it.)

For GNU <-> GPL Ghostscript see
http://www.ghostscript.com/article/41.html .