Created attachment 125657 [details] A song file that I was trying to format This concerns formatting - specifically changing indents of a paragraph. STEPS 1. Open the attached file. 2. Hit F11 to display Style Formatting window. 3. Place cursor at the start of the first Chord paragraph. 4. You should notice Style SS1b_Chords is highlighted in the Styles list. 5. Whilst observing the Outline level at the bottom of the page, Click the Increase Indent button. EXPECTED RESULT 1. Indent increases. 2. Outline level remains the same. 3. Highlighted style remains the same. ACTUAL RESULT 1. Indent does not increase. 2. OUtline level changes. 3. Style changes at each successive press of the Increase Indent button. Similarly pressing the decrease indent button changes the outline level and the highlighted style. Very strange behavior. I was trying to format a song that I had created in an earlier version of Microsoft Word.
Hi Colin, Thanks for filing and the explanation. (In reply to Colin from comment #0) > EXPECTED RESULT > 1. Indent increases. > 2. Outline level remains the same. > 3. Highlighted style remains the same. I do get exactly this result. Using a recent daily build, Version: 5.3.0.0.alpha0+ Build ID: 3ab13873ebb6dc4738be2e2184ee4433a2447c1d CPU Threads: 2; OS Version: Linux 4.4; UI Render: default; TinderBox: Linux-rpm_deb-x86@71-TDF, Branch:master, Time: 2016-06-16_01:48:26 Locale: nl-NL (nl_NL.UTF-8) and in Versie: 5.1.4.2 Build ID: f99d75f39f1c57ebdd7ffc5f42867c12031db97a CPU Threads: 2; Versie besturingssysteem:Linux 4.4; UI Render: standaard; Locale: nl-NL (nl_NL.UTF-8) So sorry, no idea where your problem comes from. Regards, Cor
I reported the problem against 5.0.3.2 - isn't it important to test against that specific build ? Presumably you use the file provided ? Could it possibly be template related - I.E. Could we be using different templates?
(In reply to Colin from comment #2) > I reported the problem against 5.0.3.2 - isn't it important to test against > that specific build ? It is important to test with newer builds to check if the issue is already resolved (in that case, the solution would be simply to update your LibreOffice). We release new bug-fix versions each month, and encourage users to use always the latest version. Bugzilla’s “Version” field is only meant to indicate the earliest version where an issue can be reproduced.
My result: nothing happens. Arch Linux 64-bit, KDE Plasma 5 Version: 5.3.0.0.alpha0+ Build ID: c13f60e7cd18df6b0ab70289f5b91ee01e4ae126 CPU Threads: 8; OS Version: Linux 4.6; UI Render: default; Locale: fi-FI (fi_FI.UTF-8) Built on June 18th 2016
I'm sorry to say, but what you say is incorrect. First of all you need to establish that you can reproduce the fault in the exact same release that it was reported against. Once you have established that you can reproduce the fault, you can then go on to test whether it still exists in a newer release of the product. If the fault still exists, then a new fix will need to be applied and the fault retested to see whether the fix worked. If you fail to follow these steps, then rather than proving that the fault is fixed, you will have merely proven that you were unable to reproduce it. There are many faults that cannot be reproduced, and you simply cannot assume that the problem is fixed simply because you cannot reproduce it, especially when you are attempting to reproduce it against the wrong release.
(In reply to Colin from comment #5) > Once you have established that you can reproduce the fault, you can then go > on to test whether it still exists in a newer release of the product. Is there a reason you cannot test it in a newer release? 5.0.x is EOL already so will not receive updates: https://wiki.documentfoundation.org/ReleasePlan/5.0#End_of_Life
I have several fault reports to write about various problems I have been having with Linux apps, and they take precedence over my resorting to updating my apps simply because developers aren't testing the reported problems against the correct release. I don't have the time to do your testing for you I'm afraid - I've only recently moved to Linux, and have come across so many problems along the way, that I've become a slave to my computer, when really it should be the other way around. Prior to that I had several days of Windows problems and re-installs which is what motivated me to try Linux for a 2nd time (the first time I gave up because there was no support for my Dell printers - sadly there still isn't support for them). I realise that's Dell's fault, but the Linux community really needs to tackle these problems if it ever wants to provide a viable alternative to Microsoft and be truly "Plug & Play".
(In reply to Colin from comment #7) > I have several fault reports to write about various problems I have been > having with Linux apps, and they take precedence over my resorting to > updating my apps simply because developers aren't testing the reported > problems against the correct release. I don't have the time to do your > testing for you I'm afraid - I've only recently moved to Linux, and have We are not developers, but users who are helping developers for free. So you really have to do *your* testing for you. There is only so much testing *we* can do without flying over to your apartment. Now I tested on Windows with 5.0.2.2 and same result: absolutely nothing happens anywhere.
Thanks all for testing and the input. Since the reported problem cannot be reproduced, there is something else going on.. There is a lot of (IMHO) weird use of spaces in the file. Should have nothing to do with the problem. But maybe there are other user habits that we cannot see that causes ..? For now it's best to close as WorksForMe. @Colin: if you have a new case, preferably against a recent LibreOffice version, can you then please provide that and reopen. Or make a new bug if is appropriate? Thanks, Mind there is community support to find your way in functions and behaviour that maybe look odd at a first sight ;) Cheers - Cor
I can reproduce the behavior, but I think, that it is no bug, but belongs to the desired behavior in case of paragraph styles having an explicit "Outline level" set. @Colin: Is there any reason why you have set "outline level" to your paragraph styles? In content it would mean, that you are creating chapter heading styles for to create your own chapter numbering. There exists only very few exceptions, when this feature is needed. Set in _all_ your paragraph styles the field "outline level" to "body text". For those paragraph styles, which are designed to be a chapter heading (e.g. song title) set the level in Tools > Outline Numbering.
(In reply to Regina Henschel from comment #10) > I can reproduce the behavior, but I think, that it is no bug, but belongs to > the desired behavior in case of paragraph styles having an explicit "Outline > level" set. Of course I looked at this settings too. But then what makes that you can reproduce it and I can't :) ? FYI: I tried with both cursor at start of the line/text and in front of the numbering.
Not the line with the number, but the line above it; that with style "SS1b_Chords", see original post.
Ah, thanks :0 Just normal behaviour then, as you explained.
It's good to hear that you have reproduced the problem. I definitely would not call it normal behavior. Why should pressing indent cause the highlighted style to flit randomly between styles just because I'm clicking on indent ?! I understand what Outline levels are for, and indeed have used them to create handy guides for infrequently used unix commands, who's detail can be revealed by changing the outline level. I have fiddled with that functionality in Libre Office, and there is a specific icon for changing outline levels. However I look at it, I can't see why on Earth pressing indent would change the highlighted style in "Styles & Formatting" window. The reason why there is so much white space in the file provided, is because I don't want the spacing between chords to change, which it would do if tabs were used, because tabs can be configured to represent any number of spaces. The same applies to gaps between words. The chords and the words have to align accurately every time, and mono font and use of spaces is the only way to guarantee that they stay aligned.
@Colin: You are right, reason is not the outline level; although that is wrong too. But the paragraph has an additional numbering set. If you right-click the paragraph and then item "Bullets&Numbering", you will see, that the "Remove" button is active. When you click that button the (hidden) numbering is removed and indent will work as expected. There might be indeed some problems when numbering and outline are mixed. I see the similar bug 93495. The normal behavior is that indent of list styles prevail over those from paragraph. [To keep chord and word together you can (miss-)use the feature "Write in double lines" from the "Asian Layout" tab of a character style.]
Thanks for your comment. I was not aware of any hidden numbering / outline added to the file. Users are not aware of any order or precedence between outline numbering etc - behaviour like I experienced just makes the user think that the application has gone completely haywire. Thanks for the idea,but using space characters to separate chords works great for me, and because I have found tabs more trouble than they are worth in the past, I will continue to use spaces to separate chords.