I have a PDF document created from the following input file.


\fbox{$\displaystyle E=mc^2$}

But it cannot be cropped by pdfcrop because of the non-white background. I think the non-white background has affected the bounding box. So how to fix this isssue?


The pdfcrop author said in Martin's and Lev's reports as follows:

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

  • pdfcrop uses gs -sDEVICE=bbox internally to get the bounding box information. The page color might be created by a large colored rectangle in the background, which is then taken as part of the bounding box by Ghostscript. I would look for options for it to maybe ignore certain colors. Or you try to feed the bounding box data to it manually, i.e. by creating an identical file without page colors and take this as reference. Jul 13, 2011 at 9:06
  • BTW: I just figured out that \pagecolor doesn't work with preview (and therefore not with standalone). Jul 13, 2011 at 9:23
  • Note that the above isn't the official bug report (which should go to the Ghostscript bug tracker), but the discussion on the TeX usenet group comp.text.tex. I liked to see what other people think about it before opening a full bug report. Jul 14, 2011 at 7:20
  • 2
    @Martin The gs bbox device has setting /WhiteIsOpaque (default false) that tells it to ignore, eg, a white rectangle in the background. With gs8.71 setting this true gives same non-cropping as you saw with gs9.00. So, with gs8.71 "white" covered various colours, whereas with gs9.00 "white" really seems to mean white.
    – Lev Bishop
    Jul 15, 2011 at 17:55
  • @Martin: Response to your comment, "BTW: I just figured out that \pagecolor doesn't work with preview (and therefore not with standalone).", what compiler did you use? Jul 30, 2011 at 9:40

2 Answers 2


I would do it another way around: (This might actually solve some other issues of you)

Place the whole thing in a savebox in the preamble. (You have to manually enable the normal font use \normalfont for this AFAIK.) Then you can measure the dimensions of the box and set the page dimensions accordantly. This will give you a PDF or PS which already has to correct size. For larger content I recommend to use a minipage wrapper as usual.

The \pagecolor command still works here. I would have thought you manually need to place a colored rectangle (\rule) with the same size behind the content.

The following works for me using pdflatex (PDF), latex->dvips1 (PS), latex->dvips1->ps2pdf (PDF), xelatex and lualatex and produces a correctly sized file.

1 without any options, no -E required


    \fbox{$\displaystyle E=mc^2 $}%

\sbox0{\raise\dp0\box0}% raise box so it is all height, no depth
%\sbox0{\rlap{\textcolor{cyan}{\rule{\wd0}{\ht0}}}\box0}% \pagecolor surprisingly works so this is not needed




  • @xport: Note that instead of box #0 you might want to use an own savebox using \newsavebox\mysavebox. Jul 13, 2011 at 10:19
  • @xport: lrbox is the environment version of \savebox and can replace by it. I personally just prefer environments before macro in such cases because they allow verbatim mode and are more efficient, both because the whole text doesn't has to be read as macro argument first. \sbox is the short version of \savebox. \box is the primitive version of \usebox but deletes the box afterwards, so can only be used once. Boxes are also simply accessed by number, so \newsavebox\mysavebox will make \mysavebox a number (identical to the next box register which was free). Jul 13, 2011 at 11:21

For what it's worth, I've had a similar problem but needed a different solution. My PDF was generated by a third-party but had a white rectangle used as a background, so that pdfcrop was still recognizing the bounding box as including the margins.

The Python module pdf-crop-margins was very helpful, and - well - simply worked. For non-white backgrounds it seems to have -t switch (--threshold) which allows you to specify sensitivity to background darkness. I'm not sure how well it would do in other cases where the text is lighter than the background, but maybe it has other switches as well.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .