[Fontconfig] Interaction of (web) document font families and fontconfig rules

[Behdad Esfahbod]

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
>>> special.
>> 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:
>>
>>   http://bugzilla.gnome.org/show_bug.cgi?id=347237
> 
> 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 see.

> 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
>>>     itself.
>>>
>>>   * 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
> detail).
> 
> 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.

Cheers,
behdad