Bug 100693 - FORMATTING MS-COMPAT: fo:wrap-option should be set for graphic-objects in text documents
Summary: FORMATTING MS-COMPAT: fo:wrap-option should be set for graphic-objects in tex...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected) release
Hardware: All All
: medium normal
Assignee: Not Assigned
Keywords: filter:odt, needsDevAdvice
: 113926 125127 (view as bug list)
Depends on:
Blocks: Textbox ODF-export-invalid
  Show dependency treegraph
Reported: 2016-06-30 12:38 UTC by Christoph Lutz
Modified: 2021-06-21 12:54 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:
Regression By:

Textdocument m (29.90 KB, application/vnd.oasis.opendocument.text)
2016-06-30 12:38 UTC, Christoph Lutz
test4.odt example text document with a frame on the right side of the first page with border='none' (29.90 KB, application/vnd.oasis.opendocument.text)
2016-06-30 12:41 UTC, Christoph Lutz
how test4.odt is displayed in LibreOffice (5.0) (229.09 KB, image/png)
2016-06-30 12:42 UTC, Christoph Lutz
how test4.odt is imported and displayed in MS Word 2013 (292.05 KB, image/png)
2016-06-30 12:43 UTC, Christoph Lutz
same test4-document with manually added fo:wrap-option='wrap' attribute that is displayed correct in MS-Office (33.02 KB, application/vnd.oasis.opendocument.text)
2018-04-05 09:54 UTC, Christoph Lutz

Note You need to log in before you can comment on or make changes to this bug.
Description Christoph Lutz 2016-06-30 12:38:58 UTC
Created attachment 126000 [details]
Textdocument m
Comment 1 Christoph Lutz 2016-06-30 12:41:23 UTC
Created attachment 126001 [details]
test4.odt example text document with a frame on the right side of the first page with border='none'
Comment 2 Christoph Lutz 2016-06-30 12:42:47 UTC
Created attachment 126002 [details]
how test4.odt is displayed in LibreOffice (5.0)
Comment 3 Christoph Lutz 2016-06-30 12:43:29 UTC
Created attachment 126003 [details]
how test4.odt is imported and displayed in MS Word 2013
Comment 4 Christoph Lutz 2016-06-30 13:13:10 UTC
This bug seems to be related to tdf:53992, but is not exactly the same, since here it is about an formatting / interoperability issue regarding text frames in LibreOffice and MS Word and the handling of (the graphic-style) fo:wrap-option.

How to reproduce the issue:
- there's a document test4.odt that was created with LibreOffice and stored to ODF
- open the attached document test4.odt in LibreOffice (find attached how test4.odt should be displayed in LibreOffice)
- open the attached document test4.odt in MS Word 2013 (find attached how test4.odt is currently displayed in MS Word)

You can see, that Word is not able to display the document correctly. The frame on the right side of the first page is much too large and the text wrapping is wrong.

This is how the document was created:
- opened a new writer document
- insert->frame
- options set on the frame:
  - unset option for automatic height
  - kept text wrapping "quadratic"
  - choose no border
  - moved the frame to the top right corner of the text area
  - resized it to be about 5cm wide and fill the height of the text area
- add some text (bt<F3>) into the text area and into the frame to see how wrapping works
- saved as ODF


For me it seems that LibreOffice and MS Office behave different regarding the graphic-style option fo:wrap-option.

By introspecting styles.xml of test4, you can see, that LibreOffice sets fo:wrap-option='no-wrap' as default graphic format.

The corresponding Textframe-style "fr1" is derived from the graphic style "Frame" and this style sets style:wrap='parallel' (and more wrapping relevant options). So if 'Frame's behaviour should enable text wrapping, why is fo:wrap-option not set to fo:wrap-option='wrap'?

If I add fo:wrap-option='wrap' to the style-definition of 'Frame', the document IS displayed correctly in MS Word. So obviously both implementations behave different in when and how fo:wrap-option is interpreted.

