Description: Table background bitmap replaced when changing the border color Steps to Reproduce: 1. Insert a table 2. Select the table 3. Table - Properties 4. Background Tab -> Bitmap -> Choose: Clouds 5. Press OK 6. Table - Properties 7. Borders tab 8. Change border line color 9. Press OK Actual Results: Painted White Expected Results: Clouds Reproducible: Always User Profile Reset: No Additional Info: Version: 6.2.0.0.alpha1+ Build ID: cb7500ddb8de6c41fca84a0009ffe22240bb1845 CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; TinderBox: Win-x86@42, Branch:master, Time: 2018-10-29_03:24:02 Locale: nl-NL (nl_NL); Calc: CL
Must be a very recent bug, because I can't reproduce with Version: 6.2.0.0.alpha1+ (x64) Build ID: 8274c4c62df5b937b3f0bec9e1eeca85f3b219d4 CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-10-22_01:47:50 Locale: en-US (de_DE); Calc: CL
Bug confirmed. Follow all the steps,it can reproduce. Not just the cloud,you use the other ones will cause the same result. Additional Info: Version: 6.3.0.0.alpha0+ (x64) Build ID: 0f25a3c36f27fd51453b9a9115f236b83c143684 CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-11-27_20:06:55 Locale: zh-TW (zh_TW); UI-Language: en-US
(In reply to Chiang Han from comment #2) > Bug confirmed. > Chiang, if you can confirm a bug, you are also allowed to change teh status to NEW => set to NEW because of comment 2 I also add bibisectRequest, because I couldn't reproduce it in older version of the master (see comment 1)
Reproduced in Version: 6.2.0.0.beta1+ Build ID: ce7bb69f8205bcbe36cba4c53bd110e07ef3e05d CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded
Regression introduced by: https://cgit.freedesktop.org/libreoffice/core/commit/?id=4f6e104499625d69d2b37271d0fee52848c0a6d4 author Jim Raykowski <raykowj@gmail.com> 2018-08-09 20:07:35 -0800 committer Tamás Zolnai <tamas.zolnai@collabora.com> 2018-10-09 11:30:34 +0200 commit 4f6e104499625d69d2b37271d0fee52848c0a6d4 (patch) tree 2d1bb1bade8399f5e285416eca47f81b7c96ad8c parent 383a4f883d4a2932167695c761611b998f773f0e (diff) tdf#111718 Fix interaction between bitmap and pattern settings Bisected with: bibisect-linux64-6.2 Adding Cc: to Jim Raykowski
Hi All, I don't repro with version 6.3.0.0.alpha0+ Linux or Windows.
(In reply to Jim Raykowski from comment #6) > Hi All, > > I don't repro with version 6.3.0.0.alpha0+ > Linux or Windows. Still reproducible in Version: 6.3.0.0.alpha0+ Build ID: 00df4a5ae395607eab1f83aacfc1fb05eb93ecc9 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded
Insert Table dialog uses Default Style by default which is an autoformat style and will produce unexpected behaviour when direct formatting is done. When did Default Style became default in the Insert Table dialog? I used the Insert Table toolbar button which uses no style so I didn't repro at first. Same can be done using Insert Table dialog by selecting None in Styles list box.
Hi Jim, I think the problem is the second time the properties dialog is open, the first bitmap is selected, thus it's applied after closing the dialog... I'm going to attach a screncast
Created attachment 147230 [details] screencast
Unfortunately, AFAIK, this has always been the behavior when using bitmap backgrounds with tables, sections, and table of contents. It has to do with how these backgrounds are stored without any identification. Here is a clip from an .fodt (flat) file showing that no identification is stored for the bitmap, just binary data. <style:style style:name="Table1.C5" style:family="table-cell"> <style:table-cell-properties fo:background-color="transparent" fo:padding="0.0382in" fo:border="none"> <style:background-image> <office:binary-data> binary data is here </office:binary-data> </style:background-image> </style:table-cell-properties> </style:style>
(In reply to Jim Raykowski from comment #8) > Insert Table dialog uses Default Style by default which is an autoformat > style and will produce unexpected behaviour when direct formatting is done. > When did Default Style became default in the Insert Table dialog? > > I used the Insert Table toolbar button which uses no style so I didn't repro > at first. Same can be done using Insert Table dialog by selecting None in > Styles list box. sorry this was for another bug as was comment 6
I think, it is not a problem with storing, but only with the new Area dialog. The dialog lacks a list of "used in document images", or at least should not preselect an image but refer to the currently assigned one. A similar problem exists in bug 107087 and its duplicate 103262. Binary data is only used in flat format, otherwise the pictures are stored in "Pictures" folder. The <style:background-image> is child-child of a style, which has a name, and therefore can always be identified by that name. It is up to the implementation to use this information.
Here is a code pointer to why the bitmap is not re-selected: https://opengrok.libreoffice.org/xref/core/svx/source/unodraw/unobrushitemhelper.cxx#66 There seems not to be a method to retrieve the name of the bitmap from the graphic object so it is always set to empty string.
I think this patch fixes this https://gerrit.libreoffice.org/#/c/66838/
I do not repro the behavior shown in Xisco's screencast using: Version: 6.3.0.0.alpha0+ Build ID: 8dabb2ae2d34f94a50ef5f94bf4bf01b2aca2071 CPU threads: 4; OS: Linux 4.18; UI render: default; VCL: gtk3; Locale: en-US (en_US.UTF-8); UI-Language: en-US Calc: threaded Setting this to Resolved Fixed
Verified in Version: 6.3.0.0.alpha0+ Build ID: ddea172792d13516ff7e0dd43f1f78b74ade8914 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded @jim raykowski, thanks for fixing this issue!!
actually this issue got fixed by https://cgit.freedesktop.org/libreoffice/core/commit/?id=222b5b5b9b0d0419e30961261c63ff8585550b81
(In reply to Xisco Faulí from comment #18) > actually this issue got fixed by > https://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=222b5b5b9b0d0419e30961261c63ff8585550b81 actually it's not... the patch is in LibreOffice 6.2.3 and I can still reproduce this problem on that version... Backporting the commit in comment 15 then -> https://gerrit.libreoffice.org/#/c/71855/
Fix in Version: 6.2.5.0.0+ Build ID: 6c3ceaf3e4d59c658d0f9e4e1b22204be25f74e2 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded after https://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-6-2&id=6c3ceaf3e4d59c658d0f9e4e1b22204be25f74e2