https://issues.apache.org/ooo/show_bug.cgi?id=118898
Armin Le Grand <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |CONFIRMED Ever Confirmed|0 |1 --- Comment #5 from Armin Le Grand <[email protected]> 2012-02-17 10:50:26 UTC --- ALG: Harder than I thought. The problem is an old conceptual one. Indeed one pixel is added (in a complicated way :-)) in X and Y when rendering content to a bitmap. Reason is the usage of hairlines; these are defined to be one pixel wide, independent from the resolution. This makes them resolution-dependent graphics, so when being precise, e.g. for an ellipse, the hairline around it would be 1/2 pixel inside and 1/2 pixel outside of it, thus a bitmap prepared to render it would need to take the geometry bounds of the ellipse and add one pixel even in all four directions. Here comes in another old convention (mainly from pre-AA times): Single pixel stuff is snapped to the next pixel right and down, so adding one in X and Y is sufficient. Since VCL is based on that conventions it is not possible to change it there: Getting the range (BoundRect) of e.g. the in-between created metafile is simply not able to take care of this, alone because of using integer for the coordinates, but also by handling hairlines as width zero. All this is handled with primitives, thus a bitmap with an ellipse with hairline completely inside would give the bounds of the bitmap (as expected), and with the ellipse outside would add the needed space for the 1/2 pixel (as expected). Unfortunately primitives cannot be used in VCL currently and this would be a too big change for 3.4. Just removing the currently used extra pixel is no option; a rectangle with hairline would then always use the bottom and right hairline visualisation. Thus, this is a task for after 3.4, sorry for the moment. -- Configure bugmail: https://issues.apache.org/ooo/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
