I have tried this with TikZ that produces the same issue, you can try Leo's solution here. In other words, this issue is NOT specific to PSTricks.

The hidden idea is to avoid cropping with pdfcrop so I can improve my web-based system performance. Here I prepare a high resolution bounding box by setting the paper size in advance to tightly fit the PSTricks objects.

To get a simpler conversion constant, I also define a new unit for my own purpose, e.g., xp that stands for xport as follows:

1 inch = 2.54 cm = 2.5 xp = 72 bp

From this convention I have:

  • 1 xp = 1.016 cm It means there is an excessive of 0.16 mm for 1 xp
  • 1 xp = 28.8 bp

Here is the minimal working example for a standalone PSTricks picture.

% gridoff.tex
\def\xpbp#1{\strip@pt\dimexpr 28.8 \dimexpr #1 pt\relax\relax bp}


Note: I set the page color to cyan to ease me to identify whether or not the excessive strip exists in my main document importing the image.

I compiled it with

latex %1
dvips -R -t unknown %1 -o
ps2pdf -dAutoRotatePages#/None -dCompatibilityLevel#1.5 -dPDFSETTINGS#/prepress %1.ps
pdftops -eps %1.pdf

I got the following PDF result:

enter image description here

and EPS:

%!PS-Adobe-3.0 EPSF-3.0
% Produced by xpdf/pdftops 3.02pl4
%%Creator: dvips(k) 5.99 Copyright 2010 Radical Eye Software
%%Title: gridoff.dvi
%%LanguageLevel: 2
%%DocumentSuppliedResources: (atend)
%%BoundingBox: 0 0 116 87
%%HiResBoundingBox: 0 0 115.49 86.69

Note: There are rounding error in %%HiResBoundingBox above. The exact values should be 115.488 and 86.688.

I must confirm that this issue is not specific to my own unit xp but it also happens in cm. If you try the following code, you will get a cyan thin strip at the top.

% incm.tex


Problems and Questions:

However, when I magnified the PDF image 6400 times, I noticed there is a blue thin strip at the bottom as follows:

enter image description here

It should not be there because in theory PSTricks use dimen=outer by default.

  1. How to make the resulting EPS have exact high resolution bounding box 0 0 115.488 86.688 rather than 0 0 115.49 86.69?
  2. How to force PSTricks to work more accurately to get rid of the excessive strip as shown above?
  • At the beginning I assumed there is a conversion error because of not-so-simple constant 28.3464567 (=72/2.54) so I created my own unit as shown above. Apparently, my assumption is wrong. My simple constant 28.8 also produces the same issue. Now, I make a new prediction that that issue might be caused by internal PSTricks calculation. Jul 11, 2011 at 10:49

1 Answer 1


It is nearly impossible to get a correct image for such small values like the line width and the different units for PDF/PS and TeX: This one for example is correct.



And another one with other values and other rounding errors will not.

  • There is a new issue emerged. If we compile your code above, the resulting EPS does not have %%HiResBoundingBox. It has only %%BoundingBox. Jul 11, 2011 at 12:13
  • Why should it have a hires bounding box? It is exactly 120 x 90
    – user2478
    Jul 11, 2011 at 12:33
  • Using bp makes us difficult to plot a polynomial graph. Do you have idea? Jul 11, 2011 at 12:49
  • you have several conversions between different units. You cannot avoid rounding errors which are not seen when you print the image or view it with a magnification less than 1000%. I have more than 1000 images in my PSTricks book, all inserted as a pdf image and you will not be able to see any problem with the always existing rounding errors.
    – user2478
    Jul 11, 2011 at 12:53
  • 1
    No, not in general! bp is not the TeX unit, you always have conversions between TeX and pdf/ps.
    – user2478
    Jul 11, 2011 at 15:07

You must log in to answer this question.

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