Created attachment 82295 [details]
screenshot from pages
Currently selecting font styles is a very long process involving several clicks and dialog boxes.
By adding a drop-down toolbar button next to font combo box, this process could be easily simplified.
Considering we could get rid of the bold, italic, and underline buttons, this could open up space on the formatting toolbar.
Attaching a SS from Pages, which has a drop down menu for selecting font styles.
Hi Emir Sari,
Thanks for the report.
Looks as a useful idea to me.
I set the version to 3.3.0 since the current situation is here as long as we know.
(Personally, I intend to take a look at the 'Side bar' (expirimental at the moment) to rework that idea to make it work effectively with styles, rather then consume space to show the direct formatting tools another time ;) )
It would be useful to add such a menu to sidebar as well.
But in order to save buttons and space, this could be directly integrated into the font drop-down menu directly.
1. User places the cursor on the Font, another sub menu opens and shows the available styles. If user clicks on the font name, default style is applied.
2. User starts to type the font name on the box, available styles appear under the text box, allowing user to navigate with arrow keys or the cursor to select the font style.
This approach would both save space and provide an intuitive interface I think.
Created attachment 83035 [details]
Font Styles Mock-up 1
Mock-up using MS Word menus.
Created attachment 83036 [details]
Font Styles Mock-up 2
Mock-up using partial MS Word menus.
This shows how it would look if a user starts typing a font on the box.
Well, this is indeed useful, especially for everyone working with professional fonts. Otoh, most fonts still ship with Regular/Bold/Italic/Bold Italic only, for which we have buttons already.
Personally, it always pains me to see that I have ~10 entries for Univers alone in my font picker (which I have in a various weights/condensations). But I have a thing for fonts, most people don't.
As for the resolution, maybe it would make sense to complement the Bold/Italic/Underlined buttons with fourth buttons for more style that would pop open a menu to choose from..?
I am not so fond of your mockups, Emir, as they would create an odd look together with scrollbars and require quite complicated widgets (which never looks good in LibreOffice).
Fourth button makes sense.
For the mock-ups, I am not so fond of them either, I just put them together to give an idea of how it would look. Plus, it would require the implementation of native drop-down menus, or custom menus. Of course if someone would come up with a nicer mock-up, always welcome.
This enhancement request deals with the same issue as bug #60741. This one uses Pages as inspiration, while the other bug uses NeoOffice, but both are seeking to combine Family, Name, and Weight information for a font into a single selector. I just wanted to make the connection visible, because if this enhancement is implemented (and it seems more likely) the other one will need to be closed.
*** Bug 60741 has been marked as a duplicate of this bug. ***
*** Bug 80694 has been marked as a duplicate of this bug. ***
I wasnt suggesting expandable trees in my bug report, i trying to show indentation in my mockup [attachment 101991 [details]].
*** Bug 87871 has been marked as a duplicate of this bug. ***
Created attachment 114907 [details]
InDesign font styles picker
Nice, I was trying to file this enhancement just now. It really is a pain to change to "light" or "black" styles for me.
I think integrating this into the font family picker has problems (as already discussed here) - it is just not logical that you would have to change the font family to select the style/weight and it bloats the ff picker.
From my UX Design perspective, I would prefer a separate dropdown menu just after the font family (or size) picker and get rid of the bold / italic buttons. Adobe got this very right with InDesign (and others, e.g. Photoshop) - see attachment.
Please keep in mind that most "free" fonts now also come with lots of more styles than just bold or italic. Also, people seem to pay more attention to fonts nowadays.
I don't think a button would be appropriate, as it is very difficult to find an instantly recognizable iconic depiction of "font styles"...
But even if you disagree with a dropdown and go for a button, I would be very very happy to at least have a shorter way of selecting font styles in LibreOffice! :)
Maybe bug 94886 I just filed offers a different route? The main challenge is avoiding significant and potentially confusing changes to the UI - in this context I like the idea of adding new "typeface" button better but it still leaves the issue of "bold" and "italics" mapping to functions that actually make sense to the user.
This bug report has 3 suggested improvements of integrating font styles into the toolbar.
1) Create a separate font style drop down menu that lists font styles and keep the current font name drop down menu exclusive to font families similar to iWork Pages (OP description) and inDesign (comment 12). This would make the toolbar similar to the controls in the font tab of character dialog, which should be easy to implement, but would take up more room in the toolbar and would be confusing to users who are used to having a single drop down menu for everything, which is the default for most apps.
2) Change the font name drop down menu to only show font family names and have a submenu that expands from each font family to select the font styles (comment 3). This would likely be more difficult to implement as we dont have any implementation of a similar submenu in the combobox.
3) Change the font name drop down menu so that font style editions of a font family are indented after the main entry (attachment 101991 [details]).
Migrating Whiteboard tags to Keywords: (needsDevEval, topicUI)
We're replacing our use of the 'ux-advise' component with a keyword:
Component -> LibreOffice
Add Keyword: needsUXEval
The design team discussed the various options of a) access to style variations in submenus, b) splitting into two dropdowns similar to InDesign, and c) indentation of the variations. All solutions are not easy to handle, and most fonts have just R/B/I/BI that are addressed by the toggle buttons bold and italic. Plus, we have the two dropdowns solution implemented in the character dialog. So the recommendation is to 'ignore' variants meaning to collapse all DejaVu fonts into one (regular).
Removing UX as input has been given.
Has the design team also discussed the proposed additional button, for accessing the styles beyond R/I/B/BI?
(In reply to Mihkel Tõnnov from comment #19)
> Has the design team also discussed the proposed additional button, for
> accessing the styles beyond R/I/B/BI?
As stated in c17, the recommendation is to access attributes beyond RIB per existing dropdown.
We only support R/B/I/BI font family model for various legacy and compatibility reasons, so such selection would be moot. Font "Foo", style "Black" will be actually showed as "Foo Black", style "Regular".
This is currently not the case on macOS, but that is a different bug.
(In reply to خالد حسني from comment #21)
> We only support R/B/I/BI font family model for various legacy and
> compatibility reasons
and that is a bug which must be fixed: bug 112973 (which I've just reopened).
> so such selection would be moot.
> Such Font "Foo", style "Black" will be actually showed as "Foo Black",
> style "Regular".
... which is a bug, since there is no "Foo Black" family, and we should certainly not duplicate the font families, nor make users believe that they're using a "Foo Black" family, which they might then expect to find in other applications.
(In reply to Eyal Rozenberg from comment #22)
> (In reply to خالد حسني from comment #21)
> > We only support R/B/I/BI font family model for various legacy and
> > compatibility reasons
> and that is a bug which must be fixed: bug 112973 (which I've just reopened).
> > so such selection would be moot.
> It won't.
> > Such Font "Foo", style "Black" will be actually showed as "Foo Black",
> > style "Regular".
> ... which is a bug, since there is no "Foo Black" family, and we should
> certainly not duplicate the font families, nor make users believe that
> they're using a "Foo Black" family, which they might then expect to find in
> other applications.
(In reply to خالد حسني from comment #23)
Khaled, with respect - you can certainly express the opinion that it's not worth pursuing, but you can't "define-away" bugs. That goes even for unconfirmed ones, and certainly for confirmed bugs with multiple dupe reports and followers.
(In reply to خالد حسني from comment #23)
Oh, but I must apologize, I referred to the wrong bug in comment #21: bug 35538 is the one about the support for font variants other than R/B/I/BI, which I've reopened.
(In reply to Eyal Rozenberg from comment #24)
> (In reply to خالد حسني from comment #23)
> Khaled, with respect - you can certainly express the opinion that it's not
> worth pursuing, but you can't "define-away" bugs. That goes even for
> unconfirmed ones, and certainly for confirmed bugs with multiple dupe
> reports and followers.
It is not an opinion, it is a fact. We don’t have more than 4 styles per family on Windows and Linux, and on macOS that is a bug we have to fix (bug 105298). If there are is no more than 4 styles per family, then the R/B/I/BI button are enough and the issue here is not an issue and need to be closed. If you want to have more than 4 styles per font family (which is a valid feature request, though I’d be inclined to close it as WONTFIX, but that is different discussion), this is not the issue to argue for it, and keeping this issue open because we will need it once an unimplemented feature gets implemented makes no sense.
(In reply to خالد حسني from comment #26)
> (In reply to Eyal Rozenberg from comment #24)
> > (In reply to خالد حسني from comment #23)
> > Khaled, with respect - you can certainly express the opinion that it's not
> > worth pursuing, but you can't "define-away" bugs. That goes even for
> > unconfirmed ones, and certainly for confirmed bugs with multiple dupe
> > reports and followers.
> It is not an opinion, it is a fact. We don’t have more than 4 styles per
And that is a recongized bug, 35538. Fonts _do_ have more variants than R/B/I/BI; so it's just that we semi-ignore that, and split the family into multiple families. This is a bug, because we're claiming that font families exist which simply do not. And ignoring or mis-representing aspects of a font is a bug.
> If there are is no more than 4 styles per family, then the R/B/I/BI
> button are enough
It's not enough even then, for at least two reasons:
1. The weight of a font is not even a binary category. In CSS, for example, font weight is a number ranging between 100 and 900 (although it seems to be discrete in increments of 100), with "normal" being 400 and "bold" being 700. In principle, a procedurally-drawn font can have its weight be a continuous sequence with fractional values; and even if we don't go this far, the user needs to be able to define styles with the level of boldness they want, to effect a gradation; and when bug 127702 is resolved, the user would be able to have a style saying "1 increment more bold than the underlying style" or "25% more bold than the underlying style". That requires weight to be a numeric category, not just another aspect of the variant.
2. Some fonts have an oblique variant rather than an italic one. IIANM (and I may be wrong) we currently treat the former as the latter. If we don't do that, we'll prevent people from using the Oblique variant. And both these behaviors are problematic.
> If you want to have more than 4 styles per font family (which is a valid
> feature request, though I’d be inclined to close it as WONTFIX
It is not something that "I want". Fonts _do_ objectively have more than 4 variants; and we must support those. It's not a feature request of mine, it has been recognized that LO's lack of support for this is a bug, bug 35538.
> and keeping this issue open because we will need it once an unimplemented
> feature gets implemented makes no sense.
I mistakenly reopened 112973 instead of 35538, which is the one I meant to. If 33538 is open, which it is and should be unless a discussion has been held in which people have been convinced it should be closed, then it makes sense for this to remain open.
Again, sorry for the bug number mixup. The thing is, once a bug has been marked NEW, people - even respected developers - can't just close it. They can argue for closing it and consider the reactions.
You are still arguing in the wrong bug. Our UI does not present more than four styles per family, so the issue here is to fix an issue that does not exist. If you want our UI to show more than 4 style per family, then argue about that in the relevant bug report, and when this is done (if ever) the issue here will be relevant again.
(In reply to خالد حسني from comment #28)
One is allowed to file an enhancement request dependent on a capability which has been recognized as missing, and depend on it existing (which is why this issue was marked NEW before you closed it). However - I'll let it go because: 1. This is a minor technicality and 2. The place to argue is indeed the main bug.