- From: Jeff Schiller <codedread@gmail.com>
- Date: Tue, 17 May 2005 12:35:48 -0500
- To: www-svg@w3.org
- Cc: codedread@gmail.com
Hello, I'm relatively new to SVG but thought I'd give you my review comments. Unfortunately I did not get a chance to finish the review as I'm doing this in my spare time. Thus, I did not get into some topics like Animation, Fonts and the SVG uDOM. I hope to finish my review but it will be after your deadline of May 20th. 1) Typos: Section 1.2: "attibute" => "attribute" Section 5.9.2: "statElement" => "startElement" Section M: "RealaxNG" => "RelaxNG" ? Section 10.11.1 Title "Intoduction to text in an area" => "Introduction...." Section 10.12.1 Third paragraph: "pletform" => "platform" 2) Section 1.1: Last sentence references [AWWW] but this link is not present in the References section (AWWW's link should be http://www.w3.org/TR/webarch/, right?) 3) Section 5.1: "An SVG document fragment consists of any number of SVG elements contained within an 'svg' element" => Should you explicitly state that a "SVG Document Fragment" also includes the containing 'svg' element? 4) Section 5.1: "An SVG document fragment can only contain one single 'svg' element, this means that 'svg' elements cannot appear in the middle of SVG content.". This seems to contradict Section 1.6 Definitions where for "SVG document fragment" which states: "When an 'svg' element is a descendant of another 'svg' element, there are two SVG document fragments, one for each 'svg' element. (One SVG document fragment is contained within another SVG document fragment.)" 5) Section 5.4: The "Discard" element states: "When the 'discard' element is used, the end user may see unexpected results when seeking backward because the seek will not re-insert the discarded elements. So, authors are encouraged to set the 'playbackOrder' attribute to true when using the 'discard' element.". The playbackOrder attribute should be set to "forwardOnly", not "true" (see Section 5.1.2). 6) Section 5.7: The 'image' element. Unless I misunderstood something, there is no way for raster images to be displayed at their native width/height without hard-coding the "width" and "height" attributes. If I want the user agent to render the image at its native resolution (let's say I'm designing a drawing program using SVG for rendering) this forces the constraint that I know all image width/heights beforehand or that I script something. Any suggestions for improving this? 7) Section 5.9.2: "The endElement event occurs either immediately preceding the statElement event in the case of an Empty-Element Tag or when the End-Tag is read." Should the endElement really precede (i.e. come before) the startElement event in the case of an Empty-Element Tag? 8) Section 5.9.2, Example progRend04.svg: <use xlink:href="#myRect" x="200" fill="green"/> <circle cx="250" cy="50" r="50" fill="pink" /> <g fill="red" externalResourcesRequired="true"> <circle cx="450" cy="50" r="50" fill="yellow" /> <rect id="myRect" width="100" height="100" /> </g> In the text below this example you state at #3 that : "3. g.startElement: no update (#myRect is resolved, but it has externalResourcesRequired set to true, so the referenced node is unresolved and rendering is stopped)." However, how is #myRect resolved upon g.startElement? Wouldn't #myRect only be resolved upon myRect.rect.startElement? Next, at #4: "4. yellow.circle.startElement: no update (rendering suspended because of use) 5. myRect.rect.startElement: no update" Isn't rendering suspended because externalResourcesRequired="true" for the containing g element (not because of the use)? 9) Section 5.9.2, Example progRend05.svg: At #7 you state: "7. fontA.font.endElement: 'A' rendered with fontB (represents current document state rendering)" This should be : "7. fontA.font.endElement: 'A' rendered with fontA (represents current document state rendering)" 10) Section 5.9.3., Prefetch, "bandwidth" attribute: What does this value really indicate? bits-per-second? kilobits-per-second? a percentage of total bandwidth? 11) Section 5.9.3, Prefetch: "User-agents can ignore prefetch elements, though doing so may cause an interruption in the document playback when the resource is needed.". Wouldn't a user agent that properly parses XML and doesn't yet support the "prefetch" element automatically ignore it? Thus, I'm not sure what to make of the "requiredFeatures" attribute and the fact that all SVG feature sets in Appendix I include "http://www.w3.org/Graphics/SVG/feature/1.2/#Prefetch". Can a user agent ignore all prefetch elements and still claim that it supports #Prefetch? Would a user agent that does not support #Prefetch throw some type of validation error? 12) Section 5.11: Into which module do the "class" and "xml:id" attributes fall? What do you use the "class" attribute for exactly -> is it used for CSS selector rules or for broader application? If only for CSS selectors, does it belong in SVG Tiny 1.2 (since Section 6.2 states SVG Tiny 1.2 does not support CSS selectors)? 13) Section 7.5, Nested Transforms, Example 07_07.svg. To me this is a poor example of the effect of a rotation within a series of translations as the first and third positions look very close to the same y-value. My suggestion is to make the third translation in ONLY the y-direction (translate(0,150)) such that it is obvious what is going on (you will have to expand the viewport size to 250 for this). 14) Section 7.7.3, Element Transform Stack, Example "Element transform stack", the lines: TS(g2) = TS(g) . scale(2) = scale(4) TS(r2) = TS(g) . scale(0.5) = scale(1) are incorrect. TS(g) is scale(2) but g2 does not have an additional scale(2) in your example. I believe they should be: TS(g2) = TS(g) = scale(2) TS(r2) = TS(g2) . scale(0.5) = scale(1) 15) Section 7.7.4, Current Transformation Matrix. The math: CTM(elt) = prod{i=0, i=n}(U[i].VB(g[i]).TS(g[i-1])).TS(elt) Where prod{i=1, i=n}(f(i)) as: prod{i=0, i=n}(f(i)) = f(n).f(n-1).f(n-2).[...].f(1).f(0) Is incorrect. Since the top formula leads to TS(g[-1]) when i=0. It should be: CTM(elt) = prod{i=1, i=n}(U[i].VB(g[i]).TS(g[i-1])).U[0].VB(g[0]).TS(elt) Where prod{i=1, i=n}(f(i)) as: prod{i=1, i=n}(f(i)) = f(n).f(n-1).f(n-2).[...].f(2).f(1) Else, define that g[-1] means the elt itself and then : CTM(elt) = prod{i=0,i=n}(U[i].VB(g[i].TS(g[i-1])) Though this seems like a bit of a "math hack" ;) 16) Section 9.3 & 9.4, Circle/Ellipse: I notice in other sections (rectangle, line, polyline, polygon) that you give the equivalent mapping to a Path element, but this is not done for a circle/ellipse. Should it? Is there any point to these mappings to a Path element other than rigor? ... and intimidation for those who read the spec ;) 17) Section 9.3 & 9.4, Circle/Ellipse: It is stated that: The arc of a 'circle' element begins at the "3 o'clock" point on the radius and progresses towards the "9 o'clock" point. What is the purpose of stating this? Does it have any bearing on anything? Also, I may be missing something here, but this would only be half the circle (or ellipse)? Shouldn't you be using the "12 o'clock" or the "6 o'clock" point to indicate which direction the arc is drawn and then state that it ends again at the "3 o'clock" point? The given text does not address whether the arc traverses counter-clockwise or clockwise (within the user-space). Same comment applies for the ellipse. 18) Section 10.10, White Space Handling. The strings you use to illustrate "preserve" do not have any spaces in them in the actual SVG html doc. See http://www.w3.org/TR/SVGMobile12/text.html#TextLayout. Perhaps ? Maybe it's just my browser? 19) Section 10.11.2, The 'textArea' element. For the "height" attribute definition, it states that a value of "auto" indicates the WIDTH is infinite. Shouldn't this be HEIGHT or is it really WIDTH? 20) Section 10.11.3, The 'tBreak' element. I do not understand how tBreak is used. I assume only with the textArea element. Is it similar to tspan elements, like this: <textarea width="200">Line 1 Text <tBreak /> Line 2 Text</textarea> Perhaps an example? 21) Section 10.11.4, 10.11.5, these properties apply only to TextArea or what? Shouldn't they be mentioned inside 10.11.2 instead? 22) Section 10.11.5, 10.11.6: I had trouble following this as I did not understand what "before-edge" and "after-edge" meant. Can these be defined somewhere? In some cases you refer to this as "before-edge" and in other cases you mention "before edge". Better to be consistent. The Unicode Annex #14 doesn't mention "before-edge" anywhere either. 23) Section 11.2 Specifying Paint: Is it really a big use case to have "currentColor"? What about other attributes such as opacity, etc? This seems like a special case, just want to verify if it is indeed necessary. 24) Section 11.3, Fill Properties. The examples (fillrule-nonzero.svg and fillrule-evenodd.svg) use the elliptical arc commands (A) in the paths, however this is apparently not supported in SVGT 1.2. Should not use a feature of SVG 1.2 Full in illustrating an example for SVG 1.2 Tiny (unless A is supposed to be supported in SVG 1.2 Tiny in which case, this is an even bigger mistake). 25) Section 11.5: "The value 'non-scaling-stroke' modifies the way object is stroked." Should be "The value 'non-scaling-stroke' modifies the way an object is stroked." 26) Section 11.7 The 'viewport-fill' Property: The raster example of 11_02.svg is incorrect, the background is not red. 27) Section 11.7 The 'viewport-fill' Property: What is the purpose of this property that the "fill" property does not fulfill? I understand it to mean that this is the default color for any viewports if "fill" property is not specified? 28) Section 11.7 The 'viewport-fill' Property: The statement "Viewport fill is not affected by the 'fill' or 'fill-opacity' properties." is a little confusing, given that the two operations are distinct (i.e. viewport-fill happens first, and then the fill operation). Also, does this property need to be mentioned somewhere in Section 3 (Rendering Model)? 29) Section 11.9 The 'overflow' Property: If this property only has "visible" in SVGT 1.2, then why not just remove it from SVGT 1.2? I see no benefit to leaving it in here unless you get document validation from this...or maybe for upward compability to SVGF? 30) Section 11.10 Controlling visibility: Should it be explicitly mentioned that neither the "display" or "visibility" properties affect the fact that the object still exists in the DOM. I guess this is rather obvious. 31) Section 11.14.1 The solidColor Element: In the example solidcolor.svg, is this proper syntax: url(#solidCrimson)n Or is the trailing 'n' a typo? I'm not familiar with the syntax, but it doesn't look right to me. 32) Section 11.14.2 : what does "potential indirect value (currentColor)" mean? Does this mean the "color" attribute can have "currentColor"? If so, then this is missing under 'value'. 33) Section 11.16.1 Linear Gradients: Perhaps it should be made explicit that the gradient's default direction is in the +x direction. This seems rather arbitrary to me (why not x2 defaulting to 0 instead so gradient defaults to +y direction?). Intuitively, I felt that the "y2" attribute should default to "1", not "0" (i.e. default direction should be diagonal across the screen from top-left to bottom-right). Guess this is just opinion. 34) Section 11.16.2 Radial Gradients: Are attributes fx and fy part of SVGT 1.2 or only in SVG Full 1.2? Example 13_02.svg mentions fx and fy, but the definition in 11.16.2 does not. 35) Section 12.2/12.3 (Audio and Video): Both reference a "requiredFormats" attribute but it is incorrectly linked to http://www.w3.org/TR/SVG12/painting.html#requiredFormats which is a dead link. 36) Section 12.3, 12.3.1, 12.3.2: Feature strings are of the form "http://www.w3.org/TR/SVG12/feature#Video", "http://www.w3.org/TR/SVG12/feature#TransformedVideo", and ""http://www.w3.org/TR/SVG12/feature#TransformedVideo". But Appendix I has them in the form "http://www.w3.org/Graphics/SVG/feature/1.2/#..." 37) Section 13.7 Magnification and panning: Mentions that all user agents should support magnification and panning, but the zoomAndPan attribute only supports "disable" and "magnify". Panning is not described. 38) Section 16.2.1 Third paragraph. The links to the "SMIL Animation Overview" and "SMIL Animation animation model" link to the same document, same anchor. Did you mean to link to http://www.w3.org/TR/2001/REC-smil-animation-20010904/#AnimationSandwichModel for the animation model? Regards, Jeff Schiller
Received on Wednesday, 18 May 2005 07:50:42 UTC