Date: prev next · Thread: first prev next last
2019 Archives by date, by thread · List index


Hi Regina,

Regina Henschel <rb.henschel@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@t-online.de
<mailto:rb.henschel@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

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.