Bug 69886 - bug introduced in OOo 3.2 produces distorted text in WMF export
Summary: bug introduced in OOo 3.2 produces distorted text in WMF export
Status: NEEDINFO
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Draw (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: EMF-WMF
  Show dependency treegraph
 
Reported: 2013-09-27 17:11 UTC by angeoco
Modified: 2019-05-08 18:28 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments
Minimal test files - ODG, exported WMF, WMF -> PDF, for all LO/OOo versions (34.19 KB, application/zip)
2013-09-27 17:11 UTC, angeoco
Details
Minimal test files - ODG, exported WMF, WMF->PDF, for various LO/OOo versions (77.49 KB, application/x-zip-compressed)
2013-09-29 19:49 UTC, angeoco
Details
ZIP containing WMFs exported under v4162, v4282, v4352, v4412 (3.50 KB, application/zip)
2015-04-04 07:00 UTC, Owen Genat (retired)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description angeoco 2013-09-27 17:11:02 UTC
Created attachment 86734 [details]
Minimal test files - ODG, exported WMF, WMF -> PDF, for all LO/OOo versions

When I export any drawing to WMF, all text appears distorted: very narrow and widely spaced. This affects files created/exported using LO 3.5.4 on Linux and OOo 3.2.0 on Windows, but *NOT* OOo 3.1.1 on Windows. In the test files attached, the WMF files were read using the Windows WMF library on Windows 2000, but results seem similar using Windows XP and Windows 7. The font used in the test files is Arial, which is available on all machines used.
Comment 1 tommy27 2013-09-27 17:34:04 UTC
not reproducible in 3.5.7 and 4.1.1 final releases under Win7 64bit.
both .wmf and .pdf export work fine with no distortion in output.

did you try using recent 4.0.5 or 4.1.1 releasese? or are you still using old 3.5.4?
Comment 2 angeoco 2013-09-27 18:58:43 UTC
I'm stuck with 3.5.4 for the moment, as it's the distro-supplied version. I'll see if I can find a machine over the weekend that I can test v4 on.
Comment 3 angeoco 2013-09-29 19:49:13 UTC
Created attachment 86814 [details]
Minimal test files - ODG, exported WMF, WMF->PDF, for various LO/OOo versions

I've now tested the bug using LO 4.1.1.2, and confirm that the results have not changed: exporting from OOo 3.1.1 works, all later versions produce faulty results. The resulting files are in the attachment.
Comment 4 tommy27 2013-09-29 20:47:17 UTC
the pdf you submitted look indeed distorted, however if I load your .odg and export it to .pdf in my PC using LibO 4.1.1, my .pdf output looks normal.
Comment 5 Owen Genat (retired) 2013-09-30 00:45:10 UTC
Thanks to the reporter for providing such a comprehensive set of test files. I am going to confirm this bug concerning aspect ratios of Draw files being exported to WMF. Setting status to NEW. I can also confirm (under Ubuntu 10.04 running LO v4.1.0.4 Build ID: 89ea49ddacd9aa532507cbf852f2bb22b1ace28) that the export to PDF ratios are OK for all the supplied ODGs. This probably just indicates that the PDF filter has improved, while the WMF filter has not.

This particular problem appears to relate to how Draw interprets the page container when exporting to the WMF format. If I select the object in the ODGs and check the Selection option on the Export dialog, the export Options dialog indicates the file will be the expected number of points in dimension. The resultant WMF is then also correct in dimension and aspect ratio for all provided ODGs (under Eye of Gnome v2.30.0 and when opened by Gimp v2.6.8):

File         Export                 EoG              Gimp
----         ------                 ---              ----
311-311.odg  236.95 x 47.42 points  236 x 47 pixels  296 x 59 pixels
320-320.odg  236.95 x 47.42 points  236 x 47 pixels  296 x 59 pixels
354-354.odg  285.79 x 47.42 points  285 x 47 pixels  357 x 59 pixels
411-411.odg  237.91 x 47.42 points  237 x 47 pixels  297 x 59 pixels

Conversely, exporting the entire page (A4 / 595 x 842 points) results in variation in the dimension (shown below in pixels), aspect ratio, and most importantly, the manner in which the content is placed within the container:

File           EoG        Gimp        Placement (of text)
----           ---        ----        -------------------
311-311.wmf    538 x 785  673 x 981   Lower half, highly compressed
311-320.wmf    538 x 785  673 x 981   Lower half, moderately compressed
311-4104.wmf*  595 x 841  744 x 1052  Full area, moderately compressed[1]
311-411.wmf    595 x 841  744 x 1052  Full area, moderately compressed
320-320.wmf    538 x 785  673 x 981   Lower half, moderately compressed
320-4104.wmf*  595 x 841  744 x 1052  Full area, moderately compressed[1]
354-354.wmf    595 x 841  744 x 1052  Lower half, moderately compressed
354-4104.wmf*  595 x 841  744 x 1052  Full area, moderately compressed[1]
411-311.wmf    538 x 785  673 x 981   Lower half, highly compressed[2]
411-4104.wmf*  595 x 841  744 x 1052  Full area, moderately compressed[1]
411-411.wmf    595 x 841  744 x 1052  Full area, moderately compressed[1]

* = my export under v4.1.0.4.
[1] Text is more compressed (taller) than shown in 311-411.wmf.
[2] Also in a different font.

The main issue would seem to be why the text is being expanded to fill either the lower half of the page or the entire page? If an entire page is being exported with only a small text object on it, I would expect to see a graphic that is in keeping with the corresponding PDF i.e., mostly blank space with a small piece of text. If a selection is made and then exported, then the available space in the graphic container should (and appears to be) filled accordingly.
Comment 6 QA Administrators 2015-04-01 14:40:57 UTC Comment hidden (obsolete)
Comment 7 Owen Genat (retired) 2015-04-04 07:00:07 UTC
Created attachment 114606 [details]
ZIP containing WMFs exported under v4162, v4282, v4352, v4412

Re-tested under GNU/Linux x86_64 using:
v4.1.6.2 Build ID: 40ff705089295be5be0aae9b15123f687c05b0a
v4.2.8.2 Build ID: 48d50dbfc06349262c9d50868e5c1f630a573ebd
v4.3.5.2 Build ID: 3a87456aaa6a95c63eea1c1b3201acedf0751bd5
v4.4.1.2 Build ID: 45e2de17089c24a1fa810c8f975a7171ba4cd432

... by opening 311-311.odg in the original attachment > File > Export... > to WMF format (entire page i.e., without selection). I am not near a computer at present with Eye of Gnome so cannot compare with my prior tests. Instead I have used ImageMagick v8:6.7.7.10-5+deb7u3 to view the resultant WMF. The WMFs exported under v4.1 and v4.2 render very poorly (unrecognisable), however the WMFs exported under v4.3 and 4.4 show significant improvement. The text is set in italic (original is Roman) but otherwise the geometry, resolution, and print size is as expected.
Comment 8 Owen Genat (retired) 2015-04-04 07:00:38 UTC Comment hidden (obsolete)
Comment 9 tommy27 2016-04-16 07:27:15 UTC Comment hidden (obsolete)
Comment 10 Timur 2018-11-05 10:44:48 UTC
Let's discuss if this is a bug. 
It lacks simple Expected and Reproduced steps. 
From what I understood, exported WMF should be opened in external viewer. 
Can't say whether it's of some use, but when all those WMFs are inserted in LO or MSO, they look fine.
Comment 11 QA Administrators 2019-05-08 18:28:11 UTC
Dear angeoco,

This bug has been in NEEDINFO status with no change for at least
6 months. Please provide the requested information as soon as
possible and mark the bug as UNCONFIRMED. Due to regular bug
tracker maintenance, if the bug is still in NEEDINFO status with
no change in 30 days the QA team will close the bug as INSUFFICIENTDATA
due to lack of needed information.

For more information about our NEEDINFO policy please read the
wiki located here:
https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO

If you have already provided the requested information, please
mark the bug as UNCONFIRMED so that the QA team knows that the
bug is ready to be confirmed.
 
Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-NeedInfo-Ping