W3C home > Mailing lists > Public > www-svg@w3.org > April 2008

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

From: Kalle Raita <kraita@nvidia.com>
Date: Fri, 18 Apr 2008 10:27:29 +0200
Message-ID: <85DD8D3F1695004A8A9A5AC16CE584BE06962D54@deemmail01.nvidia.com>
To: <www-svg@w3.org>

Hi All,
 
The conformance tests have prompted me to take a close
look at the font selection process and consequences of not
finding a match in the user provided font-family list.

I have collected some spec snippets into the end of this mail 
and will be referencing them.

Altogether there is no strict definition of what should be
done if none of the entries in the font-family list fit 
(see 1, 2, and 3). However, there are hints that UA should
continue search beyond that list and use whatever fonts
available in the system (see 4, 5, and 6). Also, this fallback
is UA dependent (especially 6).

Some things to consider:
a) If the UA is expected to perform a fallback, defining a 
missing glyph for SVG font is mostly useless. The search
will always proceed to default font set and produce 
missing glyph defined there, if the glyph is not present.

b) CSS2 section 15.5 suggests that generic families should
be user configurable, which means that there is no guarantee
about the actual glyph. There is an expectation that it
would represent the requested glyph, but we cannot be
sure.

c) In conformance test fonts-glyph-03-t.svg:
    <g font-family="SVGFont" font-size="50"> 
      ...
      <!-- Should fall back to another font --> 
      <text x="50" y="260" xml:lang="de">a</text> 
    </g>
Indicates expectation of falling back to a font 
outside the font-family list. The rendering result
is undefined.

d) In conformance test fonts-glyph-04-t.svg:
      <font horiz-adv-x="500"> 
        <font-face font-family="SVGFont1" units-per-em="1000"
ascent="800" descent="200" alphabetic="200" /> 
        <glyph unicode="f" glyph-name="upward-triangle" d="M0 0L500
0L250 900Z" /> 
        <glyph unicode="ffl" glyph-name="square" d="M0 250L500 250L500
750L0 750Z" /> 
      </font> 
    ...
    <text x="100" y="100" font-size="50"
font-family="SVGFont1">ffl</text>
Here the glyph "f" gets used twice and the glyph "l" is UA specific,
i.e., 
rendering results are undefined.

e) The conformance test fonts-desc-02-t.svg assumes
on the last row a specific fallback behaviour. Namely,
if the provided font-family does not match, the UA
is expected to find correct 'a' glyph.

f) In conformance test text-intro-01-t.svg:
Apparently the expectation is that the font
"MissingInAction" is never activated as it
contains only the missing-glyph, which should not 
be considered as match.

I'm sure that there are other affected conformance test cases.

Tests reinforce my original interpretation, but go to expect
some specific behaviour instead of UA dependent fallbacks.
Notes a and b slightly contradict my interpretation.

Given that the conformance test suite provides reference images
as the main help of determining the success of test, I find
using cases with undefined rendering behaviour undesirable. 

Thanks for interested reades that got this far, here on follows 
relevant spec language I was able to find:
 
1) Definition of the font-family property refers to XSL-11 
specification without adding anything material.
 
2) XSL-11 7.9.2 "font-family":
The generic font family will be used if one or more of the other 
fonts in a font set is unavailable. Although many fonts provide
the "missing character" glyph, typically an open box, as its name
implies this should not be considered a match except for the last
font in a font set.

3) XSL-11 refers to CSS2 font-family property, which does not add
anything, except the following errata referenced by XSL-11 as well:

[2000-10-31] Replace the sentence that says: "Although many fonts 
provide the "missing character" glyph, typically an open box, 
as its name implies this should not be considered a match except
for the last font in a font set" by:

    Although many fonts provide the "missing character" glyph, 
    typically an open box, as its name implies this should not 
    be considered a match. 

I.e. removing the "except for the last font in the font set" part

4) Neither SVG nor XLS-11 seem to say much about generic font
families, but CSS2 says that they must be supported. 
(15.2.6 Generic font families)

5) In CSS2 section 15.5 Font matching algorithm we have the following:

8. If there is no font within the family selected in 2, then use the
inherited or UA-dependent 'font-family' value and repeat from step 2,
using the best match that can be obtained within this font. If a 
particular character cannot be displayed using this font, the UA 
should indicate that a character is not being displayed 
(for example, using the 'missing character' glyph).

6) XLS-11, 7.9.3 "font-selection-strategy":
"If no matching font is found, a fallback selection is determined
in a system-dependent manner
Note:

This fallback may be to seek a match using a User Agent default 
"font-family", or it may be a more elaborate fallback strategy where, 
for example, "Helvetica" would be used as a fallback for "Univers".

If no match has been found for a particular character, there is no
selected font and the User Agent should provide a visual indication
that a character is not being displayed (for example, using the
'missing character' glyph).

 
Yours, 
  - Kalle Raita
 

Kalle Raita 
NVIDIA Corporation 
Tel. +358 40 723 1441 
kraita@nvidia.com 
http://eu.nvidia.com <http://eu.nvidia.com/>  

-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------
Received on Friday, 18 April 2008 08:28:46 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:39 GMT