Created attachment 148519 [details] Document example with a single bullet point (while using a questionable tab stop) I have tried the software “LibreOffice Writer 6.1.4.2-763.1” (Build-ID: 10(Build:2)) out again. Text layout is supported also for enumerations. https://en.wikipedia.org/wiki/Bullet_(typography) One user interface is offered which is working with a tab character and a negative distance value for the first line of a paragraph. https://help.libreoffice.org/6.1/en-GB/text/swriter/guide/using_numbered_lists.html It can happen then that the default first tabulator position will not fit to the selected paragraph border. (I got used to the layout style where subsequent text will be aligned besides a bullet point.) I imagine that a jump to the desired position would be needed by an other tab character. Another software design possibility would be to manage the relationship between an enumeration symbol and the corresponding content without the addition of tabs. https://www.w3.org/TR/CSS21/generate.html#propdef-list-style-type
Markus, thank you for reporting the bug. But at least for me the problem is not really clear. Regarding to your example document: Could you please describe the actual result, the desired result and concrete steps to reproduce it. I'm not sure, if this is really a bug or a question of how to use LO in a specific situation. Therefor it could be useful to ask a question in https://ask.libreoffice.org/de/questions/ I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the steps are provided
(In reply to Dieter Praas from comment #1) How often do you fiddle with the alignment of bullet points and enumeration text?
(In reply to Markus Elfring from comment #2) > How often do you fiddle with the alignment of bullet points and enumeration > text? I often use lists, but I create my own list styles and so it's very easy. But I'm afraid, your comment was not really an answer to my previous comment.
(In reply to Dieter Praas from comment #3) Are you aware of configuration challenges for keeping bullet point sizes and tabulator positions synchronised (at varying indentation levels)?
(In reply to Markus Elfring from comment #4) > Are you aware of configuration challenges for keeping bullet point sizes and > tabulator positions synchronised (at varying indentation levels)? Yes. But I still want to come back to your bug report. The first step is to reproduce the bug. I can't because the report is not clear to me (perhaps for somebody else it is). I want to help with bug confirming, but - to be honest - I don't want to discuss about my experiences with a certain topic.
(In reply to Dieter Praas from comment #5) Can any software improvements be achieved around the provided information “It can happen then that the default first tabulator position will not fit to the selected paragraph border.”? Do you like the specification style for enumerations in XHTML documents?
Markus: I see you have a style of answering questions with mystical questions of your own. Please stop doing this and simply respond in a clear manner to Dieter's comment 1.
(In reply to Buovjaga from comment #7) I suggest to take another look at paragraph borders and the specification of tabulator positions. Do you understand what the attached document example tries to demonstrate then?
(In reply to Markus Elfring from comment #8) > (In reply to Buovjaga from comment #7) > > I suggest to take another look at paragraph borders and the specification of > tabulator positions. > Do you understand what the attached document example tries to demonstrate > then? Stop evading and just answer the questions in comment 1
(In reply to Buovjaga from comment #9) The attached document example demonstrates a questionable layout situation already, doesn't it?
(In reply to Markus Elfring from comment #10) > (In reply to Buovjaga from comment #9) > > The attached document example demonstrates a questionable layout situation > already, doesn't it? Maybe, but that's not the point. Please answer the questions Dieter raised: (In reply to Dieter Praas from comment #1) > But at least for me the problem is > not really clear. Regarding to your example document: Could you please > describe the actual result, the desired result and concrete steps to > reproduce it.
(In reply to Buovjaga from comment #11) The attached document example is relevant also for a better common understanding of the involved configuration challenges, isn't it?
Ok, as no answers will be forthcoming we can just as well close this
(In reply to Buovjaga from comment #13) How many details do you understand from the attached document example so far?
(In reply to Markus Elfring from comment #14) > (In reply to Buovjaga from comment #13) > > How many details do you understand from the attached document example so far? Your question is entirely irrelevant. Do you understand this: https://wiki.documentfoundation.org/QA/BugReport#Examples_of_Less_Good_Reports "Do not assume contributors know what you’re talking about. Describe your steps clearly, each step of the way." This advice also applies to feature requests. If you refuse to articulate what you want, your reports will go nowhere.
(In reply to Buovjaga from comment #15) > Your question is entirely irrelevant. I disagree in this case. I offered a working document example in the hope that it will help for this clarification attempt. Can it be omitted then to repeat the creation steps for this file? Would you ever like to compare the selected paragraph border with the default first tabulator position? https://help.libreoffice.org/6.3/en-GB/text/swriter/guide/using_numbered_lists.html
(In reply to Markus Elfring from comment #16) > (In reply to Buovjaga from comment #15) > > Your question is entirely irrelevant. > > I disagree in this case. > > I offered a working document example in the hope that it will help for this > clarification attempt. > Can it be omitted then to repeat the creation steps for this file? > > Would you ever like to compare the selected paragraph border with the > default first tabulator position? > > https://help.libreoffice.org/6.3/en-GB/text/swriter/guide/ > using_numbered_lists.html The document is a good start, but we still need 1. creation steps 2. description of how the result is bad (when and how things go wrong) 3. description of what would be the desired behaviour You are obligated to provide this information. The quality assurance team is not here to reverse-engineer complete reports from incomplete ones.
(In reply to Buovjaga from comment #17) > The document is a good start, Interesting … > but we still need > 1. creation steps I disagree to this information. Is the construction of bullet lists documented in sufficient ways? > 2. description of how the result is bad (when and how things go wrong) How long will it take until an other developer or software tester will look at the display results for the shown example once more? > 3. description of what would be the desired behaviour It is desirable that content is aligned behind bullets, isn't it? The expectations can vary then for corresponding configuration convenience.
Xisco: we have 18 comments here of back and forth, with the reporter refusing to provide information required to deal with his report. Can you be the third QA team member to ask him for the same information? Maybe he will believe us then. If not, we have to arrange for twenty other QA & dev people to ask the same, I guess.
(In reply to Buovjaga from comment #19) I am curious if a more promising feedback (by other contributors) will indicate a better understanding of the available facts.
(In reply to Buovjaga from comment #17) > The document is a good start, but we still need > 1. creation steps > 2. description of how the result is bad (when and how things go wrong) > 3. description of what would be the desired behaviour > > You are obligated to provide this information. The quality assurance team is > not here to reverse-engineer complete reports from incomplete ones. => NEEDINFO
(In reply to Dieter Praas from comment #21) > > You are obligated to provide this information. I would expect that you know already how the construction of bullet lists is working so far. https://help.libreoffice.org/6.4/en-GB/text/swriter/guide/using_numbered_lists.html * How do you achieve that bullets (or generated numbers) will always be properly aligned for these listings? * Do you understand the attached document example?
(In reply to Markus Elfring from comment #22) > * How do you achieve that bullets (or generated numbers) will always be > properly aligned for these listings? I use list styles. Please have a look at documentation [1] or [2]. Does this solve your problem? => NEEDINFO [1] https://wiki.documentfoundation.org/images/5/5f/WG6012-Lists.odt [2] https://wiki.documentfoundation.org/images/d/d9/WG6012-Listen.odt (German)
(In reply to Dieter Praas from comment #23) > I use list styles. They can be nice. > Does this solve your problem? I guess that the answer will depend also on corresponding software extensions. Would you like to look at the attached document example (and the initial description for this clarification request) at all?
(In reply to Markus Elfring from comment #24) > I guess that the answer will depend also on corresponding software > extensions. I don't understand. > Would you like to look at the attached document example (and the initial > description for this clarification request) at all? No document attached. Please consider that I'm a volunteer. Please reade the documentation and use ask.libreoffice for further help. If you think, there is a bug, please provide detailed step by step how to reproduce it. => Again NEEDINFO, because at the moment I don't see really a bug description.
(In reply to Dieter Praas from comment #25) > No document attached. What is this? https://bugs.documentfoundation.org/attachment.cgi?id=148519 > Please consider that I'm a volunteer. I'm such a contributor too. Can the mentioned technical details and corresponding open issues still be clarified then?
The predefined list styles work fine for most situations. If you have special needs (e.g. different first line indent, larger bullets, high numbers, paragraph borders) you can easily modify the list style or define your own list style. If you need help in doing this, please use our support channels. I know, that in special situations the predefined tab stop position does not fit to the predefined indent. Therefore these settings are not fix, but can be configured by the user. LibreOffice has got a new set of predefined list styles. Please try a current version of LibreOffice. Perhaps one of those styles will work better for you. Besides that, I always recommend not to use the anonymous list styles of the toolbar, but the named ones from the 'Styles' deck of the sidebar.
(In reply to Regina Henschel from comment #27) > I know, that in special situations the predefined tab stop position does not > fit to the predefined indent. Therefore these settings are not fix, but can > be configured by the user. I find your feedback more constructive. > LibreOffice has got a new set of predefined list styles. But I got the impression that the list style selection can distract more from the configuration challenges which I dared to point out initially. Would you like to check alignment issues once more?
(In reply to Markus Elfring from comment #28) > Would you like to check alignment issues once more? For this, we need the steps for how you created attachment 148519 [details]. It is strange that while avoiding enumerating the steps, you have written many times more the amount of text that it would have taken you to write those steps in the first place.
(In reply to Buovjaga from comment #29) > For this, we need the steps for how you created attachment 148519 [details] I disagree to this view because I find the available software documentation sufficient to some degree for the creation of a very simple test document. > It is strange that while avoiding enumerating the steps, you have written > many times more the amount of text that it would have taken you to write > those steps in the first place. I would like to see indications for a better understanding of information which I presented already.
(In reply to Markus Elfring from comment #30) > (In reply to Buovjaga from comment #29) > > For this, we need the steps for how you created attachment 148519 [details] > > I disagree to this view because I find the available software documentation > sufficient to some degree for the creation of a very simple test document. > > > > It is strange that while avoiding enumerating the steps, you have written > > many times more the amount of text that it would have taken you to write > > those steps in the first place. > > I would like to see indications for a better understanding of information > which I presented already. No, no, no... this is not a competition, where bug analysers try to comprehend how something was created. The rules are same for *everyone*: if you created a document, you must be able to explain how you did it. You can disagree until the end of the world, but you will go nowhere with such attitude. Each time you respond like earlier, you effectively insult the volunteers who want to help you. I find this utterly perplexing.
(In reply to Buovjaga from comment #31) > if you created a document, you must be able to explain how you did it. If I would repeat existing software documentation, I do not need to provide a simple test document for a general use case.
32 comments about the request and refusal of a step-by-step instruction. Must be a record in bugzilla. Congratulations to us all. But since we've now reached this milestone, I'll quit discussion.
(In reply to Dieter Praas from comment #33) Does hinder you anything from taking a more helpful look at the attached test document?
(In reply to Regina Henschel from comment #27) I find another information interesting also from the clarification request on the topic “PARAGRAPH BORDERS: Incorrect alignment in paragraph with first line indented”. https://bugs.documentfoundation.org/show_bug.cgi?id=125804#c7
A new major release of LibreOffice is available since this bug was reported. Could you please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version.
(In reply to Xisco Faulí from comment #36) Are you aware that we did not get informed about noteworthy progress for this issue so far? https://help.libreoffice.org/7.1/en-GB/text/swriter/guide/using_numbered_lists.html
(In reply to Xisco Faulí from comment #36) > A new major release of LibreOffice is available since this bug was reported. > Could you please try to reproduce it with the latest version of LibreOffice > from https://www.libreoffice.org/download/libreoffice-fresh/ ? Comment 37 doesn't answer that question => NEEDINFO
(In reply to Dieter from comment #38) Will any release note point adjustments out for the mentioned software functionality?
[Automated Action] NeedInfo-To-Unconfirmed
The problem in the sample file is an inconsistent configuration between the non-bullet paragraph and the bullet paragraph. Non-bullet paragraph has 1 cm left indent and -1 cm first line indent but this is brought by direct formatting. In bullet paragraph, list style takes over the indents and replaces them with its own. We have both left indent and first line set at 1.27 cm with reference for bullet positioned at 0.64 cm. In the sample file, we see that the bullet is displayed at 0 cm (left margin) and not at 0,64 cm. This discrepancy should ring bells about direct formatting mayhem. Bulleting has probably been done with direct formatting (trough Format>Bullet & Numbering) and been applied to the existing paragraph style (do I guess right?). Then paragraph direct formatting has been applied over the yet current formatting. My usual mind model is to consider the following precedence, from lowest to highest: - paragraph style - character style - direct formatting But it does not include list style. It looks that list style is somewhere below direct formatting. Mike Kaganski corrected me once suggesting that I should refine my model into: - para style - para DF - char style - char DF This new model should include a layer for list DF. I assume that list styles are processed simultaneously with the paragraph style they are attached to, so that list DF is above para style layer. IMHO, I'd blame user for using direct formatting which always messes things up, all the more when we try to make advanced features to contribution.
In Impress, editing a list of numbered text lines to even-up the first word spacing in the numbered lines, and also attempting to insert a tab - seems to cause an Impress crash. I will search for an easier way to accomplish this - Word & ppt allow right-justifying the letters or numbers in the list so they line up. Maybe I will find similar functionality in Impress.
O.K., let's start almost from the beginning (after 4 1/2 years): Markus, please provide steps to reproduce: 1. Open attachment 148519 [details]. It contains a paragraph with a direct formatted list 2. ... ... Actual result: ... Expected result: ... I really don't see the bug here. You can easily customize bug list with Format -> Bullets and Numbering -> Position => NEEDINFO
(In reply to Dieter from comment #43) > 1. Open attachment 148519 [details]. It contains a paragraph with a direct > formatted list How much do you understand my test case description from 2019-01-22? I observe that the software behaviour was changed for the application “LibreOffice Writer 7.6.2.1” (Build-ID: 60(Build:1)) in the meantime. https://help.libreoffice.org/7.6/en-GB/text/swriter/guide/using_numbered_lists.html
(In reply to Markus Elfring from comment #44) > How much do you understand my test case description from 2019-01-22? Yes, perhaps I'm too stupid. So please help me and provide a set of steps. I'm sure, that won't be a problem for you. => NEEDINFO
(In reply to Dieter from comment #45) > (In reply to Markus Elfring from comment #44) > > How much do you understand my test case description from 2019-01-22? > > Yes, perhaps I'm too stupid. So please help me and provide a set of steps. > I'm sure, that won't be a problem for you. > > => NEEDINFO To help, here is documentation about writing good reports: https://wiki.documentfoundation.org/QA/BugReport#Good_Reports
(In reply to Dieter from comment #45) > Yes, perhaps I'm too stupid. This is probably not the case. But we stumbled on recurring communication difficulties. The mentioned document example contains some relevant information. Did we get used to the software behaviour that it was needed to use an extra tab character manually to jump behind a bullet point position? Did we know already that other outline tools could achieve desirable layouts also without this technical detail?