Description: The display is missing for a fill character of the first tabulator position in a paragraph where a hanging indent was selected. Steps to Reproduce: 1. Enter the letter “A” in an empty paragraph. 2. Add a tab character. 3. Enter the letter “B”. 4. Specify a line break (shift + enter key) for this paragraph. 5. Enter the letter “C”. 6. Configure a single left aligned tab stop at “2 cm” together with a fill character (dash for example). https://help.libreoffice.org/6.4/en-GB/text/shared/01/05030300.html#hd_id3159151 7. Adjust paragraph properties for a hanging indent. https://help.libreoffice.org/6.4/en-GB/text/shared/01/05030100.html#hd_id3149169 Example: Value “2 cm” for “Before text” and a value “-2 cm” for “First line”. Actual Results: Indentation is performed without the display of the selected fill character. Expected Results: A filling should be displayed in the first line for a known tabulator position in this paragraph. Reproducible: Always User Profile Reset: No OpenGL enabled: Yes Additional Info: Version: 6.3.3.2.0+ Build-ID: 30(Build:2) CPU-Threads: 4; BS: Linux 5.1; UI-Render: Standard; VCL: gtk3 See also information from the clarification request on the topic “FORMATTING: Paragraph initial tab stop cannot be filled in hanging-indented paragraphs”. https://bugs.documentfoundation.org/show_bug.cgi?id=46061
I confirm it with Version: 6.5.0.0.alpha0+ (x64) Build ID: 89f0af144c18efafe2573801641689a1432c0cae CPU threads: 4; OS: Windows 10.0 Build 18362; UI render: GL; VCL: win; Locale: de-DE (de_DE); UI-Language: en-GB Calc: threaded Problem is, that first tab stop is now at 4cm. So I think it's not really a bug, but more a reasonable enhancement request. Solution could be to add a fill character seting to Indents & Spacing tab of th paragraph dialog. I changed bug title. cc: Design-Team for further input or different opinion
Regina, what do you think? Besides, it would be good to have a test document attached.
Created attachment 156429 [details] simple document A very simple document. Just add a first line indent and see what happens.
Heiko, you changed status from NEW to NEEDINFO. What info do you need?
(In reply to Dieter Praas from comment #4) > Heiko, you changed status from NEW to NEEDINFO. What info do you need? Waiting for input from Regina.
Dear Markus Elfring, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
Dear Markus Elfring, Please read this message in its entirety before proceeding. Your bug report is being closed as INSUFFICIENTDATA due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of our bug tracker Warm Regards, QA Team MassPing-NeedInfo-FollowUp
(In reply to Heiko Tietze from comment #5) Will this issue get any more helpful input from other contributors?
(In reply to Heiko Tietze from comment #2) > Regina, what do you think? > > Besides, it would be good to have a test document attached. An hanging indent is not a tab. I have never seen fill characters and those would be in contrast to the use case of hanging indent. A hanging indent is used if "register true" is ON and therefore there is no increased space between paragraphs. The hanging indent in that case helps finding the paragraph start. If someone wants such unorthodox formatting, he can use a paragraph without hanging indent and a tab. So I'm against such "feature".
(In reply to Regina Henschel from comment #9) > An hanging indent is not a tab. Is a tab used so far to jump to the selected indentation? > I have never seen fill characters Would you like to explain such an information a bit more? > and those would be in contrast to the use case of hanging indent. I wonder about such a view. > So I'm against such "feature". Are any more factors to consider for this rejection?
(In reply to Markus Elfring from comment #10) Please excuse, I have overlooked that you want a _hanging_ indent, my remarks are for first line indent. > (In reply to Regina Henschel from comment #9) > > An hanging indent is not a tab. > > Is a tab used so far to jump to the selected indentation? You mean the indent of the second line by "selected indentation"? This is indeed treated as tab stop and a tab inserted left from it will jump to it. This tab stop at indentation has position 0. Tab stops with position 0 are not listed in the tab stops of the paragraph style and if you try to add such tab stop there, it will be automatically removed. In turn you cannot style such tab. An additional problem is, that the handling of hanging indents is interwoven with the handling of bullet and numbered lists. Hanging indents are used for definition lists or play scripts for example. There too I have not seen such fill characters. So the question is, what is the use case of such fill character? Workaround for your wish: Set a tab stop at -0.01mm and style it with a fill character. Your request is valid, but implementing it, is risky.
(In reply to Regina Henschel from comment #11) > (In reply to Markus Elfring from comment #10) > Please excuse, I have overlooked that you want a _hanging_ indent, > my remarks are for first line indent. I hope that confusion because of such information can be reduced further for the clarification of desirable software behaviour. > You mean the indent of the second line by "selected indentation"? Yes. - You would like to achieve an alignment with subsequent lines after a bit of text at the beginning of such a paragraph, wouldn't you? > This is indeed treated as tab stop and a tab inserted left from it will jump to it. Thanks for such an acknowledgement. > This tab stop at indentation has position 0. Tab stops with position 0 are > not listed in the tab stops of the paragraph style and if you try to add > such tab stop there, it will be automatically removed. In turn you cannot > style such tab. I find this information questionable. > An additional problem is, that the handling of hanging indents is interwoven > with the handling of bullet and numbered lists. I would like to achieve further improvements for this use case. > Hanging indents are used for definition lists or play scripts for example. > There too I have not seen such fill characters. You might not use fill characters for tabs so often. > So the question is, what is the use case of such fill character? But they belong to usual functionality, don't they? > Your request is valid, Thanks for such a view. Would you like to adjust the bug status accordingly? > but implementing it, is risky. I agree that corresponding software developments can become challenging.
(In reply to Regina Henschel from comment #11) > So the question is, what is the use case of such fill character? Could you please reply to this question. Ideally with a reference for a formatting standard but it's also fine if you explain how it has to look for you. And a really good use case is the round-trip with alternative programs such as but not necessarily Microsoft Office. As always: examples whether as picture or document are of great support. As Regina said, implementation is risky (and the workaround is easy to do). We need to make sure that a change is of value for the majority of users.
(In reply to Heiko Tietze from comment #13) I propose to support the application of fill characters in a consistent way for tabs. See also: https://help.libreoffice.org/7.0/en-GB/text/shared/01/05030300.html#hd_id3159151 Do you miss any background information still from the published software documentation?
Do you understand the use case better together with terms like “tab leader” and “leader character”?
We discussed the request in the design meeting and cannot follow your reasoning. The use case is unclear, hanging indent is (to me) per se white space and consistency to tabs rather inconsistency against indentation and spacing. So the suggestion is to resolve WF.
(In reply to Heiko Tietze from comment #16) > We discussed the request in the design meeting and cannot follow your reasoning. I hope that the mentioned understanding difficulties can be resolved better. > The use case is unclear, I propose to recheck available information. > hanging indent is (to me) per se white space This can be in some cases. > and consistency to tabs rather inconsistency against indentation and spacing. Are your application imaginations too limited here?
(In reply to Heiko Tietze from comment #16) > So the suggestion is to resolve WF. heiko, do you find any new arguments or aspects in comment 17? If not, I agree to close this bug as WF.
Markus reopened the WF'ed ticket and I will not close again in this case.
No further input from any person for more than two years. So I agree with Heiko and Regina and close it as WF