Faulty handle position in shapes imported from MS Office

Regina Henschel rb.henschel at t-online.de
Thu Apr 11 10:54:43 UTC 2019

Miklos Vajna schrieb am 11-Apr-19 um 09:59:
> Hi Regina,
> I might be wrong, but I would expect that the evaluation of the formulas
> don't depend on the shape type. If it does, it feels we don't understand
> the general rule, so we work the problem around with evaluating a
> formula in different ways for different shape types.

Evaluating the formulas _is_ independent from shape type. But for 
getting the adjustment value, you need to revers the calculation.
Shortened example for evaluating the formula:
To get the y position of the handle:
wedgeRectCallout: y = vertical center + adjust * height / 100000
star4 : y = vertical center - adjust * height / 100000
diagStripe : y = height * adjust / 100000

Currently we have only "adjust = y * 100000 / height" to get the 
adjustment value from the position. That fits to the diagStripe but not 
to wedgeRectCallout and star4.

The problem with the ooxml-shapes is, that they bind the handle position 
to a formula result and not directly to the adjustment value.

>> Would that be OK? If yes, which are suitable C++ tools to do that and where
>> should the parts be placed?
> Sure, if special-casing on the shape type improves the situation, then
> it's better than nothing.

I would like a generic solution too, but I see no way to do it.

  I would keep it simple: just create an enum
> with the different cases, and then you can have a switch to handle each.
> If the function gets large, extract the handling of complicated cases to
> their own functions.

I think I'll just start and work out a concrete proposal. Then it might 
be easier to discuss possible better solutions.

Kind regards

More information about the LibreOffice mailing list