Created attachment 134433 [details] Background bitmap Libre Office Writer 5.3.4.2. Win 10. Format/Page/Area/Bitmap/import Adding a bitmap imported from my own files works fine. But when I return to the file to change the Bitmap Style - eg to change the size of the background I am faced with the default LO bitmap (a blue sky bitmap) and I have to go through the whole import process again. The same thing happens when I try to adjust Transparency.
Confirming with: Version: 6.0.0.0.alpha0+ Build ID: cac5c9f6081590b0548d3116bc4cd4a2509ec576 CPU threads: 4; OS: Windows 6.19; UI render: default; TinderBox: Win-x86@42, Branch:master, Time: 2017-07-01_00:41:48 Locale: nl-NL (nl_NL); Calc: CL Steps to reproduce 1. Open attachment 134433 [details] 2. Go to Format/Page/Area/Transparency 3. Press apply 4. Go to Format/Page/Area/Bitmap. Image is replaced by the blue sky bitmap
Moving to NEW as per comment 1
@Bubli, one for you ?
Is this any different than bug#107087 ?
It is different in that it does not involve format - paragraph at all.
It's in essence same problem: the imported image is missing in the Area -> Bitmap dialog after closing Writer. Without bug 107087 comment 8 no change can be made to the background without re-importing the file after re-opening. I would suggest to backport bug 107087 comment 8 to 5.4 and 5.3 branch and mark this one as a dupe of bug 107087
I may not have made myself clear. The problem arises even without closing writer. It arises when you insert a bitmap and then go to Transparency - at which point the bitmap disappears. It does not depend on format paragraph or closing writer, but it may as you say be caused by the same fundamental issue.
(In reply to denis campbell from comment #7) > It arises when you insert a bitmap and then go to Transparency - at which > point the bitmap disappears. Sorry, for the confusion. You're right. It isn't working for LibO5.3.4.2, but it does work in the daily builds (Master). http://cgit.freedesktop.org/libreoffice/core/commit/?id=b96174fac58eff71f0a8d2ad1e99b7776e34c33b
Yes, everything I tested in this area now works fine with Version: 6.1.0.0.alpha0+ (x64) Build ID: c926a1e34672afaa5b7de0e3b08b1537e88fbb6f CPU threads: 4; OS: Windows 6.1; UI render: default; TinderBox: Win-x86_64@42, Branch:master, Time: 2017-12-24_01:10:03 Locale: de-DE (de_DE); Calc: CL
Anything left to do here? Backports anyone?
(In reply to Katarina Behrens (CIB) from comment #10) > Anything left to do here? Backports anyone? Lets dupe this one. It's similar to bug 107087 comment 12 *** This bug has been marked as a duplicate of bug 107087 ***
> Lets dupe this one. It's similar to bug 107087 comment 12 Minus the bugfix creep in bug 107087, which is a duplicate of yet a different bug I can't find atm ;-) QA is hard, let's go shopping But fear not, there's some series of patches by me in gerrit now that fixes many of those bitmap fill issues
A more appropriate duplicate, now that the original is marked as fixed. *** This bug has been marked as a duplicate of bug 125969 ***