W3C home > Mailing lists > Public > www-svg@w3.org > February 2011

Re: Test for animation of SVGLength values

From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
Date: Sat, 26 Feb 2011 14:00:47 +0100
To: Dirk Schulze <vbs85@gmx.de>, www-svg@w3.org
Message-Id: <201102261400.48182.Dr.O.Hoffmann@gmx.de>
Dirk Schulze:

> > - I think the test has a problem with the meaning of some units.
> > The relation between px and absolute units like cm
> > depend on the resolution of the screen - therefore the
> > gray marker lines should be provided with the same units
> > as the used animation values (or see below with a user
> > dependent calculation of values or positions).
>
> Yes, like you wrote below, there were long discussions, not only in
> www-style. I could search the quotes, but I think you know them already
> since you actively took part on the discussions IIRC. All viewers I know
> take a fixed resolution. This is from the WebKit source code: // We always
> assume 96 CSS pixels in a CSS inch. This is the cold hard truth of the Web.
> // At high DPI, we may scale a CSS pixel, but the ratio of the CSS pixel to
> the so-called // "absolute" CSS length units like inch and pt is always
> fixed and never changes.
>
> The test works on Firefox as well as on Batik and on a local copy of WebKit
> here. So

Hmmm, the problem with such a test suite is, that it tests the 
recommendation(s), therefore the tests have to follow what is recommended
for the related recommendation, not necessarily what is typically 
implemented - this can change and cannot be a base for a reliable test of
a defined version of a language, this has to be always some stable 
recommendation (else we get funny effects as in the middle age, where 
length units like inch were defined in relation to the size of the thumb of
the current dictator of the local area, what is a problem for the interchange
of information with other areas or if the dictator is replaced with another 
one or one simply wants to know, how much it was hundred years in
the past) ;o)
To test, what exactly gets wrong and maybe why in individual viewers
is interesting as well, but not necassarily as a test of a recommendation
as a test, whether viewers implement what is recommended or something
different.

If all or typically used viewers fail on a test, authors, implementors and WG 
members may come to the conclusion, that the tested feature is not properly
implemented or implementable, therefore should be removed or deferred
until the feature is implemented properly. 
I think, it is not a good idea to test meaningless/contradicting behaviour
from implementations, that have no sense (like interpreting an inch as 96 
pixels - following the current CSS2.1 draft it would be possible to avoid
contradictions by always presenting 96 pixels as exactly one inch, but this
is often not very useful for devices like monitors, because it typically 
requires interpolation over device pixel, what is often suboptimal for 
graphics).

By the way, according to my tests the adobe plugin, pretty popular for SVG 1.0 
and SVG 1.1, uses 90dpi (what is a bug as well, but different from 96dpi).
By the way, I discovered on my Debian 6 Linux, that several browers claiming
to use webKit try to use the adobe plugin instead for SVG 1.1 full  and do not 
display SVG tiny 1.1 at all - because I do not know how to convince them to
use webKit instead, finally the adobe plugin is still pretty alive and 
replaces webKit quite often, if SVG is presented at all with those
browsers ;o)
Typical stable versions of Mozilla/Geckos 
(for example the current iceape 2 or iceweasel 3.5) 
manage to present a cm as a cm without problems.
Therefore we can conclude, that there is no common bug phenomena 
for the presentation of absolute units within the past 10 years of SVG.
There are a lot of different bugs and problems in the implementations.

>
> > - The description is somehow surprising as well -
> > "Test possible values for 'calcMode="spline"', with both commas,
> > whitespace, and mixed separators"?
>
> Thanks, this line needs to be removed. The same for the title. Like I wrote
> in the comment on the SVG, I took test animate-elem-89-t as reference. This
> is the clincher :)
>

- yet another problem with the test - you used SVG tiny 1.1.
For this variant units are only allowed for width and height of the svg 
element, for other attribute of other elements no units are allowed for 
lengths. You can use SVG basic 1.1 or SVG full 1.1, to use units
for other attribute values like x of rect - or you have to apply the test
to width and height of the svg element, possible but difficult for 
quantitative tests, because tiny profiles allow only one svg - this is
the root element (of the SVG document, respectively fragment).

> > - missing unit ex?
>
> Yes, would be good to test it as well. Now that we use the same fonts on
> all browsers.

In the full profile one can define an SVG font for this, applied to a group
as parent of the animated elements, this can be pretty simple, if the group
contains no text at all - the viewer has only to extract the relation to em
to get it right. 

Olaf
Received on Saturday, 26 February 2011 13:01:25 GMT

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