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?
