On Sat, Sep 16, 2017 at 11:42 PM, Jerry Casiano <jerrycasiano@xxxxxxxxx> 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:High-level changes are: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 - 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 110The 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 list Fontconfig@lists.freedesktop. org https://lists.freedesktop.org/mailman/listinfo/fontconfig
_______________________________________________
Fontconfig mailing list
Fontconfig@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/fontconfig
--
behdad
http://behdad.org/
http://behdad.org/
_______________________________________________ Fontconfig mailing list Fontconfig@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/fontconfig
