- From: Thomas DeWeese <Thomas.DeWeese@Kodak.com>
- Date: Fri, 02 Apr 2004 16:16:48 -0500
- To: www-svg@w3.org
Hi all,
Attached is a detailed set of comments on WD-6 of SVG 1.2.
It may make things easier if people respond to individual sections
rather than the whole thing at once. If so changing the subject
might help.
---
FlowText Suggestion -
Can you add a 'getAsTspan()' method to the FlowRoot element? This
would return a text element with tspan's that would render identically
to the current display (ideally it would even use things like
text-length on the individual spans). This is important to avoid
'rewraps' when moving between a client environments.
One issue this would require adding the ability to include SVG
graphics in the standard 'text' element. Which only makes sense given
the support in FlowText.
---
If you are going to have flowImage (which I'm not really sure you
should) then you should really have a grid element for doing 'table
like' layout. Once the UA needs to support dynamic layout of SVG
content it might as well support grid layout. This is also really
important for GUI type stuff.
Suggestion:
<grid x/y/w/h>
<gridCell colSpan width/height>
<gridText>
<flowDiv> (could have gridDiv - but doesn't really seem needed).
</gridText>
</gridCell>
</grid>
<gridRef xlink:href="">
Like 'flowRef' allows references to gridCell's 'out of line'
so z-order can be easily manipulated.
Along with this I would add minWidth/minHeight maxWidth/maxHeight
to SVG locatable. This would allow the layout to be easily specified.
For most SVG graphics min/max W/H would == W/H. For gridText it would
be the max word length, and total line length in progression direction
with lineHeight/lineHeight*maxNumLines(?) in non-progression
direction (this might need a little tweaking, I'm not 100% sure what
makes sense in the non-progression direction).
This really should be trivial to implement given flowText as once
the table alg is applied (which is fairly simple given the methods
above - which more or less fall out of text wrapping) it should be
simple to transcode the grids to flowRoot/flowRegion equivalents.
---
2) Printing
The text seems a little contradictory in places:
"No SVG content is allowed between the pageSet and the root svg
element."
(I think this is an error) then later:
<svg ...>
<defs><!-- definitions here are always available --></defs>
<g> <!-- graphics here are always visible --></g>
<pageSet>
</svg>
---
10.3 Constrained Transformations
The value of 'target' can either be a local id URI
reference or the special keyword 'host'.
Does this mean: "ref(url(#myId))" or "ref(#myId)" or "ref(myId)".
What happens if 'myId' is "not displayed" (in defs, ancestor has
display="none", etc), Error? no transform?
It says:
if the tree is referenced by an element from the SVG language,
then the search continues from the referencing element
I assume that this means that for 'use' references the search
jumps to the use element? Gahh!
I really wish the WG would bite the bullet and say that 'use' is
really just a shadow tree. This might break the small amount of
existing code that relies on modification of the referenced element
updating all instances, but it would avoid introducing another whole
system of dependency tracking...
It would also allow for things like getTransformToElement to
be useful.
---
11.4 Inheritance into the shadow tree
The User Agent default stylesheet for SVG 1.2 user agents, to
give SVG 1.0/1.1 compatible styling, includes the following
rules:
symbol { shadowInherit: onUse; }
image, feImage { shadowInherit: none; }
This example looks really odd to me: first feImage can behave
like use or image depending on what it is referencing - so there is
really no way to mimic this behavior here. Second you swap where you
define shadowInherit from the referenced element (symbol) the the
referencing element (image). I think 'symbol' should be 'use' - since
symbol doesn't establish the show tree the 'use' element does.
---
11.6 Controlling the rendering color space
The SVG Working Group are considering removing this new feature
from SVG 1.2 due to lack of interest.
Please don't. There is a working implementation available for
Batik, and this feature is really critical for some high quality/
high performance work flows.
The current specification requires user agents to repeatedly change
the color space each time color spaces other than sRGB are used. This
causes harm to the image data, in that colors can "walk" and precision
is lost, etc.
Additionally the current support for just linear and gamma
corrected sRGB is quite limiting. There are a number of new color
spaces coming into use that are designed for image quality rather than
matching existing phosphor colors. The use of these color spaces is
likely to expand over time and in general it only makes sense to
composite an image in these optimized color spaces rather than
converting everything directly into sRGB.
Given that user agents must already support ICC profiling of image
data expanding this functionality to arbitrary 3 band color spaces
makes a lot of sense.
---
11.12 Overlaying graphics
Any comment on how this plays with background image? How about
the extended composite rules? Basically are these overlays
considered to have no background image, the background image at the
point they exist in the document, or at the point they are rendered?
Do they appear in other siblings that request background image?
Other overlays?
---
11.15 More rendering hints
It is unclear to me what the intended difference between 'cache'
and 'static' is. Can you provide an example where a UA would act
differently between 'cache: true' and 'static: true'?
Is the intent that offscreen images only be created for
"cache:true; static:true"?
---
12.2 The min-unit-scale and max-unit-scale attributes
I still think these are better done with a custom element that can
make intelligent decisions about what branch should be displayed,
and provides a much clearer semantic relationship between the
various branches. However, at the very least the following text
should be tightened:
"If the scale factor from the current user coordinate system to
the viewport coordinate system is greater than min-unit-scale,
then the test evaluates to true. If the scale factor from the
current user coordinate system to the viewport coordinate
system is smaller than max-unit-scale, then the test evaluates
to true. Otherwise, the tests evaluate to false."
This means both will evaluate to false when the scale factor equals
min/max-unit-scale - this means that most of your example content
will fail:
<switch>
<g id="veryDetailed" min-unit-scale="10"/>
<g id="somewhatDetailed"
min-unit-scale="1" max-unit-scale="10"/>
<g id="roughlyDetailed" max-unit-scale="1"/>
</switch>
Nothing will show for unit-scale = 1 & 10. One of the above
checks and only one should be changed to include "or equal to" (don't
change both otherwise people who don't use 'switch', which is likely
to be _lots_ of people will get two branches rendered at 1 & 10).
I still think you should stick with the version of this feature
that actually has a working implementation, rather than wasting time
redesigning it.
---
13 Vector Effects
So I must admit to being a bit nervous about the inclusion of
very complex actions like 'union' and 'intersection'. In my
experience even the best libraries for these actions have at times
"screwed up" (in this list I include Illustrator, Java, several
3D programs) - in fact I've never known a library that didn't have
instabilities in these operations (doesn't mean it doesn't exist
I just haven't encountered it).
Also I will point out it is not always clear what the correct
answer is for these, imagine two rectangles that share an edge:
<rect x="0" y="0" width="100" height="100"/>
<rect x="100" y="0" width="100" height="100"/>
What is the result of 'union'?
<path d="M 0,0 h 200 v 100 h-200 v-100z"/>
<path d="M 0,0 h 100 h 100 v 100 h-100 h-100 v-100z"/>
<path d="M 0,0 h 100 v 100 h-100 v-100 z
M100,0 h 100 v 100 h-100 v-100 z"/>
All three enclose the union of the area of the two shapes, thus
meeting some criteria for "an outline of the union of two shapes".
Many people would argue against #3 because it has an edge that passes
it's self going both ways, but what if the 'source' geometry contains
such edges - should they be cleaned? If so the union of an object
with it's self may not be it's self (generally not the mathmatically
desirable result).
Also while #1 and #2 would stroke identically if you apply markers
the result would be different. I've never seen a Union engine that
would generate #1 - even though that is probably what "people" would
want :)
Are any of the above acceptable? If so authors need to be warned.
I personally feel that these methods may make more sense in script
than declairative.
---
13.3 The veStrokePath element
What is the expected output of this? Are poly lines OK? In
general none of the SVG geometry can be stroked and "stay the same"
so an outset/inset cubic bezier is no longer a cubic bezier. So
some level of approximation _must_ take place. Is it up to
implementations how this feature is implemented? Once again
differences here may not have large visible differences when
filled/stroked but if markers are used these differences will be
very visible.
The specification needs to be clear about this so authors know what
to expect.
---
13.17 The vector-effect property
The specification of 'non-scaling-stroke' is:
<vectorEffect>
<veFill/>
<veStrokePath in="SourcePath"/>
<veFill transform="ref(host)" fill="StrokePaint"/>
<veMarker/>
</vectorEffect>
Shouldn't the 'transform' be on the veStrokePath? Also doesn't
the veMarker need to have in="sourcePath" otherwise it will
marker the outline of the stroke not the path as it is supposed to.
"Should markers scale in this case?"
If one had to be picked(and I think one does) the obvious answer is
no. Admittedly in some cases the markers will then start
"overlapping" each other but the alternative is that markers slowly
sink into a sea of stroke - which is almost certainly not the intent
(they might want to turn off markers at a certain point).
The reality is that this case would be unusual but when used I think
the constant size markers are significantly more likely to be
---
14 Progressive Rendering
"A user agent implementing progressive rendering must render the
current document tree with the following rules:
* The user agent updates the rendering following each startElement
and/or endElement SAX event."
First off which is it 'and' or 'or'? :)
Second off isn't O(N^2) behavior supposed to be bad? :)
I think we want to give UA's some room here to be "smart". A
renderer should not be be required to rerender a document that
contains a background rect with a filter effect comprised of 50
filter primitives that takes 30sec to render per square inch for the
10,000 simple elements that follow. It should have the option of
balancing time spent rendering the document for progressive display
with time spent reading the document - the end result will be a more
pleasant experience for users.
Also you went to such lengths to describe font's what about
gradients (gradient-stop element children), filters, vector effects,
patterns (this is a debatable), etc.
I like the model proposed but the way it is currently specified a
truely conforming implementation would be terrible to work with.
Received on Friday, 2 April 2004 16:16:59 UTC