LibreOffice does not, and probably should not, bundle a large number of fonts, even if they are distributable, license-wise. However, there are many fonts which users encounter in documents created by other office app suites, like MSO, or online document web-apps (like Google's perhaps?) - and which are available for free download. Doing so is already considered to have merit for the LO Android viewer (bug 114052) - so why not do it generally? Certainly, there some reasons one could bring up, e.g. the hassle of maintaining download locations and possible "protocols" for using them in case there aren't direct URLs for archives; and even if there are, one needs to automatically open those archives, extract and install, possibly with privilege escalation if fonts on the system require root privileges. Still, it's probably worth it - especially if we consider common fonts in non-Latin languages which we don't bundle. Note that the 'alternative' of properly using the font substitution tables: * Bug 64509: Enhance Font Substitution Table with common commercial and old fonts * Bug 120131: Include font substitutions for fonts commonly used in MS Office for which we bundle alternatives ... usually can't work, because there are no near-equivalent free variants. This is doubly poignant now that Microsoft has switched from Calibri to Aptos, while we don't have a metric-equivalent alternative like Carlito, which should substitute automatically. (And for other languages, we never had metric equivalence.)
MS Aptos will come to a head very quickly as more MS 365 and Office 2021 users normal.dot are moved onto that replacement Cloud font (requiring a MS login). Currently no viable "online source" for Aptos (it is cloud only licensing) nor for a metrically equivalent font. While individuals can find the Aptos font archive to download, with questionable license/usage rights--but that only accommodates individual users. The LO deployed crosextra Carlito <--> Calibri mapping has been functional until now for interoperability with MS Office, but that is no longer enough. Going to need additional effort/TDF sponsorship for use of selective "cloud fonts" like Aptos, or to find a viable metric equivalent with fallback.
I'm against installing fonts, in particular to some extra folder (see bug 103140), We should aim for "Smaller default font name list" (bug 91130) and "make font installation optional in Windows GUI" (bug 91886). If we ship a font at all, it should rather be some open source font. We must not run behind MSO. Users who need additional fonts ideally get it per "tight addition" via extension that forwards to the actual location.
(In reply to V Stuart Foote from comment #1) > Currently no viable "online source" for Aptos (it is cloud only licensing) > nor for a metrically equivalent font. What about this? : https://www.techspot.com/downloads/downloadnow/7566/?evp=05d5172f044d732dc42277fe5969fca6&file=10967 now, obviously, that's not a very stable source for fonts, but for manual downloading, right now, without explicitly accepting any special license - there it is. > While individuals can find the Aptos font archive to download, with > questionable license/usage rights--but that only accommodates individual > users. But that's what I'm suggesting: LO will allow individual users to download, individually, some fonts, from > The LO deployed crosextra Carlito <--> Calibri mapping has been functional > until now for interoperability with MS Office, but that is no longer enough. Was it really? IIANM, this font substitution is not defined by default.
(In reply to Heiko Tietze from comment #2) > I'm against installing fonts, in particular to some extra folder (see bug > 103140), We should aim for "Smaller default font name list" (bug 91130) and > "make font installation optional in Windows GUI" (bug 91886). This bug is not about installing fonts as part of the LO installation... > If we ship a font at all ... this bug is about _not_ shipping fonts, but rather, allowing the user to install them as the need arises.
(In reply to Eyal Rozenberg from comment #3) > > What about this? : > > https://www.techspot.com/downloads/downloadnow/7566/ > ?evp=05d5172f044d732dc42277fe5969fca6&file=10967 > It is an incomplete archive of Aptos, missing the Narrow, Serif, Display and Mono styles. And licensing of the package is suspect, it is not Freeware as Techspot marks it, and likely represents unlicensed "redistribution". Opening any of the the archived ttf in the bundle the font carries this licensing: Microsoft supplied font. You may use this font to create, display, and print content as permitted by the license terms or terms of use, of the Microsoft product, service, or content in which this font was included. You may only (i) embed this font in content as permitted by the embedding restrictions included in this font; and (ii) temporarily download this font to a printer or other output device to help print content. Any other use is prohibited.
(In reply to Eyal Rozenberg from comment #3) > > > The LO deployed crosextra Carlito <--> Calibri mapping has been functional > > until now for interoperability with MS Office, but that is no longer enough. > > Was it really? IIANM, this font substitution is not defined by default. https://opengrok.libreoffice.org/xref/core/vcl/source/font/PhysicalFontCollection.cxx?r=f0a8b5b8#933
(In reply to Eyal Rozenberg from comment #3) > > Was it really? IIANM, this font substitution is not defined by default. > and here in lo_documentLoadWithOptions() https://opengrok.libreoffice.org/xref/core/desktop/source/lib/init.cxx?r=d5fbbc75#2881
Neither the project nor TDF can host fonts of questionable license. Nor can we police the Intellectual Property rights of how LibreOffice is used. But we don't want to "poison" LibreOffice with unlicensed or illegal font bundling. "Free" or "Available" have to be kept at arms length. Why I've suggested a TDF commissioned metric equivalent to Aptos under SIL Open Font License, host it for download and bundle it into LibreOffice. Otherwise facilitating access to "cloud hosted" or "centralized" (e.g. on premise) font repositories with dynamic font loading, and optional install to user profile, is a needed feature.
(In reply to V Stuart Foote from comment #8) > Neither the project nor TDF can host fonts of questionable license. Agreed, but this bug doesn't suggest hosting fonts. Rather, it's about allowing the download of fonts from known, stable, 3rd-party sources. > Nor can > we police the Intellectual Property rights of how LibreOffice is used. Also agreed, but I don't believe I suggested we do that. > But we don't want to "poison" LibreOffice with unlicensed or illegal font > bundling. Again - this bug is not about bundling :-( I am not suggesting we bundle more stuff. Let me try to clarify this in the phrasing of the title. In fact, if anything, this may allow for a reduction in the number of bundled fonts. > I've > suggested a TDF commissioned metric equivalent to Aptos under SIL Open Font > License, host it for download and bundle it into LibreOffice. A fine suggestion, which is mostly orthogonal to this bug. I mentioned Aptos as an example of a font which users may like to have LibreOffice download when they encounter it in a document - providing that this is possible license-wise and availablility-wise, with a legit source. But if we can't do this for Aptos - we can still do it for many other fonts. > Otherwise facilitating access to "cloud hosted" or "centralized" (e.g. on > premise) font repositories with dynamic font loading, and optional install > to user profile, is a needed feature. Hmm... that would be useful as well. So, LO as bundled could have several publicly-accessible font download sources, which could be searched when an unavailable font is encountered; but this list could be made user-extensible, with a URL of a font repository which an organization might offer/configure (or an individual user if they have access to one). How does that sound?
Can 'relevant online sources' be made specific enough to be workable and maintainable?
In the design meeting today, among other aspects of the discussion, Heiko asked that we consider several bugs which, together with this one, might require some merging/duping/consolidation. Those are: Bug 78186: Way to know which fonts are used (resp. missing) in a document Bug 96872: Make it more obvious that a font has been substituted Bug 113496: Open source font installer bundles on download webpage per locale Bug 146291: Allow to use substituted font as if it were installed tl;dr: No dupes, no dependencies :-( -------------------------------------------- Here's how I see the relations between these bugs and this one: Bug 146291: ... is effectively unrelated, let's forget about it. Bug 96872: If this bug were implemented, the user opening a document with a missing font would get a dialog or notification bar through which they will see the list of missing fonts - and that's kind of obvious. (That list might be configured to skip substituted fonts, but it might not.) On the other hand, one does not necessarily remember that when editing the document and considering a specific font in some paragraph, so the bugs don't obviate each other and don't really have a dependency. Bug 78186: That bug is closer than bug 96872 to being a dependency of this one, as - for this one, we definitely need to at least be able to show the user the list of missing fonts, for choosing which if at all they want to have installed; and perhaps to show which are available on-line and which aren't. However - the UI that we would want might not be the minimum necessary for bug 78186; and I'm not certain that what this bug would need is to build upon whatever work is done for bug 78186. So, no dependency, no duplication. Bug 113496: That bug suggests an alternative mechanism for achieving a somewhat-similar effect of font installation. * Resolving bug 96872 will not obviate this bug, since many fonts are either not free for redistribution - but can be downloaded, and this is particularly true for some of the popular ones from big commercial companies. * In the other direction, resolving this bug doesn't obviate 96872, as this bug will only see action when a font in an opened document is missing, but will not offer additional fonts to users creating new documents. * ... so the bugs can't be dupes of each other. With that said - I believe that configuring online font repositories for user-initiated downloads is a far more attractive notion than us curating, storing, bundling and presenting numerous packages of fonts. A lot less effort, and less licensing issues (if any). So even offering collections of per-locale fonts would probably better be served by supporting online font repositories like in this bug, and then adding the feature of downloading a bunch-of-fonts in some locale from them.
We discussed the topic in the design meeting. It would be nice to support installing of fonts, for instance when receiving a document from colleagues. The installation has to be done by the OS/DE, which is typically the fact on executing files with ttf/otf name extensions. Access to the fonts could be organized by the community per link-only extensions. TDF should not be responsible for hosting the actual files. (In reply to Eyal Rozenberg from comment #11) > tl;dr: No dupes, no dependencies :-( Doubt that fixing one issue wont help with the others.
(In reply to Cor Nouws from comment #10) > Can 'relevant online sources' be made specific enough to be workable and > maintainable? Extending my reply from the design meeting: I believe the most common cases of missing fonts would be those fonts people use with other office suites and apps, especially on Windows and to some extent on web platforms or Mac. Consequently, major candidates for font distribution sources would be public font repositories of Microsoft, Google and Apple (the likely suspects). Google: https://fonts.google.com/ https://github.com/google/fonts Apple: https://developer.apple.com/fonts/ Microsoft: this is trickier... but see at least https://learn.microsoft.com/en-us/typography/font-list/ https://corefonts.sourceforge.net We should look into (at least) the following points regarding each of these: 1. Can one (stably) automate the location of font by name in the repository? 2. Can one (stably) automate the download of a located font from the repository? 3. Can one (stably) automate the download of license text from the repository? 4. Is it legally allowed for a program to do these three things, and for the user to be considered the actor, under appropriate conditions? (Appropriate conditions could be presentation of appropriate confirmation dialogs, e.g. "Would you like to download font family Foo from repository BigCorp Font Galleria?", "Do you accept the following license for font family Foo?") PS: It doesn't have to be just these big commercial three. other possibilities include: The Font Library (various licenses listed per font): https://fontlibrary.org Font Squirrel (only freeware fonts): https://www.fontsquirrel.com OpenFoundry: https://open-foundry.com/info etc. but of course - smaller sites are less likely to have the more popular missing fonts; so perhaps these would be better-suited for optional additions to the list? via an extension? Hard to say.