Bug 104252 - Embedded EMF/WMF and SVM images shows text content on screen but not in print or PDF export on Windows (with HW acceleration and GDI, but not with OpenGL)
Summary: Embedded EMF/WMF and SVM images shows text content on screen but not in print...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: graphics stack (show other bugs)
Version:
(earliest affected)
4.0.2.2 release
Hardware: All Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:6.0.0
Keywords: bibisected
: 58831 74686 75373 75574 77525 80389 89649 95875 99651 99727 101068 106442 108070 (view as bug list)
Depends on:
Blocks: Font-Rendering EMF-WMF
  Show dependency treegraph
 
Reported: 2016-11-29 12:05 UTC by Wytze Jager
Modified: 2018-02-28 04:42 UTC (History)
25 users (show)

See Also:
Crash report or crash signature:


Attachments
course excersise (60.53 KB, application/zip)
2016-11-29 12:05 UTC, Wytze Jager
Details
Example File (29.24 KB, application/vnd.openxmlformats-officedocument.wordprocessingml)
2016-11-29 15:54 UTC, Telesto
Details
Results PDF export (411.02 KB, application/pdf)
2016-11-29 15:59 UTC, Telesto
Details
image3.emf inserted to Draw odg (23.00 KB, application/postscript)
2016-11-29 16:38 UTC, V Stuart Foote
Details
image4.emf inserted to Draw odg (23.67 KB, application/postscript)
2016-11-29 16:41 UTC, V Stuart Foote
Details
Minimal sample EMF (2.59 KB, image/x-emf)
2017-06-21 04:47 UTC, Aron Budea
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Wytze Jager 2016-11-29 12:05:16 UTC
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.
Comment 1 V Stuart Foote 2016-11-29 15:26:43 UTC Comment hidden (obsolete)
Comment 2 Telesto 2016-11-29 15:54:18 UTC
Created attachment 129128 [details]
Example File

EMF Tables only
Comment 3 Telesto 2016-11-29 15:58:22 UTC
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
Comment 4 Telesto 2016-11-29 15:59:28 UTC
Created attachment 129132 [details]
Results PDF export
Comment 5 V Stuart Foote 2016-11-29 16:34:01 UTC
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
Comment 6 V Stuart Foote 2016-11-29 16:38:00 UTC
Created attachment 129133 [details]
image3.emf inserted to Draw odg
Comment 7 V Stuart Foote 2016-11-29 16:41:19 UTC
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.
Comment 8 V Stuart Foote 2016-11-29 16:43:39 UTC Comment hidden (obsolete)
Comment 9 m.a.riosv 2016-11-29 23:13:31 UTC
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.
Comment 10 V Stuart Foote 2016-11-30 16:32:57 UTC
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
Comment 11 V Stuart Foote 2016-11-30 18:03:24 UTC
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
Comment 12 Telesto 2016-12-28 10:49:03 UTC
*** Bug 58831 has been marked as a duplicate of this bug. ***
Comment 13 V Stuart Foote 2016-12-28 13:52:46 UTC
*** Bug 80389 has been marked as a duplicate of this bug. ***
Comment 14 V Stuart Foote 2016-12-28 14:26:41 UTC
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.
Comment 15 V Stuart Foote 2016-12-28 14:48:24 UTC
*** Bug 77525 has been marked as a duplicate of this bug. ***
Comment 16 V Stuart Foote 2016-12-28 15:26:46 UTC
*** Bug 74686 has been marked as a duplicate of this bug. ***
Comment 17 V Stuart Foote 2016-12-28 15:27:21 UTC
*** Bug 75373 has been marked as a duplicate of this bug. ***
Comment 18 V Stuart Foote 2016-12-28 15:28:41 UTC
*** Bug 75574 has been marked as a duplicate of this bug. ***
Comment 19 V Stuart Foote 2016-12-28 15:29:28 UTC
*** Bug 95875 has been marked as a duplicate of this bug. ***
Comment 20 V Stuart Foote 2016-12-28 15:30:43 UTC
*** Bug 99727 has been marked as a duplicate of this bug. ***
Comment 21 V Stuart Foote 2016-12-28 15:31:15 UTC
*** Bug 101068 has been marked as a duplicate of this bug. ***
Comment 22 V Stuart Foote 2016-12-28 16:03:24 UTC
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.
Comment 23 Telesto 2016-12-28 18:32:38 UTC
*** Bug 89649 has been marked as a duplicate of this bug. ***
Comment 24 V Stuart Foote 2016-12-31 17:36:19 UTC
*** Bug 99651 has been marked as a duplicate of this bug. ***
Comment 25 Timur 2017-02-07 09:32:12 UTC
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.
Comment 26 V Stuart Foote 2017-02-07 16:25:16 UTC
(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.
Comment 27 Aron Budea 2017-03-09 06:30:46 UTC
*** Bug 106442 has been marked as a duplicate of this bug. ***
Comment 28 Consorci Sanitari de l'Alt Penedès 2017-03-13 13:35:28 UTC
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.
Comment 29 Aron Budea 2017-06-21 04:47:09 UTC
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.
Comment 30 Xisco Faulí 2017-08-01 13:56:23 UTC
*** Bug 108070 has been marked as a duplicate of this bug. ***
Comment 31 surya 2017-08-13 09:15:54 UTC Comment hidden (spam)
Comment 32 Armin Le Grand (CIB) 2017-08-18 07:37:32 UTC
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.
Comment 33 Armin Le Grand (CIB) 2017-08-18 09:09:18 UTC
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.
Comment 34 V Stuart Foote 2017-08-18 12:49:10 UTC
(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?
Comment 35 Armin Le Grand (CIB) 2017-08-18 15:16:48 UTC
Already included :-)
Comment 36 Armin Le Grand (CIB) 2017-08-23 07:12:26 UTC
Checked with current master, as expected fixed with emf+ and it's activation
Comment 37 V Stuart Foote 2017-08-23 14:05:11 UTC
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
Comment 38 Timur 2017-08-23 15:11:32 UTC
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.
Comment 39 Timur 2017-08-23 15:13:35 UTC
Sorry for bordering, commit is 2017-08-22 10:28:57 (GMT). Just disregard.
Comment 40 V Stuart Foote 2017-08-23 16:24:36 UTC
(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...
Comment 41 Armin Le Grand (CIB) 2017-08-23 17:00:06 UTC
Also I went through all of them after fixing, regardless of setting to double
Comment 42 Jérôme 2018-02-20 20:23:43 UTC
Is there a way to backport the fix to the 5 version ?
Comment 43 V Stuart Foote 2018-02-20 20:49:47 UTC
(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.
Comment 44 Jérôme 2018-02-28 04:42:56 UTC
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.