Re: Variable fonts redux

On Sat, Sep 16, 2017 at 11:42 PM, Jerry Casiano <[email protected]>
wrote:

> The changes to FC_WEIGHT and FC_WIDTH will break anything currently using
> those, correct?
>

Yes and no.  Non-variable fonts and named-instances of variable fonts
continue to work as before.  Variable-font patterns will get weight and
width as ranges instead of double, and old clients will fail fetching
width/weight.



> Are the currently defined weights and widths sticking around or do they
> become pointless to even have?
>

They'll be around.


> Also, does this mean that a font such as Voto Serif GX will list 500
> different variations in a font selector dialog?
>

Yes.

Sorry if these are silly questions.
>
>
> On Sat, 2017-09-16 at 10:49 -0700, Behdad Esfahbod wrote:
>
> 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/
>
> _______________________________________________
> Fontconfig mailing [email protected]://lists.freedesktop.org/mailman/listinfo/fontconfig
>
>
> _______________________________________________
> Fontconfig mailing list
> [email protected]
> https://lists.freedesktop.org/mailman/listinfo/fontconfig
>
>


-- 
behdad
http://behdad.org/

_______________________________________________
Fontconfig mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/fontconfig