Often, the arrangement--i.e. layering--of graphics is not stored (correctly) in an open office writer file. This may also affect Impress files, but I notice it more in writer. I have experienced this many times over the years. I have several plots in a document and with each one I often put a 1/4 size histogram, for example, of the same plot and place it above the plot overlaping the one corner. No matter how I set the layering arrangement, *some*, but not all, of the plots show above the smaller histogram when I open the file at a later time. This happens repeatedly. Every time I print the document (to PDF, usually) I notice the error, and I have to check every graphic, reset the arragnement, and re-print. When I save and close the document and open it again, the arragement is wrong and must be manually fixed again.
Can you attach a test document?
Apparently not. I've tried several times and cannot get an example document less than 3MB, so I cannot attach it. I've posted the document here: http://neutrino.phys.washington.edu/~pdestefa/tmp/example.odt
You need to allow public reading of the file, I get "permission denied" trying to access it.
Oops, sorry, I always forget. Try again.
Can you attach a screenshot of how the arrangement should look like on a certain page and then a 1-page pdf of the page with the wrong arrangement (1-page so the filesize stays small)? In your .odt file you have images linked to your local drive: figures 11, 12, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36. This makes it somewhat hard to discern any problem with the arrangement.
Created attachment 107042 [details] Screen shot of correctly arranged plots on p. 25
Created attachment 107043 [details] PDF export of p. 25, as show, immediately after setting arragement
Created attachment 107044 [details] PDF export of p. 25 after two reloads of test document
Created attachment 107046 [details] PDF export of pg 25-31 after reloads This is a PDF export of several pages of plots that were affected by this problem. All of the plots had the intended arrangement set before saving of the file, but after reload, the arrangements were not as when the doc was saved. You can see that the histogram-like plots, the smaller plots, that were on-top of the larger plots now show below the plots. I'm including this, also, so you can see that the problem does not occur on all plots, only some of them. This problem is visible in WISIWYG after reload, and before export to PDF; it *does not* just show up in the PDF exports even though it looks right in WISIWYG. However, I notice that exporting to PDF *before* reloading, will increase the likelihood of the problem occurring after reload--that is, if I just set the arrangement, save, quit, and reload, the problem is unlikely to show up in the WISIWYG. But, if I export it looking right, then the problem is more likely to occur the *next* time I open the document. I hope that is clear; it may be key to reproducing.
Created attachment 107112 [details] Simpler test case document I created a simpler test case. Saved with Version: 4.4.0.0.alpha0+ Build ID: 0a32edcdc2bda75a7536ce7f88c91cbc56e7afb1 TinderBox: Win-x86@39, Branch:master, Time: 2014-09-24_00:45:04 I substituted the empty (linked) images with solid color ones to help clarify the situation. I noticed the upper green rectangle went under the red one, when I did the initial deconstruction, but after I did right-click, Arrange - Bring to front, I didn't manage to make it go under the red one again. I tried printing to PDF and exporting to PDF, but nothing would make it go under. Can you try to reproduce with my test case or try and create a better test case? Also, what is the LO version you are using?
LibreOffice 4.2.6.3 420(Build:3)
> Can you try to reproduce with my test case or try and create a better test > case? I'll try. What do you mean by 'better'? Did you try with my big document? See the new files I uploaded. http://neutrino.phys.washington.edu/~pdestefa/tmp/ arrangementTest2.odt is the big document, but without the version history, so much smaller than the original. I also changed all the links to not links, so now you can get the graphics. .good.pdf PDF show how it looks immediately after setting the arragement correctly and the .bad.pdf shows what it looks like after problem recurrs. Here's how I reproduced the problem. I *again* set all the arragements (pg 25-31) correctly, export to PDF, reload, export to PDF, reload, reload, restart LO, load file, *changed the title*, save, reload --> problem recurred. Now, I tried to get you a PDF of the problem from a file with the arragement set correctly, but exporting to PDF saves the document, so I can't do both. If you want, I can redo it all and get you a screenshot of the wrong arragement showing in WYSIWYG even though the file was last saved with the correct arragement showing. But, I'm not sure if that will really help. I think I've explained it pretty well, but if not just let me know. Also, as you have seen for yourself, it doesn't seem to be reproducible with small documents. I have no doubt this related large documents. > Also, what is the LO version you are using? see previous comment 11
(In reply to comment #12) > > Can you try to reproduce with my test case or try and create a better test > > case? > > I'll try. What do you mean by 'better'? Did you try with my big document? > In comment 5 I said: "In your .odt file you have images linked to your local drive: figures 11, 12, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36. This makes it somewhat hard to discern any problem with the arrangement." I'd like you to change it so the pictures are embedded. Otherwise I'm just seeing rectangles overlapping and can't tell which is on top. > > See the new files I uploaded. > > http://neutrino.phys.washington.edu/~pdestefa/tmp/ Please set permissions :) I'm just a user like you, but hopefully someone from the quality assurance team can step in after we have solid evindence of a problem!
(In reply to comment #13) > I'd like you to change it so the pictures are embedded. Otherwise I'm just > seeing rectangles overlapping and can't tell which is on top. Ah right, sorry. Then the new files are just what you are looking for. > > See the new files I uploaded. > > > > http://neutrino.phys.washington.edu/~pdestefa/tmp/ > > Please set permissions :) Dang it; every time! So sorry.
(In reply to PMouse from comment #14) > (In reply to comment #13) > > I'd like you to change it so the pictures are embedded. Otherwise I'm just > > seeing rectangles overlapping and can't tell which is on top. > > Ah right, sorry. Then the new files are just what you are looking for. > arrangementTest2.odt still has the pictures linked and not embedded.
Good lord. Is there an easy way to change links to embedded? If I have to go through the menus it will take me a while.
(In reply to PMouse from comment #16) > Good lord. Is there an easy way to change links to embedded? If I have to > go through the menus it will take me a while. I think it would be enough to change them for only one page where you can reproduce the bug. Just remove the old images and insert them again. If you use the development builds of 4.4, you can also right click - change image, which is cool. You can install a dev build alongside your normal LO: http://www.libreoffice.org/download/pre-releases/
Apparently, again, I cannot do that. I tried changing all four of the graphics on p 26 from links to embedded, and it recurred on nearly all the other linked graphics, but not the two embedded ones. Also, the grahics cannot be changed in my version. I had to completely delete the linked images, then insert replacement embedded images, which had to be, resized and re-arranged. So, if it is not link-specific but happends on embedded graphics, also--which seems likelyt to me because I only just found out how to do links and I remember this happening before that, I think--then you will have to wait a while until I have time to recreate the 5 other pages of graphics. But, it is possible this is a link-specific issue. If that is the case, I cannot think of a way create a document for you with the behavior. I could send you the graphics, but you will have set the links yourself as I'm fairly certain they must be full path links.
To change images from linked to embedded, use Edit - Links and Break Link: https://help.libreoffice.org/Common/Edit_Links#Break_Link
PMouse, After you've done a Edit -> Links -> Break Link, please upload it to a cloud storage locker like Google Drive or Dropbox. Thanks!
Okay, I have a new test document. I broke all the links, saved, then changed the title, saved, and, when I reloaded the document, the arragements were changed on the last 8 pages. http://neutrino.phys.washington.edu/~pdestefa/tmp/arrangementTest2.v5.odt
(In reply to PMouse from comment #21) > Okay, I have a new test document. I broke all the links, saved, then > changed the title, saved, and, when I reloaded the document, the arragements > were changed on the last 8 pages. > > http://neutrino.phys.washington.edu/~pdestefa/tmp/arrangementTest2.v5.odt Thank you! Now I could confirm: I opened the document, went to the last 8 pages, right clicked the chart images that were behind the larger plots and selected Arrange - Bring to front. Then I saved with a different name. PDF export went OK, but after I reopened the file, most of the small charts had again plopped under the large images. Win 7 64-bit Version: 4.4.0.0.alpha1+ Build ID: 4586a3f564600f1a0ce15a5cb98868b43bb9351e TinderBox: Win-x86@42, Branch:master, Time: 2014-10-29_07:28:16
Opening arrangementTest2.v5.odt doesn't have the problem on Ubuntu 14.10 64-bit LibreOffice 3.5.0rc3 Build ID: 7e68ba2-a744ebf-1f241b7-c506db1-7d53735 LibO 4.5 on Ubuntu has the problem. So this looks like a regression. On LibO 3.5 the small plots in the last pages are not below the bigger ones on opening.
bibisect result: 99f63b2b53c0e22baac045d54f502508d7150fef is the first bad commit commit 99f63b2b53c0e22baac045d54f502508d7150fef Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com> Date: Tue Dec 11 05:45:37 2012 +0000 source-hash-d38a2e3ea04d354492df18aa16d2304babe87dfb commit d38a2e3ea04d354492df18aa16d2304babe87dfb Author: Andras Timar <atimar@suse.com> AuthorDate: Thu Nov 22 07:01:11 2012 +0100 Commit: Gerrit Code Review <gerrit@vm2.documentfoundation.org> CommitDate: Thu Nov 22 06:00:42 2012 +0000 Updated core Project: help 53421e107f2e8c933e463e03a6bb7a0178b3ff85 move Presenter Console help to main help :100644 100644 03a040999f63a580a1509f0d908fa9a9f149fad1 c3c6030ca2524901562ab3929e935673afc71830 M autogen.log :100644 100644 760e368a7df5a07687a83c81a51e73bb80c62ceb 2c2bed043e9f7db2c6b83b8d335720cab50ca674 M ccache.log :100644 100644 88657431c9c9c0aa14b8c93c720e3c6b5222d64a c1da9e4ff9610086cab73a134a1120fddb0ee4a6 M commitmsg :100644 100644 793e45124d193a35b8925402bda4e8f14e9dba8c cda5ea59bdebfe2bfe39e2dfd18922c94824e38f M dev-install.log :100644 100644 54ed0708af49cfca9bbbe4c60484adbb1f3628f1 0a121b8ec2c59d8c7b1a2c51f2c643b288216d9d M make.log :040000 040000 8e2ebefc6e5ba8a91bf16e7cdef72824536b4fb0 d06b2228c45cf5234fd35d57f9e696bd6706b396 M opt ------ $ git bisect log # bad: [423a84c4f7068853974887d98442bc2a2d0cc91b] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e # good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932 git bisect start 'latest' 'oldest' # bad: [e02439a3d6297a1f5334fa558ddec5ef4212c574] source-hash-6b8393474974d2af7a2cb3c47b3d5c081b550bdb git bisect bad e02439a3d6297a1f5334fa558ddec5ef4212c574 # skip: [8f4aeaad2f65d656328a451154142bb82efa4327] source-hash-1885266f274575327cdeee9852945a3e91f32f15 git bisect skip 8f4aeaad2f65d656328a451154142bb82efa4327 # skip: [866567b8f6f645b3fd67aff5e493460c63c5bfa4] source-hash-62f5fc1d2f14f8164c3dd6eca5494a8c1b01301b git bisect skip 866567b8f6f645b3fd67aff5e493460c63c5bfa4 # good: [4d807eab897e451d5ab8352cdd952823281bcb7b] source-hash-05a0b08606ac77cf7d3e294998138610b53b1b6d git bisect good 4d807eab897e451d5ab8352cdd952823281bcb7b # good: [2e2d1aeff80dcbe390f6c3fbc54d6c8de81b0a0e] source-hash-64ab96cd15e52da88781e720d6f031dbcd0ba902 git bisect good 2e2d1aeff80dcbe390f6c3fbc54d6c8de81b0a0e # bad: [ec6ba885d9d4142060cebdef210d26f0b2ef5045] source-hash-1ce6d6d4133865d9616e12228be2c04cbba1976c git bisect bad ec6ba885d9d4142060cebdef210d26f0b2ef5045 # bad: [366ddd523d5f458b9d5c357934a8fa931e9f2d62] source-hash-32ca77577f781010aa4549016adaebff1a5a3624 git bisect bad 366ddd523d5f458b9d5c357934a8fa931e9f2d62 # good: [221bf5c0db153e24c67ff29fe614af7cc010a356] source-hash-9210b95bcfd65ae558f445666d9b880e794d4c74 git bisect good 221bf5c0db153e24c67ff29fe614af7cc010a356 # bad: [3d8d766f50d0fd4ead4d4f7074a35bba465b365c] source-hash-b67a51b40a4876f4bd97a2917103112006710b0c git bisect bad 3d8d766f50d0fd4ead4d4f7074a35bba465b365c # bad: [5809284e8a6f97fe3b5beb037b6b80eeb9fe1058] source-hash-246ffb108c7e1f762f8d497750ad2414b85b99ef git bisect bad 5809284e8a6f97fe3b5beb037b6b80eeb9fe1058 # good: [1f14665c5624bc7a502738aa8f4f2bd70a211e72] source-hash-d85fd8a85501547d5bb87822d2589a07aed7f2d6 git bisect good 1f14665c5624bc7a502738aa8f4f2bd70a211e72 # bad: [99f63b2b53c0e22baac045d54f502508d7150fef] source-hash-d38a2e3ea04d354492df18aa16d2304babe87dfb git bisect bad 99f63b2b53c0e22baac045d54f502508d7150fef # first bad commit: [99f63b2b53c0e22baac045d54f502508d7150fef] source-hash-d38a2e3ea04d354492df18aa16d2304babe87dfb Please note also: Up to (including) 366ddd523d5f458b9d5c357934a8fa931e9f2d62 in the bibisected versions (s. bisect log below), the following was also true: * For all commits marked with "bisect good", all of the small charts were on top of the large images when opening the original file ("arrangementTest2.v5.odt") for the first time. * For all commits marked with "bisect bad", some of the small charts were already below the large images when opening the original file ("arrangementTest2.v5.odt") for the first time. This is no longer true from 221bf5c0db153e24c67ff29fe614af7cc010a356 on. When opening the original file for the first time, some of the small charts are below the large images. However, after doing "Arrange - Bring to front", saving the file under a different name and opening again, the charts are still all on top of the large images. This is the correct behaviour as described by the "specification" in comment 22, so I marked it as "good". Should you want to bibisect the behaviour "Some of the small images are below the big ones when opening the file for the first time" (if this is a bug), then you would have to start bibisecting anew at this point.
(In reply to Michael Weghorn from comment #24) Thanks for all the hard work. I tried to use the commit hashes you marked to figure out which version of LibreOffice still contain this bug, but I guess I don't understand cgit interface very well. Can you tell me if the bug exists in v4.4? 4.4 is available in Fedora 22 and I plan to upgrade, but for now, I have to manually reset all the plots in this document every time I need to make a change.
(In reply to PMouse from comment #25) > (In reply to Michael Weghorn from comment #24) > Thanks for all the hard work. I tried to use the commit hashes you marked > to figure out which version of LibreOffice still contain this bug, but I > guess I don't understand cgit interface very well. Can you tell me if the > bug exists in v4.4? 4.4 is available in Fedora 22 and I plan to upgrade, > but for now, I have to manually reset all the plots in this document every > time I need to make a change. Bibisecting was used to find the first build (in the bibisect repository range) where this bug occurs. As this bug has not been marked as fixed yet, probably all subsequent versions of LibreOffice still contain this bug (except somebody has fixed it without actually working on this bug ticket). I just wanted to verify that the problem is present in version 4.4.3 currently provided at https://www.libreoffice.org/download/libreoffice-fresh/. However, the files you uploaded are no longer available, therefore I could not test. Example for the last link: > The requested URL /~pdestefa/tmp/arrangementTest2.v5.odt was not found on this server. I assume that the problem is still present in version 4.4.
(In reply to Michael Weghorn from comment #26) > However, the files you uploaded are no longer available, therefore I could > not test. If you want to check yourself whether the problem is still there: You should probably be able to do so by installing version 4.4 as described here: https://wiki.documentfoundation.org/Installing_in_parallel/Linux
That's okay, I have another system with 4.4 installed, it's just horribly under-powered and will take a long time to WYSIWYG. Well, I can confirm 4.3.7.2, at least. (Version on bug says "earliest" release. Is that right? I shouldn't set it to the newest release that contains the bug?)
(In reply to PMouse from comment #28) > Well, I can confirm 4.3.7.2, at least. (Version on bug says "earliest" > release. Is that right? I shouldn't set it to the newest release that > contains the bug?) As far as I know, it ("earliest") is right and that field is used to keep track of the first version in which the bug occurs. As far as I understand: When the bug is fixed in the recent version(s) of LibreOffice, the bug is closed; therefore it can be assumed that open bugs are present in the newest releases if the comments don't say anything else.
*** Bug 96315 has been marked as a duplicate of this bug. ***
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]
@Beluga, * Not sure that bug 96315 and issue here are the same. Unfortunately documents of OP are no longer available--and your test case attachment 107112 [details] does not seem to reproduce issues any longer at the 5.0.4.2 release. attachment 121114 [details] from bug 96315 has three PNG with alpha channel transparency, and an SVG. All are present within a single writer Frame. As they are arranged to bring forward or backward--on export to ODF that arrangement is being lost in somewhat random fashion. Since issue of OP here seems to be resolved, suggest this could be closed WFM. And reopen bug 96315 but maybe refine the test case there?
(In reply to V Stuart Foote from comment #32) > @Beluga, * > > Not sure that bug 96315 and issue here are the same. Unfortunately documents > of OP are no longer available--and your test case attachment 107112 [details] > [details] does not seem to reproduce issues any longer at the 5.0.4.2 > release. > > attachment 121114 [details] from bug 96315 has three PNG with alpha channel > transparency, and an SVG. All are present within a single writer Frame. As > they are arranged to bring forward or backward--on export to ODF that > arrangement is being lost in somewhat random fashion. > > Since issue of OP here seems to be resolved, suggest this could be closed > WFM. And reopen bug 96315 but maybe refine the test case there? Well I was never able to repro with my test case :) This issue is not WFM. PMouse: our Bugzilla now accepts files up to 10 megabytes. Could you attach your arrangementTest2.v5.odt document? I don't actually remember how big it was, but hoping it was under 10 megs..
As you will remember, graphics in the original file were links. So, it is nearly impossible to share a test case. And if I replace the links with embedded graphics, the file is 30 MB. Also, the problem may be associated with linked graphics, so I'm not sure that will be much help; but, I can post it somewhere else, if you think that will help. I've put conclusive evidence for this bug in this report. It's a matter of locating the bug, now, and someone with knowledge of the relevant code will have to help me generate a test document that I can send you. I've had this problem several times over many years, but only with large documents containing many graphics. I'm not sure constructing a document is the best way to fix this bug. ...Ha! Okay, I have a test file. I was just playing with my old test document and got it to work. Unfortunately, it's the 30MB one. All I did was take the document with proper arrangements, save two embedded images to a directory, then change those two images to links, save the document, reload, reload, export to PDF. Interestingly, it wasn't the two new linked images on page 25 that broke--it was all the other images on the remaining pages. http://neutrino.phys.washington.edu/~pdestefa/tmp/tofHardware.Jan2014Work.twoImageLinks.odt
Created attachment 121691 [details] decoument with overlapping graphics in frame I attached the file from bug 96315, which was marked a duplicate of this bug. It is a very basic document showing this bug.
(In reply to PMouse from comment #34) > http://neutrino.phys.washington.edu/~pdestefa/tmp/tofHardware.Jan2014Work. > twoImageLinks.odt Just a simple Save as: on page 28 the small graph of Figure 30 went under the large plot. So still reproduced. Exporting to PDF made the program hang. Win 7 Pro 64-bit Version: 5.2.0.0.alpha0+ Build ID: b4082bed2de12cd576a06a9f456a71101809f3ed CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2016-01-02_00:47:38 Locale: fi-FI (fi_FI)
After mentioning a same problem on the dev-list i added a document and a image who illustrate the problem and where the z-ordering was lost somewhere in the editing process. The image show the doc before saving Open the doc and compare... When the doc is openeed we see the cover-image and the Logo is not visible Just click somewhere on the main image to selected and arrange the image with "Send to Back" and the Logo will come Visible. Save and reopen.....
Created attachment 121768 [details] writer doc with a destroyed z-ordering
Created attachment 121769 [details] Image off the doc before saving
Fernand, Those images do not help at all. Please either attach a test document or provide a link to download it from dropbox, google drive, etc. That way we can see if it's the same issue or different.
(In reply to Luke from comment #40) > Fernand, > Those images do not help at all. Please either attach a test document or > provide a link to download it from dropbox, google drive, etc. That way we > can see if it's the same issue or different. 1 doc to reopen and see how we lost the layout from before saving 1 image to compare how the doc looks before saving
(In reply to Luke from comment #40) > Fernand, > Those images do not help at all. Please either attach a test document or > provide a link to download it from dropbox, google drive, etc. That way we > can see if it's the same issue or different. i saw you do not opened my first atachement
David, I do not think your issue is the same as this one. This has been bisected to a regression in the 4.2.x line. I can reproduce the issue with your file in both LO 4.1.0.1 and AOO 3.4.1. Fernand, Sorry for the noise/confusion. I see your test case now. I can reproduce it with 5.2 and cannot reproduce it with 4.1. So it is likely a duplicate of this bug.
There are two separate issues here. One is a 4.x regression where Z-order is lost on open. This is what Michael bisected in comment 24. "all of the small charts were on top of the large images when opening the original file ("arrangementTest2.v5.odt")" Unfortunately, I cannot test this myself as all of the links to that file have been removed. PMouse, Could you please put the file up on a more permanent location such as dropbox, google drive, or some other file hosting services? The other issue talked about in this thread appears to be a duplicate of Bug 41006 which goes back all the way to OOo.
(In reply to Luke from comment #44) > PMouse, > Could you please put the file up on a more permanent location such as > dropbox, google drive, or some other file hosting services? See comment 34. I put up a new file in the same location. It's not clear from your comment that you are referring to that new test file or not. If you have a problem with that specific host, please explain and I'll reconsider.
*** Bug 97833 has been marked as a duplicate of this bug. ***
Miklos fixed bug 107392 and it turns out bug 96315 disappeared as well, so I thought to try this old bugbear. Rejoice, for I cannot reproduce the problem with http://neutrino.phys.washington.edu/~pdestefa/tmp/tofHardware.Jan2014Work.twoImageLinks.odt anymore! Fernand's attachment 121768 [details] also works after saving and reloading. It has a different problem (page size somehow messed up and background image gets too small), but that should be reported as a separate issue. The problem on opening mentioned in comment 44 is not seen either (and was not seen at the time of comment 36). Export to PDF does not hang as it did in comment 36. Arch Linux 64-bit, KDE Plasma 5 Version: 5.5.0.0.alpha0+ Build ID: 6dbf9543c6f83d7b1fe7ad27232f65152456619a CPU threads: 8; OS: Linux 4.10; UI render: default; VCL: kde4; Locale: fi-FI (fi_FI.UTF-8); Calc: group Built on May 27th 2017 Version: 5.4.0.0.beta1 (x64) Build ID: 8672113ead4e403c55e31b1d9a3d1e0f3b299577 CPU threads: 4; OS: Windows 6.19; UI render: default; Locale: fi-FI (fi_FI); Calc: group