[Libreoffice-ux-advise] [Bug 128063] Frame resizing: Moving the top border of a frame to resize it actually resizes it moving the bottom border up.

https://bugs.documentfoundation.org/show_bug.cgi?id=128063

V Stuart Foote <vstuart.foote@utsa.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |needsUXEval
            Version|6.2.7.1 release             |Inherited From OOo
                 CC|                            |libreoffice-ux-advise@lists
                   |                            |.freedesktop.org,
                   |                            |rb.henschel@t-online.de,
                   |                            |vstuart.foote@utsa.edu
           Severity|normal                      |enhancement

--- Comment #1 from V Stuart Foote <vstuart.foote@utsa.edu> ---
IHMO => NAB

Confirmed on Windows 10 Ent 64-bit en-US with recent master
Version: 6.4.0.0.alpha0+ (x86)
Build ID: 489eef894e7034873ad262f9dfca554022db1b09
CPU threads: 8; OS: Windows 10.0; UI render: GL; VCL: win; 
TinderBox: Win-x86@42, Branch:master, Time: 2019-10-01_23:43:38
Locale: en-US (en_US); UI-Language: en-US
Calc: CL

It is not limited to anchoring 'as character'; same behavior with default
anchor for frame 'as paragraph' or the other 'to character', 'to page' anchors
behave the same.

Resizing the frame--either with the Frame... dialog's 'Height' spinner, or
using its "grips" to drag--will reduce its size from the bottom up, likewise
enlarging with grips will add space to the bottom.  

So seems size is always relative to top left corner. 

But, a potential enhancement? Should the frame resize have an variable anchor
point like rotate has a pivot? But strictly internal, ODF should not be an
issue--the resize would be complete before writing out the document.

-- 
You are receiving this mail because:
You are on the CC list for the bug.