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