Description: Formatting of the bulleted list lost after DOCX /RTF export Steps to Reproduce: 1. Open the attached file 2. Save as DOCX 3. File reload Actual Results: Notice highlighting being the same color Notice bullet color being gone Expected Results: Bullet color being present Highlighting/shading color being present Reproducible: Always User Profile Reset: No Additional Info: Found in Version: 7.1.0.0.alpha0+ (x64) Build ID: <buildversion> CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL it worked more or less in 6.4 (expect color being off else it's long road back.. with various issues in highlighting. It was working properly in 4.2
Created attachment 164323 [details] Example file
Confirmed using LO 7.1.0.0.alpha0+ (217122387f6e0ef657b8ba85eae082b448901cec) / Ubuntu. (In reply to Telesto from comment #0) > Expected Results: > Bullet color being present This is bug 134619. > Highlighting/shading color being present This started with the following commit: https://cgit.freedesktop.org/libreoffice/core/commit/?id=701238ea7d8a06fe7a90de15b7660b7c6d854f09 author Tamás Zolnai <tamas.zolnai@collabora.com> 2020-03-23 12:34:16 +0100 committer Tamás Zolnai <tamas.zolnai@collabora.com> 2020-03-23 13:34:25 +0100 "tdf#125268: Export LO character background as MSO shading by default." The change in 4.3 (bullet color changed to black) started in the following range, likely by one of Jacobo's commits (can't pinpoint the exact commit due to crashes): https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=8233226fe4614d5cebe474a0d1b026084e023e4c..291e846db9840b9f82bc28e495b54ae5ac51d0fc
Created attachment 164904 [details] Comparison screenshot (ODT vs DOCX in 7.1)
Bibisecters - please make a mental note to remember this - which will be a very common complaint in the next few years. The correct bibisect for comment 2 comes from https://bugs.documentfoundation.org/show_bug.cgi?id=125268#c56 commit a4c5e940881520834c19573c5b1119afa1c17744 author Miklos Vajna on Fri Apr 03 10:44:46 2020 +0200 tdf#125268 officecfg: export LO character background as MSO shading by default This restores commit 701238ea7d8a06fe7a90de15b7660b7c6d854f09 (tdf#125268: Export LO character background as MSO shading by default., 2020-03-23). As per ESC discussion, see <https://lists.freedesktop.org/archives/libreoffice/2020-April/084813.html> for the details. Summary: the benefit is that this way we don't loose data, and the cost is that LO's highlighting is called shading in MSO now.
Back in LO 6.0, it looked similar to today - where almost everything was a single background colour. Then in 6.1, it looked more like the original ODT (albeit scaled to the 15 available highlight colours) because of author Tamás Zolnai on 2018-01-10 05:59:14 +0100 https://cgit.freedesktop.org/libreoffice/core/commit/?id=aa02ed306f7c633bbffede16e44e8e736977ace4 tdf#106991: Highlighting remains after select no fill Using the bibisect-linux-64-6.4 is very interesting, because it includes commits that are backported. In here, we can see that the bullets lost their colour completely - both the font colour and the background highlight. This is the same bug 134619 that comment 2 identified for the lost font-colour of the bullet in 7.0 and backported to 6.4.5. author Vasily Melenchuk on 2020-05-14 21:52:44 +0200 commit ec43d70911736b821e527109fadb3537635091de tdf#132766: DOCX export: always try to set bullet font for list So this fix is going to depend on bug 134619 to be fixed first. I know that highlighting wasn't importing or exporting NONE properties, so I'm guessing that the 6.1 commit was a bit of a hack to work around that. Today a NONE should be imported and exported - and using "highlighting" instead of "shading" is now buried away were no one will find it. So we can probably just revert that 6.1 hack. But this is all speculation at this point.
Created attachment 169895 [details] 135774_numberingHighlightShd2.docx: my working test document. Proposed fix at http://gerrit.libreoffice.org/c/core/+/111201 tdf#114799 Char highlight: apply to numbering
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/873df086db969cadc66087a5abdb1ff33f2c99f1 tdf#135774, tdf#114799 Char highlight: apply to numbering It will be available in 7.2.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.
IMPORTANT: Any fix here needs to be compared with how MS Word sees the document. The only way that numbering can have a background is if it is exported as w:highlight. By default, LO (since 7.0) exports that as w:shd. So, generally the bullet colour is going to be gone. That is probably a good thing, because highlight only allows 16 colours, so a blank numbering probably looks better than a different colour. So, this example document that starts from ODT is basically an impossible-in-docx request. I'll leave it open for now as I struggle with other aspects of w:highlight, and see what might be possible later on.
(In reply to Justin L from comment #8) > So, this example document that starts from ODT is basically an > impossible-in-docx request. P.S. This is not really an ODT file. It is an MS format resaved later on as an ODT. If you start a brand new file, you won't be able to get the paragraph's background to be copied to the numbering. That is strictly an MS Word compatibility thing.
(In reply to Justin L from comment #9) > P.S. This is not really an ODT file. It is an MS format resaved later on as > an ODT. I had my suspicions about this topic already. Seen ODT demonstrating DOCX behaviour. Is there an easy way to distinct 'true' ODT from MSO compatibility ODT variant. This something which QA actually show be aware of.. The follow question for me is always.. what happens if I copy/paste MSO ODT to new ODT do I get 'real ODT' or style MSO variant? And how to convert DOCX to a true ODT (or is this not possible?). I kind of throw it to RTF paste filter sometimes in the assumption it would do better.. Or is there also a RTF ODT? [Note: ideally somewhere at wiki (?).. not deeply hidden in the bug tracker]. Nobody will find it here, I guess.
> (In reply to Justin L from comment #9) > > P.S. This is not really an ODT file. Hmmm. I probably actually lied here. I just assumed without really checking... (In reply to Telesto from comment #10) > Is there an easy way to distinct 'true' ODT from MSO > compatibility ODT variant. I don't know if there is an easy way. I just try to re-create from scratch. The real way to check would be to unzip and look at settings.xml. Then you "just have to know" some good settings to check. TabOverMargin is true for MS Formats (again, from memory). Or for this specific bug report, the interesting one is ApplyParagraphMarkFormatToNumbering. > The follow question for me is always.. what happens if I copy/paste MSO ODT > to new ODT do I get 'real ODT' or style MSO variant? ??? It might depend on the code. Generally I would not expect a copy/paste to know about compatibility settings - but I might be wrong. > And how to convert DOCX to a true ODT (or is this not possible?). Not really possible. I supposed you could delete all the items in settings.xml, but then you get an "old ODT" compatibility.
(In reply to Justin L from comment #11) > > (In reply to Justin L from comment #9) > > > P.S. This is not really an ODT file. > > Hmmm. I probably actually lied here. I just assumed without really > checking... > > (In reply to Telesto from comment #10) > > Is there an easy way to distinct 'true' ODT from MSO > > compatibility ODT variant. > > I don't know if there is an easy way. I just try to re-create from scratch. > The real way to check would be to unzip and look at settings.xml. Then you > "just have to know" some good settings to check. TabOverMargin is true for > MS Formats (again, from memory). Or for this specific bug report, the > interesting one is ApplyParagraphMarkFormatToNumbering. Hmm.. not possible to write some identifier.. some day - not sure what's allowed in ODT. or some other way of knowing.. Really dislike not knowing this There are plenty bugs closed because I can't reproduce from scratch saving to ODT. But well you have no way of knowing that the OP posted a DOCX converted to ODT. So the no repro is quite obvious.. And you get total different results for a reason. Aside from the lovely weird this does usually not happen in ODT. I'm willing to nag about this on the mailinglist. It's clear to that even developers having go through hoops to figure it out (and seems kind of time consuming activity which not really uncommon at all)
Created attachment 170075 [details] ddd1RT.docx: Word DOES use the w:shd from numbering.xml The bullet points should have a reddish orange background because of numbering.xml <w:lvl w:ilvl="1"> <w:rPr> <w:shd w:fill="ED4C05" w:val="clear"/> </w:rPr> </w:lvl> This worked until 5.0's author Luboš Luňák on 2014-05-29 14:34:50 +0200 commit df07d6cb9f62c0a2c4b29bd850d4efb4fcd4790b handle direct formatting for numbering in .docx (bnc#875717) This is just a very nasty area to work in. A lot of the smartest, most experienced people have been involved. I guess shading and highlighting are very edge cases in this saga.
(In reply to Justin L from comment #13) > This worked until 5.0's author Luboš Luňák on 2014-05-29 14:34:50 +0200 > commit df07d6cb9f62c0a2c4b29bd850d4efb4fcd4790b > handle direct formatting for numbering in .docx (bnc#875717) > > > This is just a very nasty area to work in. A lot of the smartest, most > experienced people have been involved. I guess shading and highlighting are > very edge cases in this saga. Coloring bullets in LibreOffice (without text after the bullet) is already quite an exercise. So if handling of colored bullets in LibreOffice already being odd, what to expect from DOCX? Where text color bleeds into bullets and such.. what to expect from DOCX? If this any relevant here, no clue. I think so. I might have complains about change of color of bullet after ODT save too [have to look that up] So there could be some (fundamental) design flaw. And DOCX only an facet of all of this?
Created attachment 170110 [details] ddd1_highlight.docx: This uses highlight instead of shd in numbering.xml Temporarily broken in 7.2: author Justin Luth on 2020-12-02 12:13:48 +0100 commit 20574b4023952c8fbfa728590f3bdcf603633cca tdf#138345 ms formats Char highlight: no import into char-style
(In reply to Justin L from comment #5) > I'm guessing that the 6.1 commit was a bit of a hack to work around that. > So we can probably just revert that 6.1 hack. That was done by Laszlo in 7.0 in bug 127606.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/43436ef43132eb3ee6c10c0fe50971062677682a tdf#135774 writerfilter Char highlight: revert tdf#117137 It will be available in 7.2.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 170407 [details] Test DocRT.docx: This test shows why the upcoming mxBackColor patch is so important - some bullets where missing the yellow background.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/c44b0df04c798e0a0fa094b14b9ed62ebc7594df tdf#135774 Char highlight: numbering: don't clear existing mxBackColor It will be available in 7.2.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 170451 [details] TestDoc_highlight2.docx: bullets are all green highlight A modified version of comment 18 shows why the next "save highlight" patch is needed.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/cb7839169ac58bc24d986f4cf5532d1d6219574d tdf#135774 Char highlight: partial revert tdf#114799 It will be available in 7.2.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.
I removed RTF format from the subject/bug report since in general it doesn't work well with styles and numbering. So it is very different from DOCX, and is really a separate bug. This bug should now be fixed.
(In reply to Justin L from comment #22) > I removed RTF format from the subject/bug report since in general it doesn't > work well with styles and numbering. So it is very different from DOCX, and > is really a separate bug. For RTF version: see bug 137591
(In reply to Justin L from comment #20) > Created attachment 170451 [details] > TestDoc_highlight2.docx: bullets are all green highlight Word 2010 is needed to see this. Word 2003 doesn't show stuff in numbering.xml. (I don't know what Word 2007 does...)