Re: Comments on SVG 1.2 WD-6

Hi Dean,

> On Fri 02 Apr 2004, Thomas DeWeese wrote:

>>FlowText Suggestion -
>>
>>  Can you add a 'getAsTspan()' method to the FlowRoot element?
[...]
>>  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.

Dean Jackson wrote:

> Right. Good point. Maybe it should skip graphics.

    Well I don't have strong feelings, but it seems to
me that either you have arbitrary svg content mixed with
text or you don't - having it in flowText but not in 'text'
seems wrong to me (what about text on a path?).  Of course
I'm no so sure you should have it in flowText...

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

    Why introduce a new new keyword that appears to have no
value over 'url(#myID)' as is currently used everywhere else?

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

    So I don't consider things with 'display="none"' to have
a coordinate system.  They aren't part of the display tree so
in my view they don't have a coordinate system.  In Batik
when it walks the tree building the display tree as soon as
it hits an element w/ display="none" it stops and goes to the
next element.  The above would essentially require us to
traverse that tree and build the display tree just so we know
what the nested transforms are (imagines large bock of flowText
with embedded images etc).

    I think this should just be an error in the document

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

     I've already done this - talk with Chris.

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

     Yes, of course as I noted below it wasn't clear if they
would both have to be true.

> The use case for static: true was a scroll region, [...]
> Another one is a sprite (symbol).

    Sure or a complex static background.

> 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:)

    So the intent of cache is to cache intermediate rendering
data (flattened paths etc)?  The only issue I see with this
is that unlike 'static' which says this subtree is static
so this one point is the place it makes sense to store an
offscreen buffer, cache must effect it's entire subtree.

    I guess there is some value here, but this one in particular
seems really ripe for abuse by authors (I can imagine lots of
people setting 'cache="true"' on the root of an svg document
causing memory usage to explode....

> We are currently thinking of better names. 

    How about better descriptive text :) - so both authors and
implementors have and idea of the contract underlying the hint.
In particular authors need to be made aware of the trade offs
being made here.

Received on Tuesday, 6 April 2004 06:22:26 UTC