| Summary: | FORMATTING: Number Styles, character style of "None" is ignored | ||
|---|---|---|---|
| Product: | LibreOffice | Reporter: | Dale <dale2> |
| Component: | Writer | Assignee: | Not Assigned <libreoffice-bugs> |
| Status: | NEW --- | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | CC: | anistenis, cedric.bosdonnat.ooo, fdbugs, gautier.sophie, jmadero.dev, philipz85, qubit, todventtu |
| Version: | 4.0.6.2 release | Keywords: | bisected, regression |
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | bibisected | ||
| i915 platform: | i915 features: | ||
| Attachments: | Example document | ||
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 |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
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.