I suggest to standardize the "automatic" "increment"* (increase and decrease) of boxes allowing to define height, width, top, bottom, left, right... When click on button increase or button decrease, the "increments" can be 1 cm, 0.5 cm, 0.1 cm even 0.01 cm!!! I hope that release 6 adjusts all theses "automatic" "increments" to 0.1 cm. It is very disturbing to click and to obtain a so big variety of values! * I am not sure that "increment" is the good word for "incrément" (in french). Thanks you and excuse me please for my poor english.
Left, right, top, bottom are properties of padding in the paragraph settings dialog with a (proper) increase of 0.1cm for the numerical steppers. Please be more specific on what dialog exactly you think the steppers should change differently.
Created attachment 140304 [details] Not exhaustive analysis of "incréments" supplied by "steppers" Hello! In answer to the last comment, here is a not exhaustive analysis of values of "incréments" supplied by "steppers". I did not explore "Impress Presentation" but I suppose that the same disparities also exist. Thanks for all.
Thanks for the detailed document. Putting back to UNCONFIRMED.
Great overview. Would prefer single tickets for every issue and this could be the meta ticket. But that's up to the QA folks. Issues are easy to solve for beginners, example is https://gerrit.libreoffice.org/#/c/43964/ for bug 67670. We carefully choose 0.5cm there (column gutter) which converts to 0.19685 inches (the actual value depends on Tools > Options > Writer > General). Summarizing, I'm not so sure that harmonizing is the best solution but 0.01cm is definitely bad as well as 1cm.
(In reply to Heiko Tietze from comment #4) > Great overview. Would prefer single tickets for every issue and this could > be the meta ticket. But that's up to the QA folks. Sure. So, Chrisbath: you can create a separate report for each issue and enter 115805 into the "Blocks" field every time. Use this link when you create them: https://bugs.documentfoundation.org/enter_bug.cgi?product=LibreOffice Click "Show Advanced Fields" so you can see the "Blocks" field (near the bottom).
Created attachment 169204 [details] Updated list of issues, using LO 7.0.4.2 I reviewed the original list, and there are a lot less outstanding issues now (or at least in LO 7.0.4.2) I attached the updated list, with extra objects for easy testing, and here are the remaining (potential) issues: 1. Writer > Format > Bullets and Numbering... Tab "Position", values "Aligned at", "tab stop at", "Indent at": all steps by 0.01 cm 2. Writer > Format > Image > Properties... Tab "Crop", Values "Crop": "Left", "Top", "Right", "Bottom" all step by 5 % of initial size on the image. 3. Calc > Format > Cells... Tab "Borders" > "Left", "Right", "Top", "Bottom", "Distance" all show "mm" unit and step by 0.5 mm 4. Draw > Format > Bullets and Numbering... "Indent" and "Width" all use 0.05 cm (I added this one as it wasn't already listed and I came across it while testing) Number 2 and 3 I believe both need separate bug reports if you think they need fixing, as they are special cases and might require more discussion. Number 1 and 4 I intend to patch myself, using a value of 0.1 cm to be consistent with the vast majority of steppers. There might definitely be more cases that need fixing, but moving forward, once number 1 and 4 are fixed, new specific bug reports should be opened as they will be more focused and easier to close. What do you think?
(In reply to stragu from comment #6) > ... all step by 5 % of initial size This sounds like a sensible value to me. Likewise the 0.5mm. But feel free to submit a patch and we can decide then.
Thanks Heiko. I just submitted a patch for review, related to this but for a dialogue not listed here: https://gerrit.libreoffice.org/c/core/+/110115 It was revealed with an OpenGrok search, which might be useful for someone looking for other problematic step values: https://opengrok.libreoffice.org/search?project=core&full=%22%3Cproperty+name%3D%5C%22step_increment%5C%22%3E0.01%3C%5C%2Fproperty%3E%22&defs=&refs=&path=&hist=&type=&xrd=&nn=1&si=full&si=full Once I fix 1 and 4 as well, I think we can agree to close this!