Apache OpenOffice (AOO) Bugzilla – Issue 84905
graphics change appearance when pasted as GDI Metafile
Last modified: 2013-10-11 10:35:31 UTC
1) open Paint 2) open the attached graphic with Paint 3) in paint choose "select all" and copy the graphic to the clipboard 4) Open a new blank page in witer. Ensure that the zoom factor is 100% so that an inserted image has the same resolution as original. 5) paste the graphic You will see that 2 lines are missing. The image should appear in the same way as in Paint.
Created attachment 50595 [details] image to be pasted in writer
Happens in any OOo Application. MRU->CGU: happens only when the graphic is pasted as GDI Metafile. Pasting as "Bitmap" via 2Edit.Paste special" dialog works as expected. Please reassign to appropriate developer. Thanks!
I can reproduce the bug in src680m236.
Created attachment 59506 [details] raster file to reveal deformations when pasting it into Writer
I attached a second graphic to this case with not only horizontal but also vertical lines. By inserting this graphic with the simple Paste function you will see not only a horizontal but also a vertical deformation. Please regard this case as extended to this kind of deformation. Because version 3.0.0 is now published I want to ask you to set a specific Target milestone. Please have a look on case http://www.openoffice.org/issues/show_bug.cgi?id=98256 too. This case shows that there is no way where graphics are handled really correctly. You always have problems with deformations when working with graphics with single pixel lines or with sharp outlines.
Possibly the same or a related problem that I had with OO 3, and still have with OO 4 is losing columns when pasting a large table from calc to writer as a GDI metafile: all columns which do not fit on the page are simply missing. Pasting as bitmap (I tried just now) pastes a tiny 0,04 x 0,04 cm object which when enlarged is simply a frame that reads 'Read error' (or something like that; translated from the Italian 'errore di lettura'). Pasting as a calc object seems to work fine, although for some documents I'd rather have unmodifiable images than modifiable calc tables...
(In reply to darwinbot from comment #6) > Possibly the same or a related problem that I had with OO 3, and still have > with OO 4 is losing columns when pasting a large table from calc to writer > as a GDI metafile: all columns which do not fit on the page are simply > missing. > Pasting as bitmap (I tried just now) pastes a tiny 0,04 x 0,04 cm object > which when enlarged is simply a frame that reads 'Read error' (or something > like that; translated from the Italian 'errore di lettura'). > Pasting as a calc object seems to work fine, although for some documents I'd > rather have unmodifiable images than modifiable calc tables... ...and now that I've tinkered a bit more, it's actually copying bug, rather than a pasting one, since the table won't even be pasted in calc with all its columns... Since I have no experience of programming, etc., and have no idea of the underlying issues, should this be a new bug?
(In reply to darwinbot from comment #7) > > Possibly the same or a related problem that I had with OO 3, and still have > > with OO 4 is losing columns when pasting a large table from calc to writer > > as a GDI metafile: all columns which do not fit on the page are simply > > missing. > > Pasting as bitmap (I tried just now) pastes a tiny 0,04 x 0,04 cm object > > which when enlarged is simply a frame that reads 'Read error' (or something > > like that; translated from the Italian 'errore di lettura'). > > Pasting as a calc object seems to work fine, although for some documents I'd > > rather have unmodifiable images than modifiable calc tables... > > ...and now that I've tinkered a bit more, it's actually copying bug, rather > than a pasting one, since the table won't even be pasted in calc with all > its columns... > > Since I have no experience of programming, etc., and have no idea of the > underlying issues, should this be a new bug? the bug with paste as bitmap from Calc to Writer is described in bug 122982 and fixed in 4.0.1, please update your 4.0.0 version and try the fix. The bug with the GDI metafile might be solved or not; if not, please open a new bug report, this one is rather old from 2007.
(In reply to Ariel Constenla-Haile from comment #8) > (In reply to darwinbot from comment #7) > > > Possibly the same or a related problem that I had with OO 3, and still have > > > with OO 4 is losing columns when pasting a large table from calc to writer > > > as a GDI metafile: all columns which do not fit on the page are simply > > > missing. > > > Pasting as bitmap (I tried just now) pastes a tiny 0,04 x 0,04 cm object > > > which when enlarged is simply a frame that reads 'Read error' (or something > > > like that; translated from the Italian 'errore di lettura'). > > > Pasting as a calc object seems to work fine, although for some documents I'd > > > rather have unmodifiable images than modifiable calc tables... > > > > ...and now that I've tinkered a bit more, it's actually copying bug, rather > > than a pasting one, since the table won't even be pasted in calc with all > > its columns... > > > > Since I have no experience of programming, etc., and have no idea of the > > underlying issues, should this be a new bug? > > the bug with paste as bitmap from Calc to Writer is described in bug 122982 > and fixed in 4.0.1, please update your 4.0.0 version and try the fix. > > The bug with the GDI metafile might be solved or not; if not, please open a > new bug report, this one is rather old from 2007. Thanks, updating now--wasn't yet aware there was a new version out there! Will see about GDI bug.
(In reply to uwegalle from comment #0) > 1) open Paint > 2) open the attached graphic with Paint > 3) in paint choose "select all" and copy the graphic to the clipboard > 4) Open a new blank page in witer. Ensure that the zoom factor is 100% so > that > an inserted image has the same resolution as original. > 5) paste the graphic > > You will see that 2 lines are missing. The image should appear in the same > way > as in Paint. The original bug report seems to be fixed in 4.0.1 Can anyone else confirm?
Actually, I tried the exact procedure now, and I have no idea if this is relevant, but a simple paste in Writer produces an image with anti-aliasing, so that not only is it different from the original png file, but also the top-most line is only half the original width (and one line is missing too). Paste as Paint Image gives a square image with anti-aliasing, whereas the original is rectangular; paste as GDI metafile and as bitmap give two seemingly different anti-aliased images, similar to the ctrl+v simple paste. So maybe it's just me (using Rev. 1524958), and maybe the original bug is not there anymore, I just can't tell, with this other odd behaviour...
Created attachment 81694 [details] test odt file with test images pasted from paint
(In reply to darwinbot from comment #11) > Actually, I tried the exact procedure now, and I have no idea if this is > relevant, but a simple paste in Writer produces an image with anti-aliasing, > so that not only is it different from the original png file, but also the > top-most line is only half the original width (and one line is missing too). > Paste as Paint Image gives a square image with anti-aliasing, whereas the > original is rectangular; paste as GDI metafile and as bitmap give two > seemingly different anti-aliased images, similar to the ctrl+v simple paste. I see this too, but looks like another bug, something like "Pasting (from MS Paint) does not paste the original image 'as is'"; that is, not only related to GDI Metafile, and not only related to Writer (it is reproducible in Draw too). I guess the user expectation is to get exactly the same image, at least pasting in one of the available formats. Please open another bug with your findings. Setting Armin on CC. In the meantime, another (may be unrelated) bug: [Bug 123407] Paste as bitmap from MS Paint does not paste anything
ALG: Took a look, the image has 53 lines, 27 black, at start end black. In draw, 27 black lines are shown, the start one is half and the end one 1 1/2. Images get AAed since else the quality would be bad for most images; the program can not 'guess' that someone does not want that for a special image. If you want clear bounds in a scalable image, use a vector graphic one (e.g. produce in draw), this will cleanly scale in all situations what is not possible with bitmap images. It will also be smaller and can be used as zoom-freindly fill style since 4.0.0. In Writer it's pretty much the same, 27 black lines shown, the 1st a little bit too thin, the last to thick. The AAing is more bad in writer since for writer graphic objects the AAing is still drawn hand-crafted from the VCL module AFAIK, but no lines missing. What stays is the too small first and too fat last line, this hints to a pixel offset of 1/2 pisel in graphic processing. That part is also system-dependent, thus my be different on linux/mac and win, I checked on win.