Description: 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. Actual Results: When level 10 is selected something completely different happens and some lines disappear. Expected Results: I don#t know what the expected behavior should be Can someone shed light on it. Reproducible: Always User Profile Reset: Yes Additional Info: 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 Result: 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. Expected result: Tab stop positions should always shown correctly in the preview, when they are defined. Additional informations: Same result with "Numbering followed by space" if you select level 10, previews disappears Version: 6.1.0.0.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] Attachment_1
Created attachment 142313 [details] Attachment_2
Created attachment 142314 [details] Attachment_3
@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] Attachment_4
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 Version: 5.2.0.0.alpha0+ Build ID: 3ca42d8d51174010d5e8a32b96e9b4c0b3730a53 Threads 4; Ver: 4.10; Render: default; but not in Version: 5.0.0.0.alpha1+ Build ID: 0db96caf0fcce09b87621c11b584a6d81cc7df86 Locale: ca-ES (ca_ES.UTF-8)
Dear Nithin, 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 repro in Version: 6.3.0.0.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 Calc: threaded 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.
Dear Nithin, 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 https://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://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Still present in Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: d7c609dbb1bd08865b43719d2fb7c316d30bcde5 CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: en-US (de_DE); UI: en-GB Calc: CL threaded