Description: After selecting the Heading style for the relevant chapter level of a document, typing in some words, and directly formatting the last word (e.g., italics), it changes the formatting of the number to follow the last word. Steps to Reproduce: 1. Select Paragraph Style Heading. 2. Type some text. 3. Change the formatting of the last word (or character) you type. E.g., set it to italics, or strikethrough, or unbold it, or change its color. 4. Hit enter. (The style of the number doesn't change until you move the cursor to a different line, either by entering a new line or clicking to an existing line.) Actual Results: The chapter number formatting changes to match the formatting of the last character on the line. Expected Results: The number should retain the default formatting of the Heading paragraph style. Reproducible: Always User Profile Reset: No Additional Info: Version: 7.3.5.2 (x64) / LibreOffice Community Build ID: 184fe81b8c8c30d8b5082578aee2fed2ea847c01 CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL
Hi William I couldn't reproduce with: Version: 7.3.5.2 / LibreOffice Community Build ID: 184fe81b8c8c30d8b5082578aee2fed2ea847c01 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded To see the heading numbers, have you turned numbering on previously with "Tools > Chapter Numbering... > Numbering tab > 1-10 > Number"? Could you please write steps to start from a brand new document, or provide an existing document to start from?
Created attachment 182034 [details] Video showing the bug In this video, you can see the bug at work. (Please forgive the occasional flickering.)
Created attachment 182035 [details] Document used for testing
I have attached both a video showing the bug in action and the document used to test it. A few things to note: 1) As you can see from the video, underlining and superscripting don't affect the formatting of the number, while bold/italics/strikethrough/font color do. 2) I didn't show this in the video, but it really is dependent on the formatting of the last character. If I add a space that is formatted just as bold, then that's how the number appears. (That's my current workaround for this issue when the last word in the heading needs to be in italics.) Thank you for your attention!
I can reproduce when starting with attachment 182035 [details] but can't from a brand new document. I'm marking this as NEW as it does look like an unwanted behaviour and I can't figure out from the styles and chapter numbering settings why it is behaving like this. Also reproduced with: Version: 7.2.7.2 / LibreOffice Community Build ID: 8d71d29d553c0f7dcbfa38fbfda25ee34cce99a2 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded But not in: Version: 6.4.7.2 Build ID: 1:6.4.7-0ubuntu0.20.04.4 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3; Locale: en-AU (en_AU.UTF-8); UI-Language: en-US Calc: threaded Nor in: Version: 7.1.8.1 / LibreOffice Community Build ID: e1f30c802c3269a1d052614453f260e49458c82c CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Seems to be a regression in the 7.2 branch.
bibisected on the 7.2 branch, first bad commit is: 0ecb686a9b7b69dfb5f0b8e0d0cad482efda8f63 is the first bad commit commit 0ecb686a9b7b69dfb5f0b8e0d0cad482efda8f63 Author: Jenkins Build User <tdf@pollux.tdf> Date: Thu Mar 18 19:45:16 2021 +0100 source 0a32371cc2f93fad7954e0fe9c48976aae6c5b9f source 0a32371cc2f93fad7954e0fe9c48976aae6c5b9f instdir/program/libswlo.so | Bin 22062224 -> 22062224 bytes instdir/program/setuprc | 2 +- instdir/program/versionrc | 2 +- 3 files changed, 2 insertions(+), 2 deletions(-) Which leads to this commit: https://git.libreoffice.org/core/+/0a32371cc2f93fad7954e0fe9c48976aae6c5b9f Can't CC Justin Luth so adding Michael Meeks (hope that's OK?). Full bisect log: # bad: [9dcd4f5671896db03d3bf94bbe602d58585b67e7] source ffa09959edd087794b1f2fe6b9b6faac484ef74b git bisect start 'origin/master' # good: [1810f056660f59f79e76b8bdd6f5b902c27ce14f] source 738bcf5e9a8c443d60c29c3a8068e8c16c72638a git bisect good 1810f056660f59f79e76b8bdd6f5b902c27ce14f # bad: [b58e2a603efc8e9597cd1bf963c7b2dbdbf58b3a] source c6e3fcfbb901c46191461d1a08cf0c4524729cfc git bisect bad b58e2a603efc8e9597cd1bf963c7b2dbdbf58b3a # good: [3706e5dd09070b0a0928311d833790432f7c023f] source 6220d619b42b18cca7280174daed56aad5c82fce git bisect good 3706e5dd09070b0a0928311d833790432f7c023f # good: [899ed2219898214f648d0ce86d54cfe705765583] source a1d987cf3d0e1ae4d87f7d06ae93e71a0cc59f0c git bisect good 899ed2219898214f648d0ce86d54cfe705765583 # good: [ba837bfa795464908bff7a8b44b70d21a498b724] source 6d7a7845ae9f774daf8da6ac528d970d29fa2b1d git bisect good ba837bfa795464908bff7a8b44b70d21a498b724 # good: [c46d61270444594b17e1a81617c80ec07868cf0f] source 1c0a9f7f26e7aa14b75d02a4bef033ff0a252c7a git bisect good c46d61270444594b17e1a81617c80ec07868cf0f # good: [a64a66457d16d37d4754442646591ab3e9d7aa87] source 5c330f84245978f20343ba6bc2ebcc303ab9c5f6 git bisect good a64a66457d16d37d4754442646591ab3e9d7aa87 # bad: [b2a4d8a3dff25b5c50af9f016151b69ddecf5680] source bf6efbb808929bfba42f88c894be93d1aa6f4210 git bisect bad b2a4d8a3dff25b5c50af9f016151b69ddecf5680 # good: [8674654a40e6ca36827d33fbceb28b92c690368e] source 9d02d86e8a9111b7a689062eb9a856146a9e80b1 git bisect good 8674654a40e6ca36827d33fbceb28b92c690368e # good: [edbf89a2cb07dd436e609500ee59cbb3aa77603a] source e22405c554abe13675b05eae5c8b3e15657b10d4 git bisect good edbf89a2cb07dd436e609500ee59cbb3aa77603a # good: [fffdc30ebad9cf3068eb1f873771a5b1fc82259f] source 31442054520cf0a263cc17e157cfa102cff8ef6a git bisect good fffdc30ebad9cf3068eb1f873771a5b1fc82259f # bad: [da15ebff1cadd5bfedce1d954694b58ff0e21749] source 7385ce6ac788335f15744c104c2b4e095ce90ce8 git bisect bad da15ebff1cadd5bfedce1d954694b58ff0e21749 # bad: [cedce550905f2df017c57591619f1a3417a4d4ab] source db5eec5ead50c7f9f53f446d3da16255d06ade56 git bisect bad cedce550905f2df017c57591619f1a3417a4d4ab # bad: [0ecb686a9b7b69dfb5f0b8e0d0cad482efda8f63] source 0a32371cc2f93fad7954e0fe9c48976aae6c5b9f git bisect bad 0ecb686a9b7b69dfb5f0b8e0d0cad482efda8f63 # first bad commit: [0ecb686a9b7b69dfb5f0b8e0d0cad482efda8f63] source 0a32371cc2f93fad7954e0fe9c48976aae6c5b9f
Perhaps I need to qualify the change with APPLY_PARAGRAPH_MARK_FORMAT_TO_NUMBERING?
I don't think this is a bug. The document's settings.xml has ApplyParagraphMarkFormatToNumbering set to true. It is normally false for ODT files, so this file likely has spent part of its life as a DOC/DOCX file. Thus, it needs to operate in DOCX compatibility mode then - and that is what needs to happen for MS formats.
First introduced in 6.4 via Samuel Mehrbrodt's https://git.libreoffice.org/core/+/2c0d3ce5292b45a8897758508ee61801e4e8340d%5E%21 tdf#64222 Consistently apply direct formatting to numbering Then changed by the part I reverted - probably in response to Mike K's bug 64222 comment 14.
(In reply to Justin L from comment #8) > I don't think this is a bug. The document's settings.xml has > ApplyParagraphMarkFormatToNumbering set to true. It is normally false for > ODT files, so this file likely has spent part of its life as a DOC/DOCX > file. Thus, it needs to operate in DOCX compatibility mode then - and that > is what needs to happen for MS formats. Thank you for checking this. This file was opened fresh from my customized standard template. It's possible that I once saved the file that served as the basis for that standard template in doc/docx format, although I don't remember doing so at this point. When I opened default.ott, however, I couldn't find a settings.xml file. How does a new document opened from that template know to set that setting to true? Two more issues: 1) Is there a setting available through the UI to change ApplyParagraphMarkFormatToNumbering to false? I don't see anything obvious in Tool | LibreOffice Writer | Compatibility. If not, Could such a setting be made available? 2) If a document that was once saved in doc/docx is later saved in .odt or .ott format, is there a reason not to have ApplyParagraphMarkFormatToNumbering be automatically set to false? Thank you for your attention!
(In reply to William Friedman from comment #10) > (In reply to Justin L from comment #8) > How does a new document opened from that > template know to set that setting to true? It happens automatically during save time. All internal settings are saved into the file. I wouldn't expect this result unless your template specifies it as true, since the internal setting is false. It is only set to true when loading DOC/DOCX/RTF formats. sw/source/core/doc/DocumentSettingManager.cxx: mApplyParagraphMarkFormatToNumbering(false), > Two more issues: > 1) Is there a setting available through the UI to change > ApplyParagraphMarkFormatToNumbering to false? This isn't something that would normally be exposed. I didn't find anything. > 2) If a document that was once saved in doc/docx is later saved in .odt or > .ott format, is there a reason not to have > ApplyParagraphMarkFormatToNumbering be automatically set to false? Absolutely! The whole point of this is to make sure that the document continues to remain compatible no matter what format it is saved in. If it looked a certain way in DOC format, if you save it as ODT you normally still want it to look the same. Normally once these are set you never want them to change. P.S. This section of code bothering you no longer applies to DOCX. There is a TODO to have it not apply to DOC/RTF as well - although it is complex so likely someone needs to fund it in order for it to happen.
It is a bug. It should only effect load time - not editing time. So I'd better look into // TODO remove this fallback (for WW8/RTF) What is RES_PARA_LIST_AUTO_FORMAT? It is the direct-format PARAGRAPH properties of the CR. AFAICS it is only set by writerfilter import and never via UI. (created for bug 64222) What is RES_TXTATR_AUTOFMT? It is a direct-format CHARACTER property hint. I assume it is an internal SW thing that maps to the internal character styles. It returns true for IsAutoStyle(). So it basically is a group of character attributes then, but not the official charStyle. In a sense, it is "nothing special" (although it really complicates everything). I don't think it is ever set at import (of MS formats) and should be irrelevant to this bug. ::finishParagraph should be similar to ww8scan.cxx's WW8PLCFMan::AdjustEnds.
Trying to create an SwFormatAutoFormat ends up with error: undefined reference to 'SwFormatAutoFormat::SwFormatAutoFormat(unsigned short)' sw/inc/fmtautofmt.hxx:26: error: undefined reference to 'vtable for SwFormatAutoFormat' /usr/bin/ld.gold: the vtable symbol may be undefined because the class is missing its key function This looks like it can be avoided by - class SAL_DLLPUBLIC_RTTI SwFormatAutoFormat final : public SfxPoolItem + class SAL_DLLPUBLIC SwFormatAutoFormat final : public SfxPoolItem
Depends on bug 117994 to export properly I expect. I have been using attachment 170372 [details] as my test document. Starting in LO 5.1.4 it failed to export properly - seen ONLY in MS Word - where the first number is a smaller size 10pt. That started with author Luke Deller on 2016-04-27 15:17:22 commit 817c3b17fa57a7c4c4f80569bc00a21001fb6807 tdf#99474 close direct char fmt at end of para All the numbering became small (in MSWord) in LO 7.3 with my other commit in bug 108518. That is valid - I'm not creating bogus styles any more on import. I first want to tackle this export problem, but for import, I so far have: -http://gerrit.libreoffice.org/c/core/+/139329 tdf#150613 sw: better DOC import of paragraph marker formatting -http://gerrit.libreoffice.org/c/core/+/139330 tdf#150613 sw: remove this fallback (for WW8/RTF)
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/6e1c8bcec511444d2d51c5c5143be56d1900e5e6 tdf#150613 sw: better DOC import of paragraph marker formatting It will be available in 7.5.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.
OP's situation could still happen if someone starts with an RTF -> ODT conversion. (It is a TODO in the code, so I won't bother with a new bug report, and close this specific report as fixed.)
*** Bug 143518 has been marked as a duplicate of this bug. ***
Justin, I can still reproduce as described in comment 5 with a recent master build: Version: 7.5.0.0.alpha0+ / LibreOffice Community Build ID: 2a7fcaf582df3ada57ca519b50e29011973a1b6f CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Is that because of the remaining TODO you mentioned in comment 16? Or will attachment 182035 [details] always behave the same, no matter what?
(In reply to stragu from comment #18) > Justin, I can still reproduce as described in comment 5 with a recent master > build: You are right. That is a strange document with an unclear history. The fix was for .DOC formats. (DOCX already was handled.) This bug report is only expected to affect documents that spent part of their life as doc/docx/rtf. So AFAIK, only .RTF-based files may now be affected. Early versions of my patch would have handled OP's example, but I changed it based on expert feedback.
(In reply to Commit Notification from comment #15) > tdf#150613 sw: better DOC import of paragraph marker formatting I am now very confused about this. In my patch, I very intentionally picked ADD_FLY_OFFSETS for isDOC specifically because it was NOT in writerfilter, and thus DOC only. And yet now when I am reviewing this, I am seeing the UNO name for it (which is AddFrameOffsets) applied to RTF and compat14 already in 7.2/7.1.4 and before that in all DOCX. How did I not notice that in testing? How did I not test to see which RTF files failed with an assert(false)? It has applied to all DOCX/RTF since commit 355d25eac764713f4d52eac801ade6e2ff1deab0 Author: Cédric Bosdonnat on Wed Sep 19 16:19:37 2012 +0200 n#779627: added quite some compat options from the ww8 filter on writerfilter and only since 7.1.4 did it apply only to RTF (and older DOCX compat14). So with the 7.5 patch in comment 15 I have effectively eliminated RTF from this as well. Thus this function pretty much never runs except for older ODT files that are missing some of these compatibility flags. Older than 2012 I guess. It is terrible that I made such a mistake, but probably a good outcome because the sooner this hack is eliminated, the better. No complaints yet from the RTF crowd about broken documents.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/27df5ef405826875340645b9b979bd5c2c0b92cc tdf#146168 tdf#150613 list attributes: limit hack to RTF It will be available in 7.6.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.
Justin Luth committed a patch related to this issue. It has been pushed to "libreoffice-7-5": https://git.libreoffice.org/core/commit/729ebba19d9a3d7a1de24654366e0517e30a999e tdf#146168 tdf#150613 list attributes: limit hack to RTF It will be available in 7.5.2. 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.