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

Hi Chris, 

Thanks for the answer. Just a couple of questions to verify that I have
understood this correctly. 

When talking only about fonts defined inside SVG files, which means that
there is no additional information about the fonts than the descriptors:

1) For font-face font-style 'all' != 'normal, italic, oblique'. If the
value
'all' equals not specified, I'd assume that specific list of values has
then
different meaning. Right?

2) Let's say the content requests font foo as italic and that SVG file
has the glyphs for font foo embedded in it.
  - If font-face of foo has font-style 'all', the implementation can use
    different foo font for italic if it happens to have such other
instance?
    Or use glyphs from embedded font foo. Or synthetisize oblique glyphs
    from embedded font foo. Right?
  - If font-face of foo has font-style 'italic', the UA is expected
    to use the embedded font unmodified or any other font with family
    foo and style italic. Right?
  - What if the font-style is the list of all styles? Does it change
    anything?

3) Does font author have any way of controlling whether synthesis is
recommended for the specific font? I'd assume that saying that font-face
font-style is 'normal, italic' should tell to the UA to keep its filthy
fingers of the glyphs and use the same glyphs for italic rendering as 
well. 

Yours, 
  - Kalle

> -----Original Message-----
> From: Chris Lilley [mailto:chris@w3.org] 
> Sent: 29. toukokuuta 2008 14:53
> To: Kalle Raita
> Cc: www-svg@w3.org
> Subject: Re: SVGt 1.2 Tests: Question about default value of 
> <font-face> font-style
> 
> 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
> 
> 
-----------------------------------------------------------------------------------
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 Thursday, 29 May 2008 12:17:43 UTC