[Libreoffice-bugs] [Bug 141761] New: The Display of FormControls in EditMode or PrintPreview may vanish unexpectedly

[bugzilla-daemon at bugs.documentfoundation.org]

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

            Bug ID: 141761
           Summary: The Display of FormControls in EditMode or
                    PrintPreview may vanish unexpectedly
           Product: LibreOffice
           Version: unspecified
          Hardware: All
                OS: All
            Status: UNCONFIRMED
          Severity: normal
          Priority: medium
         Component: LibreOffice
          Assignee: libreoffice-bugs at lists.freedesktop.org
          Reporter: Armin.Le.Grand at me.com

While fixing another Task I stumbled over a not reliably reproducible, but
possible error: The Display/Paint of FormControls may vanish. This can happen
- when FormControls are in EditMode (else they are Windows)
- in the Preview of the Print-Dialog (Print-Preview maybe ,too)
- when zooming in/out in that mode
Unfortunately I cannot provide the Test-Document, but a simple, self-produced
can be used, New Writer, some tex, add a CheckBox FormControl, go in EditMode,
Zoom in/out. As said interactive reproduction is not guaranteed.

But from the code there is a simple possibility (needs edit/compile, sorry):
- go to Button::ImplDrawRadioCheck in vcl/source/control/button.cxx
- after 'aSize.AdjustWidth( -(rImageSize.Width() + nImageSep) );'
- add code to set aSize.Width() and/or Height to Zero
- e.g.: aSize.setWidth(0)
- copmpile, let run, open testdoc, look at PrintPreview
-> FormControl disappears.

Background:
The code mentioned above in Button::ImplDrawRadioCheck uses

    aSize.AdjustWidth( -(rImageSize.Width() + nImageSep) );

to make the optical relation (historical reasons?) nicer/better_fitting to the
following text. Problem is that this expression *can* by coincidence get zero,
thus creating the case described above. Since

   const tools::Long nImageSep = GetDrawPixel( pDev,
ImplGetImageToTextDistance() );

is calculated using the current Zoom (CalcZoom() called) and thus being
influenced by MapMode &/| DPI of the system.
In my error-case I saw values of 25, 30 for nImageSep, adding to zero with
aSize being 25 before or even to a Width of '-5' with a Size of 30 (strange
itself - negative width ... that's why I added B2DRange/B2Iange based on
min/max so this cannot happen by definition).

I started debugging and this goes down to ReferenceDeviceTextLayout::DrawText
using m_rTargetDevice.PixelToLogic to transform the values. Unfortunately,
OutputDevice::PixelToLogic tests

    if ( !mbMap || rDeviceRect.IsEmpty() )
        return rDeviceRect;

and thus does not transform the Rectangle which compromizes it's position. As
can be seen a Rectangle may be used to transport a Position, so the Position
*should* be transformed...

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20210419/21d5330e/attachment.htm>