Re: Problems with SetSnapRect() for rotated and/or sheared custom shapes

Hi Miklos,

Miklos Vajna schrieb am 05-Nov-19 um 08:50:
> Hi Regina,
>
> On Mon, Nov 04, 2019 at 07:00:18PM +0100, Regina Henschel <rb.henschel@t-online.de> wrote:
> > So my question is:
> > What is SdrObjCustomShape::SetSnapRect() supposed to do?
>
> My guess is the snap rectangle is the same as the bounding box,

The "bounding box" (BoundRect in API, member aOutRect in SdrObject in 
core) is the actual rect needed to surround the visual parts of the 
shape. It includes the line width or considers the rounding in shape 
"rounded rectangle", for example. Or if there is no line and no fill, it 
surrounds the text only. Comment in SdrObj:// surrounding rectangle for 
Paint (incl. LineWidth, ...)


 i.e. if
> you have a shape with e.g. 45 deg rotation, the snap rectangle is larger
> than the original size of the rectangle.

The snap rectangle is member maSnapRect, which is introduced in 
SdrAttrObj in the hierarchy. And from SdrTextObj::RecalcSnapRect() it is 
clear, that it is the surrounding rectangle of the rotated and sheared 
logical rectangle. It is FrameRect in API. The logical rectangle is the 
member maRect in SdrTextObj and member aRect in SdrTextObjGeoData in core.

> > A different approach would be, to keep the current version of
> > SdrObjCustomShape::SetSnapRect() and change the found combinations so, that
> > in case of a SdrObjCustomShape, not GetSnapRect() but GetLogicRect() is
> > used.

I have seen in the meantime, that ScDrawView::FitToCellSize() will need 
to calculate the logical rectangle from the given rectangle in any case, 
because the cell rectangle is the desired snap rectangle.

And I have found a comment in SdrObj
/// SetSnapRect() tries to size the Object so that it fits into the
/// passed Rect (without stroke width, ...)

The longer I think about it, the more I get convinced that I really have 
to change SdrObjCustomShape::SetSnapRect() so that the input parameter 
is used as snap rectangle. This means that some math is required in case 
of rotation and shear.

> Do we know what "logic" means in GetLogicRect()? Is that "logic" because
> it's in mm100/twips, not pixels or something else?

I don't know why it is named "logic". But I think, the intention was 
indeed, to make clear, that it is device independent.

Kind regards
Regina