[cairo] Variable fonts redux

Behdad Esfahbod behdad at behdad.org
Sat Sep 16 17:49:47 UTC 2017


Hi,

Previously I have had implemented and merged support for named-instances in
variable fonts, but the generic variation mechanism was not integrated.
I've finished the core of what was left of implementing variable fonts in
fontconfig:

  https://github.com/behdad/fontconfig/commits/varfonts2

High-level changes are:

  - Add FC_FONT_VARIATIONS (string): this one is easy.  The library doesn't
do anything about it.  It's like FC_FONT_FEATURES. Client sets and then
retrieves. Primarily useful for non-standard variation axes,

  - Add FC_VARIABLE (bool), which is at the core of varfont support.

All font patterns that were discovered previously will get
FC_VARIABLE=False When querying fonts with (the new)
FcFreeTypeQueryFaceAll(), or when face index has top 16 bits (instance
index) set to 0x8000, then a pattern is created for the variable font as a
whole.  This pattern is only generated if there's actual variation in at
least one of weight, width, and optical size axes. This pattern then might
have ranges for FC_WEIGHT, FC_WIDTH, and FC_SIZE, and has FC_VARIABLE=True.

  - FC_WIDTH and FC_WEIGHT are now typed as ranges instead of double.

  - Fix matching and comparison logic with ranges to behave as we expect.

  - In FcDefaultSubstitute(), set FC_VARIABLE to false if it's unset.
FC_VARIABLE has very high match priority, so this takes care of backward
compatibility with clients that do not support variable fonts by pushing
them to the very back of fallback list.

  - In FcFontRenderPrepare, special-case ranges, such that if eg. request
is for weight=47, and font has weight=[50,100], then rendered pattern will
get weight=50.  For size, special case again, such that if request size=47
and font has size=[50,100], then rendered font will have size=47.

  - For clients that support variable font, eg. pango soon, they have to
opt-in.  I could have special-cased matcher for FC_VARIABLE, such that if
FC_VARIABLE=True, then both variable and non-variable fonts will be
returned, but I didn't like a custom match.  Currently if FC_VARIABLE=True
is set then variable fonts will dominate the results, even if they are not
the best match.  To solve that:

  - To solve above problem, I added a new value for FcBool: FcDontCare=2.
Pango should set FC_VARIABLE=FcDontCare.  I was hoping to allow clients to
tell fontconfig whether, everything else being equal, they prefer variable
font or static font, but that needs a very low-priority element, or a hack,
and I didn't like either, so I gave up on that.  It's not particularly
useful anyway.

Here's what's left, which I'll do in the next few days.  I just wanted to
get this out for now.

  - Config compare operations on "dontcare" are not implemented yet,

  - The variable-font pattern currently has FC_STYLE set.  I think I should
completely leave out FC_STYLE,

With those fixed, I think this can be merged.  At some point I also like to:

  - Speed up scanning of varfonts that have many named instances.  Voto
Serif GX has over 500!  Right now we open the face and do everything from
scratch for each named instance.  Can be considerably sped up by opening
once and switching coordinates around...

  - Expose slant & italic standard axes as well, but Fontconfig shoves
FC_SLANT_ITALIC and FC_SLANT_OBLIQUE in the same element, with these values:

#define FC_SLANT_ROMAN              0
#define FC_SLANT_ITALIC             100
#define FC_SLANT_OBLIQUE            110

The varfonts axis for italic has a 0..1 range, 1 meaning italic.  And the
slant axis uses slant angle.  We can:

  - Deprecate FC_SLANT element and add two new ones, eg FC_ITALIC and
FC_SLANT_ANGLE.  I don't like this particularly,

  - Repurpose FC_SLANT for *italic*, since the 0..1 range maps nicely to
FC_SLANT_ITALIC=100, and add FC_SLANT_ANGLE for the slant.  I don't
particularly like to confusing names here either.  So I'm open to
suggestions.

A point I'll raise before someone asks:

  - Exposing contents of STAT table or non-standard axes is out of scope
for fontconfig.  The rule of thumb is: if it doesn't participate in font
selection, it does not belong to fontconfig.  Things that a font dialog
needs should be fetched directly using FreeType or HarfBuzz.


Cheers,
-- 
behdad
http://behdad.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cairographics.org/archives/cairo/attachments/20170916/2767b4a4/attachment.html>


More information about the cairo mailing list