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

Re: [SVGMobile12] Review Comments on SVG Tiny 1.2

From: Ola Andersson <Ola.Andersson@ikivo.com>
Date: Fri, 11 Nov 2005 12:50:17 +0100
Message-ID: <586AE9F507AF5E4AA45364333D9E2FA201093DB2@sesthsrv02.zoomon.local>
To: <www-svg@w3.org>, <codedread@gmail.com>
Cc: "SVG WG" <w3c-svg-wg@w3.org>
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 &nbsp;?  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 GMT

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