An italic font and a slanted/oblique font are not the same thing at all: https://creativepro.com/typetalk-italic-vs-oblique/ however, our formatting toolbar has a button which applies italicization if possible and slanting otherwise (already a problem), which is marked with a slanted-i. That's misleading, or rather - contributes to the confusing between slanted and italic fonts. IIANM, this is a legacy of Microsoft's choices in the design of MS Windows, which persisted in MS-Office and propagated among users, who, these days, typically aren't well-aware of the difference. We should not continue this confusion. As for what to do concretely - there is the long-term rework suggested in bug bug 35538. But perhaps it's possible to improve on the current state of affairs today already. A few ideas of regarding what to do: 1. Change the slanted-I to italic-i on the button, do nothing else. 2. Change the slanted-I to italic-i on the button, never let it select the slanted/oblique variant of the font. 3. Replace the current button with a three-state button or menubutton: Upright, slanted, italic. 4. Replace the current button with two buttons for Italic and Slanted respectively; pressing one depresses the other; only let each of them select its own variant.
(In reply to Eyal Rozenberg from comment #0) Interesting.. didn't know about this behaviour: Italicization if possible and slanting otherwise. I surely agree this really mixing things together (undesired) -- I'm also partly confused: Is this about the button itself (icon) or how it gets applied in the document or both. Because of the suggestions at 1 + 2 > > A few ideas of regarding what to do: > > 1. Change the slanted-I to italic-i on the button, do nothing else. > 2. Change the slanted-I to italic-i on the button, never let it select the > slanted/oblique variant of the font. What should happen if Italic is missing? > 3. Replace the current button with a three-state button or menubutton: > Upright, slanted, italic. Underline button has a drop down to pick different underlines. Something similar could be done for Italicization <-> slanting. Off-topic: I kind of pro.. I have tendency to add 'unformatted' too. Applying BOLD (CTRL+B introduces formatting; CTRL+B again; creates the inverse, explicit unbold). The only way to get unformatted text is clear df. But well if you have Underline (DF) and Bold (DF), and you want to disable only bold (DF), you're in trouble. > 4. Replace the current button with two buttons for Italic and Slanted > respectively; pressing one depresses the other; only let each of them select > its own variant. Not in favor of this ..
Users know the term "italic" to get cursive text and we should not change this. Modifying the icon is cheap and wont hurt, however. We could also give hints in the tooltip and/or add a passage to the (online) help.
Rizal, what do you think?
(In reply to Heiko Tietze from comment #3) > Rizal, what do you think? I would rather keep the icon as is, since making true italic-i with probably lowercase would break consistency among other icons. Adding a dropdown as stated by Telesto would be better: Dropdwon list 1: Slanted (may be additional option to set the degree) Dropdown list 2: Italic
The dropdown button is discussed as solution for multiple variants of slantness in bug 35538. Suggest to resolve => WF (no icon change), or forward to the documentation team (component => documentation).
(In reply to Heiko Tietze from comment #5) > The dropdown button is discussed as solution for multiple variants of > slantness in bug 35538. Suggest to resolve => WF (no icon change), or > forward to the documentation team (component => documentation). First, let's put the documentation aside, this issue is not mainly about documentation. Second, I agree that the discussion of a menubutton/multi-button set can stay on bug 35538 only, especially since there's already some discussion of it there; so I'm marking bug 35538 as blocking this one and will comment there. So, while bug 35538 is not being worked on, let's rephrase the remaining spectrum of options I've suggested, and in fact I'll add another one: 1. Change the oblique-I to italic-i on the button, do nothing else. 2. Change the oblique-I to italic-i on the button, never let it select the oblique variant of the font. 3. Display _either_ oblique-I or italic-i on the button, depending on whether pressing it will apply oblique or italic (which in turn depends on what the font family provides). While option (3.) may seem a little weird, it will harmonize the ambiguity of the button's behavior with the choice of icon - and then, if/when we make the button behave more predictably (in bug 35538), we would also make its icon predictable again. Also, such icon variability is not without precedent: the bullets and the numbering buttons change their icon depending on whether we're in an LTR or RTL paragraph. I like option (3.) right now; and option (1.) would also be an improvement. Option (2.) achieves perfectly predictability/consistency of using the button, but at the price of "hiding" direct applicability of the oblique form and a strong divergence from the behavior of many common font-formatting UI schemes including MS Office. What do you (Heiko and others) think?
(In reply to Eyal Rozenberg from comment #6) > 1. Change the oblique-I to italic-i on the button, do nothing else. > ... > What do you (Heiko and others) think? No objection, though very small change. Any other modification breaks the workflow for many.
*** Bug 158518 has been marked as a duplicate of this bug. ***