Issue 118898

Summary: OOO Draw adds 1 pixel in width and height when you copy something into buffer from it
Product: Draw Reporter: vzgudaai
Component: editingAssignee: Armin Le Grand <Armin.Le.Grand>
Status: CLOSED FIXED QA Contact:
Severity: Normal    
Priority: P3 CC: Armin.Le.Grand, issues, louqingle, vzgudaai
Version: OOO330m2   
Target Milestone: ---   
Hardware: PC   
OS: Windows XP   
Issue Type: DEFECT Latest Confirmation in: ---
Developer Difficulty: ---

Description vzgudaai 2012-02-10 15:30:05 UTC

When you trying to edit some image, paste it in OOO Draw from buffer, add some comments over it, when copy back to buffer - the picture became increased by 1 pixel in width and height.


Open some photo (with dark background better) in your favorite picviewer with fullscreen mode
Select all image and copy it into the buffer
Run OOO Draw and paste this picture into it
Inside Draw right click on inserted picture > select "initial size"
When create some object (e.g. square area) inside of inserted image area
Select both the objects (ctrl+A - select all, or manually) and copy them into buffer
Know run the new copy of your picture viewer, paste into it and run both instances of pic. viewer in full screen
Alt/Tab between two instances of pic. viewer in fullscreen
You will see that the original image was increased on 1 pixel in height and width (ie 800x600 > 801>601 etc) 
So the right and bottom sides of the picture now have nasty white lines of 1 pixel width
What interest: if you will select only the inserted photo as 1 object in Draw and copy/paste it into the pic.viewer - this error will not appear
But if you'll select more than 1 object, even invisible one (excluding picture itself) - it will
This behaviour make using Draw for commenting on pictures, adding graphics into them etc, some PitA
And it's a big shame, because without it the Draw would be way more comfortable for this task than GIMP etc 
(Though the Draw have not feature "Save/export selection as..." (as far as I know), but you always can select result of your edition and copy/paste it into irfanviewer etc and save from there in desirable format).

OOO330m20 (Build:9567)
Comment 1 Armin Le Grand 2012-02-15 10:58:47 UTC
ALG: There is a 'export selection', even several. But first infos to background: When inserting a graphic (bitmap or vector) a GraphicObject gets created, representing this content. When You add TextObjects and/or other graphic objects these are not added to the GraphicObject which may be displayed in the 'background' (behind the newly created objects). These new objects are (e.g. text) no pixel data and not part of the GraphicObject.

1: To export the original graphic: Select only the GraphicObject and use the context menu command 'Save as Picture...'.

2: To export more objects: Select all you want to export, use file/export... In the dialog appearing, choose format and name. Note the checkbox on the bottom of the dialog which says 'Selection'. When used, only selected objects are exported, else the whole page.

When using (2) with a single graphic object a shortcut is used internally and the original graphic gets exported. Else a new bitmap is rendered containing all the objects. That bitmap then gets exported in the selected format (for bitmap formats, vector create all vector AFAP).

In case of (2) where you see the problem a dialog will appear (in AOO3.4) which lets you choose resolution and DPI (also direct pixels). The export tries to choose a resolution which is derived from the size of the used objects on the page of the draw application, thus it will be different from the graphic size.

