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

Re: SVGt 1.2 Tests: Question about default value of <font-face> font-style

From: Chris Lilley <chris@w3.org>
Date: Thu, 29 May 2008 13:53:27 +0200
Message-ID: <38027636.20080529135327@w3.org>
To: "Kalle Raita" <kraita@nvidia.com>
Cc: www-svg@w3.org

On Friday, March 14, 2008, 4:35:38 PM, Kalle wrote:

KR> Hi All,
KR>  
KR> The specification gives 'all' as the default value of <font-face>
KR> font-style:
KR>  "If the attribute is not specified, the effect is as if a value of
KR> "all" were specified."

Thats correct. The default value of the font-style descriptor is 'all'. 

KR> For the font-style property, i.e. what is applicable for <text>,
KR> <tspan>, and <textarea>, the default value is 'normal'

Thats also correct. The default value of the font-style property is 'normal'.

So the key to understanding the spec is to distinguish between *properties* (which request particular fonts be applied to text) and *descriptors* (which advertise certain features of downloadable fonts). You will see that descriptors and properties have the same names, but different defaults and indeed some different values, too; this reflects that they do different jobs.

KR> Looking at the italic texts in the conformance tests, it seems that at
KR> least tests:
KR> text-area-220-t
KR> text-area-213-t
KR> fonts-desc-05-t
KR> animate-elem-46-t
KR> seem to work better it is assumed that the default value for <font-face>
KR> font-style is also 'normal'.

(No, see below).

KR> On the other hand, at least test text-intro-201-t, based on the
KR> reference image, seems to assume that
KR> the default value of <font-face> font-style is 'all' as specified.  

KR> If we have understood the spec correctly, then:

KR> a) If the default value 'all' is correct and <font-face> 
KR> does not specify style, then glyphs specified in that font 
KR> will be used for all styles of that font as is.

No. The default value of 'all' for most of the font descriptors is
indeed correct, and means that *no further details are provided* - in
other words, the user agent will have to downlaod the font and see.

To take an example of font-weight. Suppose the user agent is looking
for a very heavy weight of a particular font family called Foo. It
sees two font definitions that cover the foo family and point off into
the Web somewhere for the font data. One says that font-weight is
100-300. That means it only has light weights available, there is no
point downloading it. The other gives no value for the font-weight
descriptor. That means that there is no information provided - the
font is just as likely to have any weights in it, and the only way to
tell is to download it and look.

KR>  Meaning 
KR> that requesting italic for that font X will give the 
KR> exactly same glyphs as requesting normal. 

Not if there is an italic version of that family available. 

KR> b) If 'normal' is the default, the user agent will look 
KR> further for italic variant. If none is found, the user 
KR> agent has the option of synthezising oblique glyphs to 
KR> use in place of italic.

It always has that option, as a last resort.

KR> Option a) is what the spec says, but the conformance tests are pointing
KR> to option b). Are the conformance test faulty?

The purpose of that test is:

      <p>Test text element, tspan element and various text styles.</p>
      
      <p>The first group tests that text displays at all, that it
      displays in a straight line, and that the font style can be made
      italic or bold.</p>
      
      <p>The second group tests that text can be treated as any other
      graphical element, with stroke and fill properties. The first
      word tests that fill color can be specified. The second word
      tests that stroke color can be specified in absence of fill. The
      third group tests the combination of all these effects. The
      final group tests positioning of 'text' elements.</p>

For that particular test, I agree that it would be better to have
explicit italic and bold fonts available. The fallback behaviour (eg
what to do if bold is requested but no bolder version is available) is
already tested by other tests.  That test in the 1.1 testsuite did not
specify any font family at all.

The correct rendering of the test as it is currently, depends on
whether the SVGFreeSansASCII font is the only available font (as might
be the case on some embeded systems with no system fonts) or whether
there are other fonts that can be substituted. So the test is made
more repeatable by adding explicit bold and italic versions.

I will update this test to add explicit bold and italic versions, so
that all platforms wil give the same results and the pass/fail
criteria do not depend on the presence of fallback system fonts.





-- 
 Chris Lilley                    mailto:chris@w3.org
 Interaction Domain Leader
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG
Received on Thursday, 29 May 2008 11:54:03 GMT

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