Created attachment 94475 [details] Example document Background: In Numbering Styles, the style of the number character is set by the specified character style. The default character style is "Numbering Symbols", and by default there are no attributes set for that style. In other words the visual behaviour is the same as if "None" was specified as the character style. The Problem: In LibreOffice 4.x if the character style has been defined as "None", it is automatically changed to "Numbering Symbols", which of course produces a different visual result *IF* that character style has been changed from its default. This problem is observed in LO 4.0.6.2, LO 4.1.1.2, and LO 4.2.1.1 This problem is not observed in LO 3.3.4, LO 3.4.6, LO 3.6.7.2 Platform is Windows XP. The example document demonstrates this and contains images of the relevant settings and the effects.
Hi, I can see what you said in your sample document, but what is the difference? you can still define the character style "numbering symbol" in the Style and formatting window? I don't see how it is a bug because now you have a defined style instead of none. Sophie
Hi Sophie, Unless there has been a specification change and LO4 is implementing that change, the document should look the same regardless of which tool it is opened in. LO3 and OOo3&4 render the document as I expect. LO4 renders it differently. (It is applying a style of its choice iff one is not already specified for the numbering.) The purpose (as far as I can tell) for having the ability to set the character style of numbering is to allow the numbering to be rendered differently to the paragraph it is applied to. However if we wish the numbering style to render the text the *same* as the underlying paragraph, then we do *not* want to apply a character style. We could set the character style to match the paragraph style (as you suggest), but that breaks the ability to change the paragraph style and have the numbering automatically change to match. Dale.
More details: When editing with LO 4.x, setting the relevant character style to None produces the same rendering behaviour as it does in LO 3.x. Editing with LO 4.x, setting the relevant character style to None, then saving the document, results in it being saved as expected. This is demonstrated by opening the newly-saved document with LO 3.x or OOo; it looks the same as it did in LO 4.x at the point of saving. However if that newly-saved document is reopened in LO 4.x, it now looks different - that is a bug.
Confirmed that the document looks different in 3.6.7 from 4.0 and above on Linux Mint.
bibisected: 2e0fa432485d1db6abd355dad8ccb06f0b97e4fb is the first bad commit commit 2e0fa432485d1db6abd355dad8ccb06f0b97e4fb Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com> Date: Tue Dec 11 09:32:19 2012 +0000 source-hash-ce90f99a2d66c2b998ad3f9f028e2ea623a757f5 commit ce90f99a2d66c2b998ad3f9f028e2ea623a757f5 Author: Luboš Luňák <l.lunak@suse.cz> AuthorDate: Sun Dec 2 22:35:57 2012 +0100 Commit: Luboš Luňák <l.lunak@suse.cz> CommitDate: Mon Dec 3 18:04:24 2012 +0100 fixes for where fast string operator+ is not perfectly source compatible Change-Id: I80af0399037e4f68113338139e7f2ad2400e65ab :100644 100644 d6a3e35f1dc57a7469408bdb1aaa587ba6cf3cfe b4973c1d86cfd5c0d550e84e7e483802d979829e M ccache.log :100644 100644 a2d3790ddaa245f4d56968133ce5be440af2c033 a0e5b02e554537a0bed70a3203ca3995bb6972bd M commitmsg :100644 100644 3fad2a60908b6b6bc1de0af560f7239a89b54e73 6ba1538977f3fb5b8f0ee54bbd04be28afdd85e3 M dev-install.log :100644 100644 2df1def8f8a08f16f92540ae4eab28de4984a88f dc4842a6e74513bbe562bb0d78a1ed545ead53e7 M make.log :040000 040000 0dc3db85f8784d986d2364a0972044d502c2a5e3 e70233c1668fc1da017a420ac2ed5ee366e253ad M opt # bad: [423a84c4f7068853974887d98442bc2a2d0cc91b] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e # good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932 git bisect start 'latest' 'oldest' # bad: [e02439a3d6297a1f5334fa558ddec5ef4212c574] source-hash-6b8393474974d2af7a2cb3c47b3d5c081b550bdb git bisect bad e02439a3d6297a1f5334fa558ddec5ef4212c574 # good: [8f4aeaad2f65d656328a451154142bb82efa4327] source-hash-1885266f274575327cdeee9852945a3e91f32f15 git bisect good 8f4aeaad2f65d656328a451154142bb82efa4327 # bad: [9995fae0d8a24ce31bcb5e9cd0459b69cfbf7a02] source-hash-8600bc24bbc9029e92bea6102bff2921bc10b33e git bisect bad 9995fae0d8a24ce31bcb5e9cd0459b69cfbf7a02 # good: [51b63dca7427db64929ae1885d7cf1cc7eb0ba28] source-hash-806d18ae7b8c241fe90e49d3d370306769c50a10 git bisect good 51b63dca7427db64929ae1885d7cf1cc7eb0ba28 # bad: [d65a58c31c8da044ef66ae4517fa2fe74cec0019] source-hash-2e053cf5ea4d93a2e1845e795a9c7fe1e08c84af git bisect bad d65a58c31c8da044ef66ae4517fa2fe74cec0019 # good: [79e02001f27d33b3b478324ab6fba5683413b4d9] source-hash-b6c016da23d309b4ac7d154bc33a22397974ed73 git bisect good 79e02001f27d33b3b478324ab6fba5683413b4d9 # good: [1e04c3b7ef40994ada3236fa8f90fbd1cdcea47e] source-hash-11e776023c89b3de690b37ffaed18ec996b9c207 git bisect good 1e04c3b7ef40994ada3236fa8f90fbd1cdcea47e # good: [c3482ad95176ec6762ef03e95d3287ebd5e84905] source-hash-3d4288c1c0b593421c7f6619c88584bdb7c53337 git bisect good c3482ad95176ec6762ef03e95d3287ebd5e84905 # bad: [2e0fa432485d1db6abd355dad8ccb06f0b97e4fb] source-hash-ce90f99a2d66c2b998ad3f9f028e2ea623a757f5 git bisect bad 2e0fa432485d1db6abd355dad8ccb06f0b97e4fb # good: [16817aeb240d8066676540c467a7e4aac00ed008] source-hash-4026e1824de8ff9b5d006ae6eba491f91bc4e599 git bisect good 16817aeb240d8066676540c467a7e4aac00ed008 # first bad commit: [2e0fa432485d1db6abd355dad8ccb06f0b97e4fb] source-hash-ce90f99a2d66c2b998ad3f9f028e2ea623a757f5
Whiteboard: Remove 'needQAAdvice' once bug is NEW/RESOLVED.
The behaviour seems to have changed as of the below commit. Adding Cc: to cedric.bosdonnat.ooo@free.fr. It sounds from the commit message like there is a larger context to this commit, but perhaps you might have some idea about what caused this behaviour change? Thanks commit d9ef61fb546af443736057557552e3a95c569c11 Author: Cédric Bosdonnat <cedric.bosdonnat@free.fr> Date: Mon Dec 3 17:48:40 2012 +0100 API CHANGE: roll back the XStyle changes to add a new Hidden property on Style Change-Id: If6d23925567fb184cd8fc4e00fc72fe4d216e756
This issue is still present in Version: 5.1.0.0.alpha1+ Build ID: e6fade1ce133039d28369751b77ac8faff6e40cb TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2015-11-16_00:12:42 Locale: es-ES (es_ES) on Window 7
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]
** 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.1.6 or 5.2.3 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-20170103
This issue is still present in Version: 5.2.3.3 Build ID: d54a8868f08a7b39642414cf2c8ef2f228f780cf CPU Threads: 8; OS Version: Windows 6.1; UI Render: default; Locale: en-AU (en_AU); Calc: group on Windows 7
** 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 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
Still reproducible that LibreOffice opens the file with character style 'Numbering style' despite that character style 'None' was selected and the file was saved and reloaded. Version: 6.3.0.4 Build ID: 057fc023c990d676a43019934386b85b21a9ee99 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: de-AT (de_AT.UTF-8); UI-Language: en-US
It is a problem in file open. When set to "none" and then saved, there exists no attribute "text:style-name" in element <text:list-level-style-numeric>. That is correct. But after opening the style "Numbering Symbol" is used. Problem still exists in Version: 7.1.0.0.alpha0+ (x64) Build ID: 1e0cfd5662d95cea84e80e4fe10d52c3b1101ae6 CPU threads: 8; OS: Windows 10.0 Build 18362; UI render: Skia/Vulkan; VCL: win Locale: de-DE (en_US); UI: en-US Calc: CL
It seems to be "fixed" for me since LO 6.1 (which conflicts with comment 13) with commit 74c527abc0f3b5aa0fa179401ad05a79dc889973 Author: Yousuf Philips on Tue Dec 5 13:54:29 2017 +0400 tdf#106988 New names for the new numbering styles Steps I am taking: 1.) Open the file. (Notice that the number 1 is a normal size.) 2.) Format -> Bullets and Numbering shows char style "Numbering Symbols" but with the above commit is is "None" (and still true after round-tripping). Well, that commit doesn't SOUND like it should really fix the problem, so what are the steps to reproduce still?
The problem still exists. Tested with Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 4ac9032163cf55c160145373e7c41741c9c339ca CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win Locale: de-DE (en_US); UI: en-US Calc: CL Steps to reproduce. 1. Write some lines and apply list style "Numbering 123". 2. Change character style "Numbering Symbols" to use a larger font size or to use a color in the font effects. The numbers will change accordingly. 3. Go to style "Numbering 123" and set the character style to "None". The numbers are now shown same as the rest of the text in the list item. 4. Save the document. 5. Open the document. The numbers are again as specified in "Numbering Symbols". Go to list style "Numbering 123" and look at character style. You see "Numbering Symbols" and not "None". Look at "Organizer" tab. It (correctly) does not contain a character style. Look at it with the new "Development Tools", find "CharStyleName" in "Numbering Rules". After opening from file it has "Numbering Symbol". After setting "None" it has an empty string. It should be an empty string too after loading the file. Saving is correct, the <text:list-level-style-number> element has not attribute text:style-name.
(In reply to Justin L from comment #15) > It seems to be "fixed" for me since LO 6.1 (which conflicts with comment 13) The example document in comment 0 is based on "Numbering 1" which is no longer a built-in name for a list style. So that specific document is working as desired now. But if the name matches one of the new pre-defined names, then the existing character style is retained. Proposed fix at https://gerrit.libreoffice.org/c/core/+/134888
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/758945b077220fe151c1565c6d5b0bad02de6d58 tdf#75297 sw uno: override default num char style when NONE 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.
no desire to backport this. I left it alone until 7.5 branch off.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/c24fe44064c6624fefe642508086c8562c372fba tdf#149547 fix "tdf#75297 sw uno: override default num char style" 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.