I will check the case you describe using the clipboard...
Comment 2 vzgudaai 2012-02-16 12:58:38 UTC
Thank you for info, Armin Le Grand.
I didn't know about "Selection" checkbox. Tryed it, but it performs exaxtly the same way, like my aсccustomed copy/paste method: there are white lines from left and bottom sides too. 
And the final picture have increased from 960x720 to 961x721.
(In reply to comment #1)
Comment 3 vzgudaai 2012-02-16 13:00:10 UTC
left = right side, of course
Comment 4 Armin Le Grand 2012-02-16 13:44:33 UTC
ALG: Thanks vzgudaai, that's what I saw, too, and what I'll investigate. I'd love to make Draw usable for your described purpose.
Comment 5 Armin Le Grand 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.
Comment 6 vzgudaai 2012-02-17 17:58:25 UTC
No problem, I understand the developer work may be very intricate.

Just an idea:
If the final image resolution while rendering is estimated like width+1 x height+1 comparing to the biggest selected source image, when just crop the right and bottom lines of the bitmap before the rendering into final formats.
May be it s more like crunch, than the leg, but no need to change internal mechanics for a while in return.

In fact, this idea is just a variation of what I often do manually to workaround this)
Comment 7 Armin Le Grand 2012-02-20 11:03:10 UTC
ALG: Hi vzgudaai. That's exactly what I tried to explain why this cannot be done. When doing this, painting a rectangle and converting this to bitmap would miss the right and bottom hairline what is not acceptable, happening often internally and would lead to a severe and visible error. Unfortunately there is no simple differentiation between cases where a hairline will be lost and where not.
Comment 8 vzgudaai 2012-02-20 20:20:03 UTC
Hi, Armin Le Grand
Your explanations wasn't in wain. I was close to understand that, but it's so strange to see that something correctable in several clicks from outside can not be righted out so easily from within the program.

Am I correct that, when this issue will be fixed, it's status here on tracker will be changed from CONFIRMED to RESOLVED?
Or there is a better way to know about it?
Comment 9 Armin Le Grand 2012-02-21 09:35:20 UTC
ALG: Hi vzgudaai; Yes, you are correct about status change (CONFIRMED to RESOLVED). Don't forget that the code involved was grown over more than a decade and AntiAliasing was not an option at that time. It will need some internal changes to do it correct, so - sorry - it is not easy fixable. There is another way to get informed: you may add yourself to the CC list of the task. I'll do that now; please remove yourself again when you did not want that.
Comment 10 vzgudaai 2012-02-23 00:00:55 UTC
Thank your for adding and good luck to you and your comrades in this great development work, Armin Le Grand.
I hope this issue will be righted out, because it's basic and may provoke unwanted code solutions in the future.
Comment 11 Armin Le Grand 2012-02-24 16:14:46 UTC
ALG: Adapted ImpGraphic::ImplGetBitmap to correctly convert metafiles to bitmapEx, dynamically expanding needed bitmap size right and bottom dependent of having a hairline there. To check this, I adapted GDIMetaFile::GetBoundRect to be able to deliver the HairlineBoudRect inn parallell to the regular geometry one. This solves the task fo rthe moment with minimal invasive changes and based on the old techniques.
Also adapted the graphic generators in SdrExchangeView (GetMarkedObjMetaFile, GetMarkedObjBitmapEx, removed inine versions) to work with BitmapEx. This allows gererating better quality results when converting to Bitmap, e.g. an ellipse will no longer have a withe background after conversion, but is transparent.
Committed in r1293316.
Comment 12 Armin Le Grand 2012-05-04 15:09:26 UTC
ALG: Fixed in AOO3.4 RC
Comment 13 vzgudaai 2012-05-25 09:41:37 UTC
Dear Armin Le Grand,
I just downloaded OOo v3.4.0 and for the first time this feature is working like a charm, thanks to efforts of you and your colleagues.
Most of the people won't even notice this correction, but for the programmer it's hours and hours of hard work.
Though I believe it's not only my personal inconveniences, that induce you to make this patch. It's also a professional good faith, that the software must work correctly and logical. But nevertheless, for me it was really really Grand .) help. No more problems with picture commenting.
Thank you very much!
Comment 14 Armin Le Grand 2012-05-25 18:27:27 UTC
ALG: Hi vzgudaai,

thanks that you noticed it. I hope you like AOO3.4, it was some work :-) A warm thank you for leaving a note, this is what motivates all of us!
Comment 15 louqle 2012-09-06 02:52:23 UTC
close according to reporter's comments 13