According the the ODF 1.2 spec, I cannot find any reason why LibreOffice should not write fo:wrap-option='wrap' whenever text wrapping should be active. So I have to argue that even if LibreOffice is able to display the document correct, It doesn't produce correct ODF according to the spec (regarding fo:wrap-option). This bug should be fixed in LibreOffice to improve interoperability with other ODF implementations.
Comment 5 Christoph Lutz 2016-06-30 13:24:46 UTC
already mentioned bug 53992 which describes a similar issue for Calc and suggests a similar solution
Comment 6 Xisco Faulí 2017-08-17 16:17:42 UTC
Could you please explain how the document was created? To me it seems like the problem is in MSO Word, not in LibreOffice.
I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the information is provided
Comment 7 QA Administrators 2018-03-02 10:01:28 UTC Comment hidden (obsolete)
Comment 8 QA Administrators 2018-04-04 13:26:50 UTC Comment hidden (obsolete)
Comment 9 Christoph Lutz 2018-04-05 09:54:18 UTC
Created attachment 141121 [details]
same test4-document with manually added fo:wrap-option='wrap' attribute that is displayed correct in MS-Office
Comment 10 Christoph Lutz 2018-04-05 10:06:28 UTC
This interoperability issue still occurs in combination with LibreOffice and MSO (used Office 365 Web-view for the above ODT-Documents):

test4.odt is displayed wrong in MS-Office,

test4_added_fo_wrap_option_wrap.odt is displayed correct in MS-Office.

The only difference between these two documents is, that in the second one I manually added fo:wrap-option='wrap' attribute near the place where style:wrap='parallel' is set.

So to summarize the above request:

To improve compatibility for ODT between LibreOffice and MSO, I suggest to automatically add fo:wrap-option='wrap' whenever style:wrap='parallel' is set.

more details (just because you asked for) - I don't think they are required:

a) Tested with LibreOffice on a current ubuntu bionic snapshot. MSO is run as Office 365 in the Browser (in the previous try I used a MS-Office 20xx fat client).

b) reproduce? open the mentioned documents in MSO

c) see b). Sorry, there's nothing to add.

d) already added - see above.
Comment 11 Xisco Faulí 2018-04-06 08:26:56 UTC
You can't confirm your own bugs. Moving it back to UNCONFIRMED until someone
else confirms it.
Comment 12 Thomas Lendo 2018-06-17 19:04:40 UTC
CCing Regina: Is this something LibreOffice should take care of or is it not our bug? Has ODF spec an idea about such interoperability issues?
Comment 13 Regina Henschel 2018-06-17 21:04:08 UTC
It is not only a question of interoperability. It is a real bug in LibreOffice.
LibreOffice does not write the attribute fo:wrap-option in general, but only if you set is explicitly. But such is not possible in Writer, neither for a Frame nor for a graphic Text-Box. It is only possible for a Custom-Shape.

If a graphic property is not set at the style of the object, nor at any of its parent styles, then the settings in style:default-style of the same family (here graphic) has to be used. And there fo:wrap-option="no-wrap" is set. So Word shows the file exactly as it is written by LibreOffice. But LibreOffice wraps the text although it writes "no-wrap".

The same problem is in Impress. There too the standard graphic style has no setting for fo:wrap-option and the element <style:default-style> has set fo:wrap-option="no-wrap".

A solution is possible in several steps:
1. Write fo:wrap-option="wrap" in the default style, so that file format and actual behavior fit together.
2. Write this attribute for all "frame"-graphic styles in Writer, because they are treated different from graphic objects in LibreOffice.
3. Bring this attribute to UI in all graphic styles, not only in Custom-Shapes.
Comment 14 V Stuart Foote 2019-05-06 03:43:33 UTC
*** Bug 125127 has been marked as a duplicate of this bug. ***
Comment 15 QA Administrators 2021-06-21 03:38:07 UTC Comment hidden (obsolete)
Comment 16 Regina Henschel 2021-06-21 12:44:36 UTC
*** Bug 113926 has been marked as a duplicate of this bug. ***
Comment 17 Regina Henschel 2021-06-21 12:54:46 UTC
The problem exist still in Version: (x64) / LibreOffice Community
Build ID: e718f0e703c0fb33a0b1b5efe7b13b02c25f3335
CPU threads: 8; OS: Windows 10.0 Build 19041; UI render: Skia/Raster; VCL: win
Locale: de-DE (en_US); UI: en-US
Calc: CL