Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||insert as bitmap from clipboard or convert to bitmap adds 1 pixel if anti-aliasing is used|
|Product:||Draw||Reporter:||Regina Henschel <rb.henschel>|
|Component:||editing||Assignee:||AOO issues mailing list <issues>|
|Status:||UNCONFIRMED ---||QA Contact:|
|Issue Type:||DEFECT||Latest Confirmation in:||---|
Description Regina Henschel 2012-08-28 19:28:31 UTC
1. Set the page background to blue to make the error better visible. 2. Make sure "Use Anti-Aliasing" is checked in Tools > Options > OpenOffice.org > View. 3. Draw a rectangle and set its fill color to black and border line to invisible. 4. Copy the rectangle to clipboard and insert it "as bitmap". Notice the light line at top and left. If you save the picture and examine it, you can notice, that it is a 1 pixel gray border. Alternative: 4. On the rectangle do context menu > Convert > To bitmap. There is no need for additional gray pixels for horizontal or vertical lines. And if it is intended to have them because of anti-aliasing, they should be on all four edges. Workaround: Uncheck "Use Anti-Aliasing" when inserting as bitmap or converting to bitmap.
Comment 1 Armin Le Grand 2012-09-03 15:48:59 UTC
ALG: Added myself to CC
Comment 2 Armin Le Grand 2012-09-04 16:29:49 UTC
ALG: Caused by AA coordinate interpretation (even system-dependent). The top-left corner of the example - with non-AA: fills the first row and column of pixels - with AA: Fills it half The pixel coordinates in AA (on system-level) are interpreted as mid-pixel, probably to be most compatible with the non-AA behaviour to always fill to the bottom-right. In an ideal world the coordinates would be on the grid crossing points, thus a 1 pixel wide line would fill half of the first pixel row and half of the one above. This would be in analogy to fat lines (more than one pixel) being centered to their geometric definition. This *can* be done (by substractiong 0.5 in X and Y in AA mode to all coordinates) and nothing would neeed to be adapted. The big (and unacceptable) caveat is that there would be no hairlines anymore; all 1 pixel lines (the hor/ver ones) would cover two actual pixel lines, each with half intensity. This is very tricky and there is no simple and good solution. In this case all conversions to bitmap would have to make exceptions to draw the geometry differently from the discrete screen representation. A related problem is: A logically 100x100 pixel object with a hairline will be 101x101 pixels when converted to bitmap, thus the logical object size would need to be changed when converting to bitmap. There should be better possibilities to solve such cases when the core is on full double precision...