pdfcrop and \pagecolor -- Works with Ghostscript 8.63 but not with 9.01

[Martin Scharrer]

There seems to be a new issue with GPL Ghostscript 9.01 when using `xcolor`s `\pagecolor` command in an document which should be cropped using `pdfcrop`.

The following minimal working example leads will not be cropped as long the \pagecolor is not removed.

\documentclass{article}
\usepackage{xcolor}
\begin{document}
\pagecolor{red}
Hello
\end{document}

This was tested with the following software under Ubuntu Linux 11.04:

- TeXLive 2010 (manually installed and fully updated)
- pdfTeX 3.1415926-1.40.11-2.2 (TeX Live 2010)
- PDFCROP 1.31, 2010/09/17
- GPL Ghostscript 9.01 (2011-02-07)

The `pdfcrop` command used was `pdfcrop --verbose --hires --restricted`.

Here the verbose output:

PDFCROP 1.31, 2010/09/17 - Copyright (c) 2002-2010 by Heiko Oberdiek.
* PDF header: %PDF-1.5
* Running ghostscript for BoundingBox calculation ...
GPL Ghostscript 9.01 (2011-02-07)
Copyright (C) 2010 Artifex Software, Inc. All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
Processing pages 1 through 1.
Page 1
%%BoundingBox: 0 0 612 792
%%HiResBoundingBox: 0.000000 0.000000 611.999981 791.999976
* Page 1: 0.000000 0.000000 611.999981 791.999976
* Running pdfTeX ...
This is pdfTeX, Version 3.1415926-1.40.11 (TeX Live 2010)
entering extended mode
(./tmp-pdfcrop-7571.tex [1 <./colorback-temp.pdf>] )
Output written on tmp-pdfcrop-7571.pdf (1 page, 2506 bytes).
Transcript written on tmp-pdfcrop-7571.log.
==> 1 page written on `colorback.pdf'.

However using a different machine (Windows, MikTeX) and
GPL Ghostscript 8.63 (2008-08-01)
The same file is properly cropped:

PDFCROP 1.31, 2010/09/17 - Copyright (c) 2002-2010 by Heiko Oberdiek.
* PDF header: %PDF-1.5
* Running ghostscript for BoundingBox calculation ...
GPL Ghostscript 8.63 (2008-08-01)
Copyright (C) 2008 Artifex Software, Inc. All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
Processing pages 1 through 1.
Page 1
%%BoundingBox: 92 709 115 717
%%HiResBoundingBox: 92.195997 709.937978 114.011997 716.957978
* Page 1: 92.195997 709.937978 114.011997 716.957978
* Running pdfTeX ...
This is pdfTeX, Version 3.1415926-2.3-1.40.12 (MiKTeX 2.9)

entering extended mode

("C:\Documents and Settings\Lev\Desktop\vrabipaper\thesis\test\pdfeps\tmp-pdfcr

op-3144.tex" [1 <C:/Documents and Settings/Lev/Desktop/vrabipaper/thesis/test/p

dfeps/colorback-temp.pdf>] )

Output written on tmp-pdfcrop-3144.pdf (1 page, 2566 bytes).

Transcript written on tmp-pdfcrop-3144.log.

==> 1 page written on `colorback.pdf'.

As it can be seen the returned bounding boxes are different. Ghostscript 9.01 returns the full page instead of the actual content.

Is there anything which can be done about this?

Best Regards,
Martin Scharrer

[Lev Bishop]

To be more precise, the difference seems to come between gs8.71 and gs9.00.

[Heiko Oberdiek]

Martin Scharrer <martin....@gmail.com> wrote:

> There seems to be a new issue with GPL Ghostscript 9.01 when using `xcolor`s `\pagecolor` command in an document which should be cropped using `pdfcrop`.
>
> The following minimal working example leads will not be cropped as long the \pagecolor is not removed.
>
> \documentclass{article}
> \usepackage{xcolor}
> \begin{document}
> \pagecolor{red}
> Hello
> \end{document}

The PDF format does not know a "page color". pdftex.def implements it
by putting a colored box as first thing on the page. Thus it is not
quite clear for a program what kind of boxes are valuable content
and what could be cropped.

To get a properly cropped image, you can run the TeX document
without \pagecolor and run
gs -sDEVICE=bbox -dBATCH -dNOPAUSE test.pdf
to get the bounding box data. It you are using hyperref,
you can use the Bounding Box data for option pdfpagescrop.
Or run pdfcrop with option --box and the Bounding Box data.

--
Heiko Oberdiek

[Martin Scharrer]

On Wednesday, 13 July 2011 22:31:29 UTC+1, Heiko Oberdiek wrote:
> Martin Scharrer <martin....@gmail.com> wrote:
>
> > There seems to be a new issue with GPL Ghostscript 9.01 when using `xcolor`s `\pagecolor` command in an document which should be cropped using `pdfcrop`.
> >
> > The following minimal working example leads will not be cropped as long the \pagecolor is not removed.
> >
> > \documentclass{article}
> > \usepackage{xcolor}
> > \begin{document}
> > \pagecolor{red}
> > Hello
> > \end{document}
>
> The PDF format does not know a "page color". pdftex.def implements it
> by putting a colored box as first thing on the page.

I thought that it was handled like this, which makes perfectly sense. My first workaround to this issue was to create the background color as a colored \rule of the right size by myself. I then decided to measure the content first (i.e. boxing it in the preamble) and set the page size accordantly instead. (http://tex.stackexchange.com/questions/22939/pdfcrop-fails-to-crop-a-pdf-document-with-non-white-background/22951#22951)

> Thus it is not
> quite clear for a program what kind of boxes are valuable content
> and what could be cropped.

This is understandable. The confusing this was just that it worked for Lev Bishop (we where in previous contact) but not for me and others.
We could track it down to the different Ghostscript versions. So apparently the technique for handling this has been changed between the two versions of Ghostscript.

> To get a properly cropped image, you can run the TeX document
> without \pagecolor and run
> gs -sDEVICE=bbox -dBATCH -dNOPAUSE test.pdf
> to get the bounding box data. It you are using hyperref,
> you can use the Bounding Box data for option pdfpagescrop.
> Or run pdfcrop with option --box and the Bounding Box data.

Yes, I thought something like this should be possible.
I saw the options of pdfcrop but didn't knew about pdfpagescrop.

Thanks you very much,
Martin