I'm looking for comments on how fontconfig users would prefer fontfamilies defined in web documents through @font-face (or definedby other means in other documents) to be presented in FcPattern *pfor FcConfigSubstitute(FcConfig*, p, FcMatchPattern). The question basically comes down to whetherauthor-defined/provided fonts should be treated in the same way aslocally installed fonts, or whether they should be consideredspecial. Locally installed fonts only:---------------------------- For web documents using only locally installed font familiesthrough CSS 2.1, there is a reasonably well defined algorithm forprioritizing fonts according to the font-family property, which isa list of family names, and other style properties. In the spirit of giving the user the final say, the CSS propertiesare converted to an FcPattern and presented toFcConfigSubstitute(,,FcMatchPattern), and the result is used inthe 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 elementmight be something like "Helvetica(s), Nimbus Sans L(s), BitstreamVera Sans(w)" (followed by several other family names). HereNimbus Sans L is a possible close-match to the author-requestedHelvetica (for use when Helvetica is not installed), andBitstream Vera Sans is the default font for lang="en". Thesefamilies are considered in this order when finding glyphs forcharacters. @font-face:---------- What the @font-face CSS rule adds is the ability for the author to describethe properties of a automatically-downloadable font face and the family towhich it belongs. This font face is only available to the document(s) thatuse this style rule. The following web page contains an example, which usesthe 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 maynot be the same as the family name in the font referenced by thesrc descriptor. It is the value in the @font-face rule, not thename from the font, that is matched against any HTML element'sfont-family style properties, when deciding whether to use thisfont-face. Equivalently the family name in font patternconstructed to represent this face comes from the @font-face rulenot the font. (In the @font-face rule above the descriptor value is the same asthe font family name, but the page referenced above actually useda 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 useBitstream Vera Sans for Latin languages and BPG Ucnobi U for theGeorgian language. Now, if no BPG Ucnobi U font is installed locally, and a pageincludes an @font-face rule with family BPG Ucnobi U, should theelement <p lang="ka" style="font-family:sans-serif">უნიკოდის</p> be rendered with the font fromhttp://www.w3.org/International/tests/test-webfonts/BPG-Ucnobi-U.ttfor 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 thelocally installed font? (Currently this is decided by the webbrowser. The spec is changing and currently contradictory.) Discussion:---------- Part of me would like to think that document fonts are just likeany 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 arenot considered for fallback when looking for support forcharacters not supported by the specified fonts.(The draft spec http://dev.w3.org/csswg/css3-fonts/#font-matchingis changing but currently says "the user agent performs a systemfont fallback procedure to find the best match for the characterto be rendered".) I imagine the reason for not consideringdocument fonts is that the author may (dare I mention it) playtricks using Unicode code point assignments for unrelated glyphs. My current thinking is that the FC_FAMILY value in the fontpattern representing fonts from document @font-face rules wouldhave 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), theFC_FAMILY property of the pattern passed toFcConfigSubstitute(,,FcMatchPattern) would include"@font-face:BPG Ucnobi U"._______________________________________________Fontconfig mailing listFontconfig@xxxxxxxxxxxxxxxxxxxxxxxxx://lists.freedesktop.org/mailman/listinfo/fontconfig
