<html>
<head>
<base href="https://bugs.documentfoundation.org/">
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_UNCONFIRMED "
title="UNCONFIRMED - The Display of FormControls in EditMode or PrintPreview may vanish unexpectedly"
href="https://bugs.documentfoundation.org/show_bug.cgi?id=141761">141761</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>The Display of FormControls in EditMode or PrintPreview may vanish unexpectedly
</td>
</tr>
<tr>
<th>Product</th>
<td>LibreOffice
</td>
</tr>
<tr>
<th>Version</th>
<td>unspecified
</td>
</tr>
<tr>
<th>Hardware</th>
<td>All
</td>
</tr>
<tr>
<th>OS</th>
<td>All
</td>
</tr>
<tr>
<th>Status</th>
<td>UNCONFIRMED
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>medium
</td>
</tr>
<tr>
<th>Component</th>
<td>LibreOffice
</td>
</tr>
<tr>
<th>Assignee</th>
<td>libreoffice-bugs@lists.freedesktop.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>Armin.Le.Grand@me.com
</td>
</tr></table>
<p>
<div>
<pre>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...</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>