Bug 66792 - UI: Better integration of font styles into the toolbar
Summary: UI: Better integration of font styles into the toolbar
Status: RESOLVED WONTFIX
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: Other All
: medium enhancement
Assignee: Not Assigned
URL: https://alistapart.com/article/user-i...
Whiteboard:
Keywords: needsDevEval, topicUI
: 60741 80694 87871 (view as bug list)
Depends on:
Blocks: Fonts-Name-Combobox
  Show dependency treegraph
 
Reported: 2013-07-10 20:00 UTC by Emir Sarı
Modified: 2023-08-08 22:04 UTC (History)
13 users (show)

See Also:
Crash report or crash signature:


Attachments
screenshot from pages (107.75 KB, image/png)
2013-07-10 20:00 UTC, Emir Sarı
Details
Font Styles Mock-up 1 (136.27 KB, image/png)
2013-07-26 13:44 UTC, Emir Sarı
Details
Font Styles Mock-up 2 (108.65 KB, image/png)
2013-07-26 13:45 UTC, Emir Sarı
Details
InDesign font styles picker (33.94 KB, image/jpeg)
2015-04-19 13:56 UTC, Carsten
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Emir Sarı 2013-07-10 20:00:12 UTC
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.
Comment 1 Cor Nouws 2013-07-10 21:02:17 UTC
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 ;) )
Comment 2 Emir Sarı 2013-07-26 13:42:58 UTC
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.

Two scenarios:

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.
Comment 3 Emir Sarı 2013-07-26 13:44:04 UTC
Created attachment 83035 [details]
Font Styles Mock-up 1

Mock-up using MS Word menus.
Comment 4 Emir Sarı 2013-07-26 13:45:16 UTC
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.
Comment 5 Stefan Knorr (astron) 2013-07-27 11:48:20 UTC
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).
Comment 6 Emir Sarı 2013-07-27 11:55:27 UTC
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.
Comment 7 Owen Genat (retired) 2013-11-09 22:59:07 UTC
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.
Comment 8 Stefan Knorr (astron) 2013-11-10 20:12:21 UTC
*** Bug 60741 has been marked as a duplicate of this bug. ***
Comment 9 Adolfo Jayme Barrientos 2014-06-30 04:18:10 UTC
*** Bug 80694 has been marked as a duplicate of this bug. ***
Comment 10 Yousuf Philips (jay) (retired) 2014-06-30 14:36:21 UTC
Hi Adolfo,

I wasnt suggesting expandable trees in my bug report, i trying to show indentation in my mockup [attachment 101991 [details]].
Comment 11 Yousuf Philips (jay) (retired) 2015-03-20 11:53:38 UTC
*** Bug 87871 has been marked as a duplicate of this bug. ***
Comment 12 Carsten 2015-04-19 13:56:03 UTC
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! :)
Comment 13 Fred 2015-10-08 15:56:11 UTC
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.
Comment 14 Yousuf Philips (jay) (retired) 2015-10-09 13:27:09 UTC
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]).
Comment 15 Robinson Tryon (qubit) 2015-12-13 11:24:17 UTC Comment hidden (obsolete)
Comment 16 Robinson Tryon (qubit) 2016-08-25 04:44:58 UTC Comment hidden (obsolete)
Comment 17 Heiko Tietze 2018-02-19 00:09:05 UTC
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).
Comment 18 Heiko Tietze 2019-03-11 15:24:43 UTC Comment hidden (off-topic)
Comment 19 Mihkel Tõnnov 2020-01-07 12:26:25 UTC
Has the design team also discussed the proposed additional button, for accessing the styles beyond R/I/B/BI?
Comment 20 Heiko Tietze 2020-01-08 09:47:20 UTC
(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.
Comment 21 ⁨خالد حسني⁩ 2023-08-03 16:48:52 UTC
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.
Comment 22 Eyal Rozenberg 2023-08-03 18:42:09 UTC
(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.
Comment 23 ⁨خالد حسني⁩ 2023-08-03 19:21:21 UTC
(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).

No.


> > so such selection would be moot.
> 
> It won't.

It is.
 
> > 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.

No.
Comment 24 Eyal Rozenberg 2023-08-03 19:38:39 UTC
(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.
Comment 25 Eyal Rozenberg 2023-08-03 19:41:08 UTC
(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.
Comment 26 ⁨خالد حسني⁩ 2023-08-04 09:45:46 UTC
(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.
Comment 27 Eyal Rozenberg 2023-08-04 10:30:13 UTC
(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
> family...

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.


2.  
plus, 
2.
Comment 28 ⁨خالد حسني⁩ 2023-08-07 10:51:38 UTC
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.
Comment 29 Eyal Rozenberg 2023-08-08 22:04:48 UTC
(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.