- From: Ola Andersson <Ola.Andersson@ikivo.com>
- Date: Fri, 11 Nov 2005 12:50:17 +0100
- To: <www-svg@w3.org>, <codedread@gmail.com>
- Cc: "SVG WG" <w3c-svg-wg@w3.org>
- Message-ID: <586AE9F507AF5E4AA45364333D9E2FA201093DB2@sesthsrv02.zoomon.local>
Hi Jeff,
Thanks a lot for your thorough review. The SVG WG has addressed all your
comments, if you find any of them unsatisfactory please let us know
within a week.
Best regards
/The SVG WG
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"
REPLY: All the typos have been fixed.
***********
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?)
REPLY: The forgotten link has been added to the references section
and it is indeed the link you give.
***********
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?
REPLY: We have added 'including the '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.)"
REPLY: 1.6 SVG Document Fragment now says: "The XML document sub-tree
whose root element is an 'svg' element. An SVG document fragment can
consist of a stand-alone SVG document, or a fragment of a parent XML
document enclosed by an 'svg' element. In SVG Tiny 1.2 each SVG document
fragment must not contain nested 'svg' elements ."
***********
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).
REPLY: This has been fixed in response to other comments. Check out this
thread http://lists.w3.org/Archives/Public/www-svg/2005Apr/0281.html.
***********
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?
REPLY: You are correct, you need to specify the width and height
attributes on
image in order to get it to display. This is due to the use of
coordinate systems
(viewBox attribute defines the coordinate system) which means
width and height derived from pixel dimensions is of limited value.
E.g. an image with an intrinsic size of 640x480 would be huge in this
coordinate
system: <svg viewBox="0 0 0.003 0.004"> and very small in:
<svg viewBox="0 0 3000 4000">. The user needs to specify width and
height
to define a relevant size.
***********
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?
REPLY: This was an unclear sentence which has now been fixed in response
to other
comments. It now reads: "The 'end element' event occurs either
immediately following
the 'start element' 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)?
REPLY: Concerning #3, you are right that the rendering is suspendend
because of
externalResourcesRequired="true" on the g element, i.e. because the
children of g
are not resolved at the time of parsing of the start tag of g.
The spec has been changed to: "(rendering is suspendend because of
externalResourcesRequired="true" on the g element, i.e. because the
children of g
are not resolved at the time of parsing of the start tag of g)"
Concerning #4, you are right and the spec has been changed to:
"rendering suspended
because of g".
***********
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)"
REPLY: You are right and this has been fixed.
***********
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?
REPLY: The specification has been fixed to indicate that the bandwidth
attribute is in bits per seconds.
***********
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?
REPLY: prefetch is just a hint to the UA so a UA is free to ignore
prefetch and
is not required to flag it in any way. The feature string for prefetch
is
included for completeness and as an aid for UA's that chose to honor
prefetch.
However a UA are allowed to claim support for #Prefetch and still ignore
all
prefetch elements.
***********
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)?
REPLY: The class attribute is considered metadata in SVG Tiny 1.2. SVG
Tiny 1.2
does not support selectors. These attributes are now in the Core
Attribute Module
(which contains id, xml:base, xml:lang, xml:space, class)
***********
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).
REPLY: You are right that the example could be clearer. The WG does not
consider
this to be a high priority change but will change it if time permits.
***********
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)
REPLY: Indeed it was incorrect, it has been changed to:
TS(g2) = TS(g) . I = scale(2) (I is the identity matrix)
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" ;)
REPLY: This section was incorrect and has been fixed.
***********
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 ;)
REPLY: We agree there would be no point in providing path mappings for
circles
and ellipses since it is not possible to get an exact mapping. The point
for the other mappings is that they might be helpful to implementers
that
need to perform these mappings.
***********
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.
REPLY: You are right, it is no purpose of this statement at all,
therefore
the WG has removed the entire section.
***********
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?
REPLY: It was a mistake. This has been fixed and now there are spaces.
***********
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?
REPLY: This was a mistake. It should have been height. This has been
fixed.
***********
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?
REPLY: yes, 'tbreak' is only used with 'textArea' as your example shows.
The WG will try to add an example to illustrate this.
***********
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?
REPLY: 'line-increment' and 'display-align' only apply to text area so
we have changed the "Applies-to" row in the definition to not mention
"text content elements" but TextArea instead. Attributes are normally
defined within the element definition but properties are often placed
separated from the element definition. This follows the style of earlier
svg specifications so we will keep it as is.
***********
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.
REPLY: These terms are specified in xsl
(http://www.w3.org/TR/xsl/slice4.html#area-rect)
and we have added a link to the definition.
***********
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.
REPLY: currentColor was in the previous version of svgt so it cannot be
removed, furthermore it is very useable in a mixed namespace scenario.
Opacity is specified via its own properties (fill-opacity,
stroke-opacity).
************
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).
REPLY: A-commands are indeed not in tiny. This is a bug in the example.
It has now been fixed.
*************
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."
REPLY: Now fixed.
*************
26) Section 11.7 The 'viewport-fill' Property: The raster example of
11_02.svg is incorrect, the background is not red.
REPLY: Now fixed.
*************
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?
REPLY: the fill property only applies to shapes so setting fill on the
svg element has no effect (except for being inherited to child elements
of course). Viewport-fill applies to the svg element and allows you to
specify a color that will fill the entire viewport.
**************
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)?
REPLY: since 'viewport-fill' applies to elements that 'fill' and
'fill-opacity' doesn't apply to (and vice-versa) the statement is
correct, although strictly speaking not really needed. The WG think it
increases the understandability of the property, especially for people
that are not completely familiar with the property mechanism.
The WG does not believe the property needs to be mentioned in Chapter 3.
**************
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?
REPLY: The WG now has removed the overflow property in svgt1.2. Instead
we explicitly say that the behavior of the animation element is as if
overflow=visible. (animation was the only element affected by the
overflow property)
**********
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.
REPLY: We agree and now explicitly mention this in the spec.
************
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.
REPLY: It was a typo that is now fixed. We now have:
fill="url(#solidMaroon)" (maroon because crimson isn't a valid color
keyword).
*************
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'.
REPLY: No, color cannot have 'currentColor'. We have added the following
explanation to 11.14.2:
"The 'color' property, defined in CSS2 as the color of text, does not
directly apply to SVG elements. The value of the color property may
however be used to provide an indirect value for those properties which
allow the currentColor keyword: the 'fill', 'stroke', 'solid-color' and
'stop-color' properties." Which should explain your question.
*************
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.
REPLY: You are correct. This was a typo that now is fixed. y2 default to
1. This makes the text understandable.
************
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.
REPLY: fx, fy are not part of tiny. The example has been changed.
*************
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.
REPLY: Now fixed.
*************
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/#..." This is correct!
REPLY: You are correct. We have now changed the feature strings to be
consistent (Appendix I has the correct 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
described.
REPLY: 'disable' disables zoom and pan. We don't have a separate
attribute value for panning but as the spec indicates it is clearly
supported.
**************
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/#AnimationSandwich
Model
for the animation model
REPLY: You are correct, this has now been fixed. We don't link to
smil-animation any more but to the smil 2 spec.
Received on Friday, 11 November 2005 11:50:36 UTC