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

[Karl Tomlinson]

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.


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.


@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?

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.)


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.


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"

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".