Created attachment 58333 [details] Problem document When viewing the attached file in Linux the OLE objects are not drawn correctly. Note under Windows rendering is ok (although not as clear as Word).
Created attachment 58334 [details] Image showing rendering issue A comparison between OpenOffice and LibReOffice when rendering the problem document. Note this document is also the source document for the (non-rendering) OLE bug 47240.
Thanks for bugreport reproduced in 3.3.4 and 3.5.4 on Fedora 64 bit (bug is Linux specific) Changing version to 3.3.4 as most early reproducible
Created attachment 65820 [details] wrong preview view in libreoffice despide of correct pdf rendering
Created attachment 65821 [details] part of document correctly exported to pdf
another example with libreoffice 3.5.6-1 x86_64 arch linux: one image shows wrong document preview (it is wrong in normal view and in print preview). The next image shows correct preview after exporting the document to pdf. Document preview works with libreoffice in windows. It was created in windows with libreoffice 3.6.0 but i think this is a long standing linux/x11 render bug.
earlier there where linux rendering bugs depending on graphics hw. Here i have Intel® Ironlake Desktop (intel graphics onboard)
(In reply to comment #6) > earlier there where linux rendering bugs depending on graphics hw. Here i have > Intel® Ironlake Desktop (intel graphics onboard) [Workaround] the bug vanishes under linux when i disable the grapics rendering option Antialiasing (i use a german version).
but with first attachment in 3.6.0rc on Fedora 64 bit it not helps
(In reply to comment #8) > but with first attachment in 3.6.0rc on Fedora 64 bit it not helps i tried on another linux box with a very old ati graphics card, same effect, same workaround possible. Maybe i tripped over another bug concerning X11 and antialias view.
reported bug #53959
Not just Linux, also reproducible on Mac OSX, tested with : Test file was a Word XML document containing a graph inserted from Excel 3.3.4 : no image visible, just the image frame/placeholder 3.5.5.3 : incomplete image visible, most elements of OLE object missing 3.7.0 from daily build of 21/08 : incomplete image visible most elements of OLE object missing AOOo 340 : graphs displayed correctly
Changed title to reflect situation. Alex
For me, this is a clear blocker, as professionally, it means I have to use other software to open and edit documents containing OLE objects. Alex
This is also a regression over OOo 3.3.0 where the OLE objects are shown correctly (some overlap of axis titles). Setting regression keyword, upping priority. This bug affects all those users who have to interact with e.g. scientists, who integrate Excel spreadsheet graphs or other Office or MS system declared objects into their documents. Alex
I can't provide the document that is causing me the trouble (confidentiality issues). Will have to see if I can cobble one together on Windows that displays the problem. Alex
I can also reproduce with initial submitter's test file. LO 3.5.5.3 : apparently empty image frames or incomplete image object LO 3.7.0 (master build from 21/08) : apparently empty image frames or incomplete image object AOOo 340 : chemical formulae displayed correctly AOOo 330 : chemical formulae displayed correctly NeoOffice 321 patch 7 : chemical formulae displayed correctly Symphony 3.0.1 : chemical formulae displayed correctly (last one has been resized and is a bit small compared to others, but still clearly visible) Alex
On pc Debian x86-64 with master sources updated today, there's almost nothing of the objects. Noticed this log 6 times in console: warn:legacy.osl:7156:1:/home/julien/compile-libreoffice/libo/sw/source/filter/ww8/ww8graf.cxx:2390: unknown version.
I tried the workaround: Menu Tools/Options/LibreOffice/View Option "Use Anti-Aliasing" unchecked. Restart LO I've got the same=>KO
Created attachment 75285 [details] WMF extracted from doc
Created attachment 75286 [details] WMF from doc with removed EMF/EMF+ records
Created attachment 75287 [details] EMF/EMF+ extracted from WMF extracted from doc All three chemical formula files are EMF/EMF+ wrapped into WMF. LO can draw this WMF properly (try with attached "filtered" WMF), but not EMF/EMF+ part of it.
Confirming that with LO dev Version 4.1.0.0.alpha0+ (Build ID: f5cde53719544c7445ab6fdb465e332ac5678b0) on Mac OSX the problem is still there. The test file WMF from doc with removed EMF records appears to open fine, if the following is supposed to be what is displayed : CH3CH(OH)-CH2-O-CH2-C(CH3)2-CH2-O-CH2-CH(CH3)-O-CH=CH ?? However, if I open the EMF/EMF+ extracted from WMF extracted from doc file, I get a huge recatangular object with half an "O" in the bottom right hand corner. Alex
Who's the graphics expert on the dev team ? Alex
Hi Alex - this build: Version 4.1.0.0.alpha0+ (Build ID: f5cde53719544c7445ab6fdb465e332ac5678b0) Seems to be from: commit f5cde53719544c7445ab6fdb465e332ac5678b02 Date: Fri Jan 11 15:07:10 2013 +0200 We did a chunk of WMF/EMF work recently for 4.0.1 - but sadly we're still not getting this one right it seems.
<frob_tea> mmeeks, rodo_: fdo#47243 has EmfPlusTypeSetClipRect (not supported in LO?), probably that's the reason for "I see only part of 'O'"
If I open the EMF/EMF+ extracted file with LibreOfficeDev under gdb, this is what I see : 2013-03-08 15:47:32.304 soffice[27743:7207] Failed to create connection to the daemon: connection timeout: did not receive reply No idea, what kind of daemon soffice is trying to connect to here ? Alex
this is probably not a Writer bug but in VCL / canvas.
Caolán: following Michael's last comment about a VCL/canvas bug, you might be interested in this one.
Hm I'm unsure if this is a regression if it hasn't been confirmed to have ever worked in LibreOffice .....any version that worked within LibreOffice?
Errm, I would be inclined to say that it is a regression because it displays fine in OOo 3.3.0 and the LO project based its initial tree on that code (or so I understand) ? Seems to me to be a very narrow point of view to refuse to admit that we might have introduced a regression by playing with the initial OOo code we took over when the LO project was created. Just my 2c. Alex
FWIW, both the MS Word document containing the OLE images and the separate EMF provided by the reporter all open correctly in OOo 3.4.1 on Mac. Alex
to be honest - if it worked in the first release of a libreoffice branded package then it's a regression, if OOo broke it just before we branched, then it's not - I will verify this info
Just for your information. I am working on it, but it will not be a quick easy fix.
Persisting with Version: 4.4.0.0.alpha2+ Build ID: b9efff1c738af14ae4ee89732e3bb09e515e7959 TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2014-11-11_01:57:35 Fridrich are you still on this, or should we free this bug?
Adding Cc: to chris.sherlock79@gmail.com Perhaps you can do something with this one? (apparently WMF containing EMF is a thing that exists too...)
(In reply to Alex Thurgood from comment #30) > Errm, I would be inclined to say that it is a regression because it displays > fine in OOo 3.3.0 Far too old of a regression for bibisect to be of help: Whiteboard -> notBibisectable
Created attachment 117763 [details] White rectangle obscures image Word doc appears to contain an EMF object which is mostly covered by a white rectangle when opened in Writer. I thought I would bring this problem over from an OOo bug I reported in 2007. See https://bz.apache.org/ooo/show_bug.cgi?id=79511 The problem still exists under LO 5 32-bit
Migrating Whiteboard tags to Keywords: (notBibisectable)
The doc contains a table with three fields, each containing a group object. These have a text and a wmf representing the graphic. Loading in LO and saving as odt puts these correctly fom doc file format to Pictuires folder of the odt file (checked those graphics on win). So problem is (again) importing/painting wmf files in LO, see other tasks/issues, grep for 'wmf'. Inserting the extracted wmf's to a new draw/impress shows the same effect, debugging leads to usage of rendering::MtfRenderer and the Canvas Metafile renderer with it's problems (ressources, zoom not cipped, ...) since MetaFile.GetUseCanvas() is set, but decomposition is not better. Another reminder that we urgently need a wmf/emf metafile importer to primitives, neither the canvas metafile renderer is a good solution nor the current emf/wmf import that is massively incomplete.
Created attachment 126101 [details] One of the contained/extracted metafiles (wmf) Adding one of the extracted wmf's. Just insert this as grahic to e.g. draw/impress to have a simpler way to show this bug.
Prominent task describing this is e.g. tdf#90677
When disabling emf+ import by setting the env var EMF_PLUS_DISABLE to true, result is slightly better. Problem is to programatically find out if it may be better to disable it for a given wmf file or not.
Replacing keyword 'notBibisectable' by 'preBibisect' as this bug is outside the bibisect range
Bartosz Kosiorek committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=78a3a304871eb3eb861a49ed00345b54fba01114 tdf#47243 tdf#39327 Add support for SetPageTransform It will be available in 5.4.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.
Bartosz Kosiorek committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=e31c535b574fc37e6961c5ce7bd507a30e6abff1 tdf#47243 tdf#39327 tdf#103639 Proper scaling of SetPageTransform It will be available in 5.4.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.
*** This bug has been marked as a duplicate of bug 31814 ***
Created attachment 141272 [details] Comparison of the document in LO 6.1 and Office365
Original EMF+ issue was already resolved, see comparison LO-6.1 and Office365: https://bugs.documentfoundation.org/attachment.cgi?id=141272 If you want to fix another issue please submit new bug report.