After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 786016 - support variable fonts
support variable fonts
Status: RESOLVED FIXED
Product: pango
Classification: Platform
Component: general
unspecified
Other Linux
: Normal enhancement
: ---
Assigned To: pango-maint
pango-maint
: 786985 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2017-08-08 18:55 UTC by Matthias Clasen
Modified: 2018-01-04 05:12 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch (24.58 KB, patch)
2017-09-14 14:54 UTC, Matthias Clasen
none Details | Review

Description Matthias Clasen 2017-08-08 18:55:18 UTC
https://blog.typekit.com/2016/09/14/variable-fonts-a-new-kind-of-font-for-flexible-design/

What we need in pango:

1) some new font description syntax to specify axis values

2) passing those axis values to fontconfig/freetype when selecting fonts

3) some new font family api to get information about available axes
Comment 1 Matthias Clasen 2017-08-30 12:05:46 UTC
*** Bug 786985 has been marked as a duplicate of this bug. ***
Comment 2 Krasnaya Ploshchad’ 2017-08-31 02:44:35 UTC
See: https://www.microsoft.com/typography/otspec/otvaroverview.htm
Comment 3 Behdad Esfahbod 2017-08-31 23:09:23 UTC
While fixing this, I like to also fix this old issue:
https://bugzilla.gnome.org/show_bug.cgi?id=95043
Comment 4 Matthias Clasen 2017-09-05 03:26:06 UTC
Suggested api is:

void
pango_font_description_set_variation_settings (PangoFontDescription *desc,
                                               const char           *settings);

With a syntax like

"wght=600,wdth=70".

For pango_font_description_to_string,
we could use @ to make the variation settings part:

"Noto Sans @wght=600,wdth=70"

We need a separate pango_font_description_to_display, which would convert
the variation settings to a human-readable string, using axis names, etc.

To get more useful names for variation axes, we need the font face to lookup
name strings.
Comment 5 Matthias Clasen 2017-09-05 12:20:33 UTC
I pushed some very preliminary work in wip/matthiasc/font-variations.
I just adds a string to PangoFontDescription, with some setters and getters.

Next step is to figure out how this gets passed down to actually loading a font. Is see

pango_fc_font_map_load_font
  pango_fc_font_map_load_fontset
    pango_fc_font_map_get_patterns
      pango_fc_fontset_new
        pango_fc_font_map_new_font

We store a shallow copy of the font description in the fontsetkey, and at some point we generate FcPatterns, and load an FcFont from it.

I think we can treat font variations like we treat the matrix here.

In the pangocairo case, we further have

pango_cairo_fc_font_map_create_font
  _pango_cairo_fc_font_new
    _pango_cairo_font_private_initialize

Which gets us close to the place where we create a cairo scaled font. We can pass the font variations down there and keep them in the _PangoCairoFontPrivateScaledFontData struct.

There is no cairo api to create a scaled font with variation settings. Do we need one ?
Comment 6 Matthias Clasen 2017-09-05 20:12:08 UTC
I guess the only place where we can really apply the font variation settings is in pango_cairo_fc_font_lock_face - where we can call FT_Set_Var_Design_Coordinates, right before handing out the FT_Face object.
Any place higher up risks that we run into issues with the several layers of font caching leading to unintentional sharing of FT_Face instances that have variation settings applied
Comment 7 Matthias Clasen 2017-09-07 18:59:06 UTC
I've put some more code into that branch, but it doesn't work
Comment 8 Matthias Clasen 2017-09-14 14:54:33 UTC
Created attachment 359792 [details] [review]
patch

This one works. It requires a cairo patch that has been sent to the list.
Comment 9 Matthias Clasen 2017-09-14 18:55:24 UTC
The patch adds new api, and i've marked it as PANGO_AVAILABLE_IN_1_42, which i guess means that we should branch off a stable 1.40 branch and finally open a new development cycle before landing this
Comment 10 Behdad Esfahbod 2017-09-15 01:13:21 UTC
Can you push your Pango stuff to a github or git.gnome branch as well?