Bug 91130 - Smaller default font name list
Summary: Smaller default font name list
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
5.0.0.0.alpha0+ Master
Hardware: Other All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: needsUXEval
: 60626 113089 115186 116446 119199 119915 (view as bug list)
Depends on:
Blocks: Fonts-Name-Combobox Font-List
  Show dependency treegraph
 
Reported: 2015-05-07 12:15 UTC by Yousuf Philips (jay) (retired)
Modified: 2018-09-17 07:15 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments
Drop down with substring search (220.46 KB, image/png)
2018-02-02 14:35 UTC, Ole Tange
Details
Mockup2 of multi-column font selector (161.02 KB, image/png)
2018-02-05 11:06 UTC, Ole Tange
Details
Dynamic font selector (1005.21 KB, application/vnd.oasis.opendocument.presentation)
2018-02-13 13:30 UTC, Ole Tange
Details
sections headings inside of the font name list (16.76 KB, image/png)
2018-02-16 20:19 UTC, Yousuf Philips (jay) (retired)
Details
Dynamic font selector (rev 2). (1.51 MB, application/vnd.oasis.opendocument.presentation)
2018-02-19 17:34 UTC, Ole Tange
Details
ThinkFree Office font list's preset menu (51.89 KB, image/jpeg)
2018-02-28 07:50 UTC, Rizal Muttaqin
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Yousuf Philips (jay) (retired) 2015-05-07 12:15:05 UTC
Users can have 100s of fonts on their computer and they would all be listed in the font name drop down list, though they are highly unlikely to use more than 30 of them, so i'd like to suggest a way to reduce this down for easier font selection.

My idea is that the font name drop down list will begin with containing only a short list of fonts that are commonly used and available on a user's system (e.g. Liberation Serif, Times New Roman, Liberation Sans, Arial, etc) and additional fonts will be added to the list according to the following scenarios.

1) A user opens a document which contains fonts not already shown in the list
2) A user clicks on a 'More Fonts...' entry at the bottom of the list and selects to use a particular font in the character dialog's font tab
Comment 1 Heiko Tietze 2015-05-07 17:09:54 UTC
I'd appreciate such a filter. But what is the default for all OS? Times New Roman... please don't (unless on Windows). Helvetica, Garamond? And does it makes sense to mix sans, serif, and mono fonts? Whats about the recently used?

