Description: A user reported an issue about thet he can't set bulleting for a paragraph (see attached test document). As it came out pushing bulleting button does not work because the paragraph already have bulleting, but the bullet size is set to 1% and so it's unrecognizable. In MS Office there is a 25% lower limit for bullet size. I would suggest to have a similar limit for LO, to avoid these kind of issues. Steps to Reproduce: 1. Open attached document 2. Check the paragraph with the text "Some text". It has set a bulleting with 1% relative size. Bullet are hard to recognize depending on the zoom. Actual Results: It's allowed to have such a small bullet size, which is invisible or almost invisible. Expected Results: Might be a good idea to have a lower limit for bullet size similar to MS Office. Reproducible: Always User Profile Reset: No Additional Info: User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36
Created attachment 134449 [details] Document with small bullet size
The related settings can be find at Format -> Bullets and Numbering -> Customize -> Relative size (in Impress). Here can we add the limit with not allowing to set too small size.
Sane constraints make always sense and the 25% suggestion sounds good to me. Besides this I don't understand the use case of an option to tweak the size in addition to different characters (large and small bullets). A feature that is restricted to Impress too.
(In reply to Heiko Tietze from comment #3) > Sane constraints make always sense and the 25% suggestion sounds good to me. > Besides this I don't understand the use case of an option to tweak the size > in addition to different characters (large and small bullets). A feature > that is restricted to Impress too. I see this option reasonable. That's true for some bullet characters there are two sizes (small and large), but I guess it's not true for all symbols. If you select a custom symbol (for example an arrow), it is useful that you can specify its size. This Impress-only setting might come from the different usage of text. I mean in Impress there isn't a general text flow, but text is always inside some text box. In text boxes it might be useful to use relative sizes, since in this way if you change the font (for example to fit in the current text box) of the text the bullet size will follow it. This difference is there in MS Office too.
Tamás Zolnai committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=11652be4071ef6d1d89b2c397aa1a32476e03bf6 tdf#108925: Too small bullet size confuses the user It will be available in 6.0.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Looks good for new bullets (the intervals could be in 5%, more precise input only directly). But opening a document with bullet size <25% applies the minimum automatically. I vote for keeping this behavior, consciously taking into account that user documents may change. Those who format with ultra-small bullets (what else could be the reason) should reconsider to use standard methods. Many thanks Tamas!
(In reply to Heiko Tietze from comment #6) > Looks good for new bullets (the intervals could be in 5%, more precise input > only directly). But opening a document with bullet size <25% applies the > minimum automatically. I vote for keeping this behavior, consciously taking > into account that user documents may change. Those who format with > ultra-small bullets (what else could be the reason) should reconsider to use > standard methods. > > Many thanks Tamas! Yes, it's intentional to have this automatical change of small bullets during document import to the new minimum value. It might be problematic to allow smaller values while the constraint is there on the GUI. Also it was the porpose of this change to make visible those bullets which are already there in old documents. I'll add this 5% intervals, you suggested. Thanks!
Tamás Zolnai committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=4e59f0481bdd68edfe95816f22315e1538d1a6ce Related tdf#108925: Use 5% steps for relative size number field It will be available in 6.0.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Tamás Zolnai committed a patch related to this issue. It has been pushed to "libreoffice-5-3": http://cgit.freedesktop.org/libreoffice/core/commit/?id=166d63036b57672a16d50663246c73750ef98ea7&h=libreoffice-5-3 tdf#108925: Too small bullet size confuses the user It will be available in 5.3.5. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
While the input now has 5% steps from 25% to 250% (which is cut on the upper and lower edges, btw) it's not possible to enter precise values like 22%. Or rather these values are not stored. That might affect only a few users but is bad usability as the user input is not respected. Can you change this, Tamás?
(In reply to Heiko Tietze from comment #10) > While the input now has 5% steps from 25% to 250% (which is cut on the upper > and lower edges, btw) it's not possible to enter precise values like 22%. Or > rather these values are not stored. That might affect only a few users but > is bad usability as the user input is not respected. Can you change this, > Tamás? As I see it's allowed to enter precise values like 26%, 27% and so on. The 22% value is not allowed because it's smaller than the minimum value (25%). It's not about the steps, but about the minimum value. I'm not sure what's your problem with this. That was the aim of the code change to not allow setting small values. This is how restriction works, not allowed values are ignored. You can see the same behavior if you type for example a character into this field. When the number field loses the focus it checks whether the typed value is valid and if not it changes back to the previous value or to the minimum value (if the input is a small number).
(In reply to Tamás Zolnai from comment #11) > The 22% value is not allowed because it's smaller than the minimum value... Stupid me! Was lazy and typed the 2 just twice not thinking about the minimum value. Of course it works like a charm. Issue fixed, thank you!
Tamás Zolnai committed a patch related to this issue. It has been pushed to "libreoffice-5-4": http://cgit.freedesktop.org/libreoffice/core/commit/?id=d778119b867b67241b54fd7a9698c839e9bc00f5&h=libreoffice-5-4 tdf#108925: Too small bullet size confuses the user It will be available in 5.4.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.