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

On Thursday, May 29, 2008, 3:14:15 PM, Kalle wrote:

KR> Hi Chris,

KR> Again, thanks for the answers. 

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

In that case we should make it clearer. We will ensure that the next release makes this more explicit.

The test descriptions are held in the original versions of the tests (the 'svg' directory). In the test creation process, the test descriptions are stripped out (the resulting svg goes in the 'svggen' directory) and added to the various test harnesses.

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

Maybe some fonts have nicer empty rectangles than others ;) but seriously, if the font family list has four font in it, the first three have a defined 'missing glyph' and the last one does not, its silly for the spec to require only the last font to be searched for that glyph (and then do what, display nothing at all).

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

Yes.

KR> Yours,
KR>   - 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






-- 
 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:50:52 UTC