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

>>>>> "JL" == Jim Ley <jim@jibbering.com> writes:

JL> "Tobias Reif" <tobiasreif@pinkjuice.com> wrote in message
JL> news:3DDCDC3F.2000009@pinkjuice.com...
>>  Thomas E Deweese wrote: > TR>
>> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12013
>> >
>> > The rendering of the feather is different and I agree that the >
>> > Adobe rendering is more pleasing here, however I suspect that the
>> > real problem is with the SVG,
>> 
>> That is not my point. If the SVG describes jagged outlines, then be
>> it.

   In the original message you said you had found a problem with
Batik's renderer. I was trying to respond to that (I obviously did it
before I read your response to Vincent - sorry).

>> The issue is the inconsistent rendering across viewers.

JL> They are consistent, it doesn't mean they're identical though, we
JL> can never have identical rendering - devices aren't as capable as
JL> each other.

    Jim is right here.  While I agree with the sentiment Tobias I
think it would be absolutely horrible for SVG to go any further than
it already has in specifying how rendering takes place (rendering must
be accurate to within one 'pixel' in device space - this language has
actually recently been softened a bit to deal with 2400dpi printers
for example - but basically still holds for screen display).  Looking
at the output with xmag, all the unglyness in the Batik rendering is
taking place at the sub-pixel level.

    There are three major issues with going to the level you are
asking for. First the WG would have to spec out an anti-aliasing
rendering engine completely - this would have the downside that if new
rendering techniques were discovered that were faster or higher
quality or both, they couldn't be used in SVG! Not to mention the huge
amount of work involved in doing that specification.

    Secondly it would mean that all the open-source implementations of
SVG would be hard pressed to become conformant as they would most
likely not be able to use any of the existing renderers (Xr,
OpenGL/Mesa, libart, freetype etc) - this takes away one of the huge
advantages open-source has - the ability to leverage other open-source
projects.

    Third, the target for each implementation may not be the same,
obviously the needs of a renderer for a 2400dpi printer (probably one
bit per sample output) are different from an implementation tuned for
high-speed animation, which is different from an implementation tuned
for very high quality.  I think you want a certain amount of diversity
in implementations.

    I agree the differences you point out are potentially
objectionable, but for the most part I think only the author is likely
to really notice :).  In the end the only practical way you will get
identical rendering across all implementations is if they all use the
same vector engine - at which point you really probably have just one
implementation.

Received on Thursday, 21 November 2002 08:51:50 UTC