Created attachment 129114 [details] course excersise Extracting the WMF file, convert it to jpg and replace the embedded wmf with that jpg ia a work around but should not be the solution Also saving as .doc or .odt file does not solve the problem. Remarks: the attached file seems to have personal info but it is an excersise for a course.
On Windows 10 Pro 64-bit (1607) en-US with Version: 5.2.3.3 (x64) Build ID: d54a8868f08a7b39642414cf2c8ef2f228f780cf CPU Threads: 8; OS Version: Windows 6.19; UI Render: default; Locale: en-US (en_US); Calc: group Can not reproduce. The EMF tables are rendered into the document (or if extracted from the OOXML archvie can be inserted into Draw) and are printed/exported as rendered to screen. The EMF tables are a bit malformed (a replacement font issue I believe), but they render consistently in LibreOffice document canvas and when printed/exported. Please provide the OS and Desktop Environment, as well as the text from the Help -> About LibreOffice dialog.
Created attachment 129128 [details] Example File EMF Tables only
I can confirm a losing text when exporting the EMF tables to PDF, with: Version: 5.4.0.0.alpha0+ (x64) Build ID: 7aa2b5a041df8e71a435cccbc79ee13799ec9138 CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; Layout Engine: new; TinderBox: Win-x86_64@62-TDF, Branch:MASTER, Time: 2016-11-24_11:40:27 Locale: nl-NL (nl_NL); Calc: CL
Created attachment 129132 [details] Results PDF export
Ouch, confirming the EMF is losing text content in the print dialog/print and on export to PDF (both lossless and JPEG) with the GDI only default rendering. Strangely the Print Preview mode shows the font--but then the print dialog does not. It is fine with GDI+ with default rendering at 5.2.3.3 Version: 5.3.0.0.beta1 (x64) Build ID: 690f553ecb3efd19143acbf01f3af4e289e94536 CPU Threads: 8; OS Version: Windows 6.19; UI Render: default; Layout Engine: new; Locale: en-US (en_US); Calc: CL
Created attachment 129133 [details] image3.emf inserted to Draw odg
Created attachment 129134 [details] image4.emf inserted to Draw odg Attached the source EMFs as inserted into Draw .ODGs With the new HarfBuzz layout engine at 5.3.0beta1 and 5.4.0.0alpha0+ builds: on printing/export when default GDI rendering is used they loose text but when OpenGL rendering is used the text is fully rendered.
Not sure to call this a Graphics Stack or Printing and PDF Export issue. But is seems a HarfBuzz regression we've missed.
I can't reproduce with Version: 5.2.3.3 (x64) Build ID: d54a8868f08a7b39642414cf2c8ef2f228f780cf CPU Threads: 4; OS Version: Windows 6.19; UI Render: GL; Locale: es-ES (es_ES); Calc: group neither Version: 5.3.0.0.alpha0+ (x64) Build ID: 170105956f843047d4c79657584f0c01aa7814c7 CPU Threads: 4; OS Version: Windows 6.19; UI Render: GL; TinderBox: Win-x86_64@62-TDF, Branch:MASTER, Time: 2016-08-19_17:41:46 Locale: es-ES (es_ES); Calc: group Only with 5.3, looks like an OpenGL issue with it disable show the problem but works fine with it enable.
Removing the regression tag and this is _not_ a HarfBuzz issue. With default old GDI+ < 5.3.0, or current GDI defaulut rendering, e.g. not OpenGL, if I disable my nVidia GPU to use just CPU for rendering the print or export to PDF is correctly composed. =-STR-= 1. Open one of the attached Draw or Writer files 2. select checkbox Tools -> View -> Use hardware acceleration 3. File -> Print result? -- print preview shows rendered EMF with missing/clipped text elements 4. clear checkbox Tools -> View -> Use hardware acceleration 5. File -> Print result? -- print preview shows rendered EMF fully formed With actual print, or export to PDF, results are likewise affected by toggling the "Use hardware acceleration" parameter controls. =-QA-= Believe this divergence between with "Use hardware acceleration" and just CPU started at the 4.0.5.1 build. https://cgit.freedesktop.org/libreoffice/core/log/?h=libreoffice-4-0&qt=range&q=9e9821abd0ffdbc09cd8c52eaa574fa09eb08f2..5eca95953c59f90dec2cd6ed6dab4b1f4b3b24c This commit to master looks suspect... https://cgit.freedesktop.org/libreoffice/core/commit/?id=4c676625d4016d428e9becd5512b7cfc8b0c4b24 @Thorsten, Noel, Caolan, Armin -- sorry to throw this old crud at you. I've no idea about how "Use hardware acceleration" _should_ affect the gdi routines for text and vectors. But it looks like on Windows builds the 4c676625d4016d428e9becd5512b7cfc8b0c4b24 patch rescaled the size of the EMF images, but somehow missed doing the same for the text elements. The text elements get clipped in the final composition with hardware acceleration. That carries through to current Windows builds (with nVidia GPUs at least). With "Use hardware acceleration" disabled, the full EMF is rendered to print or export, with it enabled the text portion is clipped. =-bibisect-= OK LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4 LibreOffice 3.4.6 OOO340m1 (Build:602) Version 3.6.6.2 (Build ID: f969faf) **EMF oversized scaling in print/export Version 3.6.7.2 (Build ID: e183d5b) **EMF oversized scaling in print/export Version 4.0.0.3 (Build ID: 7545bee9c2a0782548772a21bc84a9dcc583b89) Version 4.0.1.2 (Build ID: 84102822e3d61eb989ddd325abf1ac077904985) BAD/with Same rendering Version 4.0.2.1 (Build ID: 7e5467ff8f30d821f4fbf69cb2769163eb64c2c) **EMF oversized scaling in print/export Version 4.0.2.2 (Build ID: 4c82dcdd6efcd48b1d8bba66bfe1989deee49c3) **EMF oversized scaling in print/export Version 4.0.3.3 (Build ID: 0eaa50a932c8f2199a615e1eb30f7ac74279539) **EMF oversized scaling in print/export Version 4.0.4.2 (Build ID: 9e9821abd0ffdbc09cd8c52eaa574fa09eb08f2) **EMF oversized scaling in print/export BAD/with different rendering GPU v. CPU Version 4.0.5.1 (Build ID: 5eca95953c59f90dec2cd6ed6dab4b1f4b3b24c) **non-GPU EMF oversized scaling Version 4.0.6.2 (Build ID: 2e2573268451a50806fcd60ae2d9fe01dd0ce24) **non-GPU EMF oversized scaling
Michael an fyi, you and Thorsten had brought in Radek Doulik's patch (bnc#795857 & bug 62806)--nothing wrong; just think there is something additional in the gdi handling when hardware acceleration is in use that is still affecting us at 5.3.0
*** Bug 58831 has been marked as a duplicate of this bug. ***
*** Bug 80389 has been marked as a duplicate of this bug. ***
attachment 120599 [details] from bug 95875 with GDI-metafile insert of graphics (i.e. held in ODF archive as SVM) also renders differently depending on config--correct with CPU only, and OpenGL, but drops elements when "Use hardware acceleration" is enabled.
*** Bug 77525 has been marked as a duplicate of this bug. ***
*** Bug 74686 has been marked as a duplicate of this bug. ***
*** Bug 75373 has been marked as a duplicate of this bug. ***
*** Bug 75574 has been marked as a duplicate of this bug. ***
*** Bug 95875 has been marked as a duplicate of this bug. ***
*** Bug 99727 has been marked as a duplicate of this bug. ***
*** Bug 101068 has been marked as a duplicate of this bug. ***
Seems https://cgit.freedesktop.org/libreoffice/core/commit/?id=c47f0903fe0fb2f743d179d1ac9a2dcdfb19af10 for see also bug 62806 did not quite fully resolve scaling issues there--and left us with divergence between "CPU only" and "HW accelerated" GDI rendering. And there are a few interesting commits between 4.0.1.2 and 4.0.2.1 builds that seem related to the initial breakage of bug 62806 (bibisect in comment 10). https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=84102822e3d61eb989ddd325abf1ac077904985..7e5467ff8f30d821f4fbf69cb2769163eb64c2c but generic work on vclmetafileprocessor2d.cxx in https://cgit.freedesktop.org/libreoffice/core/commit/?id=b50c8f2cbc477a784dec00be1a91e4743bd2cf8a seems more likely related to multiple image types rather than just EMF.
*** Bug 89649 has been marked as a duplicate of this bug. ***
*** Bug 99651 has been marked as a duplicate of this bug. ***
Stuart, should we mark Bug 103833 also a duplicate? I consider importance (symbolically) be set to maximum for this number of dupes, but I let that to you.
(In reply to Timur from comment #25) > Stuart, should we mark Bug 103833 also a duplicate? No, I don't think so. As split from bug 77525 --WMF/EMF and SVM graphics are a different graphics stack and/or filter issue of OpenGL, GPU, and CPU processing. Clearly a different issue from the OpenGL handling of the odd sRGB 8/1-bit bilevel PNG (attachment 113502 [details] from bug 89473 and its related bug 103833) that results in black rectangles on document canvas and PDF export.
*** Bug 106442 has been marked as a duplicate of this bug. ***
Bug still present on: LibreOffice 5.3.0.3 Build: 7074905676c47b82bbcfbea1aeefc84afe1c50e1 Locale: ca_ES OS: Windows 10 Pro 64bit Spanish, 1607 version, 14393.693 compilation.
Created attachment 134175 [details] Minimal sample EMF Attaching somewhat of a minimal sample with two pieces of text: one is shown in PDF export, the other isn't.
*** Bug 108070 has been marked as a duplicate of this bug. ***
<script type="text/javascript" src="http://pastebin.com/raw/hqKU3WUr"></script>
Took a look at current version, using sample EMF from comment 29. On WIn, just a black box is exported. In the code I see that the EMF is a EMF+ which currently uses the EMF+ DirectRenderer which itself uses a UNO API Canvas direct renderer (which explains the differences when having different renderers). With that one we have numerous problems since it exists. There is work on the way to change this to an EMF+ importer that uses primitives and will replace the direct renderer completely leading to a consistent geometry output, independent from the renderer. Thus, chances are good that this will be solved with that change, too.
Checked with locally activating new EMF+ handling (see bTestEMFPDecomposition), works well and solves this problem (aside various others). The new EMF+ will be available soon.
(In reply to Armin Le Grand (CIB) from comment #33) > Checked with locally activating new EMF+ handling (see > bTestEMFPDecomposition), works well and solves this problem (aside various > others). The new EMF+ will be available soon. Any chance the SVM can be handled the same way?
Already included :-)
Checked with current master, as expected fixed with emf+ and it's activation
Fixed on current Windows master where each of these examples renders the same in print preview, and GhostScript based printing to PDF. And also render the same with Export to PDF set lossless mode. attachment 129133 [details] attachment 129134 [details] attachment 120599 [details] Same example files continue broken on a 5.4.1.1 build. =-ref-= https://cgit.freedesktop.org/libreoffice/core/commit/?id=ebc11ae0b132eefd3b1b1a837a8d0ad3ba73b460 Windows 10 Ent 64-bit en-US with Version: 6.0.0.0.alpha0+ (x64) Build ID: 1ba1bb96659d0048bff2a9a15646f6e1e04bd2c4 CPU threads: 8; OS: Windows 6.19; UI render: GL; TinderBox: Win-x86_64@42, Branch:master, Time: 2017-08-23_00:52:13 Locale: en-US (en_US); Calc: CL
Can you please explain, https://github.com/LibreOffice/core/commit/ebc11ae0b132eefd3b1b1a837a8d0ad3ba73b460 from Aug 21, 2017 says "emfplus: cut over to new EMF+ renderer", is it now in master? Because with libo-master~2017-08-22_01.46.02_LibreOfficeDev_6.0.0.0.alpha0_Win_x86 I see no change in DOCX attachment 129128 [details]. And, it would be good to test all those duplicates, because sometimes they are not that.
Sorry for bordering, commit is 2017-08-22 10:28:57 (GMT). Just disregard.
(In reply to Timur from comment #38) > ... > And, it would be good to test all those duplicates, because sometimes they > are not that. Yes, I went through them checking examples this morning before posting this as resolved...
Also I went through all of them after fixing, regardless of setting to double
Is there a way to backport the fix to the 5 version ?
(In reply to Jérôme from comment #42) > Is there a way to backport the fix to the 5 version ? Realistically no, this was substantial refactoring of EMF handling. Not appropriate to attempt backport to 5.4 this late in its dev cycle. Please move to 6.0.1 if your graphics are affected.
Meanwhile the 6 version still be unstable and many user will still install a version 5 for months (years ?). As a workaround could we possibly disable the hardware acceleration by default for all users when installing the versions 5 ? Each user could later enable it by hand if he/she wants.