Bug 495901 - Graphics getting messed up between Linux and Win32 in OOo-writer
Graphics getting messed up between Linux and Win32 in OOo-writer
Product: Fedora
Classification: Fedora
Component: openoffice.org (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Caolan McNamara
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2009-04-15 10:02 EDT by Paul F. Johnson
Modified: 2009-05-27 11:21 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-05-27 11:21:02 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
File to demonstrate the problem (46.00 KB, application/vnd.oasis.opendocument.text)
2009-04-15 10:02 EDT, Paul F. Johnson
no flags Details
A metafile (178.83 KB, application/octet-stream)
2009-04-15 12:17 EDT, Caolan McNamara
no flags Details

External Trackers
Tracker ID Priority Status Summary Last Updated
OpenOffice.org 101566 None None None Never

  None (edit)
Description Paul F. Johnson 2009-04-15 10:02:54 EDT
Created attachment 339687 [details]
File to demonstrate the problem

Description of problem:
Attached is a file created under linux with graphics brought in from OOo-draw and OOo-calc. They all use the Arial font (available from a non-supported package called msstcorefonts under Linux).

While the normal text is fine, the text from the graphics is messed up (font data looks not to be saved)

Version-Release number of selected component (if applicable):
3.1.0-9.2 (Linux) 3.0 (Win32)

How reproducible:

Steps to Reproduce:
1. Load the file attached in Linux - output is fine
2. Load under Win32 and the text on the graphics is messed up
Actual results:
See the reproduced steps

Expected results:
Text should be fine under both

Additional info:
Cannot reproduce going the other way, assuming a Linux problem. Export as PDF and the formatting is correct on both platforms.
Comment 1 Caolan McNamara 2009-04-15 12:17:10 EDT
Created attachment 339712 [details]
A metafile

I see two graphics in that file, one is the gif logo at the top of the screen. And one is the .svm metafile graph of a curve attached here. There is also two ole2 objects, a drawing of a bar-chart and a small equation.

Which one is causing the problem when opened on windows. That's not a platform I have easy access to.
Comment 2 Paul F. Johnson 2009-04-16 04:36:16 EDT
Both of them get messed up - but only the text sections
Comment 3 Caolan McNamara 2009-04-16 04:44:07 EDT
There are four graphical elements here, two graphics and two ole objects. Can you tell me which two elements have the problem. The gif logo, the drawing of a curve, the equation object or the bar-chart drawing.
Comment 4 Paul F. Johnson 2009-04-16 07:29:43 EDT
The bar chart and the curve - the text gets messed up big style on both. The others are fine.

Sorry for the confusion. Brain not working today...
Comment 5 Caolan McNamara 2009-04-17 04:12:46 EDT
With a bit of qemu magic I can verify this
Comment 6 Caolan McNamara 2009-05-05 09:01:12 EDT
oh dear, if I'm reading this right its a fairly monstrous thing really, font width metric element on windows comes from windows which would give tmAveCharWidth which is an average width which is < height on typical case. On linux we're cooking up our own one, which effectively boils down to the same as height for the typical case.

Moving everything over to the windows meaning for width seems futile as it seems ingrained that width == height ==> unstretched font.

So as a quick fix we can *not* write a specific width for a font when writing metafiles, that should mean that a default width is picked when rendering it, regardless of the platform, so the majority of the problem goes away, and only appears again for non-default widths. 

For non-default width we probably need to kill the windows width, make it same calculation as the freetype based one, and add a "GetWinAverageWidth" or something and get the wmf importer/exporter to use it to convert to the OOo understanding of the width metric
Comment 7 Caolan McNamara 2009-05-05 09:07:56 EDT
I can reduce the impact of this. Fix checked in, will be in >= 3.1.0-11.3 but problem will still exist until we can decide upstream which (if any) method should be used consistently across platforms to get the value which gets plugged into the LOGFONT record a wmf's CreateFontIndirect
Comment 8 Caolan McNamara 2009-05-27 11:21:02 EDT
Made it in as openoffice.org-3.1.0-11.3.fc11

Note You need to log in before you can comment on or make changes to this bug.