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.
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?
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.
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.
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.
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.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: *Test to see if the bug is still present on a currently supported version of LibreOffice (4.4.1 or later) https://www.libreoffice.org/download/ *If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior *If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT *Update the version field *Reply via email (please reply directly on the bug tracker) *Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-04-01
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.
Hardware set to All/All.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.0.5 or 5.1.2 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT - Update the version field - Reply via email (please reply directly on the bug tracker) - Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2016-04-16
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.
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
Dear angeoco, Please read this message in its entirety before proceeding. Your bug report is being closed as INSUFFICIENTDATA due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of our bug tracker Warm Regards, QA Team MassPing-NeedInfo-FollowUp