Bug 38580

Created attachment 48310 [details]
Screenshot of the same file in MSO

Looks like problem in path rendering and radial gradients

Reproduced with

LO 3.4.1 (OOO340m1 (Build:101))
Ubuntu 10.04.2 x86
Linux 2.6.32-32-generic Russian UI

Created attachment 48711 [details]
Comparision of 2 images

2 images with highlighted differences.

My results are very similar with 
"LibreOffice Portable 3.3.3  - WIN7  Home Premium (64bit) German UI [OOO330m19 (Build:301  Tag 3.3.3.1)]" 
"LibreOffice 3.4.3  - WIN7 Home Premium (64bit) German UI [OOO340m1 (Build:302)]" 
Server installation of Master "LibO-dev 3.5.0 – WIN7 Home Premium (64bit) English UI [(Build ID:  3b32204-7f92fce-2ba0a9f)]" (110903)

For details see "screenshots.pdf) (tests without anti aliasing, no ibg changes activating anti aliasing)

My PC:
64 bit AMD Phenom II X4 955 Processor 3.2 GHz, 4GB RAM, 
Graphic Card: NVIDIA GeForce GT 430

I can confirm some of reporter's problems (screenshots item 4
Most other are not visible-
Some problems I see were not visible in reporter's comparision to MSO (screenshots items 11-16). So some problems might be OS or video card related (or even LibO version related, but I doubt.)

@Valek Filippov:
With what LibO version and OS did you do your tests?

> @Valek Filippov:
> With what LibO version and OS did you do your tests?
Most likely it was 3.3.3 on Linux.
I've just tried with LibO from few days old git master -- same result.

EMF is vector, so it's possible to scale and exclude any possible videocard rasterisation problem.
Close look shows that all 'glitches' could be just one problem with elliptic arc radii calculations.
I will try to reduce test file to few dozens of records.

Created attachment 52134 [details]
Reduced file

You need to scale ~800% to see the image.
The only important record is the 2nd 'GDI Comment'.
It has one path with 13 coord pairs, which make 
 Start/11 Bezier/CloseSubPath Bezier.

(This one could be useful to review EmrPlusPath Object
http://msdn.microsoft.com/en-us/library/cc230895%28v=PROT.10%29.aspx)

Since all new unconfirmed bugs start in state UNCONFIRMED now and old unconfirmed bugs were moved to NEEDINFO with a explanatory comment, all bugs promoted above those bug states to NEW and later are automatically confirmed making the CONFIRMED whiteboard status redundant. Thus it will be removed.

Created attachment 58105 [details]
Paste/open Metafile error

I have similar problems with my EMF files and same with paste as GDI metafile. Example see attachment https://www.libreoffice.org/bugzilla/attachment.cgi?id=58105

Problem still exists in version 3.5.1

Problem still exists in version 3.5.2

btw, anybody listening?

I am trying to fix that problem. Meanwhile you can switch off cairo canvas (Options: View/Use Hardware acceleration) as workaround.

The problem with broken circles (generally with bezier polygons in cairo canvas) is now fixed in master.

There still remains problem with border lines around connectors. Valek, could you please extract simple test case for that issue as well?

Created attachment 59884 [details]
Reduced test file as per Radek request

Problem is reproduced with this reduced file too

Created attachment 59885 [details]
File reduced even more

With this file there is no problem

Radek, this one is quite interesting...
I've reduced file by removing most of the records from it.
Content of the reduced file is ~ 3 polygon16 and 1 polyline16.
(That's the file in the attachment id=59885).
LibO draws polygons and line.

I've added few records back (attachment id=59884) and finally triaged it to the 2nd EMF+ record. This is the 3rd record in the original (and id=59884) files and it has "path/fill path" commands.
Polygons/polyline are record 40 to 43 in file 59884, hence they should be stroked on top of anything painted before.
Somehow they probably appear under "path" from record 3.

(I can't ungroup opened EMF image, therefore cannot prove that polygons were actually stroked under grey shape. I will try to replace "fill path" with "stroke path" in the record 3 later, to check it.)

Attachment id=59884 is emf only (not plus) metafile. So it might even be related to emf/emf+ records switching.

Valek, thanks a lot for the reduced test case. Because of it I was able to trace it to pen with width set to zero, which turned out to mean "use minimal width".

Created attachment 59953 [details]
Reduced file00023.emf with a couple of PathGradienBrush sub-records.

Created attachment 59954 [details]
Screenshot with highlighted PathGradienBrush problems

Radek, see attached file reduced for PathBrushGradient records and screenshot with the problem.
Looks like PathGradient centre is placed at wrong place (swapped centre and edges?)

http://msdn.microsoft.com/en-us/library/cc230898%28v=prot.10%29.aspx

Docs on PathGradientBrush.

Switching off hardware acc. as in 
https://bugs.freedesktop.org/show_bug.cgi?id=38580#c13
does not help. 

I think I wait for next release and see if your fixes help.

I have looked at the problematic gradients. They are Path gradients and unfortunately we don't have necessary feature available in Canvas yet.

Good news is that since I last checked that, Cairo now supports Mesh gradients, which might be used for Path gradients. OTOH, it will need quite some time to support, as we will need to extend Canvas API and add support to Cairo canvas backend and maybe even extend cppcanvas module and use these in emf+ renderer. 

Not sure yet what to do in other backends - probably use circular gradients as we do now. Hopefully DirectX might have some feature to use for Path gradients as well. Didn't check that yet.

Please do not use https://www.libreoffice.org/bugzilla/*, use https://bugs.freedesktop.org/* URLs instead..
Thanks

Florian R.

(In reply to comment #24)
> Switching off hardware acc. as in 
> https://bugs.freedesktop.org/show_bug.cgi?id=38580#c13
> does not help. 
> 
> I think I wait for next release and see if your fixes help.


hi could you please give us an update about this issue with current 4.1.5 or 4.2.0 releases?

No, still doesn't work. To import my drawings I use OpenOffice 2.4, this still works.

(In reply to comment #10)
tam@gmx.org,
I suppose that you are describing some different problem in your comment 10.
I cannot decide on the status of the original issue (because it was reopen by an expert in this area, while I see the original image is imported MUCH better and closer to MSO), but your case is clearly different, as you say it hasn't improved. To help developers concentrate on specific problems, and keep track of the progress, it is required to limit each issue to one problem.
Also, to be able to reproduce your specific problem, devs need to be able to paste from clipboard the same data as you.

So, I advise you co file a separate issue here for your problem, and attach the problematic clipboard data captured with a tool like InsideClipboard, so that one could reproduce this without having CorelDRAW or some other software installed.

I'll try to reproduce it and confirm if you CC me there.
Thank you for reporting!

Radek, please tell if it is OK to CC you to NEW bug reports regarding WMF/EMF(+), as you are expert LO hacker in this area?

never confirmed by QA team - moving to UNCONFIRMED.

(In reply to Valek Filippov from comment #20)
> Created attachment 59953 [details]
> Reduced file00023.emf with a couple of PathGradienBrush sub-records.

I confirm it still looks like the screenshot in attachment 59954 [details].
Tam should file a separate report like suggested in comment 29.
I'm setting this as NEW since Radek is not apparently working on LibO anymore.

Win 7 64-bit Version: 4.4.0.0.alpha2+
Build ID: b021b5983c62e266b82d9f0c5c6d8d8900553827
TinderBox: Win-x86@39, Branch:master, Time: 2014-11-12_01:10:08