Red Hat Bugzilla – Bug 495901
Graphics getting messed up between Linux and Win32 in OOo-writer
Last modified: 2009-05-27 11:21:02 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)
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
See the reproduced steps
Text should be fine under both
Cannot reproduce going the other way, assuming a Linux problem. Export as PDF and the formatting is correct on both platforms.
Created attachment 339712 [details]
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.
Both of them get messed up - but only the text sections
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.
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...
With a bit of qemu magic I can verify this
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
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
Made it in as openoffice.org-3.1.0-11.3.fc11