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
Notice highlighting being the same color
Notice bullet color being gone
Bullet color being present
Highlighting/shading color being present
User Profile Reset: No
Version: 18.104.22.168.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
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]
Confirmed using LO 22.214.171.124.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:
author Tamás Zolnai <firstname.lastname@example.org> 2020-03-23 12:34:16 +0100
committer Tamás Zolnai <email@example.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):
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
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.,
As per ESC discussion, see
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
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
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
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":
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:
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
> (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:shd w:fill="ED4C05" w:val="clear"/>
This worked until 5.0's author Luboš Luňák on 2014-05-29 14:34:50 +0200
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
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.