Created attachment 67672 [details]
Let say I have a document "error picture 1 before.odt" with bunch of pictures (I have made "error picture 1 before.pdf" so you can see the same as I for shore). I open it, click on second picture and paste another picture (with keyboard). Than I scroll with mouse down. I get what you can see on "error.jpg" that is attached.
This thing is killing me for years now, and I finally succeed to reproduce it. Please do something about it.
Note: if I go from beginning to the end of the document after opening the document and than replacing picture -> works fine ! But that pass through the document must be with page down or with scroll on the mouse. If it is done with Ctrl+End and Ctrl+Home, the problem persists.
After scroll and before taking the picture, I have saved the "error picture 1 before.odt" as "error picture 2 after.pdf" and "error picture 2 after.odt". Weird, I get different result. With odt, last picture is missing.
Please see the attachments.
Otherwise, libreOffice is the best :)
Created attachment 67673 [details]
starting document in pdf
Created attachment 67674 [details]
Created attachment 67675 [details]
Created attachment 67676 [details]
Any questions, please send me to firstname.lastname@example.org
You'd better wait for someone to reproduce the bug before setting it to NEW.
I couldn't reproduce it with your files, but the bug is very familiar, of course. Other bug reports seem to associate it with the autosave function, however.
Rephrasing the summary to make it more precise. What you say is that newly inserted pictures end up as "read errors" at next file load when they are placed before Writer has completed the processing and layout of the complete document? (This background processing is usually rather slow, you can force it by paging through the complete document, or by forcing a reformat via "File/Page Preview".) Or did I get something wrong?
Adding this bug to the collection of Bug 47148.
newly inserted pictures end up fine, some of the old ends up as as "read errors".
click on first are second picture that appears
paste new picture so that clicked picture is replaced
then scroll the the end of the document
some pictures are "read-error"
I have just reproduced with Version 22.214.171.124 (Build ID: da8c1e6)
I get only the last one as "read-error", but I know that when I open the document it was there. Because if I open and close original document again and scroll to the end, it is there.
(In reply to comment #7)
> newly inserted pictures end up fine, some of the old ends up as as "read
> Open document
> click on first are second picture that appears
> paste new picture so that clicked picture is replaced
> then scroll the the end of the document
> some pictures are "read-error"
> I have just reproduced with Version 126.96.36.199 (Build ID: da8c1e6)
> I get only the last one as "read-error", but I know that when I open the
> document it was there. Because if I open and close original document again
> and scroll to the end, it is there.
click on first are second picture that appears
should spell :
click on first or second picture that appears
Same problem in 188.8.131.52 also.
Created attachment 76644 [details]
demonstration: open document -> replacing picture -> scroll down
demonstration: open document -> select picture -> paste and replace picture (CTRL + V) -> scroll down
I hope above demo will make things more clear.
I have a file with bunch of pictures, when :
opening a file (no scrolling no nothing)
select second picture
replacing with new picture (CTRL + V)
scroll down and second picture is in error
Please provide exact steps (enumerated) where we can reproduce this. Unfortunately as is your steps are not very clear and they are written in a way that is very hard to follow.
What I tried:
1. Download startin document
2. Scroll to last picture
3. Copy last picture with ctrl + c
4. Select below last picture
5. Paste with ctrl + v
I see no problem but I assume I am missing something.
If this is still a problem with version 4 please provide clearer steps and mark the bug as UNCONFIRMED. Thank you!
(In reply to comment #12)
You're steps are fine, just that paste is before scroll(no scrolling before paste, scroll after paste).
1. Download and save startin document
2. open startin document so it is writable
3. select a picture that is visible
4. paste a picture in clip board (such as print screen)
5. scroll down
6. some pictures are missing with "read-error"
If you open document and just scroll down, are pictures are present. Seems to me that something bad happens if you paste before scroll. If you scroll thru the document before paste, everything is fine.
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 INVALID due to lack of needed information.
For more information about our NEEDINFO policy please read the wiki located here:
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!
I _sometimes_ have this too.
And it is congruent with my strong experience in Impress (bug 46447) that carefully loading a full application before reordering, or copy/paste or whatever, makes a really good change to prevent the loss of images.
Which is in line with my limited knowledge of image handling in the code: there are several in-memory copies of the document (possibly for the various views/panels too) that need some synchronising (and prolly much more).
** Please read this message in its entirety before responding **
To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.
There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.
If you have time, please do the following:
Test to see if the bug is still present on a currently supported version of LibreOffice (4.4.1 or later): https://www.libreoffice.org/download/
If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System
Please DO NOT
Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case)
If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3)
2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword
Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa
Thank you for your help!
-- The LibreOffice QA Team This NEW Message was generated on: 2015-07-18
4.4.3 on windows 7 and
4.4.4 on Linux mint
The bug is not present - resolved.