Bug 114855 - Replacing Source Sans Pro by Source Sans Variable
Summary: Replacing Source Sans Pro by Source Sans Variable
Status: RESOLVED WONTFIX
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Fonts-Bundled
  Show dependency tree / graph
 
Reported: 2018-01-05 17:26 UTC by Volga
Modified: 2024-06-29 18:19 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Volga 2018-01-05 17:26:59 UTC 
Description:
Adobe released Source Sans Variable font in 19 Aug 2017, the variable version of Source Sans Pro. Since then, we bundle Source Sans Variable to reduce sixe of installation package. But we must get support for font variation.

Steps to Reproduce:
-

Actual Results:  
-

Expected Results:
-


Reproducible: Always


User Profile Reset: No



Additional Info:


User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
Comment 1 Heiko Tietze 2018-01-30 16:37:10 UTC 
Not a fan myself but worth to discuss.
Comment 2 V Stuart Foote 2018-01-30 17:35:33 UTC 
There is no internal UI for working with OpenType 1.8 OTF Variable fonts. Work flows would need to be altered as would printing and export.

Why would we change over to Source Sans Variable now? Absent correct handling of the variable font--we would get an arbitrary and likely unusable rendering of the font--or more likely a fall-back to another on system font. We'd just be wasting space in the deployment package.

Until such time as support for OTF 1.8.2 "fvar" (bug 103596) is implemented substituting this or any other variable font makes no sense.

Duping this to bug 103596, as only when that enhancement is undertaken would it make sense to adopt any variable font.

*** This bug has been marked as a duplicate of bug 103506 ***
Comment 3 Yousuf Philips (jay) (retired) 2018-01-30 21:56:42 UTC 

*** This bug has been marked as a duplicate of bug 103596 ***
Comment 4 ⁨خالد حسني⁩ 2022-11-24 06:07:21 UTC 
I don't see why this was made a duplicate of bug 103596, as thus obe is about replacing a font and should be judged on its own merit.
Comment 5 ⁨خالد حسني⁩ 2022-12-04 22:11:27 UTC 
The consensus seems that we don’t want to bundle any more fonts.
Comment 6 V Stuart Foote 2022-12-04 22:29:26 UTC 
(In reply to خالد حسني from comment #5)
> The consensus seems that we don’t want to bundle any more fonts.

I'm fine to not bundle specifically Source Sans Variable, but with work done on bug 103596 and bug 152206 remaining do we need at least one variable font bundled for fall back when 'fvar' table calls are used?
Comment 7 ⁨خالد حسني⁩ 2022-12-05 08:10:54 UTC 
(In reply to V Stuart Foote from comment #6)
> (In reply to خالد حسني from comment #5)
> > The consensus seems that we don’t want to bundle any more fonts.
> 
> I'm fine to not bundle specifically Source Sans Variable, but with work done
> on bug 103596 and bug 152206 remaining do we need at least one variable font
> bundled for fall back when 'fvar' table calls are used?

May be for testing, but we don’t have test color fonts either. I don’t think we need to ship every kind of font to the users, but we should be able to use fonts they have installed (deprecated font formats notwithstanding).