Created attachment 172037 [details] File to reproduce the rendering of group shape Open attached file. It has text consisting of single characters. That makes the area good visible, which is occupied by the shape in case of wrap mode 'Square' in Word or 'parallel' in LibreOffice respectively. LibreOffice makes a tight wrap to the bounding box, whereas Word wraps to the full shape. The error happens with custom shape, where the bounding box of the shape is different from the full shape. Such shapes are e.g. the types 'chord', 'partial circle', 'arc' or 'block arc'.
Created attachment 172038 [details] Screenshot of the example file The screenshot shows on left side rendering by LibreOffice and on right side rendering by Word.
No repro 6.0, looks regression, bibisect with Linux-6.1. commit e67255c720d5acfe720dc85eec1aa93d6875a6a0 Date: Sat Mar 17 23:29:14 2018 +0100 source 735d9e5828157a09e0b04b2dc5797a78208b57a2 source 86c4672f4600daf19238ef25377406f445d9453a source d1027af3c74529827d53e8cf7b0d42a0ee47d1ba previous 9886a69c472f212d88f11cfa0f3835e5dcf485b2 https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=9886a69c472f212d88f11cfa0f3835e5dcf485b2..735d9e5828157a09e0b04b2dc5797a78208b57a2 All 3 commits by Armin Le Grand, mentioned in not related bugs. When Fileopen is resolved, Filesave needs a check.
Created attachment 172086 [details] File to reproduce saved as DOC in MSO Although saving as DOC in MSO converts shapes, same issue and commit also for DOC.
I would prefer to have a new bug report for the doc file, because docx and doc are different filters and located in different parts of the code. I have started work on the problems in bug 142304 and this one: https://gerrit.libreoffice.org/c/core/+/115668
Hi Regina. I'm aware of Doc/X difference, I just have a habit of keeping them both in a bug, not to be overlooked, until we see what's gonna happen. I say it's always easy to open a new one, once one is resolved and sanple and explanation are there. Can you please comment on regression thing/commit. What was the change? ALG doesn't follow regressions, which is a pitty because explanation would be useful, even if he or any other dev who causes a regression wouldn't fix it.
(In reply to Timur from comment #5) > Can you please comment on regression thing/commit. What was the change? ALG > doesn't follow regressions, which is a pitty because explanation would be > useful, even if he or any other dev who causes a regression wouldn't fix it. I cannot identify something in the commits, which looks related to the problem here. A comment would really be helpful. I see the change in rendering not only for import from docx, but also for odt-format. Might it be, that the change was intended for odt?
Hi Armin. Please make a comment here on what's bisected as a regression but not so evident.
I do confirm the bisection mentioned in comment 2 is correct but I fail to see why this issue has a 'high' priority...
Well, I do try to follow regressions when I am involved, was a little bit away from the project the last view years - depends not only on me, but various circumstances. It also depends on the TimeFrame - how long does something count as regression - it's a 'regression' req from changes done in early 2018, so hard to remember anyways. AFAIR it was not about layout stuff, but about removing old 'hacks' at smiley and other CustomShapes - there was AFAIR some single-point-polygons in the 'corners' added to the overall PolyPolygon to 'force' the calculated BoundRect to be correct (see 8d107b8d3b33b16436fbe64a5e296ec5a2c69e5d - anyways, I usually add quite some comments to the changes - not always, but chances are good). The differing layouts btw MS and LO is no arg from my POV - LO is not a MS clone and was never intended to be (old discussion...). I would be surprised if I changed that layout in 2018, I am very careful to keep LO old docs unchanged after load, so LO compatibility to itself is much more important. If someone wants MS layout - what I can also understand and there are args for that, too - that would be a feature from my POV that somehow someway would've to be activated then - that's neither an error nor a regression, except when we also did layout like that before. In that case, the layouting 'before', as MS does in the screenshot, may have been an error due to that mentioned 'hack' and was never intended. I think for floating text around graphic it is in general better to let the text flow where there is no graphic - that's the whole purpose of that feature. In that aspect MS way is pretty bad from my POV. So: It may have been same (bad) behavior as MS, but due to an error/hack that was fixed with that change. Old way was then by pure coincidence. If MS comp/way is desired, it would need to be added as feature with switching/activating somehow. It would need to be done differently anyways: Another reason for the fix was that it leaded to errors in other cases: There were those 'hacked' corner-dots visible in PDF exports && printouts which is unacceptable. This cannot be brought back. So, please do not rewind, but - if urgently wished - create a feature request.
Fixed with https://git.libreoffice.org/core/commit/3262fc5ef3bde5b158909d11ccb008161ea95519
I confirm the fix for DOCX open and save. Thanks. I'll See also another one for DOC.