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

[Behdad Esfahbod]

Hi Karl,

Sorry to take so long to answer.

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


> Locally installed fonts only:
> ----------------------------
> 
> For web documents using only locally installed font families
> through CSS 2.1, there is a reasonably well defined algorithm for
> prioritizing fonts according to the font-family property, which is
> a list of family names, and other style properties.
> 
> In the spirit of giving the user the final say, the CSS properties
> are converted to an FcPattern and presented to
> FcConfigSubstitute(,,FcMatchPattern), and the result is used in
> the equivalent of an FcFontSetSort.
> 
> For example, with
> 
>   <p lang="en" style="font-family: Helvetica, sans-serif">
>     Paragraph.
>   </p>
> 
> After FcConfigSubstitute, the FC_FAMILY property for the element
> might be something like "Helvetica(s), Nimbus Sans L(s), Bitstream
> Vera Sans(w)" (followed by several other family names).  Here
> Nimbus Sans L is a possible close-match to the author-requested
> Helvetica (for use when Helvetica is not installed), and
> Bitstream Vera Sans is the default font for lang="en".  These
> families are considered in this order when finding glyphs for
> characters.

You do a FcConfigSubstitute(,,FcMatchFont) in the resulting fonts too, right?


> @font-face:
> ----------
> 
> What the @font-face CSS rule adds is the ability for the author to describe
> the properties of a automatically-downloadable font face and the family to
> which it belongs.  This font face is only available to the document(s) that
> use this style rule.  The following web page contains an example, which uses
> the BPG Ucnobi U font:
> 
> http://www.w3.org/International/tests/test-webfonts/test-georgian-ucnobi.html
> 
> Consider now if the author had included this style rule:
> 
>  @font-face {
>     font-family: "BPG Ucnobi U";
>     font-style:  normal;
>     font-weight: normal;
>     src: url(http://www.w3.org/International/tests/test-webfonts/BPG-Ucnobi-U.ttf);
>  }
> 
> Note that the value of the font-family descriptor here may or may
> not be the same as the family name in the font referenced by the
> src descriptor.  It is the value in the @font-face rule, not the
> name from the font, that is matched against any HTML element's
> font-family style properties, when deciding whether to use this
> font-face.  Equivalently the family name in font pattern
> constructed to represent this face comes from the @font-face rule
> not the font.
> 
> (In the @font-face rule above the descriptor value is the same as
> the font family name, but the page referenced above actually used
> a different font-family value.)
> 
> Now consider if a user has the following fontconfig rule:
> 
>         <alias>
>                 <family>sans-serif</family>
>                 <prefer>
>                         <family>BPG Ucnobi U</family>
>                 </prefer>
>         </alias>
> 
> so that FcConfigSubstitute turns font-family:sans-serif into
> "Bitstream Vera Sans(w), BPG Ucnobi U(w)", which roughly means use
> Bitstream Vera Sans for Latin languages and BPG Ucnobi U for the
> Georgian language.
> 
> Now, if no BPG Ucnobi U font is installed locally, and a page
> includes an @font-face rule with family BPG Ucnobi U, should the
> element
> 
>  <p lang="ka" style="font-family:sans-serif">უნიკოდის</p>
> 
> be rendered with the font from
> http://www.w3.org/International/tests/test-webfonts/BPG-Ucnobi-U.ttf
> or with a locally installed fallback font?

I'd say the locally installed font.


> And, if there were a locally installed version of BPG Ucnobi U,
> how would the user choose between the document font and the
> locally installed font?  (Currently this is decided by the web
> browser.  The spec is changing and currently contradictory.)

The document one used if user specified that font family explicitly.  The
system one used as a result of fontconfig configuration.  I always think of
the @font-face families as living in separate namespace.


> Discussion:
> ----------
> 
> 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.


> Document fonts are already treated differently in that they are
> not considered for fallback when looking for support for
> characters not supported by the specified fonts.
> (The draft spec http://dev.w3.org/csswg/css3-fonts/#font-matching
> is changing but currently says "the user agent performs a system
> font fallback procedure to find the best match for the character
> to be rendered".)  I imagine the reason for not considering
> document fonts is that the author may (dare I mention it) play
> tricks using Unicode code point assignments for unrelated glyphs.
> 
> 
> 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.

behdad