[metapost] Bug: wrong bounding box with mptopdf?
luecking at uark.edu
Wed Aug 13 19:40:27 CEST 2008
Oliver Buerschaper <oliver.buerschaper at mpq.mpg.de>, on Wednesday,
August 13, 2008, at 10:10 am, said
> there seems to be a bug with the bounding box handling in mptopdf
> see this test case:
> draw fullsquare scaled 3cm;
> TeXExec | processing graphic 'boundingbox.mp'
> This is MetaPost, Version 0.993 (Web2C 7.5.6)
This version can be updated to 1.004 (I think)
> PDF output:
The problem is that lines in a display have to be a whole number
of pixels. Which pixels get chosen to be in the lines depends on
the resolution of the display (pixels per inch), where the true
edges of the line happen to fall (i.e., some might land between
pixel boundaries), and what rule the display driver uses to round
these true edges to pixel boundaries.
Such concerns tend to disappear if you magnify the image ten-fold
or more, or if you print the image to a high resolution device.
On my screen, with Acrobat 7, the left and top edges appear slightly
smaller than the right and bottom at "fit-to-window" magnification.
That effect mitigates or disappears with larger magnifications.
This is discussed many, many (many!) times in comp.text.tex, usually
with regard to lines in a table next to colored cells, where the effect
is doubled due to both the lines and the cells competing for edge pixels.
Reading Knuth's discussion of rasterization in "The Metafontbook" is
a good way to get some insight. Metafont's rule is that a pixel is
taken if its center is inside the stroke. PostScript, on the other hand,
specifies that a pixel is taken if any part of it is inside the stroke.
This can lead to rather different results if one runs the same code
though Metapost and Metafont
More information about the metapost