W3C home > Mailing lists > Public > www-svg@w3.org > October 2006

Re: [SVG Tiny 1.2 CR Comment] spec text of rendering hints is confusing to implementors

From: Jean-Claude Dufourd <jean-claude.dufourd@streamezzo.com>
Date: Tue, 17 Oct 2006 22:49:05 +0200
Message-ID: <453541C1.3050107@streamezzo.com>
To: Chris Lilley <chris@w3.org>
CC: www-svg <www-svg@w3.org>

Dear Chris,

Your response is very confusing for me.

If there is a "SHALL" or a "MUST" in the text, then it shall be possible 
to create a conformance test. The absence of conformance tests seems to 
indicate that the "SHALL"s should go.

Note: You seem to dissociate the renderer from the SVG UA, and I do not 
see why you would be allowed to.
The SVG UA contains the renderer, and any relevant constraint on the UA 
passes on to the renderer.

With a SHALL in the text, *-rendering are not hints but directives. But 
the word "hint" is used.

So I am afraid I have to persist in asking for a clarification of the text.
Best regards

Chris Lilley wrote:
> On Tuesday, October 17, 2006, 3:23:34 PM, Jean-Claude wrote:
> JCD> The spec text of shape-rendering, text-rendering, image-rendering and 
> JCD> color-rendering uses repeatedly the word "shall" in the context of 
> JCD> something called "hints".
> JCD> This caused our developers to question my statement that although the 
> JCD> parsing of these attributes is mandatory, the implementation of these 
> JCD> attributes is optional.
> Thats an interesting point. The parsing *and implementation* of these attributes is mandatory, hence the shall, but the effect of them on a given renderer depends on how parameterizable its rendering engine is and thus to what extent it can honour requests for geometric precision or speed.
> JCD> Please clarify the specification. Suggested action is to replace all 
> JCD> instances of "shall" by "should" or "may" in the hints semantics.
> That wouldmean (in the case of should) That it should do the required actin unles it has reason not to. That's not really correct.
> If, for esxample, a given implementation has a very precise but sow anti-aliasong implementation (like 16x geometric sampling) then clearly if told to prioroitize speed over other things it would swithc off antialiasing.
> Another implementation that gets hardware aa for free from the hardware but has to implement non aa rendering in software would respond similarly to a request for'crisp edges' but in the opposite way if told to prioritize speed.
> Bassically it comes down to the implementation and how it is done, what the trade-offs are.
Received on Tuesday, 17 October 2006 20:49:18 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:09 UTC