https://bugs.documentfoundation.org/show_bug.cgi?id=104901
Bug ID: 104901
Summary: Image object cumulative placement error affecting
display/print & cell anchor behavior with irregular
row height
Product: LibreOffice
Version: 5.2.3.3 release
Hardware: x86-64 (AMD64)
OS: Windows (All)
Status: UNCONFIRMED
Severity: normal
Priority: medium
Component: Calc
Assignee: libreoffice-bugs@lists.freedesktop.org
Reporter: rdbing...@verizon.net
Description:
Usage context: Tabular accumulation of text data in rows including a thumbnail
image associated with each row. Each thumbnail is variable size but all have a
relatively small pixel count (no large images drag re-sized, largest about
144x192) inserted in a constant column by cell selection then paste. Object
anchor property set to Cell Anchor. Image object height and row height are
manually re-sized to give image object fully contained within row height. Row
height manually adjusted to the greater of that to accommodate text or
thumbnail image. Result is row heights are irregular (this could be
important).
LO Help About output:
Version: 5.2.3.3 (x64)
Build ID: d54a8868f08a7b39642414cf2c8ef2f228f780cf
CPU Threads: 8; OS Version: Windows 6.19; UI Render: default;
Locale: en-US (en_US); Calc: group
Steps to Reproduce:
1) The grid in the sample .ods was constructed by save-as of the live data .ods
then a global Delete of all cell content and formatting performed, leaving the
irregular grid. In the result there are rows that are inexplicably small in
height compared to the original but I left them as is.
2) Via C/P, paste a thumbnail size image object in a low-numbered row. If not
already, select the image and set Anchor property to Cell Anchor. Note if the
anchor is in the originally selected cell. If not, this fails expectations.
3) Repeat the paste every 100 rows and note any vertical offset jitter of the
image UL corner to the selected cell UL corner. If not congruent fails
expectations.
Counter example of a .ods scratch created with identical row height, even if
row height uniformly changed to a non-default value, does *not* show vertical
placement jitter.
Actual Results:
Symptoms (see Expected for contrast):
1) If the pasted image is a copy of another image in the same Calc doc with
source image set for Cell Anchor, then the pasted object anchor may be assigned
to other than the selected cell (to one nearby).
2) The pasted image upper left corner is vertically offset from the selected
cell upper left corner by an amount that can be best described as cumulative
jitter. In submitted sample .ods, an LO logo thumbnail was used and pasted in
column E at rows 3, 100, 200, 300 and 400 (rows marked in yellow for fast
locate). The row 3 paste almost behaved as expected (anchor is displaced). By
row 100 there is a slight downward offset. By row 200 there is almost a 1/2
row height downward offset. At row 300 the downward offset is reduced but
noticeable. At row 400 there is now an upward offset protruding well in to row
399.
3) The source object had cell anchor set to Cell Anchor. In none of the above
cases was the pasted object's anchor assigned to the selected cell.
4) The wandering offset shows in printed and Export to PDF output files and
accumulates vertically to the point where it cannot be corrected by manual
positioning fiddles in the WYSIWYG UI because LO object anchors have no locking
property and the anchor jumps to a different cell, that is, the user exhausts
the available vertical adjustment budget before the print/export output is
acceptable.
5) When an image object is selected or re-selected if already selected, there
is a momentary dashed-line outline displayed. This *also* accumulates an
offset jitter with increasing row number. This suggests de-coherence among LO
components as to the location of the image object on the WYSIWYG display pane.
Expected Results:
Expected image object paste behavior:
1) upper left corner of image object will initially align with the upper left
corner of the selected cell
2) if the pasted image was copied from another within the same Calc doc and the
source image had Cell Anchor property set, then the pasted image anchor will
show as anchored to the selected destination cell.
Expected Print or Export to PDF behavior when Format Page set for Print Grid
and Print Objects/Images :
Image object will appear in the printed or PDF export output approximately
WYSIWYG with respect to the surrounding printed grid (allowing for pixel and
aspect ratio jitter) and certainly closely within the expected cell boundaries
printed.
Reproducible: Always
User Profile Reset: No
Additional Info:
Not just a cosmetic problem - the accumulated vertical displacement eventually
results in rows having printed/exported output not acceptable for
organizational use. Manual maintenance of vertical adjustment of dozens to
hundred of rows is economically unacceptable so no workaround there. Where
vertical adjustment to get acceptable print/export output causes the anchor to
jump rows then filter and other spreadsheet functionality is effectively
broken, so no workaround there.
A contributing factor may be fibbing in the representation of display HW DPI by
both the display OEM and the OS (Windows 10 Pro this case). Displays in this
case are Dell model P2414H. Windows says 96x96 DPI. Calibration using GIMP
says 92.7x93.3 DPI, so if an LO component is counting pixels not using a
graphically local origin such as the anchor cell UL corner for an object (such
as with Page Anchor) the difference will accumulate. I suggest LO in
self-defense should include a display calibration tool.
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:50.0) Gecko/20100101
Firefox/50.0
--
You are receiving this mail because:
You are the assignee for the bug._______________________________________________
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