However, +1 for working on the topic of a better font list.
Comment 2 A (Andy) 2015-05-07 20:28:18 UTC
This is an interesting enhancement.  
I regularly use only about 5 fonts and it would be good if the font filter could be improved by for instance listing the maybe 3 to 5 user-dependent (user-specific) most often used fonts at the beginning.  Currently, the font list adapts in that way that the last used fonts will be shown at the beginning after they had been selected.  
I don't know if there are maybe also other good/better solutions, but for me Jay's proposals sound interesting to think about (especially No. 1, regarding No. 2 I am not yet sure, because it should further be easy to select different and new fonts without "many" mouse clicks).
Comment 3 Yousuf Philips (jay) (retired) 2015-05-07 23:03:53 UTC
(In reply to Heiko Tietze from comment #1)
> I'd appreciate such a filter. But what is the default for all OS?

As stated in the description, the default set of fonts would be of commonly used fonts found in documents, and this would be irrelevant of OS, as documents are not OS dependent. But if for example a linux user doesnt have one of these default fonts installed, it wouldnt show in the list unless he opened a document that contained it.

> Times New Roman... please don't (unless on Windows). Helvetica, Garamond?

Times New Roman is a very commonly used font in documents, as it was the default font used in Microsoft Office until MSO 2007, and still is the default font used in a number of office suites (WordPerfect, WPS/Kingsoft, AbiWord).

Helvetica isnt as commonly used in documents, except for being the default font used in iWork.

> And does it makes sense to mix sans, serif, and mono fonts?

What is your reasoning behind not mixing them? Most users know fonts by their names and not by their style classification.

> Whats about the recently used?

It would act similar to how it is now, with the list of recently used fonts would appear at the top.

I believe the list would be of both open source and proprietary fonts in sans, serif, monospace, symbol, and possibly script/handwriting. This list would also have to work in various languages. The list would have to be saved and restored when opening and closing LibreOffice, so a user doesnt have to re-add fonts in a new session.
Comment 4 Bastián Díaz 2015-10-09 14:36:36 UTC
It's amazing to have a better font list.

Please consider GtkFontChooserDialog elements (https://developer.gnome.org/gtk3/stable/GtkFontChooserDialog.html) to be included in the fonts list or character dialog.

-Neutral sentence to font preview: The font preview through its name is very ineffective. For example, the Tinos font, only available 5 characters to preview, on the other hand, it is more difficult to compare with other fonts.

-Better search engine: In gtkfontchooserdialog, to write "mono" appear all font containing that word, In LO Writer instead on only appears the font that starts with this word (assumes that you know the exact name of the fonts installed on your system).

--

Another important element is the document fonts (embedded or used in the document). In the case of not being installed on the system, marked as "not available".

Cheers
Comment 5 Yousuf Philips (jay) (retired) 2015-10-11 12:51:41 UTC
(In reply to Bastián Díaz from comment #4)
> Please consider GtkFontChooserDialog elements
> (https://developer.gnome.org/gtk3/stable/GtkFontChooserDialog.html) to be
> included in the fonts list or character dialog.
> 
> -Neutral sentence to font preview: The font preview through its name is very
> ineffective. For example, the Tinos font, only available 5 characters to
> preview, on the other hand, it is more difficult to compare with other fonts.

As it is likely only gtk3, it wouldnt be a solution that would work everywhere and the better solution would be to have live preview of the font change with the text in the document rather for an arbitrary sentence in a dialog. I used to use standalone apps on Windows that used to provide this features. ( http://www.techsupportalert.com/best-free-font-manager.htm )

> -Better search engine: In gtkfontchooserdialog, to write "mono" appear all
> font containing that word, In LO Writer instead on only appears the font
> that starts with this word (assumes that you know the exact name of the
> fonts installed on your system).

Definitely a nice feature to have of filtering out the font list. Would suggest that you suggest this in another enhancement bug report, as it is outside of the scope of this one.

> Another important element is the document fonts (embedded or used in the
> document). In the case of not being installed on the system, marked as "not
> available".

Bug 78186.
Comment 6 Bastián Díaz 2015-10-11 17:22:36 UTC
(In reply to Yousuf (Jay) Philips from comment #5)
> As it is likely only gtk3, it wouldnt be a solution that would work
> everywhere 

I was referring to consider the design elements do not use the same implementation.

and the better solution would be to have live preview of the font
> change with the text in the document rather for an arbitrary sentence in a
> dialog. I used to use standalone apps on Windows that used to provide this
> features. ( http://www.techsupportalert.com/best-free-font-manager.htm )
> 

That sounds MS Office. Imagine that works with the current selection, but how work with styles or font themes?. 

> Definitely a nice feature to have of filtering out the font list. Would
> suggest that you suggest this in another enhancement bug report, as it is
> outside of the scope of this one.
> 

OK

> > Another important element is the document fonts (embedded or used in the
> > document). In the case of not being installed on the system, marked as "not
> > available".
> 
> Bug 78186.

Thanks
Comment 7 Robinson Tryon (qubit) 2016-08-25 05:26:52 UTC Comment hidden (obsolete)
Comment 8 Heiko Tietze 2017-11-04 15:00:19 UTC
*** Bug 113089 has been marked as a duplicate of this bug. ***
Comment 9 Khaled Hosny 2018-02-01 19:24:33 UTC
I’d close this WONTFIX, Font management is not something we should concern ourselves about. Users with hundreds of fonts should use specialized font management software that are available for all major operating systems.
Comment 10 Ole Tange 2018-02-02 14:35:26 UTC
Created attachment 139530 [details]
Drop down with substring search

Mockup of what a fontselector could look like.

The text field is for entering substrings, that will dynamically filter the list. The substrings can be positive (must contain) or negative (cannot contain).

In this example the font names must contain the substrings 'igh' and 's', but cannot contain 'old'.

The first column is for fonts used in the current documents.

The goals have been:

* To make it easy to select fonts already used in the document.
* To avoid scrolling when there are many fonts - both by presenting many fonts and by dynamically filtering by substring. On my system the system administrator decides which fonts are on the system - not me.

It is fairly backwards compatible: If you write the full font name it will still match as substring.
Comment 11 Heiko Tietze 2018-02-04 11:22:28 UTC
(In reply to Ole Tange from comment #10)

Interesting idea - and I added it right to the presentation I held at FOSDEM yesterday. You find the slides at https://de.slideshare.net/HeikoTietze/improvements-to-font-handling-in-libreoffice

But I doubt that a multi-column dropdown is a good solution. You need some kind of overflow mechanism anyway, meaning vertical or horizontal scrolling is required. Could be solved, but even more important is the question if users need and want this large selection at once. IMHO the goal is to quickly select one item/font and not to show as many as possible.

Just my first impression. Plan is to discuss the whole story in the design team and to figure out how all aspects can be solved. You are very welcome to join us.
Comment 12 Ole Tange 2018-02-05 11:06:19 UTC
Created attachment 139592 [details]
Mockup2 of multi-column font selector

> But I doubt that a multi-column dropdown is a good solution.

An A/B-test might determine that.

Personally I prefer never having to use a scroll bar: I will much rather be presented with all the information that fits on the screen and only when theres is more information then have a scroll bar.

> You need some kind of overflow mechanism anyway, meaning vertical or horizontal scrolling is required.

We do not have horizontal scrolling now. I suggest we simply take the current 1-column layout and do as many columns of those as will fit on the screen (or window) width.

If we did that, I would be able to see around 10x as many fonts on my system.

First column is still reserved for fonts used in the document.

See mockup2.

Sorting should not be done as in the mockup, but instead have them sorted left-to-right:

A.. A.. B.. C..
C.. C.. D.. D..
D.. E.. F.. F..

> Could be solved, but even more important is the question if users need and want this large selection at once. IMHO the goal is to quickly select one item/font and not to show as many as possible.

The substring filtering will solve that for fonts not already in use: If you want all font containing 'Bold' you simply enter 'Bold' and all the remaining fonts in the list will contain the string 'bold'.

If you enter 'abo tse' you will probably only get 'Montserrat ExtraBold', as very few other font will match that 'tse' and 'abo'.

For fonts already used in the document, I suggest they are listed in the first column for easy selection.
Comment 13 Heiko Tietze 2018-02-05 11:19:02 UTC
(In reply to Ole Tange from comment #12)
> I suggest we simply take the
> current 1-column layout and do as many columns of those as will fit on the
> screen (or window) width.
> 
> If we did that, I would be able to see around 10x as many fonts on my system.

And it's still not enough when you have 1000 fonts as someone posted on a ticket. Most users have around 20-50 but again do they want to see all at once?

> The substring filtering will solve that for fonts not already in use: If you
> want all font containing 'Bold' you simply enter 'Bold' and all the
> remaining fonts in the list will contain the string 'bold'.

Yes, that's how the filter should work.
Comment 14 Yousuf Philips (jay) (retired) 2018-02-05 19:58:36 UTC
(In reply to Ole Tange from comment #10)
> The text field is for entering substrings, that will dynamically filter the
> list. The substrings can be positive (must contain) or negative (cannot
> contain).

Nice concept but way to complicated for the regular LO user, so would have very limited benefit. Have to agree with Heiko that a multi-column approach isnt useful.
Comment 15 Heiko Tietze 2018-02-13 10:00:50 UTC
*** Bug 115186 has been marked as a duplicate of this bug. ***
Comment 16 Ole Tange 2018-02-13 13:30:29 UTC
Created attachment 139865 [details]
Dynamic font selector

Here is an "animation" of how I see the font selector may work.

For novices they simply type the font they want.

For advanced users they type sub strings to limit the list.

For experts they figure out the minimal sub strings they can use to hit a single font and then press enter to select it.

The list is dynamically filtered after each keypress and contains 2 lists:

* First column for the fonts used in the document
* The remaining columns are for all installed fonts.
Comment 17 Yousuf Philips (jay) (retired) 2018-02-16 20:19:14 UTC
Created attachment 139953 [details]
sections headings inside of the font name list

MS has 'theme fonts' and 'recently used fonts' sections in the list and we can use a similar design to have 'preferred fonts' (locale default sans and serif fonts), 'document fonts', etc.
Comment 18 Heiko Tietze 2018-02-17 08:15:56 UTC
(In reply to Ole Tange from comment #16)
> Created attachment 139865 [details]
> Dynamic font selector

Many thanks for your proposal. We talked about this idea yesterday and some questions remain.

* Simplicity
It is a huge control spawning over the whole screen but the use case is not to see all. And search (type and filter the dropdown) replaces the need for a large overview.

* Start from sidebar and withing dialogs doesnt work
Dropdown is not only located in the top left area but also in dialogs and at the sidebar. The layout wont work on all positions.

* Scrolling unclear
Many columns mean you either scroll all, or each column individually, or you scroll horizontally. Not defined in the mockup and yet quite complicate.

* Keyboard only usage not simple
Consider a keyboard only interaction where the user type Montse and presses down and enter to get the font she is looking for. In your proposal either many arrow steps or the mouse is needed.

* Slow generation of this grid
The grid with WYSYWIG font preview sounds like a challenge for performance.

If users would need such an overview we could alternatively add a deck to the sidebar.
Comment 19 Ole Tange 2018-02-19 13:51:15 UTC
> * Simplicity
> It is a huge control spawning over the whole screen but the use case is not
> to see all. And search (type and filter the dropdown) replaces the need for
> a large overview.

Why is it not _a_ use case to see all the fonts? I would reckon many users do not have an overview over all the fonts they have installed (I, for one, do not, and I consider myself advanced user). I agree this is not the _primary_ use case, but I really do not see why giving this overview should be seen as something negative.

There is a reason we also let people see more than one file name in a directory listing: It is simpler if they can get an overview by seeing more files.

In other words: I still do not understand how it is a goal to make it harder to see all the fonts installed. Because the extension of that argument would be that it would be simpler to present a single font at a time.

Maybe you can enlighten me?

> * Start from sidebar and withing dialogs doesnt work
> Dropdown is not only located in the top left area but also in dialogs and
> at the sidebar. The layout wont work on all positions.

Can you provide a screenshot of an example where you cannot envision this will work? Then I may be able to suggest a mockuped solution.

> * Scrolling unclear
> Many columns mean you either scroll all, or each column individually, or
> you scroll horizontally. Not defined in the mockup and yet quite complicate.

As the fonts are sorted, the scrollbar will be at the right hand side controlling all columns. Just as if you had a multi-column table on a normal page in Writer.

The font dropdown already does scrolling of at least 2 columns: Font name and font preview of non-western fonts.

If it is still unclear how this would work, I will be happy to make a mockup showing the scroll bar and some scrolling action.

> * Keyboard only usage not simple
> Consider a keyboard only interaction where the user type Montse and presses
> down and enter to get the font she is looking for. In your proposal either
> many arrow steps or the mouse is needed.

To select 'Montserrat' the user will type: Mont

While the user does that, the dropdown dynamically filters the list. When the final 't' is pressed the dropdown only shows these fonts (These are the only fonts on my system that match the substring 'mont'):

Montserrat
Montserrat Black
Montserrat ExtraBold
Montserrat ExtraLight
Montserrat Hairline
Montserrat Light
Montserrat SemiBold
Montserrat Thin
Montserrat Ultra Light

Then the user presses 'down' to highlight [Montserrat] followed by 'Enter'.

In total 6 keypresses - including writing 'Mont'.

If this is unclear, I will be happy to make a mockup "animation" showing this.

How many keypresses would you find is acceptable including writing 'Mont'?

And while we are on it: How many mouse clicks/scroll-events would you find acceptable to choose a font?

> * Slow generation of this grid
> The grid with WYSYWIG font preview sounds like a challenge for performance.

I agree, but I see several solutions for that.

On slow machines generating preview of the full fontlist is somewhat of a task. One solution would be to generate those previews in the advance and cache those on disk. My testing shows that a preview PNG of a font is around 2 kb.

The generating could be done when LibreOffice starts or when the dropdown is accessed. If a preview PNG exists for the font, use that, otherwise generate a PNG, and save it to the disk.

To make the UI responsive you could use a default font until the preview is generated or loaded from disk. When opening the list the first time it will then look similar to a web page where a lot of images is loading in parallel.
Comment 20 Heiko Tietze 2018-02-19 15:15:35 UTC
(In reply to Ole Tange from comment #19)
>> * Simplicity
> Why is it not _a_ use case to see all the fonts?

The user story would be "Benjamin wants to get an overview as he don't know what fonts are installed on the current system" and this is more up to the font management tool than to the word processor.

>> * Start from sidebar and withing dialogs doesnt work
> Can you provide a screenshot of an example where you cannot envision this
> will work?

Just open the character dialog. Or think of the sidebar. Put the font name combobox somewhere at the bottom.
 
>> * Keyboard only usage not simple
> In total 6 keypresses - including writing 'Mont'.

Sure, you can enter the font name. But wouldn't the user expect to select with "Mo" and cursor down?


Your solution would suit the third option in this recent post about improvements for font listing https://design.blog.documentfoundation.org/2018/02/18/improvements-font-listing/ and we discussed it respectively. But the nobody was really thrilled by your idea.
Comment 21 Ole Tange 2018-02-19 17:34:55 UTC
Created attachment 139996 [details]
Dynamic font selector (rev 2).

> * Simplicity
> It is a huge control spawning over the whole screen but the use case is not to see all [fonts].


How about this use case:

Benjamin wants to select a different font fast. The font is not in a recent used list, but amongst all the installed fonts. Benjamin is not interested in spending a lot of time on configuring his font setup.

Here being able to see the wanted font quickly is important. That the control is huge less important: Benjamin’s focus is on finding the correct font fast; his focus is not on any other controls on the screen, thus it is not important that he can see any other controls on the screen.


Or this use case (which is a situation I have been in multiple times):

Benjamin wants to use a font, but cannot remember the start of the font name. However, he knows part of the name is ‘light’. The font is not in a recent used list, but amongst all the installed fonts. Benjamin is not interested in spending a lot of time on configuring his font setup.

A real example of this are the Microsoft fonts: Some of them are prefixed with ‘Microsoft’, others with ‘MS’ and yet others with ‘MS Office’. Take ‘MS Office Symbol Light’ as example: I would perfectly understand if a user searched for ‘symbol’ to find that one.


Or this use case (which is a situation I have also been in):

Benjamin wants to select a font. He cannot remember the name, but he knows what it looks like.

Again you really want a lot of fonts to be displayed at once.


> Sure, you can enter the font name. But wouldn't the user expect to select [Montserrat] with "Mo" and cursor down?


After typing ‘Mo’ the dynamically filtered list is the following ([] denotes substrings that are highlighted in yellow):

DejaVu Sans [Mo]no
E[mo]jiOne Color
Gara[mo]nd
Liberation [Mo]no
[Mo]dern No. 20
[Mo]ngolian Baiti
[Mo]notype Corsiva
[Mo]ntserrat
[Mo]ntserrat Black
[Mo]ntserrat ExtraBold
[Mo]ntserrat ExtraLight
[Mo]ntserrat Hairline
[Mo]ntserrat Light
[Mo]ntserrat SemiBold
[Mo]ntserrat Thin
[Mo]ntserrat Ultra Light
Segoe UI E[mo]ji

thus the user will expect “DejaVu Sans Mono” to be active when pressing ‘down’. Pressing down again with make “EmojiOne Color” active. Pressing Enter will select it.

- o -

It is clear that I have not been able to communicate the idea so clearly that you have understood it. I have updated the “animation” with an example where the user enters ‘lig’, gets a dynamically filtered list, presses ‘down’, ‘down’, ‘right’, and ‘enter’ to select the font.

I have also included an example of the character dialog and a windows with very little screen estate below the search field. The solution to both of these is the same as a normal dropbox: Put the values above the search field.

(And I have added a scroll bar, so it is clear that the box can scroll down but not sideways – just like the current font dropbox).
Comment 22 Heiko Tietze 2018-02-19 18:26:02 UTC
(In reply to Ole Tange from comment #21)
> Benjamin wants to select a font. He cannot remember the name, but he knows
> what it looks like.

That's the only valid use case, IMHO. All other are handled by the filter or auto-completion. And don't worry, I understand your idea how to filter, much better than today. What I refuse (and other people I talked to as well) is the multi-column output. A suggestion was to show fonts in an extra sidebar deck.
Comment 23 Rizal Muttaqin 2018-02-28 07:50:06 UTC
Created attachment 140204 [details]
ThinkFree Office font list's preset menu

For additional reference, we could consider what ThinkFree Office does to font list's preset menu. The left side placement is smart enough.
Comment 24 Heiko Tietze 2018-03-19 10:31:26 UTC
*** Bug 116446 has been marked as a duplicate of this bug. ***
Comment 25 Ole Tange 2018-03-19 12:14:17 UTC
(In reply to Heiko Tietze from comment #22)

> What I refuse (and other people I talked to as well) is the multi-column output.

Can you elaborate on why? What is the problem in presenting multiple columns? And how does this use differ from other situations in which we use multiple columns for presenting choices (e.g. File > New > Templates)?

I can justify why I prefer the multi-column output: IMHO the goal is to quickly identify and select one item. By using a multi-column approach we can avoid having Benjamin scrolling a huge list, but instead present more options on the screen at once. It is extremely fast see the font, very fast to select the font using arrow keys/page up/down and Enter; and it is reasonably fast to click on it with the mouse.

We can have one column reserved for fonts used in the current document (with a subscript of what style they are used in - see Yousuf's screenshot).

It is simple to use, scrolling is clear, keyboard usage is fast, and the generation of previews can be cached thus does not have to be slow.

Currently Benjamin has to scroll a huge list, and given the amount of comments about this, I think it is safe to say that scrolling through a huge list is not a good solution.

So I feel it would be beneficial to the discussion if you can elaborate on the reasons why you (and the people you talked to) refuse the idea. Maybe your concerns can be addressed in an even better solution.
Comment 26 Heiko Tietze 2018-03-21 07:03:34 UTC
(In reply to Ole Tange from comment #25)
> > What I refuse (and other people I talked to as well) is the multi-column output.
> Can you elaborate on why? 

You focus on the presentation of the list content while dropdowns and list views usually are there to select an item. When those lists grow the typical approach for quicker selection is a filter on typing and proper sorting. Your proposal is not a lightweight standard control anymore and has accessibility issues. In a one-dimensional list the navigation is done per cursor up/down while two dimensions multiply the effort (plus all the trouble around impaired users that have to relay on screen readers). And mentioned before I doubt that scrolling works nicely as your columns are filled unequally.

> I can justify why I prefer the multi-column output: IMHO the goal is to
> quickly identify and select one item. 

If you read interface styleguides you will not find the identification aspect being relevant for lists. 

Your idea is nice for the overview (I would focus on this part ignoring column types), additional to the selection. And you could realize it yourself as an extension. How about that?
Comment 27 Dieter Praas 2018-08-17 09:11:51 UTC
*** Bug 119199 has been marked as a duplicate of this bug. ***
Comment 28 Heiko Tietze 2018-09-03 06:59:05 UTC
*** Bug 60626 has been marked as a duplicate of this bug. ***
Comment 29 Dieter Praas 2018-09-17 07:15:15 UTC
*** Bug 119915 has been marked as a duplicate of this bug. ***