Re: SVG 1.2 Feedback

Hi all,

    This got lost in my drafts folder.

---

Section 12 Alternate content based on display resolutions:

    I am strongly in favor of resolution based selection
of content, and I understand the attraction of using the
switch element to provide this functionality, but if you
will recall my previous comments on this issue which come
from two prior implementations I hope you will reconsider.

    There were two major issues that I encountered with
using the switch element.

1) The way switch is specified when you introduce a new
    test attribute these attributes become available on every
    element anywhere in the document.  They are not restricted
    to the children of a switch element.

2) The 'switch' element offers no guarantee of rendering bounds.
    This is critically important for multi-resolution data. In general
    the whole idea of providing multiple data sets is that the client
    can't handle or access reasonably the entire high resolution data
    set.

    The current proposal is interesting in that it introduces a
new test attribute 'requiredView' that can be used to enable/disable
the rendering of subtrees based on the region of the document
currently being rendered.  However I must wonder what is the
advantage of 'requiredView' over extending the existing 'clip'
property?

    It seems to me that the current 'clip' property has the
advantage that authors receive visual feedback if the bounds are off
by small amounts.

    One major concern here is implementation complexity.
This proposal creates a complex 'feedback' loop between the
rendering tree and the DOM tree, to a certain extent this is
required to support multi-resolution data.  However, rather
than limiting this complexity to a single new element the current
proposal adds this complexity to every element in the language.
This might not be an issue if there were not several SVG renderers
in existence, in my experience supporting a new element (even an
oddly behaving one) is much easier than adding significant new
complexities to every existing element.

    However even discounting implementation complexity I would argue
for the element based approach.  As I said above proper use of
multi-resolution imagery almost always requires bounds information
and resolution information, by introducing a new element you can
ensure that these two pieces of information are always supplied.
With the test-attribute approach authors/tools can easily 'forget'
the bounds information - the impact of this sort of mistake is easy
to miss early on, and may only become apparent when the content is
scaled  up or distributed on the Internet (i.e. often too late!) -
making matters worse the existence of the additional test attribute
may be forgotten leaving authors wondering how to resolve the issue.

    This is my feedback based on doing two distinct working
implementations in the Batik viewer.  I have also authored a
fair amount of content that makes use of these multi-resolution
extensions so this is all _very_ practical feedback on this
feature.

    I would be very disappointed to see this very important feature
provided in a manner that is difficult to implement correctly
and makes authoring errors painfully easy.


Flow Text:

    I am a little curious what the line breaking behavior is supposed
to be.  Section 3.1.12 says that Unicode Standard Annex No. 14 is used
to determine line break opportunities.  This section also seems to
say that all glyphs from one word must appear in the same strip, yet
the 'Go!' example (while impressive) seems to violate this
principle a number of times ('p''aragraph', 'br''eak', 'th''i''rd').
I would put this down to a 'beta' implementation of flow text but
the associated text in the 'GO!' example seems to indicate that
this is the correct behavior.

    So which is correct?  I certainly hope it is section 3.1.12 as I
think the hard breaking of the words in this example is not very
good.  It might make sense to allow hard breaking only in the case
where the glyphs from the first word on the line can not fit within
a single strip although there is currently nothing that would define
this.

Received on Tuesday, 13 January 2004 08:08:37 UTC