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 12:38:07 UTC