[metapost] Bug: wrong bounding box with mptopdf?

[Daniel Luecking]

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:
> 
> ---
> beginfig(1);
>     draw fullsquare scaled 3cm;
> endfig;
> 
> end

[...]

> 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


Dan