Re: SVG authoring tool, please recommend one

> Who should I take it up with?

It more or less has to be CSS styles, when the content is HTML, because
it arises from the use of position style attributes.  It might also apply
independently to SVG, as SVG can include bit mapped images.  For styles,
you would use www-style@w3.org, but note the previous discussion that
I referenced in my addition to Bugzilla bug 88866.  Please note that
that thread was asking for exactly the opposite (so that one could have
links that were invisible but still effective).  Also check the latest
CSS2 errata, to make sure there has been no clarification.  

For SVG, the list is www-svg@w3.org.  Both lists are consultative only,
there is no requirement to act on comments and there is no obligation to
say why a decision was or was not made.

In the case of HTML, my view would be that you are straying so far out of
the remit of HTML (the T in HTML stands for text!) that the decision may
well be to leave the behaviour as an implementor choice (like rather more
things in HTML than most authors realise).  If they do make a decision,
and the de facto behaviour of Netscape and IE are consistent, I would
expect them to specify the current behaviour.

Given the de facto role of SVG (as a W3C replacement for Flash) I think 
clear specification of the behaviour would be important.  I haven't read
the specification thoroughly enough yet to be sure that the behaviour is
not already defined.  Note that SVG relies on style sheets in some areas,
and uses existing attributes, where appropriate.  Also, a bitmapped 
image in SVG can be clipped using vector commands, so the function does
not require a particular interpretation of bit map transparency.

(I see your problem with the concepts of splines and ellipses++ to be
a user interface issue for authoring tools, not really an issue for
viewing technology.  All the examples on your home page are logically
vector diagrams (and appear to have been created with vector tools,
even if the tools couldn't save the vector description).  It seems to
me that the diagrams are always going to have an underlying abstraction
(unless simple photos).  If the people converting the images to concrete
form have difficulty in externalising the abstraction, the tools to help
them are tools that attempt to recognize and recreate that abstraction,
not ones that simply allow unstructured imagery.  This is a difficult
problem (and one that people keep claiming to have solved.

Although only a pale imitation of such a tool, it shouldn't be too
difficult to post process a transparent image and construct a clipping
path for it that is a good enough approximation to the outline.  Tools
for doing this sort of thing already exist for creating outline fonts from
bitmapped fonts, and more generally for recovering vector diagrams from
scanned drawings.)

I think there are W3C people on the current list, and I'm sure they will
contact you directly if they feel the need to raise the issue using
internal channels.

++ I'm not sure that this has appeared on this list, but the reason why
imaging mapping is a problem is that the image objects are hand drawn 
objects with non-rectangular boundaries, drawn by people who have 
difficulty with handling the abstraction of letters on paper for 
spoken words and presumably with externalising other abstractions.

Actually, it is not just people officially classed as with "learning
disabilities" who have difficulties externalising abstractions, which 
why one gets so much WYSIWYG HTML.  Mainstream authoring tools could
also do more to try and divine the underlying abstractions (MS Word does
this in a limited way in that it detects the presentational form of lists
and converts them into real lists).

Received on Thursday, 5 July 2001 16:36:03 UTC