Faulty handle position in shapes imported from MS Office

Mark Hung marklh9 at gmail.com
Wed Apr 10 01:01:22 UTC 2019


Hi Regina,

Regina Henschel <rb.henschel at t-online.de> 於 2019年4月10日 週三 上午2:38寫道:

> Hi Mark,
>
> Mark Hung schrieb am 09-Apr-19 um 11:27:
> > Hi Regina,
> >
> > Regina Henschel <rb.henschel at t-online.de
> > <mailto:rb.henschel at t-online.de>> 於 2019年4月9日 週二 上午7:06寫道:
> >
> >     Hi all,
> >
> >     I'm looking at
> >     https://bugs.documentfoundation.org/show_bug.cgi?id=115813
> >     "Position shifted while moving the handle of OOXML Callout shape".
> >
> >     Unfortunately not only the Callout shape is affected.
> >     There are 106 shapes in MS Office, which have handles. 38 are OK with
> >     the current implementation and 68 have at least one handle, which
> >     reacts
> >     wrongly. These are only those from ooxml, not from binary format.
> >
> >     The calculation is in method
> >     EnhancedCustomShape2d::SetHandleControllerPosition in
> >     svx\source\customshapes\EnhancedCustomShape2d.cxx. The relevant part
> >     starts about #1230
> >
> >
> > It's not clear to me what makes control point of Impress callout shape
> > attach to the pointer,
>
> The definition of the handle position has a direct reference to an
> adjustment value or an indirect reference via a formula and is
> calculated from that. A user handle-drag requires a new adjust value,
> which will then produce a new handle position. If the calculation is
> wrong, then the new position of the handle is not there, where the user
> has released the mouse. Calculating an adjustment value from the
> drag-end position is done in method SetHandleControllerPosition.
>
>   and
> > what are the differences between the Impress one and the PowerPoint one.
>
> The PowerPoint shape uses other formulas, even if you convert from pptx
> to odp. The used formulas are direct translations of the formulas in the
> OOXML spec.
>
> For example (only for the x-coordinate):
> OOXML has
> gdRefX="adj1" and x="xPos" in the handle description
> and the formulas
> xPos: fmla="+- hc dxPos 0"      means: horizontal center + dxPos - 0
> dxPos: fmla="*/ w adj1 100000"  means: width * adj1 / 100000
>
> That is translated by the part Miklos has mentioned and results in these
> formulas, when written as odp:
> handle-position="?f3 ?f5"
> f3:  formula="?f2 +?f0 -0"
> f2:  formula="logwidth/2"
> f0:  formula="logwidth*$0 /100000"
>
> A ? means a reference to a formula.
> A $ means a reference to an adjust value.
>
> Our own callout has
> handle-position ="$0 $1"
> The handle position is directly bind to the adjustment values.
> In that case only scaling is needed.
>
> Thanks for explaining in detail.


> >
> > Have you checked how custom shapes are imported already? > Relevant
> codes are in
> > /oox/source/drawingml/customshapes/customshapeproperties.cxx
>
> Yes, the generated formulas look correct for me.
>
> The problem in the example above is this:
> If you put the formulas together you get
> handlePositionX = logwidth/2 + logwidth * $0 /100000
> Solve the equation for $0. You get
> $0 = (handlePositionX - logwidth/2) * 100000 / logwidth
>
> But current calculation has only * 100000 / logwidth without the
> subtraction.
>
>
I'm thinking if we can use delta(handlePosition) as an estimation of
delta(adjustment),
in case the position is a formula instead of an adjustment. Might be a
naive idea.


> I see no general rule. I think, I need to look at each individual handle
> to get its correct formula.
>
> Kind regards
> Regina
>


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


More information about the LibreOffice mailing list