Bug 88163 - [WMF] FILEOPEN Wrong size of fonts
Summary: [WMF] FILEOPEN Wrong size of fonts
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: graphics stack (show other bugs)
Version:
(earliest affected)
4.3.0.0.beta1
Hardware: All All
: medium normal
Assignee: Hossein
URL:
Whiteboard: target:7.3.0
Keywords: bibisected, bisected, filter:doc, regression
Depends on:
Blocks: EMF-WMF
  Show dependency treegraph
 
Reported: 2015-01-07 15:36 UTC by Bernhard Donaubauer
Modified: 2023-07-10 14:48 UTC (History)
9 users (show)

See Also:
Crash report or crash signature:


Attachments
Example doc file causing the problem (12.50 KB, application/msword)
2015-01-07 15:36 UTC, Bernhard Donaubauer
Details
output in LO 4.1.2.3 (44.64 KB, image/png)
2015-01-07 15:37 UTC, Bernhard Donaubauer
Details
output in LO 4.3.5.2 (61.95 KB, image/png)
2015-01-07 15:37 UTC, Bernhard Donaubauer
Details
output from MSO 2000 (59.63 KB, image/png)
2015-01-12 14:44 UTC, Bernhard Donaubauer
Details
Screenshot from MS Office for Mac. (479.11 KB, image/png)
2017-04-25 07:26 UTC, Bartosz
Details
On same document converted to .docx, the numbers are too small. (16.41 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2017-04-25 07:29 UTC, Bartosz
Details
Extracted EMF image with wrong font size (1.26 KB, image/wmf)
2021-05-13 10:38 UTC, Bartosz
Details
Minified sample to demonstrate the problem (198 bytes, image/x-wmf)
2021-05-31 01:43 UTC, Valek Filippov
Details
Screenshot for minified sample opened in LO 7.2 and MS Paint side by side (16.28 KB, image/png)
2021-05-31 01:46 UTC, Valek Filippov
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Bernhard Donaubauer 2015-01-07 15:36:37 UTC
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.
Comment 1 Bernhard Donaubauer 2015-01-07 15:37:16 UTC
Created attachment 111920 [details]
output in LO 4.1.2.3
Comment 2 Bernhard Donaubauer 2015-01-07 15:37:46 UTC
Created attachment 111921 [details]
output in LO 4.3.5.2
Comment 3 Robinson Tryon (qubit) 2015-01-11 11:25:32 UTC Comment hidden (obsolete)
Comment 4 Bernhard Donaubauer 2015-01-12 14:44:11 UTC
Created attachment 112121 [details]
output from MSO 2000
Comment 5 Bernhard Donaubauer 2015-01-12 14:45:18 UTC Comment hidden (obsolete)
Comment 6 Timur 2015-01-12 15:25:38 UTC
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.
Comment 7 Robinson Tryon (qubit) 2015-01-14 02:17:47 UTC
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)
Comment 8 Matthew Francis 2015-01-29 08:40:32 UTC Comment hidden (bibisect, obsolete)
Comment 9 Matthew Francis 2015-01-29 09:18:26 UTC
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
Comment 10 Timur 2015-04-23 14:43:12 UTC Comment hidden (obsolete)
Comment 11 Michael Stahl (allotropia) 2015-04-23 14:46:08 UTC Comment hidden (obsolete)
Comment 12 Matthew Francis 2015-04-23 14:50:32 UTC Comment hidden (obsolete)
Comment 13 Joerg 2015-11-28 12:32:01 UTC
This bug affects not only graphics in WMF format but also in EMF format. Seen in LO5.0.3.2 on Windows.
Comment 14 Robinson Tryon (qubit) 2015-12-13 11:12:03 UTC Comment hidden (obsolete)
Comment 15 Xisco Faulí 2016-09-26 15:09:37 UTC Comment hidden (obsolete)
Comment 16 Bartosz 2017-04-25 07:26:15 UTC
Created attachment 132816 [details]
Screenshot from MS Office for Mac.

It seems that under Office 15 for Mac, the numbers are also big
Comment 17 Bartosz 2017-04-25 07:29:54 UTC
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.
Comment 18 QA Administrators 2018-04-26 02:38:18 UTC Comment hidden (obsolete)
Comment 19 Timur 2018-04-26 10:19:52 UTC Comment hidden (obsolete)
Comment 20 QA Administrators 2019-04-27 02:51:27 UTC Comment hidden (obsolete)
Comment 21 Timur 2019-04-29 07:56:17 UTC Comment hidden (obsolete)
Comment 22 Timur 2020-05-12 14:02:14 UTC Comment hidden (obsolete)
Comment 23 Bartosz 2021-05-13 10:38:20 UTC
Created attachment 171956 [details]
Extracted EMF image with wrong font size
Comment 24 Valek Filippov 2021-05-31 01:43:36 UTC
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].
Comment 25 Valek Filippov 2021-05-31 01:46:54 UTC
Created attachment 172466 [details]
Screenshot for minified sample opened in LO 7.2 and MS Paint side by side
Comment 26 Bartosz 2021-07-15 08:50:13 UTC
More information about "Aldus Placeable Metafile" is here: 
http://fileformats.archiveteam.org/wiki/Windows_Metafile
Comment 27 Chris Sherlock 2021-08-14 21:13:23 UTC
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
Comment 28 Commit Notification 2021-09-03 07:38:15 UTC
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.
Comment 29 Buovjaga 2021-09-03 12:21:27 UTC
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
Comment 30 Hossein 2021-09-03 13:48:08 UTC Comment hidden (obsolete)
Comment 31 Hossein 2021-09-03 13:50:53 UTC
(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.
Comment 32 Bartosz 2021-09-06 06:31:33 UTC
There is similar (maybe related) Bug 142941, where embedded EMF image inside EMF+ have wrong image sizes.
Comment 33 Commit Notification 2021-09-27 20:09:16 UTC
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.
Comment 34 Mike Kaganski 2022-12-07 11:34:07 UTC
(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).
Comment 35 Hossein 2023-07-10 14:48:57 UTC
(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.