RE: SVG 1.2 General feedback

>>>>> "JL" == Jim Ley <jim@jibbering.com> writes:

JL> This is some short general feedback on various areas, more
JL> specific feedback on the SVG window interface will follow.

    Thanks for taking the time to review this...

JL> "preformatted" in 1.5 |'preformatted' This has the sole effect of
JL> turning off the suppression |of non-printing (white space)
JL> characters at the start of a line.

JL> If there's going to be such an attribute, (and I'd fall on the
JL> side of not) then why does it only do whitespace at the start of
JL> the line - why not end, or in middle?  Also I may be
JL> mis-remembering here, and I should check first, but does not XML
JL> allow the XML application to discard leading whitespace - meaning
JL> preformatted may be impossible?

    In the end the definition will probably look a lot closer to what
is in CSS.  It specifically calls out leading whitespace because the
middle whitespace is really controlled by xml:space in SVG, and the
trailing whitespace never causes line wraps, so the only whitespace
left to be effected by preformatted was the leading whitespace.

    As to why it is there, the first time I tried to do something
'real' with the flowText extensions in Batik, I found that I
desperately wanted/needed something like it.

    In most cases it would be theoretically possible to replace it
with flow-line elements with margins but that is _really_ hard to do
in XSLT type applications.

JL> 1.10 Text Flow I'd like a hyphenation engine to be an allowable
JL> extension, but obviously not required, but if a viewer did decide
JL> to implement it, I would still like it to be conformant and not
JL> need extensions.

    Since a major goal of the flowText is reproducibility across
implementations, We would have to have an attribute that indicated if
the implementation was allowed to do hyphenation.  Note that
implementations are required to support soft hyphens.

JL> 2.1 A default rendering would be very nice, it's not always
JL> desirable to spend time developing a UI widget, and it is best for
JL> understanding if we can have consistency between different
JL> applications where it's appropriate.  I also like the idea that
JL> there's a stable default rendering that users who don't understand
JL> a particular authors scheme can "switch to"

    It doesn't come across well in the draft, but the largest issue
here is that this pushes the WG to develop software.  This is not
something that is generally the domain of standards organizations.
Who will develop and perhaps more importantly maintain the default
implementation?  Handle bug reports, etc.  Obviously, if the question
is a simple do you want to have a default rendering or always have to
write your own the answer will always be give me a default rendering
(after all I can then decide not to use it).  But the real question is
do you want the resources of the working group devoted to the writing
of an SVG widget set or any of a number of competing issues?

JL> 6.2 Background fill - I'm not sure I like the idea of a pattern
JL> being fixed against user-pan, if we have a hatched background and
JL> the user pans, I think it might feel odd to not have the hatches
JL> "move", perhaps there could be an attribute to define the
JL> behaviour, if it's possible of course.

    I believe that fixed background was to be just one option.  It
depended on how exactly the fill was specified.

JL> 7.1 DOM access to images - Some image formats allow multiple XML
JL> documents to be included (e.g. Adobe's XMP can have multiple, or
JL> live alongside EXIF) it would be nice if we could make all
JL> available, but if not the spec should specify which (the "first"
JL> presumably.)

    We already require support for some image formats (PNG and JPEG),
do people have suggestions/requirements for metadata formats that
should be required?  (Please be realistic here and reasons would be
helpful).

    Also note that EXIF is not XML, which doesn't mean that we should
not make it accessable via DOM - but it points out that most of these
are binary formats.

Received on Monday, 18 November 2002 09:37:53 UTC