To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=100373
User hdu changed the following:
What |Old value |New value
================================================================================
CC|'hdu' |'aw,hdu,sj'
--------------------------------------------------------------------------------
Assigned to|hdu |iha
--------------------------------------------------------------------------------
Summary|Textshapes in Metafiles re|Textshapes in Metafiles re
|nder wrong on windows if g|nder wrong if systems have
|enerated on Unix | different fonts
--------------------------------------------------------------------------------
------- Additional comments from h...@openoffice.org Fri Mar 20 12:30:09 +0000
2009 -------
The problem is a combination of
1. the stupid legacy concept of a "font's average charwidth", which could
almost be considered to be a
font-specific random number
2. OLE previews seem to export any font-stretching not by a font-stretch
factor (e.g. 120%), but by the
font-specific random number multiplied by that stretching factor (e.g.
NimbusL.avgcharwidth*120%)
3. different platforms have different fonts. E.g. NimbusSansL which is often
available on Unix systems is
rarely available on Mac or Windows), so the random font-specific numbers would
not match. The font-
stretch-factor as the ratio of the written-avgcharwidth and the
usedfont-avgcharwidth would be off by
the difference of the font-specific random numbers.
So the central root cause is item 2: don't depend on arithmetic with random
numbers if you need
consistent results. The solution would be easy by explicitly writing out the
font-stretch-factor instead
of the bogus stretchfactor*random value, but this has problems with backwards
compatibility.
@iha,aw.sj: For unstretched fonts such as in the attached document the solution
would be quite easy
though: just request the "default-font-width" for unstretched fonts during the
metafile export! The
"regression" probably comes from the fact, that the new drawing layer is much
more accurate and so
even factors of 100.0001% get the "stretched font treatment", which has the
problem with random-
numbers of the legacy metafiles outlined above.
If the above suggestion (request default-width for is done then most of the
problem is solved. The
remainder of this issue would to extend the old metafile format to use
font-stretch-factors instead of
the insane multiplication product. Since the drawinglayer rework aims to
replace the legacy metafiles by
a much better approach based on drawing primitives (which on my advice avoid
the random width
number to calculate stretch factors) this remaining task to extend the legacy
metafile will become
redundant soon.
---------------------------------------------------------------------
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@graphics.openoffice.org
For additional commands, e-mail: issues-h...@graphics.openoffice.org
---------------------------------------------------------------------
To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org
For additional commands, e-mail: allbugs-h...@openoffice.org
