The preview position tab is not as expected. Here is what i would expect the preview to be/do. The preview shows the heading and the text following it in the preview window. The preview is for the Heading level selected on the left side pane. If i select 1 it should show me what the heading/following text for level 1 headings look like. If i select 2 then for 2. If i select 1-10 then all of them together.on beĺow the other. What is observed is something else.
Steps to Reproduce:
In the position Tab, for level 1 heading change "Numbering followed by" to "Space". A small space is shown in the preview before the Horizontal line
Click on level 2 - Nothing changes in the preview
Click on level 3 - The small space in the preview disappears.
Now give numbering to the levels in the "Numbering" Tab and try the same.
When level 10 is selected something completely different happens and some lines disappear.
I don#t know what the expected behavior should be Can someone shed light on it.
User Profile Reset: Yes
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0
I confirm it.
Steps to reproduce:
1. Open a document with chapter numbering
2. Tools => Chapter Numbering => Position
3. Change position for level 1 to "Numbering followed by tab stop" and "Tab position 2 cm"
4. Do the same for level 2 and 3
If you now select level 1 or 1-10, tab stop positions of level 1 to 3 are shown correctly
If you select level 3, tab stop position of level 3 isn't shown.
If you select level 4, tab top position of level 2 and level 3 isn't shown.
If you select level 5 and higher, no tab stop position is shown.
Tab stop positions should always shown correctly in the preview, when they are defined.
Same result with "Numbering followed by space"
if you select level 10, previews disappears
Version: 220.127.116.11.beta1 (x64)
Build ID: 8c76dfe1284e211954c30f219b3a38dcdd82f8a0
CPU threads: 4; OS: Windows 10.0; UI render: GL;
Locale: de-DE (de_DE); Calc: CL
The "Level" list selects what you can tweak on the middle column under "Numbering". And the preview shows all together, which is correct IMHO, since you want to know how the levels relate to each other. Thing is that this dialog has the same UI/workflow as other numbering dialogs and thereby the shortcomings noted in https://design.blog.documentfoundation.org/2017/10/28/impress-lists/
This ticket has likely a duplicate.
Created attachment 142312 [details]
Created attachment 142313 [details]
Created attachment 142314 [details]
@Heiko, The preview I was referring to are the ones in Attachment_1 and Attachment_2, What you were referring to is the one in Attachment_3. It makes sense in Preview of in Attachment_3 to see all levels relative to one another. But in the Attachment 1 and 2, I would expect see only the Selected Level and not all levels.
It can be made to show a preview how the selected level with multiple lines and following text would look like in Attachment_4. What are your opinions.
My argument here is that, relative positional relationship between different Headings is available in the Numbering Tab. So in the Position tab we can show only the required level, with more detailed information.
Created attachment 142316 [details]
Created attachment 142317 [details]
Screenshot of results (see comment 1)
In addition to comment 1 this attachment shows screenshots of the results I described in comment 1.
(In reply to Nithin from comment #6)
> @Heiko, The preview I was referring to are the ones in Attachment_1 and
> Attachment_2, What you were referring to is the one in Attachment_3....
True, that preview is weird. Hope we can fix that.
The behaviour described in comment 1 is also reproducible in
Build ID: 3ca42d8d51174010d5e8a32b96e9b4c0b3730a53
Threads 4; Ver: 4.10; Render: default;
but not in
Build ID: 0db96caf0fcce09b87621c11b584a6d81cc7df86
Locale: ca-ES (ca_ES.UTF-8)
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!
Still repro in
Version: 18.104.22.168.beta1 (x64)
Build ID: a187af327633f5f00363be5131bd21a13e0f1a7b
CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win;
Locale: en-US (de_DE); UI-Language: en-GB
With further testing I could specify the behaviour:
1. change Tab stop of a level, press O.K. and reopen => everything looks fine
2. change to another level and back => preview of that level not correct, but it is correct for all previous levels
I added keywords possibleRegression and bibisectrequest because of comment 10
It may well be that the users having problems do not have the correct permissions set on their systems, due to other software https://chateasy.me/chatrandom/ installations, or tinkering. These permissions can be reset using the disk utility in the Applications/Utilities folder https://bigbucket.co/nordvpn/.
I don't see this as a regression and remove bibisectRequest. Ok to add but after test not based upon someone's comment.
If Numbering is changed to add numbers, than it's visible that in Position every other line is wrong, it's too long previous line.
This is not minor but confusing, so I set Normal.