Issue 96581 - Font rendered wrong in text objects
Summary: Font rendered wrong in text objects
Alias: None
Product: Draw
Classification: Application
Component: formatting (show other issues)
Version: DEV300m35
Hardware: All Windows XP
: P3 Trivial (vote)
Target Milestone: OOo 3.1
Assignee: wolframgarten
QA Contact: issues@graphics
: 97337 99349 99482 99605 99901 (view as issue list)
Depends on:
Blocks: 87854 23486 47221
  Show dependency tree
Reported: 2008-11-25 12:50 UTC by daniel.rentz
Modified: 2009-04-24 16:03 UTC (History)
5 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Note You need to log in before you can comment on or make changes to this issue.
Description daniel.rentz 2008-11-25 12:50:05 UTC
In calc, insert a text object, enter some text, make sure that font size is !=
10 points. Leave edit mode -> characters are to wide and overflow each other.
Comment 1 Armin Le Grand 2008-12-17 16:59:26 UTC
AW: It's a WIN32 only error and seems to have to do with the different Font
matching on windows. Problem here is that Windows does not allow to get a
good/correct font with providing width and height values. Current behaviour is
to offer only height, a good width is offered from the system. Currently, there
is still System-dependent code in getVclFontFromFontAttributes to set the font
width after getting a font when the target width != target height.
I already fixed this in aw059 for TextSimplePortionPrimitive2D::getB2DRange and
TextSimplePortionPrimitive2D::getTextOutlinesAndTransformation by calculating a
scaling factor between the target font width and the acually offered one from
Windows. This is done using getCurrentFontRelation().
I will now test out if it is necessary at all to set the font width in
Comment 2 Armin Le Grand 2008-12-17 17:41:01 UTC
AW: It is necessary.
The mechanism to transport the font info that the original font had no width, is
that in the TextSimplePortionPrimitive2D FontAttributes transformation the scale
is equal in X and Y. Due to the calculated (bended...) MapModes used form the
calc for repaint, multiplying this with the ObjectToWorld transformation in the
renderer leads to unequal font sizes in X and Y. This again leads to the
renderer is thinking it needs to adapt font scaling.
Maybe i will need to transport the WidthEqualHeight info independent from the
Scaling in the text primitive transformation, i have to think about this
carefully. Maybe it's also an option to force the current font's width when not
set in VCL::Font, have to ask HDU what he thinks...
Comment 3 amy2008 2008-12-18 01:30:25 UTC
*** Issue 97337 has been marked as a duplicate of this issue. ***
Comment 4 amy2008 2008-12-18 01:39:19 UTC
Meiying -> aw,
Font changed not only in Text but also in Callouts, so give you a kindly 
reminder, hope this problem can be solved    :-)

Li Meiying
Comment 5 Armin Le Grand 2008-12-18 12:42:20 UTC
AW: Yes, it can be solved.
I had a long discussion with HDU about font stretching. We have differences on
different systems (esp. WIN32, of course :-)), but the root problem is that SC
creates MapModes (ViewTransformations) with unequal X and Y scaling. This leads
to problems for the font rendering which lo longer safely recognizes that the
fonst shall not be stretched at all. This is recognized in checking that scale X
and Y from the TextTransformation is equal, after multiplying with the
I could simply test without multiplying with the ViewTransformation, but this is
no general solution for primitives. We want to be able to keep linear algebra
here so that we can do matrix multiplications.
Another result of the discussion with HDU is that it might be better to not use
a font width in TextTransformations scale.x but a font scaling. This would work
with matrix multiplications and be more system-independent. I'm thinking about
changing the text primitive to this (so some people on copy here). The base
primitives will freeze one day and will no longer change, so i'm thinking about
that change.
The basic problem should more be fixed by looking why SC (or others) creates
MapModes with unequal scaling and solving that. Maybe even a 'hack' to know in
the renderer that SC is rendering and to ignore unequal scalings in text
primitive rendering maybe a shorthand solution.
Since i have other pending text rendering changes in aw059 (which will be in
DEV300 m38) for a secure fix i'll have to move this one to after aw059
integration anyways. Removing from CWS aw061...
Comment 6 2008-12-18 14:03:34 UTC
While we are on that topic that Calc regularly requests slightly stretched fonts, I"d like to point out that this 
is also the root cause of the problem that text in Calc sometimes looks "aesthetically challenged" (this 
problem is mentioned e.g. in issue 47221): For stretched fonts hinting becomes almost always disabled, 
because the font designers and their tools request it that way.
Comment 7 Armin Le Grand 2008-12-18 14:14:26 UTC
AW: Just for clearance: This poblem is not generally for text in calc, but only
for text in SdrObjects in calc.
Comment 8 amy2008 2009-01-04 08:57:11 UTC
Meiying -> aw, hdu
Thank you for your detailed explaination, learning
Comment 9 Armin Le Grand 2009-01-14 11:51:38 UTC
AW: Adding flag wait for DEV300m29
Comment 10 Armin Le Grand 2009-01-22 13:27:05 UTC
AW: Added to CWS aw063 based on DEV300 m39. Discussions in the meantime lead to
the following picture:
The transformation for the text primitive is seen as 'FontTransformation' and
should be as close to similar systems (e.g. Adobe, etc.) as possible, so it is
correct to use X==Y scaling for non-scaled fonts, with using Y as FontHeight (as
it is now).
This makes it necessary to handle the FontTransformation and ViewTransformation
differently in the renderer. It is possible to detect X==Y using the
FontTransformation separately from the ViewTransformation.
Checking code and doing some tests...
Comment 11 Armin Le Grand 2009-01-26 11:52:14 UTC
AW: Again discussed with HDU and PL. The solution is to use the combination of
view transformation and font transformation, but to handle the font stretching
separately. It is also necessary to explicitely not apply font stretching to
DXArray, but only to the font creation. I also added a percentage check of the
X!=Y compare and a fallback to do no stretching for up to 5% difference, this
consumes most of the in principle unwanted SC font stretchings without visible
Tested and looks good. Doing some more tests...
Comment 12 Armin Le Grand 2009-01-26 11:54:26 UTC
AW: Works as expected, looks good. Checking in. Need to check on linux version
ASAP (when CWS is built).
Comment 13 Armin Le Grand 2009-01-30 11:02:05 UTC
AW->WG: Please verify. Simplest check is a DrawingLayer TextFrame in SC.
Comment 14 wolframgarten 2009-01-30 12:42:29 UTC
Verified in CWS.
Comment 15 kla 2009-02-23 09:51:53 UTC
*** Issue 99482 has been marked as a duplicate of this issue. ***
Comment 16 kla 2009-02-23 09:53:03 UTC
*** Issue 99349 has been marked as a duplicate of this issue. ***
Comment 17 wolframgarten 2009-02-26 09:59:33 UTC
Tested in OOO310_m3. Closed.
Comment 18 IngridvdM 2009-03-05 09:15:13 UTC
*** Issue 99605 has been marked as a duplicate of this issue. ***
Comment 19 IngridvdM 2009-04-24 16:03:14 UTC
*** Issue 99901 has been marked as a duplicate of this issue. ***