Re: Faulty handle position in shapes imported from MS Office

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
Regina

_______________________________________________
LibreOffice mailing list
LibreOffice@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/libreoffice




[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux