Bug 104901 - Image object cumulative placement error affecting display/print & cell anchor behavior with irregular row height (see comment 6)
Summary: Image object cumulative placement error affecting display/print & cell anchor...
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
5.2.3.3 release
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: regression
Depends on:
Blocks: Calc-Images
  Show dependency treegraph
 
Reported: 2016-12-24 05:02 UTC by R. Bingham
Modified: 2018-01-28 13:48 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
Shows accumulating vertical placement jitter of image objects (26.52 KB, application/vnd.oasis.opendocument.spreadsheet)
2016-12-24 05:06 UTC, R. Bingham
Details
Shows accumulating vertical placement jitter of image objects (26.92 KB, application/vnd.oasis.opendocument.spreadsheet)
2017-01-11 18:11 UTC, R. Bingham
Details
2018-01 bug 104901 Object placement jitter re-test (195.90 KB, image/png)
2018-01-25 01:00 UTC, R. Bingham
Details

Note You need to log in before you can comment on or make changes to this bug.
Description R. Bingham 2016-12-24 05:02:56 UTC
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
Comment 1 R. Bingham 2016-12-24 05:06:03 UTC
Created attachment 129913 [details]
Shows accumulating vertical placement jitter of image objects

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.

See rows 3, 100, 200, 300, 400 for accumulating vertical placement jitter of a pasted small image object.
Comment 2 Buovjaga 2016-12-31 18:44:21 UTC
(In reply to R. Bingham from comment #0)
> 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.

I copied the image from E3 and pasted to I3 and then to all the yellow rows to the I column up to row 400.
The jitter is only shown after save & reload.

The good news is that it is fine in 3.6, so can be bibisected.

Arch Linux 64-bit, KDE Plasma 5
Version: 5.4.0.0.alpha0+
Build ID: fc0d4e6bc43d5f982452df07930f5ecf5927ad22
CPU Threads: 8; OS Version: Linux 4.8; UI Render: default; VCL: kde4; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Built on December 31st 2016

Arch Linux 64-bit
Version 3.6.7.2 (Build ID: e183d5b)

Win 10
Version: 5.4.0.0.alpha0+
Build ID: 7ed40deee74a9869b7da073ad473241187420ff8
CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2016-12-30_23:18:54
Locale: fi-FI (fi_FI); Calc: group
Comment 3 R. Bingham 2017-01-01 09:24:56 UTC
In addition to noting the vertical offset jitter in the static display of the pasted image object (cell UL corner to image UL corner) also note #5 in the Actual Results section of the original filing about the momentary dashed outline when an image object is selected. I observed that not only does the static display of an image vertically drift with respect to cells but the momentary outline is not congruent with *either* the selected cell or the image edges - the momentary outline is offset slightly in 2 dimensions.  I mention this as this behavior suggests that yet a different code section mis-computes display coordinates of the momentary outline flash in a different way from the mis-computation of image object UL to cell UL corners.

Then, "The jitter is only shown after save & reload." Probably, but I encountered *dynamic* drift within the same session after a print operation or an Export to PDF operation.  That is, I would manually fiddle image object vertical placement based on correcting a prior Export to PDF output, run a new Export, then find my manual placements negated with more drift, with the amount of drift roughly proportional to row number.  Almost like cumulative error in floating point arithmetic where integer counting of pixel quanta should be used and fractions should be done with rational numbers.  This means manual correction of image placement is not a viable workaround because it is not sticky across print-like operations.
Comment 4 R. Bingham 2017-01-11 18:11:14 UTC
Created attachment 130324 [details]
Shows accumulating vertical placement jitter of image objects

Shows differential vertical jitter behavior between bordered and non-bordered image objects.
Comment 5 Cor Nouws 2018-01-24 08:39:26 UTC
Looking at https://bugs.documentfoundation.org/show_bug.cgi?id=98931#c26 I have the idea that this might well be fixed. Can you please test, and mark this one as duplicate if it's OK in master now? Thanks - Cor
Comment 6 R. Bingham 2018-01-25 01:00:16 UTC
Created attachment 139351 [details]
2018-01 bug 104901 Object placement jitter re-test

Re-test with:
Version: 5.4.4.2 (x64)
Build ID: 2524958677847fb3bb44820e40380acbe820f960
CPU threads: 8; OS: Windows 6.19; UI render: default; 
Locale: en-US (en_US); Calc: group
Windows 10 x64 v1709

PNG attachment combining two screenshots shows that:

A) In spreadsheet edit mode view (top of PNG) object vertical display placement jitter appears corrected up through at least row 400. This was the original complaint.

B) Print preview view (bottom of PNG) of row 400 continues to show vertical mis-placement. Same result for multiple "printers" (LO Export to PDF, Print to PDF, Print to XPS, print to paper). This was *not* part of the original complaint as there was little apparent distinction at the time.

Actual LO Export To PDF and various print to PDF output documents show substantially the mis-placement the LO Print Preview shows for row 400.

So, progress has been achieved but in the course of that a new facet has become distinct. I don't know enough of DF bug protocol to say if bug 104901 should be continued or if bug 104901 should be closed and a new one for object mis-placement in Print Preview and Export to PDF should be opened.
Comment 7 Buovjaga 2018-01-25 06:51:35 UTC
(In reply to R. Bingham from comment #6)
> Created attachment 139351 [details]
> 2018-01 bug 104901 Object placement jitter re-test
> 
> Re-test with:
> Version: 5.4.4.2 (x64)
> Build ID: 2524958677847fb3bb44820e40380acbe820f960
> CPU threads: 8; OS: Windows 6.19; UI render: default; 
> Locale: en-US (en_US); Calc: group
> Windows 10 x64 v1709

It is interesting that it is better in 5.4.4. However, the enhancement of bug 98931 is only in master for now, so you should install a daily build to test it: http://dev-builds.libreoffice.org/daily/master/Win-x86_64@42/current/
Comment 8 Xisco Faulí 2018-01-25 12:08:20 UTC
Closing as dupe of 98931.
R. Bingham, please, try on a master build as Buovjaga said.

*** This bug has been marked as a duplicate of bug 98931 ***
Comment 9 R. Bingham 2018-01-27 15:52:03 UTC
(In reply to Xisco Faulí from comment #8)
> Closing as dupe of 98931.
> R. Bingham, please, try on a master build as Buovjaga said.
> 
> *** This bug has been marked as a duplicate of bug 98931 ***

Re-test with:
Version: 6.1.0.0.alpha0+ (x64)
Build ID: 8a73799d12f0d2dc04890b96bd0adf0ffcf50d17
CPU threads: 8; OS: Windows 10.0; UI render: GL; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2018-01-25_23:42:12
Locale: en-US (en_US); Calc: CL
Windows 10 x64 v1709

Same result as previously reported for re-test with 5.4.4.2 (x64) and shown in https://bug-attachments.documentfoundation.org/attachment.cgi?id=139351, to wit:

Placement of graphic objects in standard edit view of a spreadsheet appears fixed within the limited context (row 400) of my previously submitted test .ods. Placement in Print Preview and PDF output remains broken as shown in previously submitted screenshots https://bug-attachments.documentfoundation.org/attachment.cgi?id=139351

I will open a new bug week of 29 Jan for Print Preview and PDF output placement since edit display object placement now seems fixed but also conflated with Print Preview object placement in this bug 104901 marked RESOLVED/DUPLICATE.
Comment 10 Buovjaga 2018-01-27 18:52:33 UTC
Ok, good to hear you will create a new report. Correcting status as the fix cannot be from bug 98931