Re: agenda+ SVG 2 Features and Approach

Hi Doug & All,

	When the WG was private all development by the group tended to be
what the members themselves were interested in, rather than the community.

	As we became public and are now soliciting feedback from the
outside world about what we should focus on, it would be great to keep
focus on fast iterations, and what is of use to people in the real world for
use cases that SVG just doesnt do (well or at all).

	Keep it Agile, aim for small chunks and don't get absorbed in the
'process'. From the past few years of observation, here is a short list of
features that keep being asked for but are not yet addressed:

1) Non-scaling stroke. All SVG Tiny 1.2 viewers already implement this as
   part of the vector-effect module. Should be a no-brainer to add as a module
   for 1.1, rather than a 2.0 feature.
2) Shared-paths (super-path). Required for mapping and boundaries of
   countries etc. I can remember Andreas asking for this nearly a decade
   ago - this should be high priority IMO.
3) Adaptive stroking. Needed for cartography where the dashing always
   ends with a full length dash at the start and end of the stroke. So the
   borders of things look consistent - i.e. not chopped off. It requires the
   renderer to work out the length of the path and scale the dasharray
   appropriately. Been a part of HP-GL for decades, surely SVG should
   handle this; and relatedly:
4) Hatch-fill. Required for mapping again. If you have a large area you
   just want to fill it with a bunch of spaced lines/hatches etc. Pattern fill
   doesn't work since you get tiling problems. Easy to do in Postscript
   or HP-GL. Difficult in SVG.
5) Level of detail control. If we have a large data set, and we zoom, then
   level of detail control of what gets drawn is useful for _lots_ of use cases.
6) Text flow into arbitrary shapes. Flow charts, organisational charts, heck
   _lots_ of use cases. The WG designed this for years for 1.2 Full,
   Inkscape implemented it and then it vanished due to Mobile obsession
   or some other reason. I would really like to be able to shove some text
   into a diamond without pain.
7) Templating for controls (a.k.a widgets). Building a web app with UI
   components needs this. JonF's original 'Grand Unified' plan which
   begat RCC, sXBL, etc. and then vanished is a gaping hole in the
   spec. as is. Just the other day I wanted to build a scroll bar and polled
   "people that know" who advise me to use Javascript libraries. I can
   build Windows apps with all sorts of component controls, OS X apps
   with Interface builder etc. A templating mechanism for things that can
   be re-used would be nice.
8) Take a machete to the DOM. People complain and rightly so. The
   1.2 Tiny micro-DOM didn't seem to tickle anyones fancy. So we need
   to address the DOM to attempt to keep people happy and make the
   web app developers life nicer.

My own wish-list:
1) Arbitrary fill. e.g. specify video or an image as a fill paint source. Someone
   said this was just texture mapping, but it's not. Texture mapping is mapping
   a 2D thing onto a 3D surface using anisotropic scaling, mip-maps or whatever
   technique you like. What I mean here is still plain 2D. It would allow video
   for example be the fill of an object (nice for video fonts:-) Also an SVG image
   could be a fill. Most of this could be done with clip paths too, but it would be
   much easier to avoid the clip-path route since that is not as flexible since
   you could animate a rectangle/path etc. and then you're dealing with one
   object alone. From a model point of view I can't see why this should be
   difficult.
2) Flatten to image. For some use cases, a zillion paths or objects probably
   end up chewing memory and bloating the DOM for some special cases.
   So, it would be nice to have a primitive that takes the rendered output
   of arbitrary SVG and flattens it to an image so all you get is the pixels.
   Think of it like 'use', but the target of the use becomes a sprite with all
   it's efficiency of rendering, blitting etc. Access to the pixels of course
   is a logical extension of this; and so:
3) Hit-testing on image alpha. This has been asked for - but if we add
   it for PNG, then we could have the: <path> becomes <image> then
   you get hit-testing the same from the flattened to image version as with
   the original path data, only no DOM for the path(s) that made the
   original image.
4) Automatic fetch/discard sub trees. Thinking of the 'Big Data Set' like
   say all of openstreetmap.org, it would be nice to have a parent element
   like say <animation> that manages conditional zoom/pan to fetch and/or
   discard the child tree data. This is along the lines of the SVG Tiling
   module but more general. If we want to pan an SVG of the entire
   planet in detail, then the UA should be able to load content that
   declaratively says it should exist if you've panned within 'n' pixels of
   the viewport or have a specific user->device zoom level set. Then
   you can walk a tree of the world and only have relevant content
   in your DOM without ever resorting to script to manage it all.
5) Fluorescent colours/extended colour specifiers. At the moment
   we have the HTML colour names, rgb(,,) and ICC support. Extended
   colour spaces have been in mainstream O/S graphics libraries for
   quite some time allowing you to specify R greater than 1.0 (or 255
   if you think 8-bit). It's high time we had high dynamic range colour
   in the stack.

and many more.

But of course pragmatism should rule, as with anything.

Just my first rant at some things that could be nice.

Alex

Received on Monday, 9 May 2011 02:45:57 UTC