Bug 88416 - UI: Allow hiding fonts from font drop down list in options dialog
Summary: UI: Allow hiding fonts from font drop down list in options dialog
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
(earliest affected)
Inherited From OOo
Hardware: Other All
: medium enhancement
Assignee: Not Assigned
Keywords: needsDevEval, topicUI
: 36492 91036 150113 (view as bug list)
Depends on:
Blocks: Options-Dialog Font-List
  Show dependency treegraph
Reported: 2015-01-14 18:23 UTC by Geoffrey
Modified: 2023-01-30 18:33 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:

fonts preferences section in scribus (109.04 KB, image/png)
2015-03-19 23:55 UTC, Yousuf Philips (jay) (retired)
textmaker's options dialog's fonts tab (25.11 KB, image/png)
2017-10-15 22:37 UTC, Yousuf Philips (jay) (retired)

Note You need to log in before you can comment on or make changes to this bug.
Description Geoffrey 2015-01-14 18:23:15 UTC
I would like to have the ability to hide fonts/font families from the font list in LibreOffice, without removing the fonts from my system. This option could be integrated into the LibreOffice options GUI.

For the implementation, I was thinking about a ListBox.
Comment 1 Robinson Tryon (qubit) 2015-01-14 20:21:03 UTC
UX Team: Assemble!
Status -> NEW
Component -> ux-advise
Severity -> enhancement
Comment 2 Yousuf Philips (jay) (retired) 2015-03-02 03:36:48 UTC
Well it could be put in Tools > Options > Fonts, but with most users, they have a long list of fonts, so many it would be easiest to allow the user to specify the only fonts he/she wants to see in the font list.
Comment 3 Yousuf Philips (jay) (retired) 2015-03-19 23:55:30 UTC
Created attachment 114199 [details]
fonts preferences section in scribus

Was going through Scribus today and noticed they had a section in their preferences for the user to select which fonts they want to have available in their interface, so i've attached a screenshot of how they present it.
Comment 4 Geoffrey 2015-03-20 08:48:16 UTC
Good screenshot. For the implementation in LibreOffice however, I would choose to work with font families instead of fonts. Otherwise the view is cluttered really fast.
Comment 5 Yousuf Philips (jay) (retired) 2015-03-20 12:09:52 UTC
Yes by font family would be the way to go, though LO doesnt detect font families correctly (bug 72944), so one way or another the list will be cluttered. :D

So i'd assume the grid would have the following fields :-

enable checkbox
family name
number of styles
Comment 6 Geoffrey 2015-03-20 15:00:53 UTC Comment hidden (obsolete)
Comment 7 Yousuf Philips (jay) (retired) 2015-03-20 20:23:30 UTC Comment hidden (obsolete)
Comment 8 k.wuestermann 2015-05-07 12:55:33 UTC
*** Bug 91036 has been marked as a duplicate of this bug. ***
Comment 9 Robinson Tryon (qubit) 2015-12-13 11:24:05 UTC Comment hidden (obsolete)
Comment 10 Yousuf Philips (jay) (retired) 2017-10-15 22:37:09 UTC
Created attachment 137006 [details]
textmaker's options dialog's fonts tab
Comment 11 Yousuf Philips (jay) (retired) 2017-10-19 11:05:54 UTC
*** Bug 36492 has been marked as a duplicate of this bug. ***
Comment 12 Coburn Ingram 2022-04-22 15:13:33 UTC
The elephant in the room is that the LO font list is unbelievably cluttered with a default install (using Gnome on Ubuntu). If your default is EN-US, you get lots of fonts installed that are used in English-speaking countries that you will never use! I am referring especially to Indic and Asian fonts.

The solution to that problem is to metapackage Indic and Asian fonts upstream, and only install them when a user chooses a locale where they are used! But until Gnome/Ubuntu get their act together, LO needs to have a way to hide font packages and metapackages. The upstream locale inadequacies simply highlight the need for a font selection list. It is obviously useful in other contexts. Just keep it simple! A clutter problem does not call for a cluttered answer. Thanks.
Comment 13 Buovjaga 2023-01-30 18:33:39 UTC
*** Bug 150113 has been marked as a duplicate of this bug. ***