Created attachment 111919 [details] Example doc file causing the problem We have MS word files (*.doc) with WMF embeded. With LO version 4.1.2.3 those documents were correctly displayed. With version 4.3.5.2 the numbers in the dimensioning are far to big. Please see my attachments.
Created attachment 111920 [details] output in LO 4.1.2.3
Created attachment 111921 [details] output in LO 4.3.5.2
(In reply to Bernhard Donaubauer from comment #0) > We have MS word files (*.doc) with WMF embeded. With LO version 4.1.2.3 > those documents were correctly displayed. With version 4.3.5.2 the numbers > in the dimensioning are far to big. > > Please see my attachments. Hi Bernhard, Thanks for the great bug report! Would it be possible for you to include a screenshot of how the file appears in MS-Word? (and a comment with the software version #) That would help confirm the expected behavior. Thanks! Status -> NEEDINFO (Please change the status back to UNCONFIRMED after you provide the screenshot and/or leave a comment)
Created attachment 112121 [details] output from MSO 2000
I attached the output of MS Office 2000 (9.0.2812)
I set version to 4.3.0-beta, where it can be reproduced (I don't have alpha) and add a keyword "regression". Tested on Win64.
TESTING on Ubuntu 14.04 + LO 4.4.0.2 (In reply to Bernhard Donaubauer from comment #0) > We have MS word files (*.doc) with WMF embeded. With LO version 4.1.2.3 > those documents were correctly displayed. With version 4.3.5.2 the numbers > in the dimensioning are far to big. > REPRO: - Open attachment 111919 [details] in Writer RESULT: See the distorted image (compared to how it renders in Word: attachment 112121 [details]) CONFIRMED: Embedded WMF renders incorrectly, similar to rendering in attachment 111921 [details] Status -> NEW Hardware -> (Generalize)
Bibisect results from 43all: 038ec16923792263990256ed738920cd761e4f70 is the first bad commit commit 038ec16923792263990256ed738920cd761e4f70 Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com> Date: Tue May 20 11:36:30 2014 +0000 source-hash-11b81c1026c17548bfdbb861ac696f9c6acc628e commit 11b81c1026c17548bfdbb861ac696f9c6acc628e # bad: [423a84c4f7068853974887d98442bc2a2d0cc91b] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e # good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932 git bisect start 'latest' 'oldest' # good: [e02439a3d6297a1f5334fa558ddec5ef4212c574] source-hash-6b8393474974d2af7a2cb3c47b3d5c081b550bdb git bisect good e02439a3d6297a1f5334fa558ddec5ef4212c574 # good: [4850941efe43ae800be5c76e1102ab80ac2c085d] source-hash-980a6e552502f02f12c15bfb1c9f8e6269499f4b git bisect good 4850941efe43ae800be5c76e1102ab80ac2c085d # good: [a900e72b6357882284c5955bdf939bf14269f5fb] source-hash-dd1050b182260a26a1d0ba6d0ef3a6fecc3f4e07 git bisect good a900e72b6357882284c5955bdf939bf14269f5fb # skip: [e80660c5a1d812cd04586dae1f22767fc3778c4a] source-hash-07c60c8ee2d1465544a6a39e57bc06b3690b8dfb git bisect skip e80660c5a1d812cd04586dae1f22767fc3778c4a # skip: [df9bcaed2faa2a8d11b19f877cdff3a12a887278] source-hash-6ba9692d8bbe3e3c245aca9a7c928e81178d05f1 git bisect skip df9bcaed2faa2a8d11b19f877cdff3a12a887278 # bad: [5c9e81ec77cd98f952434decf83ec9820d736e56] source-hash-94e3f3e5015e53b5f3c8e5775b668e0bc12ab457 git bisect bad 5c9e81ec77cd98f952434decf83ec9820d736e56 # good: [6feabb3ce67846b727583754afd4380ec7d59f13] source-hash-874a9b46cb54e4c05e262e5d7490790a08ea0c55 git bisect good 6feabb3ce67846b727583754afd4380ec7d59f13 # good: [e4b46548ba53a7007ed023fc2b2287c4ff9796dd] source-hash-9f06e4bc3a56806061f759770f758ad3c7ddf09c git bisect good e4b46548ba53a7007ed023fc2b2287c4ff9796dd # bad: [c6faec16f965fa85bd2df9f3f6a4e96838f97737] source-hash-1e5b495a882493a81cc82ee34e3339b071bc162d git bisect bad c6faec16f965fa85bd2df9f3f6a4e96838f97737 # good: [16d0a5059bce9198bfae647a72dc06b438be583f] source-hash-944c78ecb91608f4c3e9bab32fdbc90c67326525 git bisect good 16d0a5059bce9198bfae647a72dc06b438be583f # good: [a9a94da9a44ce71a7a767738992779f7070ce193] source-hash-c764a3d978beb2e6197a8d3f7df53d81ebf72467 git bisect good a9a94da9a44ce71a7a767738992779f7070ce193 # bad: [038ec16923792263990256ed738920cd761e4f70] source-hash-11b81c1026c17548bfdbb861ac696f9c6acc628e git bisect bad 038ec16923792263990256ed738920cd761e4f70 # good: [daff10f9ce14ce7139fe7c0dee02c23b5dbeadef] source-hash-3d91d54c49af4dd0832c27ccb9721724fa98b6b5 git bisect good daff10f9ce14ce7139fe7c0dee02c23b5dbeadef # first bad commit: [038ec16923792263990256ed738920cd761e4f70] source-hash-11b81c1026c17548bfdbb861ac696f9c6acc628e
The behaviour seems to have changed at the below commit. Adding Cc: to quikee@gmail.com; Could you possibly take a look at this? Thanks commit a9020e461803964a206d5551884b70717eed165c Author: Tomaž Vajngerl <tomaz.vajngerl@collabora.com> Date: Mon Apr 28 15:16:53 2014 +0200 fdo#74336 limit the size of the non-placeable WMF image For a non-placable WMF image the size is unknown and needs to be calculated by using a bounding box over all elements. Sometimes this results in a very big image which is not drawn correctly when using dashes and dots. This change normalizes the size to reasonable values. Change-Id: I0e5b71fb011c5a9dff1c5cb13e29d5578570ca65
Matthew, can you please explain why you added quikee@gmail.com and not tomaz.vajngerl@collabora.com to CC? Thank you.
(In reply to Timur from comment #10) > Matthew, can you please explain why you added quikee@gmail.com and not > tomaz.vajngerl@collabora.com to CC? Thank you. what's the difference, it's the same person :)
You can only Cc: to email addresses which are bugzilla accounts - not everyone has the same commit email and bugzilla email (I don't either)
This bug affects not only graphics in WMF format but also in EMF format. Seen in LO5.0.3.2 on Windows.
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]
Adding Cc: to Tomaž Vajngerl
Created attachment 132816 [details] Screenshot from MS Office for Mac. It seems that under Office 15 for Mac, the numbers are also big
Created attachment 132817 [details] On same document converted to .docx, the numbers are too small. On same document converted to .docx, the numbers are too small. In MS Office numbers looks correctly.
** 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 with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. 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) from 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: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Repro in 6.1+
Repro 6.3+
Repro 7.0+.
Created attachment 171956 [details] Extracted EMF image with wrong font size
Created attachment 172465 [details] Minified sample to demonstrate the problem It looks like this problem is related to the wrong interpretation of the "BoundingBox" and "Inch" values in AldusPlaceable header together with SetMapMode set to 8 (MM_AMISOTROPIC) and dimensions created by SetWindowOrgEx/SetWindowExtEx. In this sample BoundingBox is [0, 0, 10000, 10000], Inch is 1440; SetWindowOrgEx is [0, 0] (could be skipped) and SetWindowExtEx is [2000, 2000].
Created attachment 172466 [details] Screenshot for minified sample opened in LO 7.2 and MS Paint side by side
More information about "Aldus Placeable Metafile" is here: http://fileformats.archiveteam.org/wiki/Windows_Metafile
Yeah, the header is different for placeable metafiles, Microsoft (back when it had a useful KB) actually ga e some example code: https://web.archive.org/web/20141130065426/http://support.microsoft.com/kb/66949
Hossein committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/d25906087918c085239aac30fd72cb65aa7b9eb4 tdf#88163 Fix WMF font size It will be available in 7.3.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I verify the font size in the graphic in attachment 111919 [details] is now the expected one. The font size in attachment 132817 [details] is still tiny, but I guess that is the yet-unsolved second issue. Arch Linux 64-bit Version: 7.3.0.0.alpha0+ / LibreOffice Community Build ID: 104847ed014e95a915d314de7091c7d572eade67 CPU threads: 8; OS: Linux 5.13; UI render: default; VCL: kf5 (cairo+xcb) Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded Built on 3 September 2021
(In reply to Buovjaga from comment #29) > I verify the font size in the graphic in attachment 111919 [details] is now > the expected one. > > The font size in attachment 132817 [details] is still tiny, but I guess that > is the yet-unsolved second issue. Thank you for testing, and you're right. As can be read in the commit message: The problems in tdf#88163 can be categorized into two parts: 1. A regression which is caused by the commit a9020e461803964a206d5551884b70717eed165c. The font size for text is wrongly calculated for wmf files WITHOUT the placeable header. 2. A long-lasting bug that has existed from LO 3.5 (tested with various LibreOffice versions from 3.5 to master). The font size for text is wrongly calculated for wmf files WITH the placeable header. The above patch only solved the first part. The wmf file inside attachment 111919 [details] does have placeable header, and this is the unsolved second part of the issue.
(In reply to Buovjaga from comment #29) > I verify the font size in the graphic in attachment 111919 [details] is now > the expected one. > > The font size in attachment 132817 [details] is still tiny, but I guess that > is the yet-unsolved second issue. Thank you for testing, and you're right. As can be read in the commit message: The problems in tdf#88163 can be categorized into two parts: 1. A regression which is caused by the commit a9020e461803964a206d5551884b70717eed165c. The font size for text is wrongly calculated for wmf files WITHOUT the placeable header. 2. A long-lasting bug that has existed from LO 3.5 (tested with various LibreOffice versions from 3.5 to master). The font size for text is wrongly calculated for wmf files WITH the placeable header. The above patch only solved the first part. The wmf file inside attachment 132817 [details] does have placeable header, and this is the unsolved second part of the issue.
There is similar (maybe related) Bug 142941, where embedded EMF image inside EMF+ have wrong image sizes.
Hossein committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/5e4e1cdb1e14354b42838e1dfcf82873b3071896 tdf#88163 Fix font size for placeable wmf files It will be available in 7.3.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Commit Notification from comment #33) > Hossein committed a patch related to this issue. > It has been pushed to "master": > > https://git.libreoffice.org/core/commit/5e4e1cdb1e14354b42838e1dfcf82873b3071896 I'm afraid, this was a completely incorrect change. It caused tdf#149894; and looking at it, I see that the bugdoc in this bug (attachment 132817 [details], mentioned in comment 29 and comment 31) is also treated incorrectly. Extract the WMFs from the attachment 132817 [details] (unzip, look at word/media/image1.wmf). Open the WMF in Draw. Check to reset to original size by right-clicking the object. Before the change, the size was 270.93 x 198.17 mm. After that, it is now 25.99 x 18.99 mm. Now open MS Word, create a blank document, make it use the largest possible page size (~55x55 cm, to avoid automatic downscale), and drag-and-drp the WMF onto its document. The object size (as seen in its "Layout" dialog, accessible in Word by right-clicking the object, and choosing "Size and Position") is 270.93 x 198.44 mm. It also shows "Original size", which is 7168.36 x 5243.25 mm. Note how the reference implementation (MS Word) used ~the same dimensions as we did *before* the change. If you do the same procedure with the WMF contained inside attachment 181179 [details], you will see a similar picture (except the wrong new size in Draw is now much *bigger* than the correct size used before).
(In reply to Mike Kaganski from comment #34) > I'm afraid, this was a completely incorrect change. > It caused tdf#149894; and looking at it, I see that the bugdoc in this bug > (attachment 132817 [details], mentioned in comment 29 and comment 31) is > also treated incorrectly. I have checked both files, and both two are rendered exactly the same as visible in the latest version of Microsoft Word. Both font size and the visible image height and width is the same in the two documents with what Word shows. > Extract the WMFs from the attachment 132817 [details] (unzip, look at > word/media/image1.wmf). > Open the WMF in Draw. > Check to reset to original size by right-clicking the object. > Before the change, the size was 270.93 x 198.17 mm. After that, it is now > 25.99 x 18.99 mm. > > Now open MS Word, create a blank document, make it use the largest possible > page size (~55x55 cm, to avoid automatic downscale), and drag-and-drp the > WMF onto its document. > The object size (as seen in its "Layout" dialog, accessible in Word by > right-clicking the object, and choosing "Size and Position") is 270.93 x > 198.44 mm. It also shows "Original size", which is 7168.36 x 5243.25 mm. > > Note how the reference implementation (MS Word) used ~the same dimensions as > we did *before* the change. > > If you do the same procedure with the WMF contained inside attachment 181179 [details] > [details], you will see a similar picture (except the wrong new size in Draw > is now much *bigger* than the correct size used before). The font size for the examples here is fixed with the above patches. I think wrong calculation of the image size is another issue, which is discussed in tdf#149894, and I will try to fix it.