- From: Michael Day <mikeday@yeslogic.com>
- Date: Fri, 27 Feb 2009 11:27:30 +1100
- To: John Daggett <jdaggett@mozilla.com>
- CC: www-style <www-style@w3.org>
Hi John, Following on from our discussion last month we have been modifying Prince to implement the latest revision of CSS3 Fonts. In particular, we have changed the behaviour of @font-face rules so that descriptors only take one value and there is no "all" value, which does make it easier to write rules that match appropriately. We are also going to change our implementation of the "src" descriptor such that it follows the spec and is not used for character fallback, instead only the first loadable source will be loaded. Combining more than one font for character fallback will require multiple @font-face rules with the same font-family, which seemed awkward at first, but makes a lot of sense once you start using the unicode-range descriptor. However, I'm still a bit unsure of how local() is supposed to work. In Prince we implement it very simply: it is a font family name, and we query the operating system for fonts with that family and pick the most appropriate one. For example X in the spec: @font-face { font-family: Arial; src: local(Helvetica); } If a document requests "bold italic 12pt Arial" we will check for fonts in the "Arial" font family, and choose the one which is the closest match to the requested properties. This involves using Fontconfig on Linux, and EnumFontFamiliesEx() on Windows, and some ATS / ATSUI functions on MacOS X, but it's all very easy: you put in a family name, you get out some font references, you get more information about those fonts to check their boldness, style, width/stretch, and that's it. The spec seems to hint at doing more than that, eg. by matching "Futura-Medium" and "HoeflerText-Ornaments" which look like PostScript names rather than font family names, however the mechanism is not fully explained. What is the use case and expected mechanism for this? Best regards, Michael -- Print XML with Prince! http://www.princexml.com
Received on Friday, 27 February 2009 00:28:34 UTC