Description: FILESAVE DOCX: Heading get bullets Steps to Reproduce: 1. Open the attached file 2. Save as DOCX 3. File reload -> Look at heading Actual Results: Numbering changes into bullets Expected Results: Shouldn't happen Reproducible: Always User Profile Reset: No Additional Info: 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
Created attachment 163576 [details] Example file
I can't reproduce it in Version: 7.1.0.0.alpha0+ Build ID: b68c10a0d0e6f83b6b037da72210033cacb1677b CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
Created attachment 163613 [details] Example file Proper
(In reply to Telesto from comment #3) > Created attachment 163613 [details] > Example file Proper Again, not reproducible in Version: 7.1.0.0.alpha0+ Build ID: b68c10a0d0e6f83b6b037da72210033cacb1677b CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
> Additional Info: > 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 Please, add the buildversion
It's the build from 7/24/2020 -> I'm updating now.. they see if the build id is back..
Created attachment 163616 [details] EXPORTED DOCX
Created attachment 163617 [details] PDF
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 Build of today -> someone meddled with Build ID
Thanks you for reporting this bug. I can not reproduce this bug in: Version: 7.1.0.0.alpha0+ (x64) Build ID: 5f665a855ef26fae4dfa2ac427685b60545e8b8 CPU threads: 16; OS: Windows 10.0 Build 18363; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL
Not seen in Version: 7.0.0.2 Build ID: c01aa64b6c3d89ebe5fe69c28c7adb24eb85249c CPU threads: 4; OS: Mac OS X 10.12.6; UI render: default; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded Looks like a kind of font issue
Created attachment 167763 [details] Minimized source file
Created attachment 167764 [details] The minimized source file saved as docx Looks like the frame at the bottom of the original document - anchored to a bulleted paragraph - has something to do with this. Removing the frame before save does not trigger this problem.
Created attachment 167765 [details] The minimized and the docx verson in Writer master Version: 7.2.0.0.alpha0+ (x64) Build ID: 4e63ec27b69fa01ff610c894c9fbf05c377a6179 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: default; VCL: win Locale: en-US (hu_HU); UI: en-US Calc: CL
Bibisected with minimized example file on bibisect-linux-64-7.1 to: https://cgit.freedesktop.org/libreoffice/core/commit/?id=04ca5efc800c6b7a6e98e4278eb8be6ac6737fe9 author Julien Nabet <serval2412@yahoo.fr> 2020-06-27 09:27:50 +0200 committer Caolán McNamara <caolanm@redhat.com> 2020-06-27 16:27:13 +0200 cid#1464974: Null pointer dereferences (sw/unosett) Adding CC to: Julien Nabet Side note: the original file does not seem to save badly on Linux, only on Windows. But saving the minimized one to docx indeed adds numbering to Heading paragraphs.
(In reply to NISZ LibreOffice Team from comment #13) > Created attachment 167764 [details] > The minimized source file saved as docx > > Looks like the frame at the bottom of the original document - anchored to a > bulleted paragraph - has something to do with this. > Removing the frame before save does not trigger this problem. Win only? I can't reproduce it in Version: 7.2.0.0.alpha0+ Build ID: 480d00625534c356dabd96c503d992f07c99d152 CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
On pc Debian x86-64 with master sources updated today with gtk3 or gen rendering, I don't reproduce the pb with minimized source file. I also put a trace at the location indicated by: https://cgit.freedesktop.org/libreoffice/core/commit/?id=04ca5efc800c6b7a6e98e4278eb8be6ac6737fe9 author Julien Nabet <serval2412@yahoo.fr> 2020-06-27 09:27:50 +0200 committer Caolán McNamara <caolanm@redhat.com> 2020-06-27 16:27:13 +0200 cid#1464974: Null pointer dereferences (sw/unosett) It seems LO doesn't go there. Also the patch doesn't change functionality, just avoids some null pointer. diff --git a/sw/source/core/unocore/unosett.cxx b/sw/source/core/unocore/unosett.cxx index 817938749bf7..81f1a6a2e33a 100644 --- a/sw/source/core/unocore/unosett.cxx +++ b/sw/source/core/unocore/unosett.cxx @@ -1771,8 +1771,8 @@ void SwXNumberingRules::SetPropertiesToNumFormat( { OUString sBulletFontName; rProp.Value >>= sBulletFontName; - SwDocShell* pLclDocShell = pDoc->GetDocShell(); - if( !sBulletFontName.isEmpty() && pLclDocShell ) + SwDocShell* pLclDocShell = nullptr; + if( !sBulletFontName.isEmpty() && pDoc && (pLclDocShell = pDoc->GetDocShell()) ) Did I miss something?
Created attachment 169158 [details] Cumhuriyet Dà ¶nemi (s6)RTdocx.pdf: round-tripped in LO 6.4 bibisect. I had no problem reproducing this in Ubuntu 20.04 / gtk3 using bibisect-linux-64-6.4. It started off with no bullets, then for a short time with nice round bullets, and then with this awefol symbol starting with: author Michael Stahl on 2019-09-05 12:46:19 +0200 commit 632ee9aae6d5f3cf08b6d6b2789310c20db713b7 tdf#95848 sw: DOCX export: export w:lvlOverride elements ... when necessary; factor out MSWordExportBase::NumberingLevel() so it can be called for this purpose.
The bullets were first introduced earlier in 6.4. author Michael Stahl on 2019-09-05 10:18:12 +0200 commit 1f6b7030cbdc81e8e408e3a13bfcd01fcbdd7550 tdf#95848 sw: DOCX export: crude implementation of abstractNum mapping This is the more relevant commit to this issue I would expect. It is probably worth noting that Word 2003 cannot even open the round-tripped DOCX file - some kind of error it can't fix.
Comment 12's minimized version is fixed by bug 136194 comment 14's patch, but not comment 3's 11MB version. Both of these ODT files lived previous lives as DOC or DOCX.
Oh boy - even worse. The DEFAULT PARAGRAPH STYLE has numbering turned on. So anywhere there isn't any numbering, it is explicitly turned off. Hmm - I wonder why things start getting numbered?
Hmm. It doesn't seem like a file-save problem, because MS Word 2016 opens the round-tripped file fine (after complaining about errors). I tried this against my series of import patches, but it still has problems. But I can't see the REASON for the bullet point showing up. Neither the Heading style (Chapter Numbering), nor the WW8NumX styles used indicate any numbering (although of course the Default Paragraph Style does use numbering, but this NONE numbering should override that). So this probably is some strange side effect of lvlOverrides. CC: Michael.
Fix in LO 7.3 (and 7.2) with commit d1f1f546b212ecd651146addeb328806bb270d5f Author: Vasily Melenchuk on Thu Aug 5 20:40:13 2021 +0300 tdf#143605 sw: numbering rule is not constructed for numbering type "None"
Justin Luth committed a patch related to this issue. It has been pushed to "libreoffice-7-2": https://git.libreoffice.org/core/commit/824a46920348451a483dd195bb6ca651cf1d4f4c tdf#135164 add unit test It will be available in 7.2.1. 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.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/226ab4d444dbbf8a257b38e08b138713466fe7cd tdf#135164 add unit test 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.