Natural units for page properties are not usually the same as for line properties. Typically (in all other word processors) page properties (e.g. margins, tabs, etc.) are measured in inches or cm/mm while line properties (e.g. line and paragraph spacing) are measured in pt. It is very unusual and difficult to have to see only the same units for both. e.g. if I use inches for everything then I can't see what line spacing or paragraph spacing is currently set to in pt since it only shows inches. Whereas if I use pt for everything then I can't see what margins and tabs are in inches. I can modify to some value in any units but I can't tell what the existing value is or whether it's the same as the value I want. It's slow and irritating to work with, unnatural, and unlike any other word processor.
Jingle UX, Jingle UX, Jingle all the way... Another one for y'all!
[Retiring ux-advise: Change Component: ux-advise -> LibreOffice Add Keyword: needsUXEval ]
Created attachment 127367 [details] screenshot from gimp and inkscape Would suggest we use a units drop down list next to the spinboxes like other apps do.
Created attachment 130628 [details] Mockup for unit selection at numerical inputs (In reply to Yousuf Philips (jay) from comment #3) > Would suggest we use a units drop down list next to the spinboxes like other > apps do. Definitely yes. This would replace Tools > Options > LibO X > General: Settings, Measurement unit with Millimeter, Centimeter, Inch, Pica, Point for Writer and Draw plus Meter, Kilometer, Foot, Miles, Char, Line in Draw/Impress. I'd suggest to add the SI unit and to show the current value converted. The attachment shows how it could work. Ideally, we define a default unit per input, depending on the localization, and allow the user to change it - and store what he or she selects. That means we have centimeter for page settings when the system language is not EN otherwise it would be inch. And we have points for the paragraph distances. If Benjamin changes the unit for 'spacing above' to pica, he will still have points for spacing below and indentations. The conversion table can be found at http://opengrok.libreoffice.org/xref/core/vcl/source/control/field.cxx#1114. While it contains Char and Line for Draw/Impress those units are not known in the ODF specs (http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#__RefHeading__1419774_253892949) neither I found any other reference. @Regina, Cor: Any thoughts? If no one remembers why those units have been implemented I suggest to kick them out. Likewise mile and kilometer as they clutter the list too much. We could also consider to switch from the hard coded conversion list to the more general UCUM (http://unitsofmeasure.org/trac) standard, which would provide the conversion formula with the (extendable list of) unit.
Removing needUX. The idea is to introduce a numerical stepper control which holds the values as well as the corresponding units. On click at the unit a dropdown allows to change it from px, for instance, to cm. Fine-tuning is needed in respect to how the configuration is stored (we have the global setting in Tools > Options but need a way to remember per control), and also in respect to the precision (10px = 0.0000008km, bug 44267). Could be a good project for GSoC.
(In reply to Heiko Tietze from comment #5) > Removing needUX. The idea is to introduce a numerical stepper control which > holds the values as well as the corresponding units. Not sure that I understand what you are proposing. I am a user who needs this feature. I have literally toggled the sole "measurement unit" option between 'point' and 'inch' hundreds of times in my life. There is no reason that I should know this feature by heart. The solution is simple: we need sane defaults. I just check Word Perfect and MS Word. As expected, both of them measure line widths and spacing in points. We measure them in our default unit, inches. This is illogical and wrong. There very well established industry standards. Fonts and line spacing are measured in points. This is typography 101. The whole point of units is to interact with others, and this is an established standard for the field. The primary fix should not be to clutter the UI with more options. We just need sane defaults. If we must allow customizing of units normally measured in points, then have 2 measurement options. A primary for your ruler and object lengths. A secondary for more specialized typography uses such as fonts width, line spacing, and line width. But sane defaults would have prevents me from toggling the "measurement unit" 99% of the time. It sounds to me like the proposed solution is over engineered and over complicated.
(In reply to Luke from comment #6) > It sounds to me like the proposed solution is over > engineered and over complicated. Maybe from your POV. But take into consideration that your default is not mine, inch vs. cm, points vs. pixel, expert vs. layman. So yes to the default but plus easy ways to switch.
(In reply to Heiko Tietze from comment #7) > Maybe from your POV. But take into consideration that your default is not > mine, inch vs. cm, points vs. pixel, expert vs. layman. So yes to the > default but plus easy ways to switch. I am not talking about switching from cm to in and neither is the bug reporter. We now have to switch units often because LibreOffice is not using the natural units for many items. > “Natural units for page properties are not usually the same as for line properties.” Your proposed solution of making it easier to switch default units completely misses the underlying problem while making more complex UI. We are using the wrong units in many places. If we used the same, sane defaults as Word and WordPerfect, then users would not need to change units often. This bug report would have never been filed. Your proposed fix doesn't address this. Instead it leaves the user to still having to toggle units that shouldn't have to be toggled in the first place. From the Wikipedia article on the unit 'point'. "In typography, the point is the smallest unit of measure. It is used for measuring font size, leading, and other items on a printed page. " WordPerfect and Word correctly use this natural unit of measure for leading. LibreOffice does not. This is the problem.
(In reply to Luke from comment #8) > If we used the same, sane defaults as Word and WordPerfect, then users would > not need to change units often. And those individual units would have to be stored anyway. Plus we need an option to switch from point to something else, in to cm was only one example.
(In reply to Heiko Tietze from comment #9) > And those individual units would have to be stored anyway. Plus we need an > option to switch from point to something else, in to cm was only one example. Agreed, which is why I proposed that we have 2 classes, a general measurement unit of in. or cm.(page, margin, ruler dimensions etc.) And a typography class where point is commonly used(line spacing, font, line width etc.). This alone would solve my use case and the use case described by the bug reporter. Making the UI easier to change these 2 classes is fine, but I'm opposed to modifying the UI without first addressing this underlying issue.
Created attachment 147251 [details] Word vs Writer: Indent should be in inches/cm - Spacing should be in point
Created attachment 147252 [details] Word vs Writer: Line Width should be in points here
(In reply to Luke from comment #10) > This alone would solve my use case and the use case described by the bug > reporter. Making the UI easier to change these 2 classes is fine, but I'm > opposed to modifying the UI without first addressing this underlying issue. Looks as a useful idea to me.
This is also an internal consistency issue. For example, the measurement unit Table -> Table Properties -> Borders -> Line Width = pt. Shape -> Line -> Line Properties -> Line Width = <default measurement unit> We are correctly using the natural measurement unit in one dialog, while using a nonstandard, user-defined unit in the other. A consistent UI is part of a good UI design.
Created attachment 148081 [details] Writer vs Writer: Inconsistent Units for Same Measurement
*** Bug 121011 has been marked as a duplicate of this bug. ***
*** Bug 105176 has been marked as a duplicate of this bug. ***
*** Bug 115266 has been marked as a duplicate of this bug. ***
The UI and precision problem demonstrated in Bug 115266 is yet one more reason all instances of fonts size, line spacing, and line width should be represented in points, their natural unit. Expecting the user to constantly toggle units back and force because we use the same unit for quantities that have different natural units makes no sense. The obvious solution here is to do what every other OfficeSuite does and use the natural units of measure. For 99.9% of users forcing them to find the location of this feature and micro-manage it, it a waste of time. It's UI design failure. I strongly disagree that we should make the micro-managing easier for the other 0.1% of use cases. For the rare case when you do not want to use the natural unit, you can always do the conversion manually. With the added bonus that you avoid the precision, issue of Bug 115266.
Created attachment 149725 [details] WordPerfect uses Natural Units for Line Spacing, Font size, and Line Width In WordPerfect, the default setting in my local is inches for both, "Units of Measure" and "Ruler Display". Yet, WordPerfect correctly uses the natural unit of point for Line Spacing, Font size, and Line Width.
Created attachment 149726 [details] Google Docs also Uses Point for Line Spacing, Font size, and Line Width
(In reply to Luke from comment #19) > ... I strongly disagree that we should make the micro-managing easier... https://bugs.documentfoundation.org/show_bug.cgi?id=121011#c7
To be clear, I was saying "I strongly disagree that we should make the micro-managing easier" as a fix to this issue of using the wrong units of measure. Instead, I propose we fix the underlying problem by: 1) Hard code "point" as the unit of measure in all dialogs with typography units. 2) Add a 2nd class of measurement unit:"typography". The default should be point. At first, this should be located next to Tools>Options>LibO X>General: Settings All dialogs with fonts size, line spacing, and line width should use hard coded point or the new typography class of measurement unit.
*** Bug 83615 has been marked as a duplicate of this bug. ***
(In reply to Luke from comment #23) > > 1) Hard code "point" as the unit of measure in all dialogs with typography > units. Which definition of "point" do you want use? In https://en.wikipedia.org/wiki/Point_(typography)I see several definitions, and, if I am not wrong, no official standard. SI unit system is the only common standard and should be used as the basis for all units chosen by the end-user. Best regards. JBF
Some of you young whipper-snappers may very well believe that all typographical measurements are supposed to be in PostScript points. Well, font size and leading are traditionally given in points, but LINE LENGTH is given in PICAS. When using PostScript points, of course these will be PostScript picas (1/6 international inch exactly). When using picas, fractions of a pica should be expressed in points, not as decimal fractions of a pica. Thus, 10p6 rather than 10.5 pc, or 10p8.2 rather than 10.6 pc. (Adobe supports this -- so can we!) Hardcoding any measurement unit as mandatory would of course a dreadful mistake.
The request here is to allow difference measurement units for typography vs Page Properties. No one is asking to remove pica as a typography choice.
Please add keyword 'needsUXEval' and CC 'libreoffice-ux-advise@lists.freedesktop.org' if input from UX is needed.
*** Bug 141094 has been marked as a duplicate of this bug. ***
*** Bug 147899 has been marked as a duplicate of this bug. ***
Interesting alternative by GIMP: https://librearts.org/2020/07/how-to-use-math-input-in-gimp/. GIMP allows to add the unit at the spinedit, even mixed with simple arithmetic (see bug 158685), and the data is converted into the defined unit. For example: 5ft+4in => 162.56 (cm).
Summarizing: So there are a lot of spinedits for setting number values for different things, say paragraph spacing, border/margin width etc. And all those have a number and a unit. Now the issue is that for the whole application (calc/writer etc), we have a single unit for all such spinedits under the application, which is like "one size trying to fit all" situation. The solutions proposed are a) modify the spinedit to show a dropdown when clicked on the unit, so that the user can choose the appropriate unit. b) the gimp way of doing it (where what we type in inside the spinedit will manipulate the unit (comment 31). The GSoC Idea page also talks about remembering unit per spinedit (ideally), and some way to change the precision as number with more/less decimal places are typed in. My take: I just jumped in looking at the cool spinedit mod, but now that I see the whole picture, the gimp way makes more sense, because in the approach (a), most of the energy goes into creating a new spinedit, which looks cool, but might not be as functional as the the ones gimp has. Also if approach (a) is implemented, then clicking on the modified spinedit (unit area) will show the units dropdown, which might come in the way if later someone tries to add some of the approach (b) features. Currently if the spinedit has the units in pt, and I type 1cm (after clearing the whole entry, then it converts that to pt, and shows the new unit 28.3pt. But any arithmetic conversion/binary operation doesn't work right now (either with same units, or with different units)
What are your opinions on this. We add support for arithmetic, like gimp does, and for units, we will take the unit of the last metric in the equation. Like if the current entry is 1 cm, and some one adds 1 pt to it, then the sum is displayed as 29.3 pt (taking the unit of 1 pt). If we want to keep the unit same, we can have an extra + 0 cm at the end. If no unit is specified, then the current unit is used for that number. (And once the unit has been changed, it will be remembered)
Taking "Spacing above paragraph" as example, and I am on metric units means when I enter "1 in" it becomes 2.54cm - correct. But "10 px" become "10 cm" (no warning), "1 mm" is for some reason "0,1 cm", and "0,35 cm" in the sidebar 11,3pt but inserted in the dialog 0 (guess the comma is not working). Ultimately it works as expected with some issues. Foremost usability blocker is that this feature is completely hidden. Maybe we could give some feedback by a warning status if the unit is not recognized together with a tooltip what is possible. Nice enhancement yet not really needed is the "complex" formula (would be bug 158685).