Not sure how much skipping installation of certain fonts can impact normal usage, but in general, this sounds like a reasonable enhancement.

and we can have situation when our Impress templates will look ugly by default

Possibly UX-team have own opinion?

I wish we would ship no fonts at all. The font management is up to the OS and if any random application installs additional fonts it becomes a mess. Another argument is that we have to keep the font up to date, which is not always guaranteed (see bug 121676 for example). 

No objection to make Liberation a dependency, speaking of Linux, or to bundle and have an installer option in case of Windows. But the ultimate solution to me is to make fonts part of the extension management. Whether we ship some or not, the update feature could work out of the box as well as the opportunity for users to uninstall.


Read also about "Dealing with Missing Fonts" at https://design.blog.documentfoundation.org/2016/10/21/dealing-with-missing-fonts/ and maybe "Improvements to Font Listing" at https://design.blog.documentfoundation.org/2018/02/18/improvements-font-listing/

But:

the fonts used in own templates must be present after installation (user uninstalling them later shoots in own leg deliberately) - these fonts missing would be a BUG - I definitely second comment 2 (and not only about Impress);

the fonts used in known metric-compatible substitutions must be present (this is a built-in mechanism for keeping document layout when interoperating with MSO).

Maybe there are more cases where missing fonts are BUG. Currently TDF package includes all dependencies including fonts; the fonts are handled as separate sub-packages, so that distros are free to exclude them and make them separate dependencies if needed (and Debian does that).

Installing fonts is normal for any application that needs them. On Windows, it's normal practice, e.g. MSO does that.

Making new extension category for fonts is absolutely wrong IMO: as mentioned, font management is OS feature, and those extensions would effectively create a duplicating font management mechanism.

I don't think this should be "fixed". If some of the bundled fonts are not necessary in the bundle, then inclusion of those was a mistake, and they should be dropped. But not all.

