W3C home > Mailing lists > Public > www-svg@w3.org > November 2002

Re: Identical rendering? [was Re: SVG 1.2 General feedback]

From: Vincent Hardy <vincent.hardy@sun.com>
Date: Thu, 21 Nov 2002 16:05:15 +0100
Message-ID: <3DDCF62B.5090402@sun.com>
To: Tobias Reif <tobiasreif@pinkjuice.com>
CC: www-svg@w3.org

Hello Tobias,

At this point, I think we need to get other implementors feedback.   I 
do not think we can propose wording in the spec. before we are sure we 
understand why there is a difference in the rendering and whether there 
is a reasonable way to reduce or remove these differences in the 
specification. I gave you my interpretation (or wild guess) but I think 
we need other implementor's input.

Note that the working group has discussed rendering accuracy several 
times and the consensus has always been on 1px accuracy as this is what 
the working group members felt was reasonable given platform 
differencies and capabilities. Thomas has also detailed why it is hard 
to go beyond that, but let's see what other implementors think.

Vincent.



Tobias Reif wrote:
> 
> Hi Vincent,
> 
>  >> ... of "..."? If it's a limitation of Squiggle, then the bug report
>  >> is
>  >> relevant.
>  >>
>  > I was explaining what we are doing. Hinting would be a better solution
>  > but does that mean it is a bug?
> 
> Please feel free to handle the "bug report" as a request for
> improvement. The various versions of the text in ASV look good, so that
> might be a motivation for you.
> 
>  > I do not think what you are saying is irrelevant and I was not trying
>  > to
>  > dismiss you comment. You filed a bug against Batik and I was pointing
>  > out that I do not consider the difference in behavior to be
>  > necessaraly
>  > a bug. I did not say that the fact there is a difference is irrelevant.
> 
> OK. So what's the plan, since it's a relevant issue?
> 
> I reported the difference in rendering three months ago, and there still
> is no single comment on the page. So I have reason to believe that this
> issue will again have to wait many months until it gets addressed, in
> any public way.
> 
> You are an author of the SVG spec, so you could act on the bug report as
> WG member / spec author, and offer solutions regarding more detailed
> specification in the spec.
> 
>  >> I'm much more interested in a solution than in an explanation :)
>  >>
>  > I thought it helped the discussion to explain what we are doing (or
>  > not
>  > doing in that case). Before proposing a solution, I think it is
>  > important to understand the problem clearly and why we may have
>  > differences.
> 
> Yes, I also think this is important. But as I said, in addition, the
> issue should get solved. Sorry if I misunderstood you, but I didn't see
> any suggestion for possible solutions, so I was afraid they won't happen.
> Since that's not the case, I'm looking forward to a solution.
> 
>  > I agree with you and I like the "be strict to be cool" approach
>  > (quoting
>  > Karl from the W3C QA team).
> 
> Me too. We need identical rendering, and this can only be reached down
> this route. If I then get jagged curves in ASV/CSV as well, that's OK; I
> then have the power to smooth them myself, and get the effect in all
> viewers, not just some.
> 
>  > This said, it is an area where it is really
>  > hard to find a proper way of specifying accuracy.
> 
> As I wrote in the P.S. post, "No path smoothing is allowed." might help
> a lot already. No?
> 
>  > The reason I brought
>  > up curve simplification is that I thought the rendering difference
>  > could
>  > come from a viewer simplifying the path depending on zoom ratio.
> 
> If that is the case, then behaviour could be specified in the spec. If
> something else is the reason, it still shold be addressed in the spec.
> If you don't know what the reason is, then it would be great if you 
> could continue to look for it.
> 
> Sure, not everything can be specified in mm or in a schema, but the spec
> does a lot more than that anyways, which seems to work OK.
> 
> Tobi
> 
Received on Thursday, 21 November 2002 10:09:35 GMT

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