- From: Chris Lilley <chris@w3.org>
- Date: Thu, 29 May 2008 14:37:28 +0200
- To: "Kalle Raita" <kraita@nvidia.com>
- Cc: www-svg@w3.org
On Friday, April 18, 2008, 10:27:29 AM, Kalle wrote: KR> Hi All, KR> KR> The conformance tests have prompted me to take a close KR> look at the font selection process and consequences of not KR> finding a match in the user provided font-family list. Hi Kalle I think the specs do define it, but not in an especially clear way. The definitions are there, but clarifications should be made to those specs. So, thanks for bringing this to our attention. To some extent this has come about because the html markup part of the web was deployed before any style mechanism was standardised; the expectation therefore was that text would always be displayed somehow; and styling was a way to add greater control over the display, but in a heterogenous environment where display capabilities and font availability was unknown. Contrast this with for example print publishing, where all fonts are specified explicitly, and if one is missing, the print job stops. However, we are no longer in the early days, and some assumptions which were implicit then need to be made more explicit. KR> I have collected some spec snippets into the end of this mail KR> and will be referencing them. An additional one that is relevant: CSS2, 15.2.6 Generic font families http://www.w3.org/TR/CSS2/fonts.html#generic-font-families Generic font families are a fallback mechanism, a means of preserving some of the style sheet author's intent in the worst case when none of the specified fonts can be selected. For optimum typographic control, particular named fonts should be used in style sheets. All five generic font families are defined to exist in all CSS implementations (they need not necessarily map to five distinct actual fonts). So this is saying that if none of the specified fonts is available, some measure of authorial intent can be preserved by saying 'at least give me a sans-serif font if you have one' but that equally, even if sans-serif is specified, you might still get a serif font if that is all that the system has. So if an (optional) generic font family is specified as the last one in a list, it will always match, as its always defined to exist; but it might not give the style you are asking for. (This is particularly the case for the vaguely specified 'fantasy' one). The assumption (and this needs to be made explicit, I agree) is that if no generic font family is specified, any one of them can be used (remember, they are all defined to exist). The other assumption (remember, CSS1 and 2 were written before 1998 so full internationalisation was seen as further off and more 'researchy' than it is now) is that the fallback fonts have complete glyph coverage. Which they won't. But equally, the fallback font on a given system may not actually have a 'missing glyph' glyph. KR> Altogether there is no strict definition of what should be KR> done if none of the entries in the font-family list fit KR> (see 1, 2, and 3). However, there are hints that UA should KR> continue search beyond that list and use whatever fonts KR> available in the system (see 4, 5, and 6). Also, this fallback KR> is UA dependent (especially 6). KR> Some things to consider: KR> a) If the UA is expected to perform a fallback, defining a KR> missing glyph for SVG font is mostly useless. The search KR> will always proceed to default font set and produce KR> missing glyph defined there, if the glyph is not present. Looking at the erratum to XSL which you referenced below, if there are no matches at all, the missing glyph does not have to be taken from the last font in the list. It can be taken from anywhere (but does not constitute a match and does not prevent further processing of the rest of the list). KR> b) CSS2 section 15.5 suggests that generic families should KR> be user configurable, which means that there is no guarantee KR> about the actual glyph. There is an expectation that it KR> would represent the requested glyph, but we cannot be KR> sure. Yup. See above for discussions of glyph coverage. KR> c) In conformance test fonts-glyph-03-t.svg: KR> <g font-family="SVGFont" font-size="50"> KR> ... KR> <!-- Should fall back to another font --> KR> <text x="50" y="260" xml:lang="de">a</text> KR> </g> KR> Indicates expectation of falling back to a font KR> outside the font-family list. The rendering result KR> is undefined. But the test does link to a font that has no lang descriptor (and thus, applies to any language) and has an "a" glyph. So the result is not undefined; an "a" must be displayed and there is al least one font available to do that. KR> d) In conformance test fonts-glyph-04-t.svg: KR> <font horiz-adv-x="500"> KR> <font-face font-family="SVGFont1" units-per-em="1000" KR> ascent="800" descent="200" alphabetic="200" /> KR> <glyph unicode="f" glyph-name="upward-triangle" d="M0 0L500 KR> 0L250 900Z" /> KR> <glyph unicode="ffl" glyph-name="square" d="M0 250L500 250L500 KR> 750L0 750Z" /> KR> </font> KR> ... KR> <text x="100" y="100" font-size="50" KR> font-family="SVGFont1">ffl</text> KR> Here the glyph "f" gets used twice and the glyph "l" is UA specific, KR> i.e., KR> rendering results are undefined. I agree that 'SVGFont1' does not have a glyph for "l", by design, but SVGFreeSansASCII is also referenced from that test and does have an "l" glyph. So the result is semi-defined. An "l" must be displayed, but it may come from SVGFreeSansASCII or from some other font. Displaying a 'missing glyph' would be a fail here. The test should note this explicitly. KR> e) The conformance test fonts-desc-02-t.svg assumes KR> on the last row a specific fallback behaviour. Namely, KR> if the provided font-family does not match, the UA KR> is expected to find correct 'a' glyph. The test says <p>The last line of test can be 'square', 'a', 'a' (from a fallback font), 'diamond'. The first 'a' can be replaced with a smallcaps 'A', if there is a smallcaps font installed or if synthesis is supported.</p> which seems to be correct. KR> f) In conformance test text-intro-01-t.svg: KR> Apparently the expectation is that the font KR> "MissingInAction" is never activated as it KR> contains only the missing-glyph, which should not KR> be considered as match. I'm slightly worried when you say "apparently". Just checking - you are reading the test descriptions? In this case its explicit: <p>Correct rendering requires that each character is rendered. it may be rendered with the 'missing glyph' if no glyphs are found in the fonts listed in the content, or in any fallback font that is available. The first choice font is a special SVG font that only contains the 'missing glyph'. Missing glyph from other fonts may conformantly be used, however.</p> And yes, that is explicitly the purpose of the test. The spec says that processing of the font-family list continues until, for each character, a font has been found that a) exists and b) has the glyphs to display that character. (If you fall off the end then we are back to generic font families, fallback, and questions of glyph coverage in the fallback font). KR> I'm sure that there are other affected conformance test cases. KR> Tests reinforce my original interpretation, but go to expect KR> some specific behaviour instead of UA dependent fallbacks. In the cases you mention above, I hope I have shown that the specific fallback behavious is justified; although perhaps the test descriptions or pass/fail criteria could be clarified. KR> Notes a and b slightly contradict my interpretation. KR> Given that the conformance test suite provides reference images KR> as the main help of determining the success of test, I find KR> using cases with undefined rendering behaviour undesirable. Again, I hope that you are reading the test descriptions as well as just looking at the reference images. KR> Thanks for interested reades that got this far, here on follows KR> relevant spec language I was able to find: KR> KR> 1) Definition of the font-family property refers to XSL-11 KR> specification without adding anything material. KR> KR> 2) XSL-11 7.9.2 "font-family": KR> The generic font family will be used if one or more of the other KR> fonts in a font set is unavailable. Although many fonts provide KR> the "missing character" glyph, typically an open box, as its name KR> implies this should not be considered a match except for the last KR> font in a font set. KR> 3) XSL-11 refers to CSS2 font-family property, which does not add KR> anything, except the following errata referenced by XSL-11 as well: KR> [2000-10-31] Replace the sentence that says: "Although many fonts KR> provide the "missing character" glyph, typically an open box, KR> as its name implies this should not be considered a match except KR> for the last font in a font set" by: KR> Although many fonts provide the "missing character" glyph, KR> typically an open box, as its name implies this should not KR> be considered a match. KR> I.e. removing the "except for the last font in the font set" part KR> 4) Neither SVG nor XLS-11 seem to say much about generic font KR> families, but CSS2 says that they must be supported. KR> (15.2.6 Generic font families) KR> 5) In CSS2 section 15.5 Font matching algorithm we have the following: KR> 8. If there is no font within the family selected in 2, then use the KR> inherited or UA-dependent 'font-family' value and repeat from step 2, KR> using the best match that can be obtained within this font. If a KR> particular character cannot be displayed using this font, the UA KR> should indicate that a character is not being displayed KR> (for example, using the 'missing character' glyph). KR> 6) XLS-11, 7.9.3 "font-selection-strategy": KR> "If no matching font is found, a fallback selection is determined KR> in a system-dependent manner KR> Note: KR> This fallback may be to seek a match using a User Agent default KR> "font-family", or it may be a more elaborate fallback strategy where, KR> for example, "Helvetica" would be used as a fallback for "Univers". KR> If no match has been found for a particular character, there is no KR> selected font and the User Agent should provide a visual indication KR> that a character is not being displayed (for example, using the KR> 'missing character' glyph). KR> KR> Yours, KR> - Kalle Raita KR> KR> Kalle Raita KR> NVIDIA Corporation KR> Tel. +358 40 723 1441 KR> kraita@nvidia.com KR> http://eu.nvidia.com <http://eu.nvidia.com/> KR> ----------------------------------------------------------------------------------- KR> This email message is for the sole use of the intended recipient(s) and may contain KR> confidential information. Any unauthorized review, use, disclosure or distribution KR> is prohibited. If you are not the intended recipient, please contact the sender by KR> reply email and destroy all copies of the original message. KR> ----------------------------------------------------------------------------------- -- Chris Lilley mailto:chris@w3.org Interaction Domain Leader W3C Graphics Activity Lead Co-Chair, W3C Hypertext CG
Received on Thursday, 29 May 2008 12:38:07 UTC