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
getVclFontFromFontAttributes...

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...

*** Issue 97337 has been marked as a duplicate of this issue. ***

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

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
ViewTransformation.
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...

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.

AW: Just for clearance: This poblem is not generally for text in calc, but only
for text in SdrObjects in calc.

Meiying -> aw, hdu
Thank you for your detailed explaination, learning

AW: Adding flag wait for DEV300m29

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...

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
difference.
Tested and looks good. Doing some more tests...

AW: Works as expected, looks good. Checking in. Need to check on linux version
ASAP (when CWS is built).

AW->WG: Please verify. Simplest check is a DrawingLayer TextFrame in SC.

Verified in CWS.

*** Issue 99482 has been marked as a duplicate of this issue. ***

*** Issue 99349 has been marked as a duplicate of this issue. ***

Tested in OOO310_m3. Closed.

*** Issue 99605 has been marked as a duplicate of this issue. ***

*** Issue 99901 has been marked as a duplicate of this issue. ***