Bug 91886 - Make font installation optional in Windows GUI
Summary: Make font installation optional in Windows GUI
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Installation (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: x86 (IA32) Windows (All)
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 136550 137524 145107 (view as bug list)
Depends on:
Blocks: Installer-Windows Fonts-Bundled 136646
  Show dependency treegraph
 
Reported: 2015-06-06 09:25 UTC by Petr Vones
Modified: 2021-10-13 12:32 UTC (History)
11 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Petr Vones 2015-06-06 09:25:12 UTC
Please introduce new option to Custom installation that allow to disable font installation to the system.
Comment 1 Aron Budea 2016-08-13 21:06:21 UTC
Not sure how much skipping installation of certain fonts can impact normal usage, but in general, this sounds like a reasonable enhancement.
Comment 2 Roman Kuznetsov 2020-03-14 13:19:18 UTC
and we can have situation when our Impress templates will look ugly by default

Possibly UX-team have own opinion?
Comment 3 Heiko Tietze 2020-03-17 08:27:06 UTC
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/
Comment 4 Mike Kaganski 2020-03-19 09:43:28 UTC
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.
Comment 5 Heiko Tietze 2020-03-19 09:57:21 UTC
(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>
Comment 6 Mike Kaganski 2020-03-19 10:36:20 UTC
(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.
Comment 7 Mike Kaganski 2020-03-19 10:42:22 UTC
(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.
Comment 8 João Paulo 2020-06-18 07:30:36 UTC
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).
Comment 9 Mike Kaganski 2020-06-18 09:23:23 UTC
(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.
Comment 10 João Paulo 2020-08-13 08:11:49 UTC
(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.
Comment 11 Mike Kaganski 2020-08-13 08:42:24 UTC
(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.
Comment 12 S.Zosgornik 2020-08-14 21:40:39 UTC
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.
Comment 13 Mike Kaganski 2020-08-31 14:15:08 UTC
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.
Comment 14 V Stuart Foote 2020-08-31 18:59:25 UTC
(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
Comment 15 Mike Kaganski 2020-09-01 03:04:27 UTC
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?
Comment 16 Adolfo Jayme 2020-09-01 15:15:53 UTC
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.
Comment 17 Heiko Tietze 2020-09-02 08:58:57 UTC
(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.
Comment 18 Ale Cogli 2020-09-02 15:19:21 UTC
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.
Comment 19 Mike Kaganski 2020-09-07 16:09:21 UTC
*** Bug 136550 has been marked as a duplicate of this bug. ***
Comment 20 stephen.sottong 2020-09-07 16:46:54 UTC
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.
Comment 21 Jean-Francois Nifenecker 2020-09-09 05:10:21 UTC Comment hidden (obsolete)
Comment 22 Jean-Francois Nifenecker 2020-09-09 05:10:43 UTC Comment hidden (obsolete)
Comment 23 Mike Kaganski 2020-09-09 06:19:56 UTC
(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.
Comment 24 Ale Cogli 2020-09-09 06:40:20 UTC Comment hidden (no-value)
Comment 25 stephen.sottong 2020-09-09 16:56:57 UTC
(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.
Comment 26 João Paulo 2020-09-18 23:47:20 UTC
(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.
Comment 27 Mike Kaganski 2020-10-16 10:35:09 UTC
*** Bug 137524 has been marked as a duplicate of this bug. ***
Comment 28 Ale Cogli 2020-11-13 10:04:30 UTC
(In reply to João Paulo from comment #26)

Thank you, great! I'll try next time I update!
Comment 29 Roman Kuznetsov 2021-10-13 11:39:47 UTC
*** Bug 145107 has been marked as a duplicate of this bug. ***