Take the 2-minute tour ×
TeX - LaTeX Stack Exchange is a question and answer site for users of TeX, LaTeX, ConTeXt, and related typesetting systems. It's 100% free, no registration required.

I need a "perfect" pdfcrop, one that crops exactly to the edge of the figure or text for alignment issues as a graphic in other programs. I'm aware of the standalone package, and have gone through all the questions on pdfcrop including the --hires option. Neither solution crops to exactly to the edge. For example, using standalone:


enter image description here

and using pdfcrop --hires:

enter image description here

As you can see, pdfcrop is close, but I need something exact. I think that standalone only knows the width given by the glyphs and pdfcrop gets its information from gs. Is it possible to achieve a perfect crop using LaTeX or any external tool?

share|improve this question
A better test example is Ag\"e as you will also see the most top and bottom parts. –  I am who I say I am Jul 3 '12 at 3:38
I don't have this software, but the crop feature in Adobe Acrobat (Standard or Pro) might be worth trying. If I remember correctly, there is a feature in the crop tool to remove surrounding white space. –  JohnReed Jul 3 '12 at 5:36
@JohnReed: The feature is there but has similar “problems” like the other mentioned tools. So better trying before buying ;-) –  Chris Jul 27 '12 at 11:38
add comment

2 Answers

up vote 16 down vote accepted

To be able to crop a vector graphic reliably you must "print" it to see where the black dots are.

"Printing" always involves a resolution: the black dots must have a positive size.

pdfcrop uses the bbox device of ghostscript. According to the documentation of ghostscript the default resolution of this device is 4000 dpi.

You can change this resolution but simply enlarging it doesn't mean that you get a more "perfect" result: To be able to decide if a crop is "perfect" you must "print" it e.g. to a screen to see where the black dots are and on the lower resolution of the screen you will see your "exact" crop only at a very large zoom.

share|improve this answer
1] Is there a way to get a higher resolution than the setting of --hires (which I'm assuming is the 4000 dpi you are talking about)? 2] If a vector graphic is simply a collection of (bézier?) curves, isn't it possible to mathematically determine the bounding box without printing? –  Hooked Jul 3 '12 at 12:59
1. Theoretically yes. I can e.g. do something like this: C:\Test>mgs -dNOPAUSE -dBATCH -sDEVICE=bbox -r8000 -g800000x800000 test-utf8.pdf (mgs is the ghostscript in miktex). 2. I have no idea how difficult if would be to calculate a perfect resolution independant bounding box: But as the dots on your screen have a size they will no be able to stop exactly at this bounding box. You can't avoid the resolution issue. (And naturally the values don't need to be rational numbers). –  Ulrike Fischer Jul 3 '12 at 13:20
Link to gs documentation about bbox –  Paul Gaborit Jul 3 '12 at 17:26
add comment

To expand on Ulrike's excellent answer:

The reason this is only guaranteed after rendering the font to an actual pixel map is that there is, in principle, no obligatory relation between a glyph's ink and its bounding box.

Here's an example; a lower-case 'm' from URW Nimbus Sans:

font view of a glyph m

The left and right sidebearings (the space between the ink and the bounding box) are shown. TeX , of course, sets to the bounding box, and not the ink 'for typographical reasons'.

If precision copyfitting before the final pixel map rendering is important for you, a solution which allows you to access the sidebearing values is available with XeTeX, as described in this question. However, this is not guaranteed 100%.

share|improve this answer
Thank you very much for that link! I think it may be the solution I'm looking for. I'm also trying to learn the proper typographic vernacular, is ink the proper term here? –  Hooked Jul 3 '12 at 13:02
@Hooked: Don't know; I just pulled it out of the top of my head as being (probably) a clear name for what I was talking about... –  Brent.Longborough Jul 3 '12 at 15:27
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.