Bug 136604 - Unbundle the Source font families and remove them from our templates
Summary: Unbundle the Source font families and remove them from our templates
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:7.5.0 inReleaseNotes:7.5 targe...
Keywords:
Depends on:
Blocks: Fonts-Bundled
  Show dependency treegraph
 
Reported: 2020-09-09 11:42 UTC by Adolfo Jayme Barrientos
Modified: 2024-09-11 08:16 UTC (History)
6 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 Adolfo Jayme Barrientos 2020-09-09 11:42:54 UTC
Per bug 91886 comment 16.

(Ridiculous) upcoming renamings as “Source Sans 3” and “Source Serif 4” prevent us from upgrading our users to these families without their documents not breaking.

It’s better for us to just let users find these fonts on their own, rather than installing and upgrading them ourselves for them. Besides, these fonts are not crucial for interoperability, and we’re now considering them bloat.
Comment 1 V Stuart Foote 2020-09-09 21:07:50 UTC
Yup, needs to go, in line with bug 91886

If we proceed to weed out the fonts, some thought though to TDF sponsored font pack 'extensions'?
Comment 2 Mike Kaganski 2020-09-10 04:10:57 UTC
(In reply to V Stuart Foote from comment #1)
> some thought though to TDF sponsored font pack 'extensions'?

Please no. We are not a platform to distribute some unrelated products. If at least those were created *for* LibreOffice! But fonts are just products of respective unrelated projects, with their own distribution means.
Comment 3 V Stuart Foote 2020-09-10 05:16:33 UTC
(In reply to Mike Kaganski from comment #2)

I suppose (pensive sigh here...)

But, how do we feel about LibreOffice as a demonstration platform for Graphite smart font features--Tim & Martin from SIL put a lot of effort in with Lazlo, and Khaled used a lot of their framework for OpenFont support with the Harfbuzz implementation.

Do we dump Linux Libertine G and Linux Biolinum G outright? Or, maybe recognize unique capabilities of Graphite framework, and as for bug 135788 build Khaled's Libertinus with Graphite support, and swap it in as a viable Graphite enabled font?
Comment 4 Caleb Maclennan 2020-09-10 06:05:14 UTC
> build Khaled's Libertinus with Graphite support

It's not quite as simple as enabling a flag and rebuilding the font. You have to have have all the Graphite tables and extra work that was done on the font source. Khaled's Libertinus font family has progressed significantly, expanded character sets and weights, and generally gotten a lot of cleanup since the Linux Libertine days. You can't just patch in the Graphite tables without doing quite a bit of work to apply them to the current state of the font family. Not an impossible amount of work, but quite a bit none the less.

I say this as the current maintainer of the Libertinus fonts; Khaled passed on the role to me earlier this year. I'd be happy to see it support all the Graphite from Linux Libertine G if somebody was willing to help with that work, but I'm also struggling to see the benefit since the same function can not be gotten with‌ OpenType. If there was layout that could not be accomplished with OpenType and could with Graphite I'd be even more willing to put some time into it myself, but at this point I'm not sure who that would actually be serving.
Comment 5 Mike Kaganski 2020-09-10 06:12:44 UTC
(In reply to V Stuart Foote from comment #3)

I really appreciate all the work those people have done and are doing - both in their projects, and for LibreOffice! Please don't take the discussion of bundling or providing extensions for fonts as something related to the appreciation of some personal contributions. (I feel that trying to relate to their great job in this context as moving away from the topic.)

IMO, bundling fonts (because they are great!!!) is no better than what those great installers do that tell you "you are installing our product Foo. But why not additionally install this great browser, and this nice Antivirus, and also that other piece of software"...

Please put links to them near the download link on our site (a suggestion), like "suggested downloads" or something. Describe them there, why do you feel that's a good to accompany our software. Credit those people for their great job. But don't bundle! And don't re-distribute. Re-distribution of *anything* must not be the business of TDF.
Comment 6 Caleb Maclennan 2020-09-11 06:46:00 UTC
(In reply to Mike Kaganski from comment #5)
> IMO, bundling fonts [...] is no better than what those
> great installers do that tell you "you are installing our product Foo. But
> why not additionally install this great browser, and this nice Antivirus,
> and also that other piece of software"...

I hear what you are saying but I think you're completely missing the point. I don't want TDF/LO to distribute a bunch of unrelated projects either. But that's not what this issue report is about. "Here are cool fonts you might use" is not the point here, the point is that the fonts being discussed are *used in LO documents and templates*.

Any font used in any documents or templates distributed as part of LO also needs the specific fonts used to be distributed as well otherwise they are worse than useless to the end user. You simply can't guarantee that system will have the font otherwise, and font fallbacks are an absolutely terrible end user experience that would basically ruin most templates and leave a bad impression. Bundling fonts used by default and/or in templates that ship with LO is pretty much a requirement for the suite to be fully featured. This is not at all the same issue as random software that installs unrelated packages that are not needed to function as a form of promotion.
Comment 7 Mike Kaganski 2020-09-11 06:53:32 UTC
(In reply to Caleb Maclennan from comment #6)

Heh, see bug 91886 comment 23 to decide if I miss the point or not.
Comment 8 Commit Notification 2022-12-05 06:47:26 UTC
Khaled Hosny committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/05eb5e487455dfaa0947c704c2ae06544d1f9253

tdf#136604: Remove Source Serif Pro and Source Code Pro fonts

It will be available in 7.5.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 9 Heiko Tietze 2022-12-05 08:04:06 UTC
(In reply to Commit Notification from comment #8)
> Khaled Hosny committed a patch related to this issue.

Thanks for the patch, should be solved now.
Comment 10 Adolfo Jayme Barrientos 2022-12-05 08:24:32 UTC
متشكر اوي
Comment 11 ⁨خالد حسني⁩ 2022-12-05 08:25:56 UTC
(In reply to Heiko Tietze from comment #9)
> (In reply to Commit Notification from comment #8)
> > Khaled Hosny committed a patch related to this issue.
> 
> Thanks for the patch, should be solved now.

We still have Source Sans Pro, and it is used in some templates. But I just noticed that we use fonts in templates that we don’t bundle (e.g. Noto Serif CJK), so may be it is OK to drop the bundled font and keep the templates unchanged?
Comment 12 Heiko Tietze 2022-12-05 08:50:56 UTC
Just reopen if you think it needs more work.

My take in general is to install no fonts at all by default (bug 148337 and bug 91886). And if the user decides to use Liberation, for example, this font should go into the system folder (bug 103140).
Comment 13 Stéphane Guillou (stragu) 2022-12-12 17:14:02 UTC
Verified that Source Serif Pro and Source Code Pro fonts are gone in:

Version: 7.5.0.0.alpha1+ (X86_64) / LibreOffice Community
Build ID: ad085990b8073a122ac5222e5220f8f1d6826dcf
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: threaded
Comment 14 Commit Notification 2022-12-31 19:35:21 UTC
Khaled Hosny committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/5d42f4403d4e51f33ad8f2ce9efbed542978b521

tdf#136604: Remove Source Sans Pro fonts

It will be available in 7.6.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 15 ⁨خالد حسني⁩ 2022-12-31 19:38:09 UTC
(In reply to Commit Notification from comment #14)
> Khaled Hosny committed a patch related to this issue.
> It has been pushed to "master":
> 
> https://git.libreoffice.org/core/commit/
> 5d42f4403d4e51f33ad8f2ce9efbed542978b521
> 
> tdf#136604: Remove Source Sans Pro fonts
> 
> It will be available in 7.6.0.
> 
> The patch should be included in the daily builds available at
> https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
> information about daily builds can be found at:
> https://wiki.documentfoundation.org/Testing_Daily_Builds
> 
> Affected users are encouraged to test the fix and report feedback.

Should this be cherry-picked to libreoffice-7-5 branch or is it too late?
Comment 16 Adolfo Jayme Barrientos 2023-01-01 16:03:17 UTC
I’d say let’s leave that last part for the trunk branch only and buy ourselves six more months to update those templates.

Thanks, Khaled!