Keith Packard wrote: > > Mostly, I'm looking for a reasonable font matching scheme
When I implemented parts of the CSS2 font spec for Mozilla on Windows and X, I let Windows do most of the matching for me (italic, bold, etc), though I had to do some of it myself (e.g. checking for availability of a glyph for a particular Unicode char), while on X, I did most of it myself, using XListFonts to get the available fonts, and parsing those XLFD names to figure out their boldness, etc. I tried to follow the CSS2 spec as closely as possible, especially on X, where I checked the font properties in the order specified in CSS2. On Windows, I let the OS do a lot of the matching, and it may not have followed the CSS2 order exactly, but the results looked OK. I could have followed CSS2 more closely on Windows by calling the font enumeration API (similar to XListFonts), and then matching the font properties in the CSS2-specified order. In fact, another Mozilla developer later did enumerate fonts to implement font-weight on Windows. My point is that both X and Windows have APIs at a low enough level to do matching in whatever way you like. The X Window System has in the past applied the principle of "mechanism, not policy", so as long as the new font APIs include some low-level ones that allow apps to do their own matching (non-CSS if they wish), then it doesn't really matter that fontconfig happens to have chosen to follow CSS2. > and CSS2 is > really close to what I'm doing now, in fact, my current matching scheme is > CSS2 compliant except for weight fill-in. Your current scheme does seem quite close to CSS2's. CSS2 specifies that the implementation must behave as though it looks at each character. I suppose fontconfig could do that using an FcCharSet with only one member :-) but CSS3 seems to have backed off from the per-character spec, choosing instead to go with per-textual-element, which is probably more sensible. MSIE apparently looks at neighboring characters (according to a Unicode conference paper), and XSL has a property called font-selection-strategy that can take a value called auto, which specifies that an implementation-defined algorithm may be followed (and in the accompanying note it talks about contextual chars). Your scheme seems to use the order charset, family, size, slant, weight, while CSS2 specifies the order character, family, style, weight, size. Also, your scheme measures the "distance" between a pattern and a font, while CSS2 specifies that e.g. font-style must be matched exactly. Minor nits? > I see no reason to have a non-standard matching scheme which is gratuitously > different from CSS2. Well, I can certainly see your point, but the question is, how far do you want to take this? Do you want to implement CSS2 exactly? In that case, you may want to use the CSS2 syntax. Alternatively, you could follow XSL, whose syntax is based on XML, just like fontconfig's. Or you could just ignore the CSS and XSL syntaxes, and just come up with your own XML DTD/schema. Also, CSS stands for Cascading Style Sheets. There are three types of style sheets: author (of the document), user and user agent (browser). Normally, the author trumps the user, who trumps the user agent: author > user > user agent However, "!important" rules allow the user to make the final decision (as it should be): user > author > user agent Does fontconfig also allow the user to override the author (i.e. app)? Erik _______________________________________________ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
