Re: Interaction of (web) document font families and fontconfig rules

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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:

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.

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

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.

>> 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.
Fontconfig mailing list

[Index of Archives]     [Fedora Fonts]     [Fedora Users]     [Fedora Cloud]     [Kernel]     [Fedora Packaging]     [Fedora Desktop]     [PAM]     [Gimp Graphics Editor]     [Yosemite News]

  Powered by Linux