Description: Indents and spacing changes in DOCX not appliedd Steps to Reproduce: 1. Open attachment 165457 [details] 2. Save to DOCX 3. File reload 3. Place they cursor after AAAA 4. Press Enter 5. Type say BBB 6. Press Enter 7. Type say CCC 8. Press Enter 9. Type say DDD 10. Sidebar -> Style Deck -> Right Click. Text Body -> Modify 11. Indents and spacings tab 12. Set Below Paragraph to 0 and Line Space to single Actual Results: Spacing doesn't adjust as expected Expected Results: Should be so; compare with ODT by following the same steps Reproducible: Always User Profile Reset: No Additional Info: Version: 7.1.0.0.alpha0+ (x64) Build ID: ed4f610f4a3de12016f8308a17b6ad4f86e9d67a 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
Also in Version: 6.3.0.0.alpha0+ Build ID: da881f38c088c439f034e340bbbb4ca53e67389f CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; Locale: nl-NL (nl_NL); UI-Language: en-US Calc: CL
It's adding headings instead of textbox in 6.1 and 6.0 It's working as expected in 4.4.7.2
Created attachment 165460 [details] Exported docx with 6.5 Flaw goes back to 4.1 if we take the file generated by 6.5/7.1
Created attachment 165461 [details] Bibisect log Bisected to author Justin Luth <justin_luth@sil.org> 2018-07-06 10:03:07 +0300 committer Justin Luth <justin_luth@sil.org> 2018-07-07 19:56:21 +0200 commit ac540c1d743250062b3e71b094209ec1428872e9 (patch) tree 55adaf3beadbc8697caf22ca2ad1089aecae176e parent 363146254bd44ab82d657f2ca0293d03bd111280 (diff) tdf#95114 writerfilter: follow correctly converted stylename Using styleIdentifierD works *if* you do an bExtendedSearch. But since we already took the pains of ensuring that sStyleName is not empty, and ExtendedSearch is expensive, just use sStylename. (I don't know *why* we ensure that styleName exists, and this code was originally flakey enough that it might be a fake requirement...) This only affects the few styles which have a different "name" than their ID. The primary one affected is TextBody/Body Text. https://cgit.freedesktop.org/libreoffice/core/commit/?id=ac540c1d743250062b3e71b094209ec1428872e9
Adding CC: to Justin Luth This is not a regression strictly speaking. The situation improved after the commit (previous situation chapter heading was added). Now a Text Body. Except the text body isn't behaving as expected.. For the record: So the bibisect is done backwards.. Marking the 'improved' situation as bad and the 'bad' situation as good.
(In reply to Telesto from comment #0) > Indents and spacing changes in DOCX not applied They are being applied. It is just that there is direct formatting that is carried over from the Heading1 paragraph. Direct formatting gets copy-plastered all over the place while importing DOCX numbering. If you re-apply the TextBody paragraph style (which discards the direct formatting), then you will get the results you expect. (Notice the Before Paragraph value of .77cm which is where most of the space comes from.)
I don't see any need to keep this bug report around. Numbering is known to be absolutely garbage. Marking as WONTFIX. There are plenty of other bugs around, and this one doesn't add anything other than the necessary direct-property-plastering has editing downsides.
(In reply to Justin L from comment #7) > Numbering is known to be absolutely garbage. Marking as WONTFIX. There are plenty of other bugs around Bit off topic Kind of searching for 'best practice/approach'. Bug tracker is in principle dedicated to developers (enhancement kind open for debate). Most bug reports are symptom reports (examples illustrating a bug at work. Instead of in depth analysis of the (logical) flaw /issue at code level. Is it an idea to collect all symptoms related to numbering being garbage into meta bug with some kind of (developer) summary? Having list of bug reports (or actually 'symptom reports) flying around as separate instances not really beneficial. Maybe even closing all in state of 'handled at meta bug summary'. To trim down number of open bugs? The current approach does 'mask' the scope of the issue (20 symptoms point same 'cause') but all reported separately with on lose connections. The 'numbering being garbage' is more developer side knowledge as common knowledge :P. And kind of plastering used to hold everything together to some extend.. This might give developers (volunteers) kind of global overview what needs to be done... but as the needs quite kind of in depth (dev) expertise to analyse.. But only an idea.. not saying this being 'it'.