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
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.
(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
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.
Created attachment 130324 [details] Shows accumulating vertical placement jitter of image objects Shows differential vertical jitter behavior between bordered and non-bordered image objects.
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
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.
(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/
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 ***
(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.
Ok, good to hear you will create a new report. Correcting status as the fix cannot be from bug 98931