RE: SVGT 1.2: Font-family selection, no matches in the list

Hi Chris,

Again, thanks for the answers. 

As you suspected, I have not been reading the test descriptions. 
This is because we are not using the provided harnesses and I never
realized that a harness could contain descriptions of the tests 
as well. My bad.

I'm a bit amazed that the UA can choose any missing glyph it wants, but
that is not in any way critical.

If I understood correctly, linking to a font from a SVG file forces 
the UA to have that font in the UA font database. Is that correct?

Yours,
  - Kalle Raita

> -----Original Message-----
> From: Chris Lilley [mailto:chris@w3.org] 
> Sent: 29. toukokuuta 2008 15:37
> To: Kalle Raita
> Cc: www-svg@w3.org
> Subject: Re: SVGT 1.2: Font-family selection, no matches in the list
> 
> 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 13:15:04 UTC