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.

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).

(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.

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

(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.

(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

*** Bug 113089 has been marked as a duplicate of this bug. ***

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.

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.

(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.

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.

(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.

(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.

*** Bug 115186 has been marked as a duplicate of this bug. ***

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.

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.

(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.

> * 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.

(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.

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).

(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.

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.

*** Bug 116446 has been marked as a duplicate of this bug. ***

(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.

(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?

*** Bug 119199 has been marked as a duplicate of this bug. ***

*** Bug 60626 has been marked as a duplicate of this bug. ***

*** Bug 119915 has been marked as a duplicate of this bug. ***

Proposal has been mad in this blog post https://design.blog.documentfoundation.org/2018/02/18/improvements-font-listing/. 

Removing UX to attract devs.

*** Bug 101748 has been marked as a duplicate of this bug. ***

Changing priority to 'high' since the number of duplicates is 5 or higher

*** Bug 130396 has been marked as a duplicate of this bug. ***

*** Bug 140519 has been marked as a duplicate of this bug. ***

*** Bug 143021 has been marked as a duplicate of this bug. ***

*** Bug 148209 has been marked as a duplicate of this bug. ***

*** Bug 136943 has been marked as a duplicate of this bug. ***

*** Bug 148643 has been marked as a duplicate of this bug. ***

Created attachment 186234 [details]
GoogleDocs approach to organizing font families

Using version: LibreOffice 7.5.1

I think this case has two challenges as below:

Challenges:
1. Users have no specific liking of which font they want to use this time (Some of them may know little about fonts)
2. Users know which font they want to use but are exhausted from finding it from the very long dropdown list. Users' eyes are too busy.

For each challenge, here are my ideas:
-1. Users have no specific liking of which font they want to use this time (Some of them may know little about fonts)
IDEA: Put 3-5 fonts that are familiar to most users at the top of the dropdown box, such as Arial and the SF font family. This will help users not well-versed in fonts choose a font that suits their needs easily.

-2. Users know which font they want to use but are exhausted from finding it from the very long dropdown list. Users' eyes are too busy.
IDEA: Organize the same font family into one row. For example, SF Pro, SF Pro Display, SF Pro Rounded, and SF Pro Text can all be collapsed under "SF Pro" with an icon ">" on the right. This will help users who know which font they want to use but are having trouble finding it in the long list. They can simply click on the icon ">" to select the font they want. This way could reduce the length of the long dropdown font list.

A screenshot of the Google Docs font selection is provided, which demonstrates a similar approach to organizing font families. I would be glad to discuss if these ideas would be practical.

One thing that would really help is linking the default installed fonts to a user's LOCALE in the operating system. This is an upstream problem, but what happens on my Ubuntu system, when I choose US English as my install language, I get ALL KINDS of fonts installed that absolutely NOBODY in the continental US has ever heard of, let alone knows how to use. The fact that 128 million people in India speak English has absolutely NO BEARING on the fonts I need or want. They have their own locale! Let them install the fonts they like! A user who installs an OS with an EN-US locale should have absolutely NO non-English fonts on their system. Maybe a good Unicode font or two, in order to display web pages. But we should not have MORE non-English fonts than English. WE DON'T USE THEM!

And so when it comes to LibreOffice, as I said, this is an upstream problem, and it is not going away right now. What we ought to have, plain and simple, is a page in Tools | Customize that allows us to CONFIGURE the font-menu! It just needs to be set up like the regular menu configuration, with the ability to reorder the fonts, and most important, a CHECKLIST that allows us to filter and NOT DISPLAY system-wide fonts. It needs to be its own tab in the Customize window.

I will say that sorting fonts alphabetically is nice. It works for me. My only problem is that the system does not allow me to fine-tune the display of those fonts in any way. LO could provide that way. I highly encourage it. Thanks.

(In reply to Arlene from comment #40)
> IDEA: Put 3-5 fonts that are familiar to most users at the top...
Rather the recently used.

> IDEA: Organize the same font family into one row.
Good idea. Turns the simple list into a tree, however, but hides away all the annoying Noto fonts ;-). OTOH, it's always a good idea to keep the UI simple- and the tree with all fonts could also come after the recently used per "More..." in an extra dialog.

> A screenshot of the Google Docs font selection...
This is a solution for bug 35538 "Handling of fonts with more than 4 styles". But makes the idea clear.

(In reply to Coburn Ingram from comment #41)
> One thing that would really help is linking the default installed fonts to a
> user's LOCALE in the operating system.

This is bug 148337 being a duplicate of bug 91886 as well as bug 103140	and other. Keeping the list clean is one approach, could be done at the installation or per deinstallation, hiding/filtering items another, but a better organization is needed anyway for people using a lot of different fonts.

Created attachment 186255 [details]
Wireframe1.0 of my ideas about redesigned font selector-Arlene

Please see my wireframe of my ideas for this bug:
1. More Fonts (thinking...)
2. Theme Fonts (3-5 most users familiar fonts)
3. All Fonts (display alphabetically)
4. Recent Fonts (Only after users have used at least one font will it appear in the font selector. Max 5 most recent fonts here)

Feedback is needed. Please see if this wireframe can be practical from both UX and development perspectives.

(In reply to Heiko Tietze from comment #42)
> (In reply to Arlene from comment #40)
> > IDEA: Put 3-5 fonts that are familiar to most users at the top...
> Rather the recently used.
> 
> > IDEA: Organize the same font family into one row.
> Good idea. Turns the simple list into a tree, however, but hides away all
> the annoying Noto fonts ;-). OTOH, it's always a good idea to keep the UI
> simple- and the tree with all fonts could also come after the recently used
> per "More..." in an extra dialog.
> 
> > A screenshot of the Google Docs font selection...
> This is a solution for bug 35538 "Handling of fonts with more than 4
> styles". But makes the idea clear.

Thanks for replying. I agree that always keeping the UI simple would be great for users, and relieve their workload. At the same time, provide customized options for advanced users and improve their efficiency. I am thinking about how to let advanced users be happier of the font selector. 

Feel free to comment on this post about how you(every user of LO) would like some customization of the font selector.

(In reply to Arlene from comment #43)
> 1. More Fonts (thinking...)
What is this about?

> 2. Theme Fonts (3-5 most users familiar fonts)
The term "Theme" is occupied as a collection of design elements around a document. If that's your idea I wonder how to manipulate it.

> 3. All Fonts (display alphabetically)
> 4. Recent Fonts (Only after users have used at least one font will it appear
> in the font selector. Max 5 most recent fonts here)
It's most likely that you pick one from the favorite fonts. Would show this on top (and All on bottom)

In general, the duplication of items (Arial, for instance, is listed in Recent, Theme, and All) in the categories bloats the list. Would show it only once.

> Feel free to comment on this post about how you(every user of LO) would like some customization of the font selector.

On my machine I have not actively added fonts. I have ~250 fonts installed.

When selecting a font I sometimes know what I am looking for. Maybe I know it is called something with "Gothic", but I cannot remember that it is really called "MS Gothic". In this case it is important for me, that I can find the font if I know parts of the name. In other words: Sorting will not help me here, because I will be looking under 'G' when I should be looking under 'M'. Substring search would be preferably.

Other times I am looking for a special look of the font, but have no idea what it might be called. For this I need a way to see as many font samples on the screen as possible.

If I write in Thai, it would be important to me that I could choose to only show fonts that had Thai letters. I imagine this is a problem for languages, too. It would be OK, if this filtering is a bit harder to do (E.g. behind an "Advanced" button).

(In reply to Heiko Tietze from comment #45)
> (In reply to Arlene from comment #43)
> > 1. More Fonts (thinking...)
> What is this about?
I was thinking about putting the Sort/Filter feature after people click on this, advanced users can better find what they are looking for. But I am still in the ideation process and need feedback and ideas.

> > 2. Theme Fonts (3-5 most users familiar fonts)
> The term "Theme" is occupied as a collection of design elements around a
> document. If that's your idea I wonder how to manipulate it.
I think calling it "Popular Fonts" could be less confusing.
 
> > 3. All Fonts (display alphabetically)
> > 4. Recent Fonts (Only after users have used at least one font will it appear
> > in the font selector. Max 5 most recent fonts here)
> It's most likely that you pick one from the favorite fonts. Would show this
> on top (and All on bottom)
Do you mean "Recent Fonts" at the top, "Favorite Fonts (Popular Fonts)" in the middle, and "All Fonts" at the bottom?


> In general, the duplication of items (Arial, for instance, is listed in
> Recent, Theme, and All) in the categories bloats the list. Would show it
> only once.
Good point. I understand this would not make users not see the same font repeat in multiple categories. But my point is the "Recent Fonts" would have only displayed the most recently used 5 fonts and is in changing with users' behavior. For example, when a user first used Arial font and then used another 5 fonts, then Arial would not appear on "Recent Fonts" anymore, so I am thinking about whether it is good that we still keep Arial in both "Recent Fonts" and "All Fonts" at the same time as "Recent Fonts" list is always changing.

(In reply to Ole Tange from comment #46)
> > Feel free to comment on this post about how you(every user of LO) would like some customization of the font selector.

> On my machine I have not actively added fonts. I have ~250 fonts installed.
Thank you Ole for providing those great ideas!

> When selecting a font I sometimes know what I am looking for. Maybe I know
> it is called something with "Gothic", but I cannot remember that it is
> really called "MS Gothic". In this case it is important for me, that I can
> find the font if I know parts of the name. In other words: Sorting will not
> help me here, because I will be looking under 'G' when I should be looking
> under 'M'. Substring search would be preferably.
Yes! I agree that Substring search would be very useful for users. It is common that users only remember part of the name of fonts and want to use that memory to find the font they want. I feel this feature would need to talk with develop team to see their ideas or constraints in it.
 
> Other times I am looking for a special look of the font, but have no idea
> what it might be called. For this I need a way to see as many font samples
> on the screen as possible.
It is really great that now LO has this preview feature. Do you have any ideas in improving it?

> If I write in Thai, it would be important to me that I could choose to only
> show fonts that had Thai letters. I imagine this is a problem for languages,
> too. It would be OK, if this filtering is a bit harder to do (E.g. behind an
> "Advanced" button).
I found several comments in here and other similar bugs that talk about this feature. A filter or sorting feature can let LO be customized in some certain way for users. That would be great. Maybe we could welcome more users to comment here about their ideas for the filter/Sort feature of the font selector.

(In reply to Arlene from comment #48)
> (In reply to Ole Tange from comment #46)
:
> > Other times I am looking for a special look of the font, but have no idea
> > what it might be called. For this I need a way to see as many font samples
> > on the screen as possible.
> It is really great that now LO has this preview feature. Do you have any
> ideas in improving it?

A way to see more fonts. Right now I can see ~20 fonts. So to scroll through 250 I will have to scroll 13 pages.

That feels sub-optimal since there is space for 5 times that many on my screen.

One solution would be to have multiple columns. My screen would fit 5 columns showing ~100 fonts. Meaning that I would only scroll 2.5 pages given my ~250 fonts.

Maybe this should not be the dropdown, but opening a window in itself, where you choose your favorite fonts from all fonts (including the ones that supports Thai - see below), and the dropdown only shows your favorite fonts?

In my day-to-day work use I use maybe 10 fonts. So it would be nice if these somehow were easily selected.

> > If I write in Thai, it would be important to me that I could choose to only
> > show fonts that had Thai letters. I imagine this is a problem for languages,
> > too. It would be OK, if this filtering is a bit harder to do (E.g. behind an
> > "Advanced" button).
> I found several comments in here and other similar bugs that talk about this
> feature. A filter or sorting feature can let LO be customized in some
> certain way for users. That would be great. Maybe we could welcome more
> users to comment here about their ideas for the filter/Sort feature of the
> font selector.

I think it ought to be reasonably easy to either select the language or type 'th' for Thai, 'da' for Danish and 'en' for English (possibly just use ISO 639-1). Given the language it should be possible to determine which UTF-8 characters that language requires, and if these are present in the font, then include the font in the filter. E.g. for Danish it would be a-z+æøå.

(In reply to Ole Tange from comment #49)
> (In reply to Arlene from comment #48)
> > (In reply to Ole Tange from comment #46)
> :
> > > Other times I am looking for a special look of the font, but have no idea
> > > what it might be called. For this I need a way to see as many font samples
> > > on the screen as possible.
> > It is really great that now LO has this preview feature. Do you have any
> > ideas in improving it?
> 
> A way to see more fonts. Right now I can see ~20 fonts. So to scroll through
> 250 I will have to scroll 13 pages.
> 
> That feels sub-optimal since there is space for 5 times that many on my
> screen.
> 
> One solution would be to have multiple columns. My screen would fit 5
> columns showing ~100 fonts. Meaning that I would only scroll 2.5 pages given
> my ~250 fonts.
I understand you as a user, that uses 10 fonts daily. You would need to see/select fonts quickly. But, multiple columns interrupt the vertical momentum of moving down the list. I would suggest keeping users in a single column with a separate row of fields.

> Maybe this should not be the dropdown, but opening a window in itself, where
> you choose your favorite fonts from all fonts (including the ones that
> supports Thai - see below), and the dropdown only shows your favorite fonts?
Great idea that to add a field of "Favourite Fonts", so users can add their most often used fonts in it, and no need to do searching work in every time they want to change a font.

> In my day-to-day work use I use maybe 10 fonts. So it would be nice if these
> somehow were easily selected.
> 
> > > If I write in Thai, it would be important to me that I could choose to only
> > > show fonts that had Thai letters. I imagine this is a problem for languages,
> > > too. It would be OK, if this filtering is a bit harder to do (E.g. behind an
> > > "Advanced" button).
> > I found several comments in here and other similar bugs that talk about this
> > feature. A filter or sorting feature can let LO be customized in some
> > certain way for users. That would be great. Maybe we could welcome more
> > users to comment here about their ideas for the filter/Sort feature of the
> > font selector.
> 
> I think it ought to be reasonably easy to either select the language or type
> 'th' for Thai, 'da' for Danish and 'en' for English (possibly just use ISO
> 639-1). Given the language it should be possible to determine which UTF-8
> characters that language requires, and if these are present in the font,
> then include the font in the filter. E.g. for Danish it would be a-z+æøå.
I agree this search way could be much easier for users to search for fonts. More feedback is needed from development perspective, I think. Welcome any ideas from the coding view to see if this substring search would be practical.

What people seem to be asking for is tools to streamline their work.

LO already provides a "recent" font list that populates automatically above the alphabetized list. This list is not always persistent. Fonts cycle in and out.

It seems like there are two things people want.

* A way to completely hide fonts from the main list.

* A way to "favorite" fonts that will then appear at the top of the list.

It may be a good idea to think of the font list as a "font dash," or a "font launcher." It would probably work to put "Hide Font" and "Favorite Font" in a right-click menu, in addition to having a checklist in Tools | Configure...

suggestions:

1/ Package LO as a stand-alone, all-inclusive flatpak. To include all help files, and a very limited set of generic fonts (eg Arial and Times). To exclude other fonts installed by gnome.

2/ At installation, users choose their Language Pack. This will ensure English users do not install fonts for Gujurati, Chinese, Japanese, Tamil, etc. 

3/ Add a menu macro that enable users to EASILY add or remove fonts either: they have downloaded from the web; or, installed from the LO site.

4/ Alter the LO drop down list to enable users to define, choose, label font categories. Example of Categories: Apple fonts; MS fonts; Fancy fonts; Foreign language fonts; etc.

(In reply to robgrune from comment #52)

> 4/ Alter the LO drop down list to enable users to define, choose, label font
> categories. Example of Categories: Apple fonts; MS fonts; Fancy fonts;
> Foreign language fonts; etc.

Great idea to let users have their customized categories. I made a wireframe in the attachments. Please check it and see any feedback.

Created attachment 186345 [details]
Wireframe2.0 of my ideas about redesigned font selector-Arlene

I have a straight forward suggestion:
Show the fonts that are already used in the document at the top separated by a line then all the available fonts accessible to LibreOffice.

For example: When I am choosing between Liberation Sans and Liberation Serif, I do NOT want to search ANY list: just click on the font drop-down and see the fonts currently used in the document.

If I want to search for others then I can type the font name or browse the list for a desirable font.

Just My 2 cents.
Thanks, Tracey

So, is there an accepted design, or approach, for this change? Or is it still in "brainstorming mode"?

Also, I wonder if all of these suggestions really belong on the same bug:

* Suggestions to make the "full" list shorter, e.g. the grouping font family variants (see also bug 35538) - I'd create a separate bug for that.

* Suggestions to have shortlists: By popularity among documents ever seen,  popularity among documents seen recently, by document theme/styles, by fonts already used, by marking fonts favorite

* Suggestions regarding selection layout: More submenus, multi-column