Re: Comments on SVG 1.2 WD-6

On Fri 02 Apr 2004, Thomas DeWeese wrote:

> 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.

Yes, thanks for reminding us.
I think Jon had mentioned it in his DOM proposal for this
stuff, but it has not made the draft.

>   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.

Right. Good point. Maybe it should skip graphics.

> ---
> 
>    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.

[skipping suggestion]

Having tried to lay out documents with the current
flow text and flow image, I really really strongly 
agree with you. It's nearly impossible to create a 
document without some form of automatic layout (other
than by using an external layout program like
InDesign, but then there isn't really much point using
flowRoot). Eg. a bullet list.

+1 on grids (and I agree that they aren't a huge
implementation burden).

> 2) Printing
> 
>   The text seems a little contradictory in places:
> 
>      "No SVG content is allowed between the pageSet and the root svg
>       element."

That was supposed to be "No content between the end of the pageSet
and the </svg>". My mistake.

>   (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>

Yep. The example is right.

> 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)".

I'd assume ref(#myId).

>    What happens if 'myId' is "not displayed" (in defs, ancestor has
>    display="none", etc), Error?  no transform?

It still is in a coordinate system, even if it is never
displayed. Or am I misunderstanding the question?

> 
>   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!

That's my understanding. I'm not sure if it is what people
want.

>   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.

Comment accepted :)


> 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.  

OK. We'll probably have to remove the feImage bit and
put it in the specification text. What a pain.

> 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.

Agreed.


> 
> ---
> 
> 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.

That sounds like "interest" to me. To be honest one of the
reasons we put that in was to encourage feedback like this.
However the most important thing is to ask whoever gave the
feedback if they would be willing to write the test cases.
I'm not joking.

>    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.


The next problem will be getting enough implementations, but
that is a problem in CR, not now.

> ---
> 
> 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?

I'll skip this one for now.

> ---
> 
> 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'?

Do you mean between "cache: true; static: false" and 
"cache: false; static: true"?

The use case for static: true was a scroll region (say a 
large amount of text where only a small amount is shown, the
rest is clipped - the user drags the region around). While this
is redrawn often, it is the same thing being redrawn each time
(with a different clip). Another one is a sprite (symbol).

For cache: true, it could be something that is modified by script
often. A user agent may cache as many of the drawing objects as
possible (pens, bboxes, filter buffers, etc), hopefully speeding up
subsequent redraws.

Does this make sense? (Not sure it does to me:)

We are currently thinking of better names. 

>    Is the intent that offscreen images only be created for
>    "cache:true; static:true"?

No. My understanding is that cache: true *may* cause the
UA to not create an offscreen. That is, it would be
better off storing other information than an offscreen (since
it would be changing often).

However, I wouldn't be shocked if I were wrong.

> 
> ---
> 
> 12.2 The min-unit-scale and max-unit-scale attributes

I'll also skip this one for now.

> 
> 13 Vector Effects
> 
>    So I must admit to being a bit nervous about the inclusion of
> very complex actions like 'union' and 'intersection'.  

Again, skipping for now.

> ---
> 
> 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.

Agreed.

> ---
> 
> 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? 

Yes, my bad.

>  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.

Yes, my bad again.

> 
>    "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).

I wasn't sure which way it should be.

>   The reality is that this case would be unusual but when used I think
> the constant size markers are significantly more likely to be

.... what was intended? I think so too.

> 14 Progressive Rendering

skipping.

Thanks for the comments. I'll gather my strenth before 
tackling the harder ones.

Dean

Received on Monday, 5 April 2004 13:45:34 UTC