Description: While Writer load background image from document, open the Page Style dialog, click Area tab, the image can be seen at the Preview area, but can’t be seen at the Bitmap list, making it impossible to switch back if this image is replaced by other image and before the document is saved. Steps to Reproduce: 1. Open Wood.odt from my attachment 2. Click Format -> Page -> Area Actual Results: The wooden background can be seen at the Preview, but it can’t be seen at the Bitmap list. Expected Results: The wooden background should also available at the Bitmap list. If this image is replaced by another image, the document is saved, and Writer is closed, this image can be dropped from the Bitmap list. Reproducible: Always User Profile Reset: No Additional Info: 版本: 6.3.0.0.beta1 (x64) Build ID: a187af327633f5f00363be5131bd21a13e0f1a7b CPU 线程: 4; 操作系统: Windows 10.0; UI 渲染: 默认; VCL: win; 区域语言: zh-CN (zh_CN); UI 语言: zh-CN Calc: threaded
Created attachment 152249 [details] Sample file
Created attachment 152250 [details] My snapshot This is my snapshot, notice that the Page Style dialog is resized to larger size.
On pc Debian x86-64 with master sources updated today, I could reproduce this. I suppose a good start should be in this file: https://opengrok.libreoffice.org/xref/core/cui/source/tabpages/tpbitmap.cxx
(In reply to Julien Nabet from comment #3) > On pc Debian x86-64 with master sources updated today, I could reproduce > this. > > I suppose a good start should be in this file: > https://opengrok.libreoffice.org/xref/core/cui/source/tabpages/tpbitmap.cxx Let's turn this into an easyhack then...
I am familiar with this problem and I can solve it.
*** Bug 134259 has been marked as a duplicate of this bug. ***
Version: 7.0.0.3 (x64) Build ID: 8061b3e9204bef6b321a21033174034a5e2ea88e CPU threads: 4; OS: Windows 10.0 Build 19041; UI render: Skia/Raster; VCL: win Locale: en-GB (en_GB); UI: en-GB Calc: threaded Bug still present in this version.
Dear duuxixu, This bug has been in ASSIGNED status for more than 3 months without any activity. Resetting it to NEW. Please assign it back to yourself if you're still working on this.
Hello I want to work on this bug. Progress made in solving the bug- In file cui/source/tabpages/tpbitmap.cxx SvxBitmapTabPage::Reset performs the actions when user clicks on the bitmap section in Format->PageStyle->Area tab . IMPL_LINK_NOARG(SvxBitmapTabPage, ModifyBitmapHdl, ValueSet*, void) performs actions when user clicks on the default bitmaps present and add the bitmap into the preview . IMPL_LINK_NOARG(SvxBitmapTabPage, ClickImportHdl, weld::Button&, void) performs actions when user clicks on add/import button and new image is added in the bitmaps. The idea to solve the bug is to get the image from the background and add it into the bitmaps and into the preview which can't be done in the file cui/source/tabpages/tpbitmap.cxx because no idea of how to retrieve the background image. This is the idea i could think of with the pointers(cui/source/tabpages/tpbitmap.cxx) provided in the bug. Correct me if i am wrong at any point and please provide more pointers or some guidance to solve the bug.
Since Tushar Kumar Rai assigned himself recently, let's put it back to ASSIGNED. Tushar: you can discuss with LO Devs on IRC or ask on dev LO forum.
> Tushar: you can discuss with LO Devs on IRC or ask on dev LO forum. Sure. I was busy working on Gsoc proposal and am working on different patch now. Will assign it to myself after finishing.
The page area dialog does not work as the dialog used for shapes, see bug 103916.
Started in 5.3, when the dialog was redone to add new images to the list, and allow naming them. (libreoffice-5.3.0.0.alpha1 in linux-64-releases bibisect repo.) Same happens with e.g. Draw's Page > Page Properties > Background > Image. Still reproduced in recent trunk build: Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: e9a0c97de95688b2f86bbb4dd8c823af5442401c CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded
*** Bug 130543 has been marked as a duplicate of this bug. ***
This is also true for the dropdowns in the Properties (for Draw/Impress) or Page (for Writer) sidebar decks, as mentioned in bug 130543 comment 5.
*** Bug 108905 has been marked as a duplicate of this bug. ***
Setting priority back to "normal": 3 duplicates; functionality seems broken; it affects more than Writer; and more than page background (e.g. paragraph styles too).
WIP fix at https://gerrit.libreoffice.org/c/core/+/176253. The biggest problem is that these auto-added backgrounds should NOT persist beyond the document itself. The big test for this would be to auto-add a background from an imported file, and then (using a textbox) to deliberately add/import a JPG. While that intentionally added JPG should be permanent, the auto-added one should not be permanent. Note that prior to bug 163824, non-editeng backgrounds works "as hoped for" - i.e. they only existed in the current document. So it SHOULD be enough to simply never write these bitmaps to the user profile. I say simply... I wonder if it can be filtered out by URL?
(In reply to Justin L from comment #18) > I wonder if it can be filtered out by URL? No - none of the predefined items have a getOriginURL. At this point I have no idea how this could be possible. The only point that "save" iterates through the individual items is in svx/source/xml/xmlxtexp.cxx where everything is already reduced to a simplistic XNameContainer. This is not an easyHack.