- From: Tobias Reif <tobiasreif@pinkjuice.com>
- Date: Thu, 21 Nov 2002 17:12:16 +0100
- To: www-svg@w3.org
Thomas E Deweese wrote: > 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 want an extreme with lots of disadvantages, I just could imagine a better compromise; but that's up to you, the implementers, and the spec authors to investigate and decide. I just wanted to express that this is something that is important for me, and probably others, but I don't have the solution. > 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. I see. But for a lot of the other aspects of SVG, the spec does specify the standard to be followed. > You also just deleted all of _my_ concerns on this topic, at least > I took the time to respond to yours... Sorry. I didn't have top say much about them, but I didn't want to offend you, if that's the case. > Suggestions? I'm also looking forward to seeing some, eg from others :) > 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. I see. I never really suspected any specific reason, as I'm no implementation expert. > 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? This is a problem to be solved IMHO. Wouldn't it be relatively simple to automatically compare pixel for pixel against a reference PNG? The test suite includes tests that don't get "proven", but compared, which is what I did with my screen shots. > The only thing you are left with is visual difference ... which is the case for all static test cases. > - 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..)? Again: the different shots were made on the same platform and box. At least in these situations I would like to get more cosistent rendering, and be able to request it from implementers, via the spec. > All of these can play a very important role in something being > 'visually different'. Sure; but if I have one SVG on one box, and two conformant viewers, then there should be greater similiarity. > Also what implementation get's to specify the golden standard for > comparison of 'no visual difference'? None; the spec specifies what's conformant, as with any other aspect of SVG. Tobi -- http://www.pinkjuice.com/
Received on Thursday, 21 November 2002 11:12:15 UTC