Created attachment 121138 [details] test doc numbering style My paragraph style numbers my paragraph. I have set the used number style to put the numbers in bold, but this is occasionnally 'forgotten' by the program. (I also use 'paragraph titles', which is just text at the beginning of the paragraph in bold to summarise it.) How to reproduce most easily: open the attachment. Go somewhere in the text. Add a new paragraph by pushing on enter. This paragraph is numbered; the number should be in bold but often is not (repeat a few times if the bug does not appear). Typing in the paragraph often reminds Writer of the style; bolding the first characters has often the same result. Technical information: OS: Windows 10, also appeared in Windows 8 (both home edition). LO: 5.0.3.2 (x64) (has been present since some time) Build ID: e5f16313668ac592c1bfb310f4390624e3dbfb75 Locale: nl-BE (nl_BE)
In 5.0.4.1 (x64) Build ID: 2def61bcbb29a7a8611b833682fe1291910b11ad this bug seems to have gone away of its own accord.
Correction: I was a little bit too quick. The bug is still present, but somewhat less severe. LO 5.1.0.1 (x64) Build ID: bcace328aabc4c8c10b56daa87da0a2ee6579b5a Threads 4; Ver: Windows 6.19; Render: default; Locale: nl-BE (nl_BE)
Nobody confirmed this bug report. Set status back to unconfirmed. Best regards. JBF
(In reply to f5d505f9 from comment #2) > Correction: I was a little bit too quick. The bug is still present, but > somewhat less severe. What do you mean? I tried 30 times, but the number was always bold. Win 7 Pro 64-bit Version: 5.2.0.0.alpha0+ Build ID: 22e5170af74c635cf55d089f97946b6dc86f82ad CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2016-01-05_23:41:26 Locale: fi-FI (fi_FI)
Windows 10 Pro, Version 1511 (OS Build 10586.36) LibreOffice 5.0.4.2, Build ID 2b9802c1994aa0b7dc6079e128979269cf95bc78 Locale en_US Can confirm described behaviour. Reproduced by: going to page 341, placing cursor 10 characters after footnote 1726 and pressing Enter repeatedly. Only the paragraph number next to the cursor will be bold. Example: 1. Set your cursor to the described position, press Enter, paragraph number 762 appears in bold next to the cursor. 2. Press Enter again, paragraph number 763 is in bold next to the cursor, 762 has lost its formatting. 3. Press Enter yet again, paragraph number 764 is in bold next to the cursor, 763 has lost its formatting. The bold formatting did "come and go" when writing and deleting characters in those new paragraphs, although I could not discern any pattern. Changing to NEW since I found it to be reliably reproduceable otherwise.
The numbering loses is bold attribute when the paragraph is empty. Type some text and the bold attribute comes back. In fact bold is not an attribute like the color, it is the variant of the font. You are using "Strong accentuation" as character style for the numbering style. If you change the character color in this character style, you can see that the color attribute is kept even when the paragraph is empty. Not sure if it a bug. Tested with LibreOffice 5.1.0.0.0+ built at home under Ubuntu 15.10 x86-64. Best regards. JBF
Idem as comment #6 with LibreOffice 5.0.5.0.0+ Best regards. JBF
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.2.5 or 5.3.0 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170306
Dear f5d505f9, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Created attachment 156703 [details] test doc minimal With master 6.5+, ODT cannot be open at all. I'll report another regression. Report is not clear, never say "go somewhere" but be precise instead. For test, I add 2-pages ODT. If we type enter in item 4., numbering is as expected bold, text regular. If we type enter in item 5., numbering is not bold until text typed. Tested with reported LO 5.0 and LO 6.0. And that was a regression because worked fine in OO 3.3. and LO 4.4. But no repro anymore with LO 6.3.3 and master 6.5+. So WFM.
Bibisected with 62, fixed with: 168c54c84fb9e5f7b673af39df970bd80359c9ad is the first *good* commit commit 168c54c84fb9e5f7b673af39df970bd80359c9ad Author: Jenkins Build User <tdf@pollux.tdf> Date: Fri Mar 22 12:50:08 2019 +0100 source 6bbcf6e2839ef2747ec3677e5daa7a6ce118fd81 Previous source 76848756909cb969b4689ebd2dd3b5fa27b0dc23 https://gerrit.libreoffice.org/plugins/gitiles/core/+/6bbcf6e2839ef2747ec3677e5daa7a6ce118fd81%5E!/ commit 6bbcf6e2839ef2747ec3677e5daa7a6ce118fd81 [log] author Miklos Vajna <vmiklos@collabora.com> Mon Mar 18 21:40:15 2019 +0100 committer Caolán McNamara <caolanm@redhat.com> Fri Mar 22 12:24:58 2019 +0100 tree b1454087b7da6c8a5b65f647cd572204aa0f9229 parent 76848756909cb969b4689ebd2dd3b5fa27b0dc23 [diff] tdf#120548 sw ApplyParagraphMarkFormatToNumbering: fix handling of font color
Cool -> FIXED