W3C home > Mailing lists > Public > www-svg@w3.org > May 2005

[SVGMobile12] Review Comments on SVG Tiny 1.2

From: Jeff Schiller <codedread@gmail.com>
Date: Tue, 17 May 2005 12:35:48 -0500
Message-ID: <da131fde050517103564f78ab7@mail.gmail.com>
To: www-svg@w3.org
Cc: codedread@gmail.com


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

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" />

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 &nbsp;?  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:


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#TransformedVideo", and
""http://www.w3.org/TR/SVG12/feature#TransformedVideo".  But Appendix
I has them in the form

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

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
for the animation model?

Jeff Schiller
Received on Wednesday, 18 May 2005 07:50:42 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:03 UTC