Created attachment 170888 [details] Same font size, different character heights The customary measure of font size is actually a rather complex voodoo which doesn't tell the user much. At best, it is close to being "somewhere between 1/0.7 and 1/0.6 of the Em-height". See discussion here: https://graphicdesign.stackexchange.com/questions/4035/what-does-the-size-of-the-font-translate-to-exactly or here: https://www.thomasphinney.com/2011/03/point-size/ In LO writer (and all of LO) font dialogs, sizes are given in terms of this inscrutable font size. And if you create a style derived from another style, it will maintain the same "size" - but not necessarily the same Em-height nor x-height. This is problematic in running (Latin) text, where most characters are lowercase, and their height is basically the x-height. Now, if you use character styles with different fonts in the same text run, and fail to carefully set their font size (possibly even to a non-integral value), the sizes of different parts of the run will vary, distracting the user. This is not some esoteric use case: You just: 1. Create a new document in LO writer. 2. Write some text, say "foo bar" 3. Select "bar" 4. Change the character style (not the paragraph style!) to "Source Text" You'll see a significant character height difference. (Actually, this might depend on your font selection, but it would work with most default choices, and particularly with Liberation Serif vs Liberation Mono.) The attached document illustrates this. This also happens when your concern is the M-height: 1. Create a new document in LO writer. 2. Write some text, say "foo bar" 3. Select "foo" 4. Set the font family to Liberation Serif 5. Select "bar" 6. Set the font family to Lucida Sans Unicode (available from here if you don't have it: https://www.wfonts.com/font/lucida-sans-unicode ) You'll again notice a significant difference height difference. It would be useful (perhaps one might even say: necessary), if it were possible for derivative styles to track the x-height (or M-height) of the underlying style rather than its M-height. This can be achieved in one of several ways - partially depending on the extent to which there is an interest in exposing these height figures to users. I'm mulling over opening a separate bug about that.
Created attachment 170889 [details] Same font size, different character heights (screenshot)
Please don't forget to CC @libreoffice-ux-advise when using the keyword needsUXEval.
You want LibreOffice to adjust the font size so two fonts with different x-height become more similar? This would distort when ascenders and descenders not taken into account. But ultimately it's up to the font designer how it looks and it's off-topic for the word processor.
I'm not very knowledgeable in this field; but are there any examples how other applications implement such a measure in UI (some screenshots please)?
(In reply to Heiko Tietze from comment #3) > You want LibreOffice to adjust the font size so two fonts with different > x-height become more similar? Oh no, no, that's not what I mean. I mean allowing the user to say "I want to choose a font in this family in which the x has a height of so-and-so points", while right now you can only say "I want to choose a font in this family in which the Em has a height of so-and-so pointer". No distortions or adjustments. > But ultimately it's up to the font > designer how it looks and it's off-topic for the word processor. It's not about how the font looks. A font designer is literally prevented of doing anything about this issue: If they created a font (family) where an x height of 10 pt corresponds to an M height of 30pt, the designer can't tell you in any way "please don't think of my Em-height-30 font as being that high in lower case". Deciding what measures to focus on is the application's responsibility.
(In reply to Mike Kaganski from comment #4) > I'm not very knowledgeable in this field; but are there any examples how > other applications implement such a measure in UI (some screenshots please)? Mostly I don't know, but: Microsoft Word (and MS office in general) - they only offer Em sizes and don't mention the units: https://images.tips.net/S06/Figs/T10556F1.png In gimp, you get a menulist offering units when selecting font size: cm, px, in, mm and even yd and ft (for yards and feet). But these are absolute units of the Em size of the fonts, not anything else.
(In reply to Eyal Rozenberg from comment #6) > Microsoft Word (and MS office in general) - they > only offer Em sizes and don't mention the units: > https://images.tips.net/S06/Figs/T10556F1.png This is wrong. Word (and MSO in general) only use "font size" as you discuss in comment 0. Literally following your steps in Word 2016 results in exactly same result as in Writer. For Word and Writer, having any font set to same numeric value of size results in pixel-perfect match (both on screen and on paper) of same characters. So no, Word uses same size units, and since you declare that Writer does not use Em-size but some "inscrutable font size", so does Word.
(In reply to Eyal Rozenberg from comment #5) > (In reply to Heiko Tietze from comment #3) > > You want LibreOffice to adjust the font size so two fonts with different > > x-height become more similar? > > I mean allowing the user to say "I want > to choose a font in this family in which the x has a height of so-and-so > points", while right now you can only say "I want to choose a font in this > family in which the Em has a height of so-and-so pointer". No distortions or > adjustments. Actually, let me rephrase; it's not quote how I opened this bug. In this bug, I focused about derivative styles, not setting size in general. That would be a different bug which may I should file. So, answering Heiko's question again: I mean allowing the user to say "I want this character style's font size to be chosen so that x characters have the same height as in the underlying paragraph style" or "123% of their height in the underlying paragraph style, while currently the user can only say that about M heights.
(In reply to Mike Kaganski from comment #7) > This is wrong. Word (and MSO in general) only use "font size" as you discuss > in comment 0. Literally following your steps in Word 2016 results in exactly > same result as in Writer. For Word and Writer, having any font set to same > numeric value of size results in pixel-perfect match (both on screen and on > paper) of same characters. So no, Word uses same size units, and since you > declare that Writer does not use Em-size but some "inscrutable font size", > so does Word. Yes, that's what I mean. Perhaps more importantly than what I described - neither MS Word nor Gimp offer facilities for setting font size relative to some existing font; which is what this bug is focused on.
(In reply to Eyal Rozenberg from comment #0) > In LO writer (and all of LO) font dialogs, sizes are given in terms of this > inscrutable font size. And if you create a style derived from another style, > it will maintain the same "size" - but not necessarily the same Em-height > nor x-height. > > This also happens when your concern is the M-height: > > ... > > You'll again notice a significant difference height difference. > > It would be useful (perhaps one might even say: necessary), if it were > possible for derivative styles to track the x-height (or M-height) of the > underlying style rather than its M-height. (In reply to Eyal Rozenberg from comment #8) > while currently the user can only say that about M heights. You seem to mix Em-size, x-size, M-size, and "inscrutable font size" in different combinations, so that in the end, it's unclear what size in your opinion is used now, i.e., what works and what doesn't.
(In reply to Mike Kaganski from comment #11) > You seem to mix Em-size, x-size, M-size, and "inscrutable font size" in > different combinations, so that in the end, it's unclear what size in your > opinion is used now, i.e., what works and what doesn't. Too bad I can't edit Bugzilla comments. But you're right: Even M-height is not something you can properly track right now in derivative styles.
Let's resolve this as WF.