Graphics in WordPerfect .wpd files show as black and white when they are actually color. Currently seen in nightly build target 4.3.1 for OS X (seems to be Mac-specific). WordPerfect .wpd - test file is imported and displayed but the color graphics in the test file display BLACK AND WHITE. Obtain test file as posted at http://resource.dopus.com/viewtopic.php?p=61641 as the Quick View Plus sample file (see wrdprfct.zip) TESTED VERSION COMPARISON (OS X) Nightly build - Use this to reference problem as earliest version seen, since WordPerfect import (and other importers) works again on Mac OS X in this build libreoffice-4-3~2014-08-05_07.27.10_LibreOfficeDev_4.3.1.0.0_MacOS_x86.dmg LibreOffice 4.3.0 release - WordPerfect .wpd files do NOT import at all due to bug #82035, so not relevant LibreOffice 4.2.6 release - WordPerfect .wpd files import and display properly, including color graphics
Hello pinertech, Thank you for submitting the bug. I can confirm that the bug is available in 4.3.1 and master on Linux. The bug only shows in the interface and not when you export it to PDF.
Created attachment 104129 [details] 4.2.6 vs 4.3.1
Created attachment 104154 [details] Wordperfect document
bibisected: 7e673c13a5ce2578df74ab1491b1ab3389e9d4cc is the first bad commit commit 7e673c13a5ce2578df74ab1491b1ab3389e9d4cc Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com> Date: Mon May 12 10:53:29 2014 +0000 source-hash-cddf4bd65fb4ce5615ca770946707d0db657e8ec commit cddf4bd65fb4ce5615ca770946707d0db657e8ec Author: Tor Lillqvist <tml@collabora.com> AuthorDate: Sat Apr 12 23:35:37 2014 +0300 Commit: Tor Lillqvist <tml@collabora.com> CommitDate: Sat Apr 12 23:35:37 2014 +0300 HEADER_SEARCH_PATHS is duplicated for Debug and Release Change-Id: Ifbed4933f528342300642673d707c8189eda1e8c :100644 100644 c91cd8360bfcddfe2b370ce731a5c0c7af518464 487e04e7487e5538655b5a0ee2c776c3cdec2ec4 M ccache.log :100644 100644 0e16c65b97a3d606c7a6da97b6b9dcea98af2a66 4400ff24ca61e361d48a7fcc74e11b2678bdfe1d M commitmsg :100644 100644 361f6153b6cc0ad3a7384c08d3d61e416c773748 c028fd587274eacf5514d0af00dc209d4ebb3205 M make.log :040000 040000 b99029c83b440856fe9427d8c2bfb4ac9cf234c6 89ec4e44157432c6efde13d28ba9179a77699ee3 M opt # bad: [423a84c4f7068853974887d98442bc2a2d0cc91b] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e # good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932 git bisect start 'latest' 'oldest' # good: [e02439a3d6297a1f5334fa558ddec5ef4212c574] source-hash-6b8393474974d2af7a2cb3c47b3d5c081b550bdb git bisect good e02439a3d6297a1f5334fa558ddec5ef4212c574 # good: [4850941efe43ae800be5c76e1102ab80ac2c085d] source-hash-980a6e552502f02f12c15bfb1c9f8e6269499f4b git bisect good 4850941efe43ae800be5c76e1102ab80ac2c085d # good: [a900e72b6357882284c5955bdf939bf14269f5fb] source-hash-dd1050b182260a26a1d0ba6d0ef3a6fecc3f4e07 git bisect good a900e72b6357882284c5955bdf939bf14269f5fb # skip: [e80660c5a1d812cd04586dae1f22767fc3778c4a] source-hash-07c60c8ee2d1465544a6a39e57bc06b3690b8dfb git bisect skip e80660c5a1d812cd04586dae1f22767fc3778c4a # bad: [df9bcaed2faa2a8d11b19f877cdff3a12a887278] source-hash-6ba9692d8bbe3e3c245aca9a7c928e81178d05f1 git bisect bad df9bcaed2faa2a8d11b19f877cdff3a12a887278 # good: [9d57c189d74551d2b3770cc81139ea10a62e672f] source-hash-5b5e62650354788e50b44f32c22b687b2018aba9 git bisect good 9d57c189d74551d2b3770cc81139ea10a62e672f # good: [894c969cde608547fda47917dbeeffdf7ebb4628] source-hash-7cc6de1cc2cfb466131072c2a1cd99c4a6279ebc git bisect good 894c969cde608547fda47917dbeeffdf7ebb4628 # good: [875a961e9f1dfc859b2b294bdea2649201919a95] source-hash-4a8cf5221f425118a7ec79e0cbf9cb0fb47bf823 git bisect good 875a961e9f1dfc859b2b294bdea2649201919a95 # bad: [7e673c13a5ce2578df74ab1491b1ab3389e9d4cc] source-hash-cddf4bd65fb4ce5615ca770946707d0db657e8ec git bisect bad 7e673c13a5ce2578df74ab1491b1ab3389e9d4cc # good: [316b704902eaa41ddf6787911f47c771042dbfd0] source-hash-4ef6d67ddb80cddd94716484c282cb646230ff0f git bisect good 316b704902eaa41ddf6787911f47c771042dbfd0 # good: [65826168ee84bda78a9f3bd2e4fece50a478e89b] source-hash-7f64da067644972ea7990977e1f45ab588166c15 git bisect good 65826168ee84bda78a9f3bd2e4fece50a478e89b # first bad commit: [7e673c13a5ce2578df74ab1491b1ab3389e9d4cc] source-hash-cddf4bd65fb4ce5615ca770946707d0db657e8ec
On pc Debian x86-64 with master sources updated today, I could reproduce this I noticed a lot of these on console: :drawinglayer/source/primitive2d/svggradientprimitive2d.cxx:355: SvgGradient Atom creation with no step width (!) (I increase a bit importance since it's a regression)
If the images are svgs, is it possible to extract the tiger one so i can send in a bug report for it, as its not rendered correctly and in able to get it out of the wpd file by converting it to odt.
Created attachment 104189 [details] Color tiger extracted from test WordPerfect file in LO 4.2.6 Using LibreOffice 4.2.6, I saved a copy of the color tiger from the test WordPerfect file. It saves it as an ODF Drawing (.odg), which may contain an SVG version of the tiger.
Hi pinertech, Thanks for trying. Yes i saw that i could export is as an odg, but it is a format like svg, so there wouldnt be an svg in it. :)
Created attachment 104206 [details] SVG first pict picture extracted using the standalone wpd2odt application with a modified version of libodfgen
Created attachment 104207 [details] the second SVG picture
Created attachment 104211 [details] LibO 4.2.6 VS WordPerfect X7 Thanks osnola. Seems that WordPerfect rendered the first SVG incorrectly, as Opera, Inkscape, and Chromium all show it the same as LibO. So thankfully no need to bug report this. :)
Created attachment 104213 [details] safari rendering of Pict0.svg This is odd, because I open them with Safari and Gimp on OSX, and these two applications show them "correctly", ...
Created attachment 104214 [details] LibreOffice 4.3.0 displaying of Pict0.svg on OSX... Oops, I see what you mean. However there seems to be two problem: - one with libwpd ( or maybe the librevenge's SVG generator), - a second one on OSX with SVG's rendering. Ie. I obtained on OsX 10.9.4 with LibreOffice 4.3.0 this rendering, which makes me think of a "Black and White" first comment.
Created attachment 104218 [details] rendering wpdprfct I have finally reproduced the first poster's problem(*): - top, the rendering when I open wpdprfect.wpd, - bottom, the same rendering when I double click on the first image. (*) with LibreOffice version: 4.3.1.0.0+ Build ID: 51acd019a038e0b69490290d4808ec49c7c27ba7 TinderBox: MacOSX-x86@49-TDF, Branch:libreoffice-4-3, Time: 2014-08-06_08:04:48 Notes: - as libwpd generates a SVG and a odg version of each converted picture, I suspected that in top, we see a black and white rendering of the SVG picture and at the bottom, we see the rendering of the odg picture, - I suspect that the bugs of pinertech and Jay Philips are very different bugs :-~ ( but each are regression from LibreOffice 4.2 )...
Svg management in LO is taken into account at 2 different locations, see http://nabble.documentfoundation.org/About-Svgreader-td4107050.html#a4107868 for more details. David: is there one or several reference dev(s) about svg issues? (I thought about Thorsten, Miklos or Christina since they had answered to the quoted thread) Also, I thought about creating a meta bug for svg + adding a keyword in whiteboard of "children bugs" to distinguish "open" and "insert svg" issues, any idea?
There are two SVG filters in libreoffice. One when you open an SVG in libreoffice which jumps into Draw and the second when you insert/embed a SVG into libreoffice, like when you add it to a writer document. I have found that the SVG filter for Draw isnt that good, while the SVG insert filter is quite good. We even have whiteboard keywords to differentiate between the two implementations as they are quite wide in their differences. (In reply to comment #14) > - I suspect that the bugs of pinertech and Jay Philips are very different > bugs :-~ ( but each > are regression from LibreOffice 4.2 )... This bug is about the svg insert filter, which is why pinertech and I are talking about the same issue. :) I had noticed that blue tiger when i opened the svg in Draw and was contemplating submitting a bug for it, though i havent had much successful bug fixes in the svg draw filter. I even noticed that in version 3.6.7 and below, all you see is the filled in black outline the tiger. (In reply to comment #15) > Also, I thought about creating a meta bug for svg + adding a keyword in > whiteboard of "children bugs" to distinguish "open" and "insert svg" issues, > any idea? The whiteboard keyword currently being used for the two implementations are filter:svgInsert and filter:svgOpen. If you do create the meta bug for svg, please let me know as i have a few i've submitted/commented on that i'd gladly add to it. :)
Created attachment 104266 [details] an odt file with the same problem Hello, (In reply to comment #16) > This bug is about the svg insert filter, which is why pinertech and I are > talking about the same issue. :) > Ok, sorry. I have done some tests: if I only keep the first odg picture in the odt result produced by libwpd (by removing all svg codes and the odg code of the second picture), I see the same problem, i.e. the odg picture is displayed in black and white but can be edited in color.. Note: - if I do the opposite, i.e. if only keep the svg picture, the picture is displayed with colors.
The below commit appears to be where the behaviour of the orignally attached file (attachment 104154 [details]) changed. Adding Cc: to chris.sherlock79@gmail.com. Could you possibly have a look at this? Thanks commit bb5c7d6a79309236d4f19bb2498f2e850f735a2f Author: Chris Sherlock <chris.sherlock79@gmail.com> Date: Sun Apr 13 01:42:27 2014 +1000 fdo#38844 Reduce XOR clipping for gradients Removed XOR clipping version of ClipAndDrawGradientMetafile. Because it has been removed, the other version isn't really needed in it's own function so I've moved it back into DrawGradient. Change-Id: Ib1519a019061c8c71183db63e5c11681bcad4cc4
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=e2883ca86f747eb62d1fe9e9b8d115c689e3abd7 Resolves: fdo#82219 color graphics as black and white It will be available in 4.5.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-4-4": http://cgit.freedesktop.org/libreoffice/core/commit/?id=938deff2a1e5451fd5493520480ae3c9615af3f9&h=libreoffice-4-4 Resolves: fdo#82219 color graphics as black and white It will be available in 4.4.0.2. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-4-3": http://cgit.freedesktop.org/libreoffice/core/commit/?id=3c3f77338ebfdc449cec2cd658bf07e99a765466&h=libreoffice-4-3 Resolves: fdo#82219 color graphics as black and white It will be available in 4.3.6. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]