(In reply to Mike Kaganski from comment #4)
> Making new extension category for fonts is absolutely wrong IMO: as
> mentioned, font management is OS feature, and those extensions would
> effectively create a duplicating font management mechanism.

Which is exactly my argument against shipping fonts that users cannot get rid of. All those who don't care about compatibility, use own templates, don't want the Noto overkill... IMHO the extension solution gives users more freedom.

My take:
Summary: "Make fonts extensionizable"
Hardware/platform: All
Blocks: <none>

(In reply to Heiko Tietze from comment #5)
> Which is exactly my argument against shipping fonts that users cannot get
> rid of.

How cannot they get rid of them?

> All those who don't care about compatibility, use own templates,
> don't want the Noto overkill...

So the punch line should have been "Let's drop Noto"?

> IMHO the extension solution gives users more freedom.

Fonts-as-extensions is WRONG. You create a font (re)packaging and (re)distribution infrastructure, where each of those fonts is not created here. An extension is a creation of its author; it might include something from outside, but its essence is what is unique in it. A font-as-extension is just repackaging someone other's work. With possible licensing problems - much more severe than with current extensions, where each of them has very high chance to be intellectual property of those who upload them.

And then - you install such an extension, but - suddenly users *are* able to delete installed fonts using OS features, that are not synchronized with your extension mechanism. And then you have extensions that are easily broken from outside.

My take is PLEASE NO FONTS AS EXTENSIONS.

(In reply to Mike Kaganski from comment #6)
> A font-as-extension is just repackaging someone other's work.

... and in fact, each of such font has its "home", where it might be obtained from: freely if authors allow that; or otherwise, but in all cases legally, without entangling TDF and its sites into the mess.

I remember there was a discussion if certain fonts should be removed from the main .MSI package and put on a ancillary .MSI package (just like the offline help files are packaged), so the main .MSI file could be reduced in size by removing "obsolete" fonts.  The consensus at the time was that if a font is packaged, it should be always packaged because the user may have used it on its documents, removing the font would break the documents and the user could blame LibreOffice for showing "ugly" documents.

I agree with that, but I propose the following, which may please everyone (except maybe the people who make the .MSI packages):

* Each font family shipped should appear as a feature that could be disabled by the user and not installed (just like the interface languages, the dictionaries and other features can be disabled from installing);

* Each font family should have on its description text when installing a warning to the user that the font family is used on some templates that will not appear as they should and also could have been used on previous documents that will not appear as they should, unless the user installs the font family (of course the user can install the font family without help from LibreOffice .MSI package).  This description text is the one that appears on the right when the user chooses to do the custom install instead of the default install;

* If possible, a new message window warning the user when disabling the font installation should appear, so the user could select the "Ok" button or the "Cancel" button.  This message window should not be shown if the disabled font is deprecated;

* Now the .MSI packaged can be built to only install templates if the fonts they need are installed.  I prefer that LibreOffice installs the templates even if the fonts are not installed because the user can always get and install the needed font without help from LibreOffice.  I myself like to keep fonts installed to a minimum and only install them on the user account and not system wide (Windows 10 version 1909, maybe 1903, allows the user to install fonts this way, they go to the "%LocalAppData%\Microsoft\Windows\Fonts" folder), because the more fonts installed on Windows, more slowly Windows starts and more system resources are needlessly used;

* If possible, the .MSI can be built so the list of the packaged fonts which are installed (or the list of deactivated fonts) are sent to the developers (with user consent, of course, but enabled by default on silent installs and with a package property to switch it off).  This way, LibreOffice developers can track which fonts are installed or not to decide if the font should be packaged, deprecated (disabled by default on new installations, but when upgrading keeping the installed fonts -- just as LibreOffice .MSI packages already does for the other features), and finally not packaged anymore;

* The removed fonts from the main .MSI package could still be packaged on an ancillary .MSI package to be downloaded just like the offline help files are, if the .MSI package builders think it would be good.

Resuming, fonts would be installed by default, the user could choose to not install, when upgrading his/her choice would be preserved, and if there is telemetry of packaged fonts which are installed or not then LibreOffice could have a smaller .MSI package.

I myself prefer to manage the fonts outside of the LibreOffice installer package.  The task of updating fonts should not be a burden for LibreOffice developers, it should be made by the operating system's package manager (as is on NetBSD, FreeBSD, OpenBSD, various Linux distros, some Android distros, Haiku, OpenIndiana, etc.).  Even if Windows don't have a package manager outside of Microsoft Store (which has a Fonts section with freeware and paid fonts), LibreOffice installer could still give the user the option to use external font managers, such as SkyFonts that allow to use and automatically update Google Fonts (check https://www.fonts.com/web-fonts/google).

(In reply to João Paulo from comment #8)

We should only distribute fonts with LibreOffice that are needed by LibreOffice, and distribute them unconditionally.

The fonts are just another kind of resources, like DLLs or XCUs. Without them present on the system, the program would fail to work *as intended* (and as tested). Of course, they are installed system-wide (correctly, just like LibreOffice itself).

Any font that is not actually used in LibreOffice, and was added "because it's cool, free, and I like it!!111" should be unconditionally dropped from the package. E.g., *if* Noto fonts mentioned in comment 5 are not actually used in LibreOffice, they must go away (I personally hadn't check that about Noto, and just use it because of the mention above). Possibly there should be some design guidelines and some procedure in our Wiki regarding which fonts we may use in our templates (likely it exists already). But we should not remove or make optional anything else.

Trying to make packages more modular not only tries to put additional load on those who create installer (and in fact, it's a trivial task), but more importantly, to put more load on TDF as a non-profit organization to *support* more variety of configurations, without any hope that it would ever be able to test them. Any such configuration, if needed, must be backed by a custom distribution; e.g., those Linux distros that allow modular LO installations from their repos do have own people creating and supporting those packages; they have own bug trackers, etc. If someone wants to create a modular distribution for Windows based on LO, then they need to take the load of supporting them on themselves, so that inevitable results like "I installed, then this doesn't work" caused by using that additional flexibility would not drain the resources from the organization, precious resources better placed elsewhere.

(In reply to Mike Kaganski from comment #9)
> We should only distribute fonts with LibreOffice that are needed by
> LibreOffice, and distribute them unconditionally.

I think the OpenSymbol font is needed by LibreOffice, because it uses the symbols on the Math component and also the templates use it for the bulleted lists, and also the following font families are needed by LibreOffice to ease interoperability:  Liberation (Sans / Sans Narrow / Serif / Mono), Caladea and Carlito.  **Everything else is unneeded and I agree with you.**

But I don't agree that these fonts should be distributed unconditionally, as:

1) There are people/systems administrators who manages the installed fonts to keep them installed on the system to a minimum (LibreOffice would be another software installing unneeded/unwanted fonts);

2) Not everyone needs interoperability by default, as fonts can be embedded on the .odt files and people may need to send only PDF files instead of the source files (for example, my interoperability workflow is with PDFs with embedded fonts or with, unfortunately, .docx files using only fonts preinstalled with Windows if the other party needs to edit them).

Maybe my Comment #8 is way too complex to implement, as each font family would be made an optional feature on the .MSI package, but keeping the fonts distributed with LibreOffice to a bare minimum as on this Comment (OpenSymbol/Liberation/Caladea/Carlito) **and** making them (individually or as a group) as optional features installed by default could be a useful compromise.

(In reply to João Paulo from comment #10)

Again - please don't forget that not only "it should be done because someone possibly would ever need it" matters, but also "... and making it possible is maintainable - i.e. allows testing that it works".

If something is a resource, and its absence breaks functionality, than this is not optional. Built-in things like font substitution expects to find those fonts => they are required for correct operation. Unless someone volunteers to perform complete audit, and also provide extensive set of unit tests to cover "no fonts" scenario -> WF IMO.

But removing unnecessary fonts already bundled into LO would be great.

MS Windows already has a huge amount of installed system-fonts. And trust me when I say it is must painful to remove any of those because Microsoft's policy is all about compatibility.
The mechanism to avoid users from inconveniences by searching "endless" font-lists is done by flagging foreign language fonts. So applications don't load foreign language fonts by default but just when needed. This feature became more or less mandatory for Windows applications since Windows 7.
 
Unfortunately, LibreOffice still omit the capability of hiding foreign language fonts. Instead does LibreOffice install with its own blob of fonts - without asking the user for nor limiting fonts to the users region.

Also is LibreOffice's font-menu very basic. It doesn't limit the amount of shown fonts while searching be letters but jumps to the most related entry inside the full list. And scrolling inside the menu feels very uncomfortable to me, especially with many installed fonts where the list starts to lags.

For this reason do I fully agree to make font-installation optimal. As least for all unnecessary fonts, like the 48!! different Noto variants.

Just start with a review of the bundled 192 fonts, creating a list like:

> Font          - Required for LO functionality
> opens___.ttf  - Math; bullets
> Alef_Bold.ttf - ???
> ...

and then just remove everything that is not required for LO. Then re-visit the issue.

(In reply to Mike Kaganski from comment #13)
> Just start with a review of the bundled 192 fonts, creating a list like:
> 
> > Font          - Required for LO functionality
> > opens___.ttf  - Math; bullets
> > Alef_Bold.ttf - ???
> > ...
> 
> and then just remove everything that is not required for LO. Then re-visit
> the issue.

+1 for this approach; but some project obligation to packaging of removed fonts as extension for legacy usage?

Likewise UX-advise encouragement of extension to package demonstration fonts--e.g.  a Graphite enabled flavor of Libertinus, should we purge current Graphite enabled fonts as for bug 135788

Could someone please explain just *why* should LibreOffice redistribute fonts that are not created by LibreOffice, for LibreOffice, or required to LibreOffice? Maybe let's also start redistributing paper or printers on the grounds that they may be used for printing from LibreOffice? Or find likewise unrelated activity?

The Noto fonts have precious value for us because they give us wide language support. The Source fonts, on the other hand… not so much. After reading you, Mike, I came to the conclusion that bundling the Source fonts was a mistake (I proposed Source Serif back in the day). Another reason for their removal: Adobe will mess up with the font’s names to add version numbers, which will break users’ documents on upgrades. So we better remove them now from our build and our templates before this causes us more damage.

(In reply to Adolfo Jayme from comment #16)
> I came to the conclusion that bundling the Source fonts was a
> mistake

Please file an extra ticket.

I suppose I agree with comment #8.

Everytime I update LO it takes me an hour or so to get rid of undesiderated fonts and (mostly annoying) re-install the ones overwritten by an older version.

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

If the templates don't work without the excess fonts, then make the template part of the font option. I've removed the fonts and the basic word processor and spreadsheet work fine which is what I want. I personally never use any font except Times New Roman, Arial and Courier New and don't want to have to sort through a mess of useless, duplicative ones to get to the few I do use. Forcing fonts on the user represents and elitist attitude that says we know more about what should be on your computer that you do. That shouldn't be the attitude of an open source software organization.

(In reply to Adolfo Jayme from comment #16)
> The Noto fonts have precious value for us because they give us wide language
> support.

(In reply to Jean-Francois Nifenecker from comment #22)
> Some notes WRT the Source* fonts.
> 
> These fonts are good quality ones: they provide multiple weight variants
> which give a better result than software changes (change font instead of
> selecting the software rendered bold, for instance). Granted, they lack the
> italics rendering.
> 
> What the LibreOffice project should provide is a set of such high quality
> fonts: a set of fonts with separate weighted fonts (multiple levels) and
> italic fonts.

I don't buy this reasoning. Who should provide "a set of such high quality fonts", e.g. with "wide language support", is font forges that create the fonts. LibreOffice project should provide a tool that may use any fonts on the system, be it "high quality" or not (very subjective); it's up to user to decide if user wants "wide language support" or only their spoken language; if they need fonts with Graphite features or some dumb fonts, etc.

Only one thing matters here: if a font is required for proper functioning of the software itself. A font which absence makes software broken is a required resource, and as such must be available unconditionally. (FTR: in case of OpenSumbol, tdf#128226 had made it available locally in LibreOffice, without the need to install system-wide). Otherwise, if the font is not required to make LibreOffice functional, the font needs to be unconditionally excluded.

It's OK to keep some kind of knowledge base (wiki?) with some suggestions of "good" (in the eye of beholder) fonts for different tasks (quality? multi-language? features? open-sourcedness?). Point from there to the corresponding resources/vendors who provide them on their respective terms.

I suppose that a very narrow set of fonts may be actually required for us. Given that interoperability is very important thing for LibreOffice, and problems of layout of documents created using different major office suites is always considered by users as bugs, we *must* provide the fonts created specifically for the task of interoperability (Liberation + C-fonts) unconditionally (their use is hard-coded in substitution tables) ... but then, we must realize that on Windows (versions that we support, i.e. Win7+), the required original fonts (TNR/Arial/Courier/Cambria/Calibri/...) are already guaranteed to be present, so fonts to substitute these are not required on that platform even for that reason.

This leads to the need of very strict rules regarding use of fonts in bundled templates - because I agree (partially) with comment 20 wrt the questionable requirement of font based on its use in a template. (But otherwise, that comment is funny: it calls "elitist attitude" what is not that: there is no "we know more about what should be on your computer that you do", there should only be "we know more about what is *required for our program* that you do", which is perfectly OK - but the comment itself shows "elitist attitude" by asserting "I know what you must do - e.g., put your effort into testing of additional configurations instead of, say, fixing bugs, better than you do").

And so, distributing as much templates as extensions as possible is reasonable, which should enable to have their extension pages with the information (with links) to the used fonts, so a user decided themselves what to install system-wide.

(In reply to Mike Kaganski from comment #23)

> > What the LibreOffice project should provide is a set of such high quality
> > fonts: a set of fonts with separate weighted fonts (multiple levels) and
> > italic fonts.
> 
> I don't buy this reasoning. Who should provide "a set of such high quality
> fonts", e.g. with "wide language support", is font forges that create the
> fonts. LibreOffice project should provide a tool that may use any fonts on
> the system, be it "high quality" or not (very subjective); it's up to user
> to decide if user wants "wide language support" or only their spoken
> language; if they need fonts with Graphite features or some dumb fonts, etc.
> 
> Only one thing matters here: if a font is required for proper functioning of
> the software itself. 

I'm in agreement with this. Since fonts are so easy to delete, making your software dependent on auxiliary fonts is asking to break it. If you want your software to be robust, it can't be dependent on something the user can, and often will, delete. If one font is required, that shouldn't be a problem, but the mass of fonts packaged with the software is almost an invitation to delete them for users and system managers who want their computers to be lean and clean.

(In reply to Ale Cogli from comment #18)
> I suppose I agree with comment #8.
> 
> Everytime I update LO it takes me an hour or so to get rid of undesiderated
> fonts and (mostly annoying) re-install the ones overwritten by an older
> version.

I discovered a workaround for this on Windows, run (one line only):

MsiExec.exe /Package "path_where_LibreOffice_MSI_package_is\LibreOffice_%Version%_Win_%Platform%.msi" REMOVE=gm_r_Fonts_OOo_Hidden

Substituting %Platform% with x86 or x64 and %Version%... with version.

If by any chance the OpenSymbol font will not be installed at "%Folder_Where_LibreOffice_Is_installed\program\resource\common\fonts" because of this command (I have not tested it with LibreOffice 7 yet, I do that with LibreOffice 6.x), it is easy to get it from the LibreOffice MSI package using 7-zip:  Just find the "opens___.ttf" file, extract and install it manually.

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

(In reply to João Paulo from comment #26)

Thank you, great! I'll try next time I update!

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

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

Any progress on this? Several users would be interested in being able to toggle the installation of custom fonts during setup, it doesn't seem like a difficult feature to implement and there's no real reason not to.

On the other hand, there are plenty of cases in which a new installation of the bundled fonts would be undesirable, including:
- LO comes with an older version of fonts that the user has updated (not necessarily due to LO's failure to keep fonts up to date, which can also be an issue, but even when the fonts were up to date at the time of the release of any particular LO version - it may have received an update in the meantime)
- the user has modified the font files according to personal preferences
- the user has deleted certain fonts in order to save some disk space/unclutter the font menu/etc.

I always deleted all the fonts LO installed and it worked fine, but it was a royal pain, so I've stopped upgrading until this is finally cleared up. This is one of those cases where the people making the software think they know better than the people using it. I don't want my font menu cluttered and won't use any of the fonts these people seem to love so much, so I guess I can't use LO.

I don't want to impute any bad intentions to the developers, who are doing fabulous and truly praiseworthy work. And I understand the rationale behind providing users of open-source software with some access to open-source fonts. I myself have learned of the latter through LO. But if this user request comes up so regularly, the addition of a switch for bundled fonts in the Custom Setup menu obviously constitutes a significant improvement to the software that can, moreover, be easily achieved. A simple warning in the installer about potential ramifications for the bundled templates when deselecting the fonts can preclude any unexpected problems arising from that choice. But I bet people who chose not to install the fonts are already aware of that and know what they're doing. (In reply to Stephen Sottong from comment #32)
> I always deleted all the fonts LO installed and it worked fine, but it was a
> royal pain, so I've stopped upgrading until this is finally cleared up. This
> is one of those cases where the people making the software think they know
> better than the people using it. I don't want my font menu cluttered and
> won't use any of the fonts these people seem to love so much, so I guess I
> can't use LO.

You can't tell me that every font that LO installs is required by a template. All the rest are forced on the user because someone in the staff likes open source fonts. But isn't the idea of open source about choice? That choice should include the right to choose not to load a mass of fonts that the user considers useless.

And why aren't the templates for the Windows install made with the Windows fonts. Every Windows machine has a set they can't get rid of. Use those. The install file for LO would be much smaller without the unnecessary fonts. You can link to them for the people who CHOOSE to install them.

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