Re: SVG authoring tool, please recommend one

Well, I have a differnt approach. I still think that the support in the
underlying languages is adequate. In the case of animated HTML you should use
a tool to pick out the actually visible part of the image and apply a map to
make that part the link, and then moving the image has no great effect,
since the map applies relative to where you are in the image rendered, not
where the image is rendered on the page. In SVG you define whatever
part you want to be the link, so the idea os to define the link as the
visible part(s) of the image.

This does need to be better supported in authoring tools, and probably in the
content guidelines - it is an extension of the principle that the stuff in a
link is meaningful, as applied to what is meaningful in a picture (a
transparent background generally isn't), but I think we should be more
explicit about that.

(Incidentally, yesterday I spent a bit of time in Geneva talking to some
folks who are working on how to convey what is in an image to people who
can't see it, and they have a similar kind of issue - identifying shapes and
objects within the image is important to them.)

cheers

Charles McCN

On Thu, 5 Jul 2001, David Woolley wrote:

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


-- 
Charles McCathieNevile    http://www.w3.org/People/Charles  phone: +61 409 134 136
W3C Web Accessibility Initiative     http://www.w3.org/WAI    fax: +1 617 258 5999
Location: 21 Mitchell street FOOTSCRAY Vic 3011, Australia
(or W3C INRIA, Route des Lucioles, BP 93, 06902 Sophia Antipolis Cedex, France)

Received on Thursday, 5 July 2001 18:01:05 UTC