[Fontconfig] Interaction of (web) document font families and fontconfig rules
behdad at behdad.org
Tue Dec 30 20:53:28 PST 2008
karlt+freedesktop at karlt.net wrote:
> On Wed, 17 Dec 2008 00:08:56 -0500, Behdad Esfahbod wrote:
>> Karl Tomlinson wrote:
>>> I'm looking for comments on how fontconfig users would prefer font
>>> families defined in web documents through @font-face (or defined
>>> by other means in other documents) to be presented in FcPattern *p
>>> for FcConfigSubstitute(FcConfig*, p, FcMatchPattern).
>>> The question basically comes down to whether
>>> author-defined/provided fonts should be treated in the same way as
>>> locally installed fonts, or whether they should be considered
>> My take on it is that they should be considered special. And that's the API
>> I'm going to implement in Pango. Actually the proposed Pango API is very
>> close to CSS. Or I think it is. Anyway, the bug to track it is here:
> Thanks, Behdad.
> The fontconfig API that was useful for Mozilla was FcFontSetSort so
> that both system and document-specific FcFontSets could be
> included in the same sort without polluting all font sorts with
> the fonts from one document.
> I don't really have any good suggestions on how to do something
> similar with a PangoFontMap, unfortunately. It may be nice to
> have a single FontMap throughout the app so that caches are shared
> - a separate FontMap for each document may get heavy.
Yeah. The way I thought this may be used is that the application assigns a
unique family name to each document font. And application fonts are not used
in fallback (because they are not added to fontconfig catalog at all).
> Perhaps an API to "Add font file and/or cairo font face to
> catalog" could be used if there was a flag to say whether or not
> it should be used for fallback. In our case we want the font
> to only be used if the font was explicitly requested in the description.
>> You do a FcConfigSubstitute(,,FcMatchFont) in the resulting fonts too, right?
> Yes, though there were speed and memory gains from only doing this
> for fonts that actually get used to render glyphs.
>>> Part of me would like to think that document fonts are just like
>>> any other fonts but I think there are differences.
>>> * The user has control over locally installed fonts, and can set
>>> up fontconfig rules appropriately. Document fonts change as
>>> often as users view different documents and do not get parsed by
>>> acceptfont/rejectfont rules.
>>> * Document fonts may not be what they seem.
>>> * The font-family descriptor may have little to do with the font
>>> * The document font may be a trimmed down version of the font
>>> with only enough glyphs to display a heading, for example.
>> Exactly. A good way to think about them is like fonts embedded in a PDF, or a
>> SVG. Do you expect your PDF/SVG. That makes things much easier.
> CSS may be a little different here (but I don't know PDF/SVG in
> I imagine a PDF would specify one font for each character (or run
> of characters).
> CSS OTOH specifies a number of fonts for a block of characters.
> The intention is that the fonts that are actually used depend on
> which fonts are actually available and support the characters.
Yeah, the fallback makes it quite complicated. I'm not sure how useful
fallback to @font-face fonts are, but as you say, it's CSS spec and you have
to implement it :).
>>> My current thinking is that the FC_FAMILY value in the font
>>> pattern representing fonts from document @font-face rules would
>>> have a namespace. e.g.
>>> family: "@font-face:BPG Ucnobi U"
>> Exactly my thinking in the context of how this will be used with Pango.
>>> and, when the CSS style for an HTML element requests
>>> "font-family:BPG Ucnobi U" (and an @font-face rule exists), the
>>> FC_FAMILY property of the pattern passed to
>>> FcConfigSubstitute(,,FcMatchPattern) would include
>>> "@font-face:BPG Ucnobi U".
>> You sure can do that. But I'm not sure how useful that would be.
> We kind of need to do this because of the way CSS's font-family
> can include a list of both system and document font families (in
> any order). If we are going to pass the system font families
> through FcConfigSubstitute, then the document font families need
> to passed also.
> A fontconfig API that might provide more flexibility here would be
> something like FcValueGetBinding or perhaps FcPatternGetBinding.
> At present the only way to properly interpret the families from
> FcConfigSubstitute is to use FcFontSetMatch or FcFontSetSort.
> Though, that would only make the sorting more flexible - I think
> all families still need to be passed to one FcConfigSubstitute.
I'm not sure GetBinding would be that useful. The configuration can do
binding=same or binding=strong easily.
More information about the Fontconfig