There are many ChemDraw objects (molecules) in the referenced presentation. These objects are not displayed in LibreOffice 3.3 beta 3. This is a regression, because: Go-OO 3.2.1 - OK OOo 3.3RC - OK LibO 3.3b3 - BUG http://ftp.fsf.hu/LibreOffice/Heteroarom%e1s%20vegy%fcletek%20k%e9mi%e1ja-V.ppt
I can confirm this behaviour. The objects are also displayed correctly in NeoOffice. In LibO beta 3, only the image handles are displayed. Alex
Thorsten?
Eh, it's loading those as emf+ - Rodo, any cycles left to look into this?
(if not, just return to me of course)
The sample document opens correctly in LibreOffice 3.4.
Presentation is displayed correctly in LO 3.4.0 in windows xp sp3 but not in Fedora 14
More data: The sample doc's images also fail to display for me in LO-3.4.1 on Ubuntu Linux x86_64. (In reply to comment #6) > Presentation is displayed correctly in LO 3.4.0 in windows xp sp3 but not in > Fedora 14
Created attachment 51694 [details] File with example OLE objects that are not shown correctly under LibO/Fedora15 64bit Is anybody working on this? This bug is really bothering me, as it does not only affect ChemDraw objects, but apparently /any/ chemical structure objects, both in document and presentation files, that people send me. Not sure if it affects all OLE objects, but I guess there's a chance for that, too. For me the problem exists since Fedora switched from OpenOffice to LibreOffice (Fedora 14 -> 15, 64bit version). I also tried with a recent nightly build, and the problem persists. I have attached a test file that has objects created with ChemDraw, Accelrys Draw (= formerly ISISDraw/SymyxDraw), and MarvinDraw, none of which are fully visible for me in LibO. I hope this helps for fixing the problem! Christian
To Thorsten Behrens or any other dev that might be reading this: can you please check whether anybody is actually working on this? This bug has been reported 11 months ago now, and the assignee has not responded a single time to this yet. Also, the bug has been closed and reopened. I am thus wondering whether it somehow got overlooked/dropped under the radar? I would have expected to get at least a one-liner saying something like “Yes, I can reproduce it, but I'm busy with more critical stuff right now, will try to fix it for version 3.x”, or “We can still not reproduce it, can you please try ...”, or something. Without any feedback, I can only guess whether or not those comments have been noticed, and whether there's any additional info I could provide that might help. Thanks!
Just checked a recent master build, MarvinDraw displays there, ChemDraw still not. Rodo, any cycles left to have a quick look?
Checked the ChemDraw image and it is indeed emf+, but it opens in Draw (atom letters are missing though). So I guess it is Writer problem. I will try to fix the emf+ issue - missing letter. Giving Cc to Lubos so that he can check the Writer related part.
I have fixed emf+ issue with atom names text drawing. All the embedded emf files now render OK in Draw. Reassigning to Lubos for the Writer part.
(In reply to comment #12) > I have fixed emf+ issue with atom names text drawing. All the embedded emf > files now render OK in Draw. > > Reassigning to Lubos for the Writer part. I cannot confirm with current master, if I convert the .doc from comment #8 to .docx using MSO2k7, which I assume does not change the embedded .emf files, then Draw does not open the first two here. Reassigning back.
Must be another regression :-( I will look into it.
OK, I was wrong, probably mistaken by exported env. variable EMF_PLUS_DISABLE set to 1 at some point. I implemented uhnadled emf+ record DrawImage and it works now. There's another problem though, as it is rendered in very low resolution. I will need to look into whether we can draw embedded metafiles better (best without intermediate bitmap representation). It will take some time though. Meanwhile the fix for DrawImage record is available in master branch. Looks like writer part is OK as far as I can tell.
*** Bug 57032 has been marked as a duplicate of this bug. ***
Fails on Windows Version 3.6.3.2 Too. (32 Bit, 2x Intel Core2 Duo) Displaying ChemDraw works when setting EMF_PLUS_DISABLE to 1. strangely, the error occurred obviously with delay.
Created attachment 75220 [details] emf extracted from the doc
Created attachment 75221 [details] 2nd emf extracted from the doc
It is a regression, because the bugdoc opens perfectly in Go-OO 3.2.1 (and even in AOO 3.4.1).
Created attachment 82938 [details] Bug 31814 - LO 4.2 vs Word 2010 Confirmed with: LO 4.2.0.0.alfa0 Build ID: 2013-06-24 own debug build Windows 7 Professional SP1 64 bit Objects are displayed in LibreOffice, but don't look very well. Comparison screenshot LO vs Word 2010 is attached.
Please read this message in its entirety before responding. Your bug was confirmed at least 1 year ago and has not had any activity on it for over a year. Your bug is still set to NEW which means that it is open and confirmed. It would be nice to have the bug confirmed on a newer version than the version reported in the original report to know that the bug is still present -- sometimes a bug is inadvertently fixed over time and just never closed. If you have time please do the following: 1) Test to see if the bug is still present on a currently supported version of LibreOffice (preferably 4.2 or newer). 2) If it is present please leave a comment telling us what version of LibreOffice and your operating system. 3) If it is NOT present please set the bug to RESOLVED-WORKSFORME and leave a short comment telling us your version and Operating System Please DO NOT 1) Update the version field 2) Reply via email (please reply directly on the bug tracker) 3) Set the bug to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + LibreOffice is powered by a team of volunteers, every bug is confirmed (triaged) by human beings who mostly give their time for free. We invite you to join our triaging by checking out this link: https://wiki.documentfoundation.org/QA/BugTriage There are also other ways to get involved including with marketing, UX, documentation, and of course developing - http://www.libreoffice.org/get-help/mailing-lists/. Lastly, good bug reports help tremendously in making the process go smoother, please always provide reproducible steps (even if it seems easy) and attach any and all relevant material
The bug is still there in Version: 4.4.0.0.alpha1+ Build ID: dc6052564600688c7baf2be7f5ae07b8706695aa I tested it on Windows 7.
Adding Cc: to chris.sherlock79@gmail.com Chris, here's another EMF bug that may interest you
*** Bug 89376 has been marked as a duplicate of this bug. ***
Created attachment 120324 [details] master screen shot as of today
Migrating Whiteboard tags to Keywords: (preBibisect) [NinjaEdit]
Sorry, I can't see this as fixed in 5.1 or 5.2+. Please check.
(In reply to Timur from comment #28) > Sorry, I can't see this as fixed in 5.1 or 5.2+. Please check. Tested today with LO 5.1.3.0.0+ with the same bugdoc as Caolan and I get the same result. I you disagree with Caolan and me, please attach your own screencopy showing how _this_ bug is still there. If you see some problem with embedded EMF objects, please, open a new bug report with a detailed description and a test file. Closing again. As we don't know which commit[s] fixed the bug, the right status is WorksForMe. Best regards. JBF
Created attachment 124176 [details] master screen shot with LO52+ in Windows My comment is for Windows, because bug is marked as "All". So please either mark as Linux or reopen.
(In reply to Timur from comment #30) > Created attachment 124176 [details] > master screen shot with LO52+ in Windows > > My comment is for Windows, because bug is marked as "All". So please either > mark as Linux or reopen. It is another problem, the report is about OLE objects not displayed. Please open a new bug report for this bad rendering. Best regards. JBF
Created attachment 124180 [details] Another example of ole object The content of the document is not displayed at all unless EMF_PLUS_DISABLE=1 variable is set Fedora 21 x86_64 Libreoffice Version: 5.1.3.0.0+ Build ID: 8aa9fac23bc8f29de5e91293352f96c99418ddfc CPU Threads: 1; OS Version: Linux 4.1; UI Render: default; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:libreoffice-5-1, Time: 2016-04-07_13:49:34 Locale: ru-RU (ru_RU.UTF-8)
*** This bug has been marked as a duplicate of bug 103639 ***
A lot of EMF import issues was resolved witg LibreOffice 5.4. Please download the LibreOffice 5.4 Daily Build from website: http://dev-builds.libreoffice.org/daily/master/ and check if the problem was resolved for you. Please check if LibreOffice is importing correctly OLE objects created by ChemDraw application.
Created attachment 133111 [details] Extracted emf+ image which illustrate wrong rendering of some lines (too thin)
Bartosz Kosiorek committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=ff7f5e1bbd4a9a3e3fa3e4ddb349c97605dc8a01 tdf#31814 Introduce minimal value of line width to fix EMF+ import issues 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=4c40aeeaf37bb3c0b780e7b0c2f9afe8c06091f5 tdf#31814 EMF+ Fix an issue when not all elements were displayed 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.
*** Bug 102321 has been marked as a duplicate of this bug. ***
*** Bug 47243 has been marked as a duplicate of this bug. ***
*** Bug 61083 has been marked as a duplicate of this bug. ***
Created attachment 133184 [details] shaded box
The box is covered with gray box instead of shading
Created attachment 133185 [details] gradient-filled boxes gradient filling is not displayed on all boxes Version: 5.4.0.0.alpha1+ Build ID: 2b1737f648024328390bf44c4f2c614e748a92fd CPU threads: 2; OS: Linux 4.1; UI render: default; VCL: kde4; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2017-05-07_03:08:54 Locale: ru-RU (ru_RU.UTF-8); Calc: group
Thank you gvlatyshev. Unfortunately I don't own ChemDraw. Could you please separate figures into separate EMF files? It will simplify the investigation process. It will be also great to create new ticket for every issue you will find. Please let me know (eg. via email), about any new ticket for EMF import.
Bartosz Kosiorek committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=43f5268c6fa394b0d219f8653ef827bdd531b4e4 EMF+ tdf#31814 Add support of reading EmfPlusBoundaryPointData 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.
*** Bug 97720 has been marked as a duplicate of this bug. ***
*** Bug 47240 has been marked as a duplicate of this bug. ***
*** Bug 108207 has been marked as a duplicate of this bug. ***
In Windows, I can't see why this was fixed, 5.4 and 6.0+ showed it wrong similarly to 5.3. With https://cgit.freedesktop.org/libreoffice/core/commit/?id=ebc11ae0b132eefd3b1b1a837a8d0ad3ba73b460 it's not blurry anymore but still not correct. So I set to Reopen.
(In reply to Timur from comment #49) > In Windows, I can't see why this was fixed, 5.4 and 6.0+ showed it wrong > similarly to 5.3. > With > https://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=ebc11ae0b132eefd3b1b1a837a8d0ad3ba73b460 it's not blurry anymore but > still not correct. So I set to Reopen. Yes, there is still something going on. Converting attachment 51694 [details] .doc with Word 2016 to OOXML, or to ODF, places all four images into a media directory. The media are 3 EMF and a PNG as found in the document. The EMF for the "Marvin Sketch" renders fine when the .doc/.docx/.odt is opened in current LO master. But the other two EMF (from Accelrys Draw, and ChemDraw) are only partially rendered and show a low resolution raster of the images lines but no lettering. Weird as attachment 133111 [details] is pretty well formed (except for the dashed lines around the reaction box.
EmfPlusRecordTypeFillRegion - we get: warn:cppcanvas.emf:49701:3004821:drawinglayer/source/tools/emfphelperdata.cxx:1682: EMF+ TODO unhandled record type: 0x4013 EmfPlusRecordTypeComment - we get: warn:cppcanvas.emf:49701:3004821:drawinglayer/source/tools/emfphelperdata.cxx:1682: EMF+ TODO unhandled record type: 0x4003 I'm assuming that comment record holds the text. On the latest build, the lines also aren't antialiased.
Created attachment 136406 [details] EMF file from Accelrys Draw EMF file from Accelrys Draw (formerly ISISDraw/SymyxDraw). Note that the Comment record which has a signature of MDLS is proprietary data, we can ignore this.
Created attachment 136407 [details] cppcanvas logging 630188s-iMac:core 5K$ export SAL_LOG=+INFO.cppcanvas 630188s-iMac:core 5K$ instdir/LibreOfficeDev.app/Contents/MacOS/soffice 2> ~/emf.log
info:cppcanvas.emf:72789:3187441:drawinglayer/source/tools/wmfemfhelper.cxx:3051: EMF+ passed to canvas mtf renderer, size: 104 info:cppcanvas.emf:72789:3187441:drawinglayer/source/tools/emfphelperdata.cxx:774: EMF+ record size: 12 type: EmfPlusRecordTypeSetTextRenderingHint flags: 4 data size: 0 info:cppcanvas.emf:72789:3187441:drawinglayer/source/tools/emfphelperdata.cxx:1329: EMF+ SetTextRenderingHint info:cppcanvas.emf:72789:3187441:drawinglayer/source/tools/emfphelperdata.cxx:1330: EMF+ TODO info:cppcanvas.emf:72789:3187441:drawinglayer/source/tools/emfphelperdata.cxx:774: EMF+ record size: 48 type: EmfPlusRecordTypeObject flags: 1537 data size: 36 info:cppcanvas.emf:72789:3187441:drawinglayer/source/tools/emfphelperdata.cxx:136: EMF+ Object slot: 1 flags: 1536 info:cppcanvas.emf:72789:3187441:drawinglayer/source/tools/emfpfont.cxx:49: EMF+ font EMF+ header: 0xdbc01 version: 0x1001 size: 71 unit: 0x3 info:cppcanvas.emf:72789:3187441:drawinglayer/source/tools/emfpfont.cxx:50: EMF+ flags: 0x0 reserved: 0x0 length: 0x5 info:cppcanvas.emf:72789:3187441:drawinglayer/source/tools/emfpfont.cxx:63: EMF+ family: ARIAL info:cppcanvas.emf:72789:3187441:drawinglayer/source/tools/emfphelperdata.cxx:774: EMF+ record size: 44 type: EmfPlusRecordTypeDrawString flags: 32769 data size: 32 info:cppcanvas.emf:72789:3187441:drawinglayer/source/tools/emfphelperdata.cxx:1219: EMF+ DrawString info:cppcanvas.emf:72789:3187441:drawinglayer/source/tools/emfphelperdata.cxx:1224: EMF+ DrawString brushId: 4278190080 formatId: 4294967295 length: 1 info:cppcanvas.emf:72789:3187441:drawinglayer/source/tools/emfphelperdata.cxx:1231: EMF+ DrawString layoutRect: 2468.02,3460.2 - 0x0 info:cppcanvas.emf:72789:3187441:drawinglayer/source/tools/emfphelperdata.cxx:1234: EMF+ DrawString string: N And before this there is a world transform. But you can see we do actually extract the "N" string, but where on earth is being painted to?!?
Hi, this bug looks strange, because the content of attached emf from comment 52 is pretty "simple" ... Since I contributed to the new emf(+) renderer, I will look into this.
Could it be world to device coordinate mapping that is causing this? Just a suggestion, I get confused how EMFs do affine transforms so I might not be much help here. It would be nice if there was a way of automatically turning on anti-aliasing by default.
Oh, also: I have submitted a patch to dump comment records in hex if you turn on INFO debugging in cppcanvas.emf https://gerrit.libreoffice.org/#/c/42558/1/drawinglayer/source/tools/emfphelperdata.cxx Comment records are a pain as they include proprietary data, but better for us to have a way of getting out a hex dump of the content than nothing. If you could have a look at that, would be appreciated.
Sorry, link should be https://gerrit.libreoffice.org/#/c/42558/
Hi, I investigated this bug. Attachment 136406 [details] is a strange file. It is basically just an EMF file containing all necessary info: text and lines are given there. But, there is a quite large EMF-Comment in beginning of the file, containing a lot of EMF+ data. Again, there is all info about lines and text given, too. Why is this redundant? What bothers me: The file is only rendered in a very bad resolution and I don't know why. There are a lot of "DrawImage" records in the EMF+ part, which are crucial, because disabling them leads to a blank white picture... For what I saw, there is no bug in the EMF+ related code. My guess is there's a bug in the correspondence between EMF/EMF+ caused by the redundant records.
I have take a look at EMF+ header, and the file is identified as dual file (dual: 1). According to documentation: Metafiles identified as EMF+ Dual can also contain both EMF+ records and EMF records. The EMF+ Dual flag indicates that the metafile contains a complete set of EMF records sufficient to correctly render the entire drawing on a system that cannot playback EMF+ records. This feature makes it possible to render an image with different levels of graphics support in the operating system. However, only one or the other type of records is processed. All records are enumerated sequentially. For EMF playback, the metafile player only uses EMF records and ignores EMF+ records. For EMF+ playback, the metafile is played as if it is EMF+ Only. There are two issues in Attachment 75221 [details] image display: 1. Low resolution of background image. It could be caused by not implemented image attributes: info:cppcanvas.emf:72789:3187441:drawinglayer/source/tools/emfphelperdata.cxx:1136: EMF+ TODO: use image attributes info:cppcanvas.emf:72789:3187441:drawinglayer/source/tools/emfphelperdata.cxx:1146: EMF+ DrawImage source rectangle: 4,4 100x98 2. Not visible strings which should be displayed by: info:cppcanvas.emf:72789:3187441:drawinglayer/source/tools/emfphelperdata.cxx:774: EMF+ record size: 44 type: EmfPlusRecordTypeDrawString flags: 32769 data size: 32 info:cppcanvas.emf:72789:3187441:drawinglayer/source/tools/emfphelperdata.cxx:1224: EMF+ DrawString brushId: 4278190080 formatId: 4294967295 length: 1 info:cppcanvas.emf:72789:3187441:drawinglayer/source/tools/emfphelperdata.cxx:1231: EMF+ DrawString layoutRect: 2468.02,3460.2 - 0x0 info:cppcanvas.emf:72789:3187441:drawinglayer/source/tools/emfphelperdata.cxx:1234: EMF+ DrawString string: N Maybe it was caused by wrong layoutRect, which is 2468.02,3460.2 - 0x0, but for DrawImage it is just 4,4 100x98
If this is a dual EMF/EMF+ record, then perhaps we should have a way of falling back to EMF only for now in a non-debug mode? However, the world transform is: info:cppcanvas.emf:72789:3187441:drawinglayer/source/tools/emfphelperdata.cxx:774: EMF+ record size: 36 type: EmfPlusRecordTypeSetWorldTransform flags: 0 data size: 24 info:cppcanvas.emf:72789:3187441:drawinglayer/source/tools/emfphelperdata.cxx:1396: EMF+ SetWorldTransform info:cppcanvas.emf:72789:3187441:drawinglayer/source/tools/emfphelperdata.cxx:1404: EMF+ m11: 0.133333 m12: -0 m21: -0 m22: 0.133333 dx: -304.02 dy: -424.681 So translate and scale the layout rect from 2468.02,3460.2 - 0x0... x coord = (2,486.02 - 304.02) * 0.133333 = 288.532612 y coord = (3,460.20 - 424.681) * 0.133333 = 404.734854827 Unless I'm miscalculating this? but the EMF+ picture frame goes from 0,0 - 1886,2217, so this location looks about right I think...
Chris Sherlock committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=6996c65015703b6aaa6d44f76c492371f47b138d tdf#31814 drawinglayer: dump EmfPlusRecordTypeComment records It will be available in 6.0.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.
Hi! Thanks for the additional info. In Comment 61, you made a little mistake: The transformation is done by scaling first and translating second. In your case x coord = 2,486.02 * 0.133333 - 304.02 = 27.4 y coord = 3,460.20 * 0.133333 - 424.681 = 36.7 But I don't know what to do with this information... I'll go a little bit deeper in this bug. Thank for pointing out the "dual" thing. I never heard about that before. First, I need to study the documentation and then the code.
Hey, I found something! Problem is the following: In dual mode, there the bool "bHaveDC" seems to be never set in the EMF+ Comments. therefore, the statement (DC = Device context, and it tells the parser precess following EMF records) else if( !mbEMFPlus || bHaveDC || nRecType == EMR_EOF ) in emfio/source/reader/emfreader.cxx line 700 is never true. By manually setting it to "true" renders the EMF+ file together with the EMF content pretty fine. But it renders both in one picture, this looks not so nice. The EMF+ part looks really good. The question is now, should we precess the EMF or the EMF+ part?
Created attachment 136699 [details] Another EMF+ file with dual mode I have attached another file with dual mode, when not all EMF+ records are displayed correctly. I spend ours in investigating why it is happening. Generally for LibreOffice in dual mode we should display EMF+ by default (as EMF+ is more advanced than EMF). If Dual mode is not set, then EMF should be also displayed in case of EmfPlusGetDC record is set (in our case it is haveDC variable). More information is available at EmfPlusHeader Record. (Dual mode) - If set, this flag indicates that this metafile is EMF+ Dual, which means that it contains two sets of records, each of which completely specifies the graphics content. If clear, the graphics content is specified by EMF+ records, and possibly EMF records ([MS-EMF] section 2.3) that are preceded by an EmfPlusGetDC record. If this flag is set, EMF records alone SHOULD suffice to define the graphics content. Note that whether the EMF+ Dual flag is set or not, some EMF records are always present, namely EMF control records and the EMF records that contain EMF+ records.
Another update: I have written a small patch resolving this issue. It renders EMF+ records only, if dual mode is set. Like Bartosz just mentioned. There is a little trouble with the unit tests because as it turned out, all test files are in dual mode! I will give another update within the next few hours.
Last info for today: Sorry, I mixed it up. You can easily write a small patch that suppresses EMF+ recored and renders ONLY EMF records. Actually, this solves the bug and gives a fine output but does not take advantage of the better EMF+ functionality. However, while trying to force only EMF+ records to be rendered I noticed something: In the "render loop" in emfhelperdata.cxx, there are only a handful records passed, which is strange. Then I noticed, there is a "DrawImage" record which creates a BitmapsEx: --> BitmapEx aBmp(image.graphic.GetBitmapEx()); <-- which calls an old VCL routine to parse the source file again. This seems not good and causes the low DPI! I'll start there the next time.
In that case, as Bartosz says, we should definitely use EMF+ for dual EMF+ records. :-) Nice work guys! Every EMF/EMF+ fixes helps our rendering fidelity and helps win over converts to LO, what you two are doing here is really quite awesome.
Hi Patrick, is your patch on gerrit?
Hi Chris, https://gerrit.libreoffice.org/#/c/43122 This is the patch I mentioned earlier. It uses the fallback EMF renderer in dual mode. Jenkins will fail, because it does not pass all unit tests since the test files are in dual mode. Basically, it resolves this bug here! There is a slight shift in the position of the letters to the right. I went through the code were the positioning is done but there everything looks right. The better way would be to go for the new EMF+ renderer. But as I mentioned before, there is trouble caused by the DrawImage record. So there are essentially two problems left: - text position in the EMF renderer - DrawImage record in the EMF+ renderer
Created attachment 136757 [details] Document view with (first) dual mode patch applied This is the document with the patch (43122 on gerrit) applied. There you can see the slight shift to the right of the letters.
Looks like it's failing with an off-by-one pixel failure.
Actually, it is more: the shift is about 4 logical units in the data and about 20 units in the device space.
Hello Patrick. What is happening when you are using EMF+ and disable DrawImage record? As I understand DrawImage record is not working correctly. Do you have idea what could be wrong with it?
Then it renders blank. Just a white rectangle.
Created attachment 136872 [details] How LO 6.0 master is opening EMF+ attachment 75221 [details] In attachment you could find how attachment 75221 [details] is opened by LO 6.0 master. The strings on that EMF+ should be drawed by EmfPlusRecordTypeDrawString. Unfortunately it is not visible at all. Generally only lines drawed by EmfPlusRecordTypeDrawLines records are visible. But it has low resolution. Do you know the cause of this issue?
Hi, I submitted another patch: https://gerrit.libreoffice.org/#/c/43367/ Yesterday I noticed, that I missed the case of a 'metafile' in DrawImage, therefore is was always rendered as a bitmap in low resolution, this is fixed with the patch (you can review it if you like) The missing characters (as Bartosz) mentioned are caused by a missing "stringFormat" attribute in DrawString. Documentation says, it is optional, so I fixed that, too. What the patch does not offer: There is still both EMF and EMF+ records rendered. I will upload the "dual mode patch" in a minute as a separate patch. What is still unresolved: Both EMF and EMF+ puts the characters not in the right place (this is annoying!). For EMF it is shifted to the right, EMF+ is shifted to the left... I have no idea why. DrawString positioning is tested well, so there is no error I think. The lines and the strings use the same map/base/world transformation. The misplacement is already found in the raw coordinates in the EMF file. Maybe there is another hidden attribute that tells the letters to be aligned at the center or something. But we will solve this one too!
https://gerrit.libreoffice.org/#/c/43122/2 here is the updated patch for the dual mode. It causes trouble with some unit tests. Maybe you can also take a look where this happens (or there is something completely wrong with the patch?)
Patrick Jaap committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=52a2a0101f71b21876f17d5419132ffa27f6e35d tdf#31814 Fix for EMF+ DrawString and DrawImage It will be available in 6.0.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=f2410ad4d0f1e93c7f12ee51da9e1a1a90f0f5a4 tdf#31814 Resolve TODO from EMF+ DrawImage and DrawImagePoints It will be available in 6.0.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.
Patrick Jaap committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=e06807f51d157844b357dab1bbf960cc55162330 tdf#31814 EMF/EMF+ implement dual mode It will be available in 6.0.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 and Bartosz, thank you for your dedication to this issue. I have no idea whether it's all done, but I see it OK in 6.0+. So I'll set as Fixed. Surely, if you have some comment or conclusion, you're welcome.
Bartosz and Patrick, of course.
Hi! The general rendering is fine now. Thanks for closing this bug. But still, the position of the characters is not completely right. I have this in mind and I'm still looking for some solution. Can you open a separate bug for this and put me in CC?