Created attachment 173702 [details] Comparison MSO 2010 and LibreOffice 7.3 master Steps to reproduce: 1. Open attachment 91424 [details] from bug 73227 -> The smartart is displayed on top of the document. See comparison image Reproduced in Version: 7.3.0.0.alpha0+ / LibreOffice Community Build ID: c6695a4aabeaae99174b7658f2b813788ecff7f0 CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded [Bug found by office-interoperability-tools]
Regression introduced by: https://cgit.freedesktop.org/libreoffice/core/commit/?id=3262fc5ef3bde5b158909d11ccb008161ea95519 author Regina Henschel <rb.henschel@t-online.de> 2021-05-15 23:40:34 +0200 committer Miklos Vajna <vmiklos@collabora.com> 2021-06-28 09:49:00 +0200 commit 3262fc5ef3bde5b158909d11ccb008161ea95519 (patch) tree aa2b4926146eaddaa60878b920da77bd5871f67d parent 2ffdd37067926ddb841c6055205f267b96706945 (diff) tdf#142304 a.o. Improve wrap margins in docx filters Bisected with: bibisect-linux64-7.3 Adding Cc: to Regina Henschel
Same problem reproduced with attachment 111363 [details] from bug 73797. Second image is displayed on page. Maybe it's a different issue ?
and same problem with attachment 129385 [details] from bug 104486. The three shapes in the first page have the same position
(In reply to Xisco Faulí from comment #3) > and same problem with attachment 129385 [details] from bug 104486. The three > shapes in the first page have the same position That is not related to the problem with attachment 91424 [details]. I have written a new bug 143476 for it. (In reply to Xisco Faulí from comment #2) > Same problem reproduced with attachment 111363 [details] from bug 73797. > Second image is displayed on page. Maybe it's a different issue ? That is not related too. I have written a new bug 143475 for it. Attachment 91424 [details] shows a problem with a diagram (SmartArt). It is imported as shape with type OBJ_GRUP. It is formally added as SdrGroupObj, but it has an unsuitable object list, which contains only a default shape at position 0|0 and size 100Hmm x 100Hmm from initialization. The content of the SmartArt is not included in the object list of the group object. The implementation currently does not consider this. There will be (hopefully) a TDF tender about dynamic diagrams, but it is not clear in this moment, whether that will be implemented in version 7.3. https://www.mail-archive.com/board-discuss@documentfoundation.org/msg05049.html I'll try to implement a workaround for 7.3.
@Xisco: Please take a look at the patch to see if this workaround is sufficient. https://gerrit.libreoffice.org/c/core/+/119344
Regina Henschel committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/17cfd3d3e2e6f807eb1faf07436c7e96e15157a7 tdf#143455 exclude diagram from pos and margin adaptions It will be available in 7.3.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Created attachment 173808 [details] How it looks with the patch applied
(In reply to Regina Henschel from comment #5) > @Xisco: Please take a look at the patch to see if this workaround is > sufficient. https://gerrit.libreoffice.org/c/core/+/119344 Hi Regina, Yes, it looks fine with the patch applied. Thanks for the quick fix!
@Xisco: Thank you for testing it. I have added the bug 106547 to 'Blocks', so that it will not be overseen, that the workaround needs to be replaced with a true solution, when a new way for diagrams is implemented.
Hi Regina, I do confirm the issue is verified in Version: 7.3.0.0.alpha0+ / LibreOffice Community Build ID: 6e53e03f752c2f85283c4d47efaaf0683299783c CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded Should it be closed as RESOLVED FIXED ?
(In reply to Xisco Faulí from comment #10) > Should it be closed as RESOLVED FIXED ? I would prefer to keep it open, because there will be a tender about dynamic diagrams and that needs to adapt the fix to the new structure of the solution implemented with the tender. When it is listed as "new" in meta bug OOXML-SmartArt, it is more likely that it will not be overseen. But my work is done so far, so I remove me from Assignee.
(In reply to Regina Henschel from comment #11) > (In reply to Xisco Faulí from comment #10) > > Should it be closed as RESOLVED FIXED ? > > I would prefer to keep it open, because there will be a tender about dynamic > diagrams and that needs to adapt the fix to the new structure of the > solution implemented with the tender. When it is listed as "new" in meta bug > OOXML-SmartArt, it is more likely that it will not be overseen. > > But my work is done so far, so I remove me from Assignee. The tender already addresses different bug reports while this issue is about a specific problem. My concern is this remains opens forever...
OK. Then close it. I will be watching the tender work anyway.