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

>>>>> "TR" == Tobias Reif <tobiasreif@pinkjuice.com> writes:

TR> Thomas E Deweese wrote:


>> 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 :)


TR> Imagine the father printed on a huge bus or cruise ship (or "ocean
TR> liner" or whatever).

    In a conformant viewer These errors will not blow up like that -
they must stay 'sub pixel' errors.  This doesn't mean that they can't
be seen, but they should not grow as you seem to imagine them growing.
Just try zooming on the feather the 'jaggies' go away.

TR> This real issue is that everyone tries to downplay a serious
TR> issue, instead of trying to improve the situation.

    As I said I agree with the sentiment but there are lots of reasons
not to change the situation.  I think that doing what you suggest
represents a significant tradeoff between innovation and
standardization.  I don't think we are in a position to standardize
the rendering to the extent you are asking for right now, there is no
clear 'golden standard' for anti-aliased rendering.

    You also just deleted all of _my_ concerns on this topic, at least
I took the time to respond to yours...

>> 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.

TR> I think there is room for improvement without taking this absurd
TR> measure.

    Suggestions?

    I know you suggested 'no curve smoothing'.  How do you test that
as a conformance criteria? Like in this case I actually don't think
Adobe is curve smoothing, I think you are just seeing differences in
how the two implementations do anti-aliasing.  Even if Adobe is doing
curve smoothing or Java2D is dropping points due to zoom level, how do
you 'prove' this to say one is conformant and the other
non-conformant?

    The only thing you are left with is visual difference - which is
what you want (I think). Then you get into the question of; What is a
visual difference?  Who's vision?  Under what viewing conditions?
8bit (hand held) 16bit (many laptops) 24 bit (most desktop) 30 bit
(high end medical)?  LCD, CRT, OLED, Plasma? What Phosphor set? What
about printing (4inks, 6inks..)?

    All of these can play a very important role in something being
'visually different'.

    Also what implementation get's to specify the golden standard for
comparison of 'no visual difference'?

Received on Thursday, 21 November 2002 10:54:47 UTC