Created attachment 60738 [details]
example showing the problem

@weiz, please have look.

@iha: the error is caused by the value "mfSmallValue" at
basegfx\source\numeric\ftools.cxx.
 
In the example document, when translate the minimum y value
"aMatrix.translate(0.0, -MinY, 0.0);" at
"PlottingPositionHelper::getTransformationScaledLogicToScene()", the "-MinY" is
smaller than the mfSmallValue(1.0E-9), so "-MinY" is treated as Zero.

In the example document, when translate the minimum y value
"aMatrix.translate(0.0, -MinY, 0.0);" at
"PlottingPositionHelper::getTransformationScaledLogicToScene()", the "-MinY" is
smaller than the mfSmallValue(1.0E-9), so "-MinY" is treated as Zero.

If call fTools::setSmallValue to set a small value which is smaller than the
minimum value, the result it correct. But I don't know whether it will cause
other problems. 
Please let me know your suggestions. Thank you!

@aw, within the chart we need more accurate matrix calculations as currently
possible with the default value mfSmallValue. As this is a global static
variable it cannot be changed for chart usage only. Can you suggest what to do
here? Thanks!

AW->IHA: That small value is well balanced to make all kind of linear algebra
stuff work with the double precision values which sadly are not natural
mathematical numbers, but only try to come close to them. All kinds of precision
problems will arise when You change that number, so no, You cannot change it.
All algorithms using the non-ednless double precision values need to be balanced
with a restricting precision value (maybe You will again not believe me here, in
that case look in the net for answers :-).
That small number would even have to be smaller when we would decide to go from
doubles to floats.
The standard convention normally used in basegfx is to have the function call in
a second version where the small number is handed over as last parameter, see
various examples by grepping basegfx. This would mean to add below

		void translate(double fX, double fY);

a second method with

		void translate(double fX, double fY,  const double& rfSmallValue);

and to implement it accordingly by handing over that value to the used
fTools::equalZero tests which have a SmallValue supportig version. When You do
this, please take the time to add all necessary calls to the implementation of
B2DHomMatrix, others may need it in the future, too.

Another possibility is that You have a numerical problem with floating point in
the sense of numerical mathematics: You may use the wrong numerical method. If
that translation is an added translation with thousands of small moves, the
numerical way is not to translate thousands of time by the small value, but to
collect the combined translation locally and to apply a single one. Tis is done
for precision reasons and was stated in the 70's together with IEEE formats (in
fortran77 at that time).

I will add thb to cc, he may have more information on the topic if needed.

AW: Another comment to Your (beloved? :-)) broken and regression flags: That
behaviour has always been in basegfx (since it's been necessary from the start)
and has never been changed, so this cannot have come up from basegfx changes.

@aw, the regression flag is absolutely correct. Load the attached file with
OpenOffice.org 2.2 and double click the chart you can see that it was rendered
correctly. Starting with OOo 2.3 where the chart started to use basegfx matrices
the chart rendering of this file is broken.

@aw, thb, adding an additional parameter to several methods at the matrix
classes seems quite unhandy to me. What an ugly interface to use (and
implement). Wouldn't it make more sense to add the precision limit as a member
to the matrix class?
Furthermore the current precision limit:
double ::basegfx::fTools::mfSmallValue = 0.000000000001;
seems to me to be optimized for graphical display purposes where operations
might mostly happen in orders of magnitude of typical pixel counts or cm. That's
quite ok if one looks at the namspace of this matrix classes.
So maybe the use of the basegfx matrices for more general mathematical
calculations is not the right choice. Can one of you suggest another matrix
class? Or have the basegfx matrix classes the claim to be all purpose matrices?
Thank you for sharing your thoughts on your classes with the users of your classes.

small correction, the current limit is:
double ::basegfx::fTools::mfSmallValue = 0.000000001;

AW: I'm sorry that You think the interface is ugly, thb and i designed it
carefully. Adding the value to each incarnation of a matrix would bloat memory
and solve only for matrices. We offered possibilities to hand over an own small
value where needed, but it's implemented as needed. You are the first who
requests it for matrices.
The current small value has nothing to do with screen pixels or cm at all, but
only with double precision using IEEE 754 (AFAIK, see
http://de.wikipedia.org/wiki/Gleitkommazahl for more infos) where the number is
64bit, divided in exponent (11) and mantisse (52). In that sense, the matrix
class is not designed for graphics, but for common purpose. I see no hindrance
in expanding the interface in the suggested way.

@weiz, please implement this as aw has decided. Thanks!

Nothing substantial to add; only the canonical ptr to
http://www.physics.ohio-state.edu/~dws/grouplinks/floating_point_math.pdf

The problem here is the special case for comparing against zero (which does not
allow for relative precision calculation) - what I don't recall here is what the
checks at translate() were for, @aw, were there cases of catastrophic
cancellation you recall?

Oh, one additional note: if there's a need for a general-purpose matrix class
(that also handles much larger matrices), please use boost's
http://www.boost.org/doc/libs/1_38_0/libs/numeric/ublas/doc/index.htm

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

weiz, as discussed in weekly IRC chat I take this issue back for fixing. Thanks
again for finding the reason of this problem.

Fixed in CWS chart39. I changed the order of translation and scaling operations
accordingly within chart so there is no collision with the current behavior of
the basegfx matrices anymore.

@Sophie, please verify in CWS chart39. Thanks, Ingrid!
Load the attached document and look at the chart. At first you will see how it
looks wrong, because only a replacement image is displayed that was wrongly
created before. Now double click on the chart to trigger a new rendering. The
expected result is that the red background now is within the rectangle defined
by the axis.

Verified in CWS chart39 - Red background is displayed within axis rectangle
after editing. Sophie

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

Verified in DEV300m54 - Closing - Sophie