- From: Dirk Schulze <dschulze@adobe.com>
- Date: Wed, 10 Oct 2012 11:59:38 -0700
- To: "Dr. Olaf Hoffmann" <Dr.O.Hoffmann@gmx.de>
- CC: "www-svg@w3.org" <www-svg@w3.org>
On Oct 10, 2012, at 11:08 AM, Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de> wrote: > Dirk Schulze: >> Hi, >> >> I want to announce that WebKit switched to the new concept of focal radius >> and unbound focal point. I added a simple example on the bottom of the mail. >> You can download a nightly from webkit.org and try the demo. We did this to >> get responses on possible broken content as early as possible - hopefully >> before shipping it in a release product. So far we are aware of one broken >> test on the W3C test suite. >> > If it is already known, that the implementation in WebKit is broken, if > the noted focal points coordinates are outside the r-circle, why isn't this > simply fixed? Would be fine, before such a version of a viewer is > published… You might got my mail and my request wrong. We removed the restriction that a focal points needs to be inside the outermost circle in SVG2. So it is expected that this test does not pass anymore. It tests if the implementation moves the focal point back into the outermost circle if you position it on or outside the circle. The question is if we break content. I would not expect a test suite to be content so. Sometimes we might break content in a positive way. Especially with removing this requirement, authors can actually do more things that they were not able to do before. As a second benefit: we align with HTML Canvas now. > > If you need response on broken content without automatic correction: > As already mentioned, in my art gallery I use the automatic correction in > combination with animation and in some other documents as well, > including a publication in a wikibook and a tutorial. > At least for the animated documents, no automatic correction means > a lot of server sided number crunching and huge output to work around such > bugs in viewers - because fx, fy and r can be animated with independent > timing, the file-size of such a 'workaround' can increase by orders of > magnitudes - maybe larger than WebKit can manage, if the server does > user-agent version sniffing and sends the workaround. > For the files without animation - well, typically there will be no server > with user-agent sniffing to generate and send a workaround to WebKit. I am fine with that. Greetings, Dirk > > > Olaf >
Received on Wednesday, 10 October 2012 19:00:09 UTC