# The perfect pdfcrop

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:

\documentclass[crop]{standalone}
\begin{document}
Hi
\end{document}


and using pdfcrop --hires:

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?

• A better test example is Ag\"e as you will also see the most top and bottom parts. – kiss my armpit 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
• – Steven B. Segletes Aug 19 at 16:34

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.

• 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

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:

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%.

• 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

Expanding the comment of @ulrike-fischer, as it contains the solution that works in most of the cases I deal with - and as I guess this might help in many similar situations:

If your goal is to have no margins, and if pdfcrop crops/clips/moves parts of the content beyond the image borders, or if there remain some margins, then a combination of higher resolution (--hires) and larger image scaling (--resolution WIDTHxHEIGHT) might be a quick and practical solution:

pdfcrop --hires --resolution 1000x1000 my.pdf

If it needs to be more exact, then increase the resolution further:

pdfcrop --hires --resolution 50000x50000 my.pdf

In most cases I deal with this solves the problem in a quick and practical way, though there might be special cases where this is not exact enough.