Created attachment 48309 [details] EMF file with problem LibreOffice doesn't import attached EMF file properly. 1. Some strokes are missed. 2. There are glitches around yellow/green leds, fiber and db9 connectors. I'm attaching also a screenshot (half of the picture, because it's symmetrical) how it looks in MS Office.
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
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.0.4 or later) https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-12-20
Still the same as in Comment 31. LibreOffice 5.2.1.1/Windows 7.
Setting Assignee back to default. Please assign it back to yourself if you're still working on this issue
Hi, there is a completely new EMF+ parser in development. Code is already to find in cppcanvas/source/tools. Your picture was one of my benchmarks for the implementation, thanks! In a few days the new parser will be activated and completely resolves this bug! Feedback is always welcome :)
Bug is fixed in current master, due to the new EMF+ renderer! Feedback is welcome :)