Faulty handle position in shapes imported from MS Office

[Mark Hung]

Regina Henschel <rb.henschel at t-online.de> 於 2019年4月11日 週四 下午6:55寫道：

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

The equation should hold: (adj1-adj0) = (y1-y0) * 100000 / height.
I think this should cover lots of cases already.


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

I think the patterns of the formula is much less than the number of types.
Maybe worthy of identify them?

> 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 at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/libreoffice



-- 
Mark Hung
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice/attachments/20190411/bf8491d7/attachment.html>