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 14:31:38 +0100
Message-ID: <3DDCE03A.3080501@sun.com>
To: Tobias Reif <tobiasreif@pinkjuice.com>, www-svg@w3.org

Hello Tobias,

Tobias Reif wrote:
 > Hi Vincent,
 >>> [...]
 >>> Two issues I found with Squiggles rendering quality:
 >>> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14673
 >> This shows that Batik does not do as well with
 >> text-rendering=optimizeGeometricPrecision. In Batik, that turns off
 >> anti-aliasing and the text does not look as good becauce we do not do
 >> hinting. This is a known limitiation.
 > ... 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?

 >>> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12013
 >> You point out to several differences between ASV and Batik, but it is
 >> unclear to me what is 'right'. For example, the feather is jagged
 >> indeed (i.e., the path has lots of control points that do not describe
 >> a smooth curve).
 > I see.
 >> So I am not convinced Batik is not doing anything bad there.
 > Me neither; it just doesn't look as pretty, and what's more important,
 > shows that different viewers render the SVG differently.
 > So the issues are not to be dismissed as irrelevant,

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.

  > but are to be
 > solved; if not in Batik, then in the spec.
 > If both viewers conform to the 1.0 spec, then 1.2 needs to be clearer
 > and more detailed, so that we get [subj], without the "?".
 > Perhaps the spec needs to go to go down to the level of anti-aliasing
 > etc algorithms etc.
 >> We do not smooth curves before rendering.
 > 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.

 > I don't know if ASV and CSV do "smoothing", but the text (bash etc) also
 > doesn't look as pretty, as I describe.
 > The curves of the feather are so jagged in Batik, that if that is
 > conformant rendering *and* if the rendering behaviour of ASV and CSV are
 > also conformant, there is a grey area in the spec where too much
 > difference in rendering behaviour is allowed, which results in very
 > relevant rendering differences, which means lower quality, less
 > predictability, thus less usefulness of SVG itself.
 > Sorry if I'm drastic this morning, but I want to express that it helps
 > SVG if stuff like this gets resolved, in some way.

I agree with you and I like the "be strict to be cool" approach (quoting
Karl from the W3C QA team). This said, it is an area where it is really
hard to find a proper way of specifying accuracy. 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.

Received on Thursday, 21 November 2002 08:35:58 GMT

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