Bug 113346

Summary:	Writer image frame object placement
Product:	LibreOffice	Reporter:	Selkie <selkietg>
Component:	Writer	Assignee:	Not Assigned <libreoffice-bugs>
Status:	RESOLVED INSUFFICIENTDATA
Severity:	normal	CC:	telesto, vsfoote
Priority:	medium
Version:	5.4.2.2 release
Hardware:	x86-64 (AMD64)
OS:	All
See Also:	https://bugs.documentfoundation.org/show_bug.cgi?id=47148
Whiteboard:
Crash report or crash signature:		Regression By:
Bug Depends on:
Bug Blocks:	103152
Attachments:	Zip file containing the images used to insert in the test docs

Description Selkie 2017-10-22 13:07:06 UTC

In due course over the next week I'll work on reporting individual bugs for these problems, and try to prepare some files to show them, with steps.

(All references here to an "image" here is to an image with captions, thus to an image+caption in a frame. All images I was working with were intended to occupy most of the page they appeared on.)

Images move dramatically: large distances from where they're anchored, whether you anchor them to a paragraph or to a character.

Images, when they move unexpectedly, can even move before earlier images.

Images, when text is edited, can "vanish".

Image vanishing can be to unspecified parts of the document (disappearing from the frame they're supposed to be within).

Body text can disappear under image frames, regardless of how the image is anchored. The only way to be able to see the text again is to delete the image and then its frame, and re-insert the image. Simply changing the anchor style of the image is not enough to make the text visible again. It's as if the text is wrapped behind the image, despite having wrap turned off.

An image anchored to a paragraph can move large distances from the paragraph it's anchored to, even though wrap is turned off.

Updating a table of cross references to captioned images, all of which are anchored to paragraphs, changes all anchoring to a character instead. Any subsequent attempt to change the anchoring of any image back to a paragraph moves the image quite unpredictably - including, outside its frame. Editing the text near the image will also tend to trigger this effect.

If you add a caption above or below, trying to change this placement later will generally lead to a caption that overlaps underneath the image and is largely (or completely) obscured. The only way to get the caption positioned correctly is to delete the image + frame and reinsert the image and recaption it with the placement desired.

Inserting an image near another image is likely to cause one or all images earlier in the document to move.

I've suffered these problems in LibreOffice and OpenOffice and StarOffice for many years. But it was only this month when I was preparing a document with images for publication that I discovered how buggy the functionality was. Apparently it has been so for a long time, based on my own experience, and blog articles such as http://www.linux-magazine.com/Online/Blogs/Off-the-Beat-Bruce-Byfield-s-Blog/The-mysteries-of-positioning-pictures-in-LibreOffice-OpenOffice

A search in the bug database uncovered few if any of the bugs I experienced (104998 and 108748 seem to be related to PDF creation). 51131 from 2012 seems like it might be related to some of these bugs. 87272 might be related, only in that nothing bizarre that an image in LO does would surprise me: the behaviour is so unpredictable I have no mental model for how images are linked into the text.

Comment 1 V Stuart Foote 2017-10-22 18:10:15 UTC

(In reply to Selkie from comment #0)
> In due course over the next week I'll work on reporting individual bugs for
> these problems, and try to prepare some files to show them, with steps.
> ...

Have at it, but please make each of them concise, each with valid STR and sample documents that reproduces the issue(s). 

Then link them to one of the META issues -- bug 47148, or bug 103152.

Comment 2 Selkie 2017-10-23 16:32:17 UTC

I've spent about 9 hrs on this so far.  I now have 56 document files, producing by step by step adding images and then trying to reproduce the problems, and have been largely successful.

However, each .odt file averages about 3MB, so I certainly can't attach them all here, nor would you want that, even though they make most sense as a collection.  If there's somewhere I could upload a set of files as a 218MB .zip file, let me know.  Otherwise I'll start filing bug reports one by one over the next few weeks I guess, with just one file attached.  Perhaps here it will help if I attach just the set of images I used?  Though that might be too big on its own, at 6MB.  I guess I'll try, and see.

Comment 3 Selkie 2017-10-23 16:35:23 UTC

Created attachment 137242 [details]
Zip file containing the images used to insert in the test docs

$ unzip -l JustImages.zip
Archive:  JustImages.zip
  Length      Date    Time    Name
---------  ---------- -----   ----
   354974  2017-10-23 18:08   images/1-Mermaid-MichaelCoglan-photo-cropped.jpg
   141367  2017-10-23 20:39   images/2-ariel_by_sina_rose-d8we1ma.jpg
  1176063  2017-10-23 18:12   images/3-Dollarphotoclub_36948095-mid-crop.jpg
   810832  2017-10-23 18:15   images/4-Dollarphotoclub_34029590-mid-crop-harsh.jpg
   156523  2017-10-23 18:04   images/Cover-Wikipedia-Image-Peacock_Springs_EntranceX2.jpg
   826886  2017-10-23 17:39   images/Dollarphotoclub_34029590-mid-crop-harsh.jpg
   387303  2017-10-23 17:37   images/Dollarphotoclub_34029590-sml-crop-harsh.jpg
  1231961  2017-10-23 17:41   images/Dollarphotoclub_36948095-mid-crop.jpg
   682478  2017-10-24 00:12   images/LO-fattened-image-displayed-bug.png
   566284  2017-10-24 02:30   images/LO-maybe-spurious-blank-page-displayed-bug.png
   353062  2017-10-23 17:33   images/Mermaid-MichaelCoglan-photo-cropped.jpg
   132045  2017-10-23 17:59   images/Wikipedia-Image-Peacock_Springs_EntranceX2.jpg
    98370  2015-06-23 15:24   images/ariel_by_sina_rose-d8we1ma.jpg
---------                     -------
  6918148                     13 files

Comment 4 QA Administrators 2018-05-02 15:47:18 UTC Comment hidden (obsolete)

Dear Bug Submitter,

This bug has been in NEEDINFO status with no change for at least
6 months. Please provide the requested information as soon as
possible and mark the bug as UNCONFIRMED. Due to regular bug
tracker maintenance, if the bug is still in NEEDINFO status with
no change in 30 days the QA team will close the bug as INSUFFICIENTDATA
due to lack of needed information.

For more information about our NEEDINFO policy please read the
wiki located here:
https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO

If you have already provided the requested information, please
mark the bug as UNCONFIRMED so that the QA team knows that the
bug is ready to be confirmed.
 
Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-NeedInfo-Ping-20180502

Comment 5 QA Administrators 2018-05-30 16:48:20 UTC

Dear Bug Submitter,

Please read this message in its entirety before proceeding.

Your bug report is being closed as INSUFFICIENTDATA due to inactivity and
a lack of information which is needed in order to accurately
reproduce and confirm the problem. We encourage you to retest
your bug against the latest release. If the issue is still
present in the latest stable release, we need the following
information (please ignore any that you've already provided):

a) Provide details of your system including your operating
   system and the latest version of LibreOffice that you have
   confirmed the bug to be present

b) Provide easy to reproduce steps – the simpler the better

c) Provide any test case(s) which will help us confirm the problem

d) Provide screenshots of the problem if you think it might help

e) Read all comments and provide any requested information

Once all of this is done, please set the bug back to UNCONFIRMED
and we will attempt to reproduce the issue. Please do not:

a) respond via email 

b) update the version field in the bug or any of the other details
   on the top section of our bug tracker

Warm Regards,
QA Team

MassPing-NeedInfo-20180530