Re: Things I wanted to see in SVG 1.2, but aren't yet mentioned.

On Saturday, June 7, 2003, 4:50:16 PM, Jim wrote:


JL> Hi,

JL> Elements invariant to normal zooming/panning.

JL>   This is often requested in UI's, that some portion don't respond to zoom
JL> and pan, and it's often done with scripting. However that's obviously not
JL> ideal since it makes it impossible for those visually impaired users who
JL> need to zoom into content, unable to do so.

A trend that I see in interactive SVG content is to provide a
panner/scaler widget and for this to affect transformations, not
zooming. In some cases the zoom/pan is disabled, or the right-click
menu in ASV is edited, to encourage users to use the widget instead.

While disabling the zoom and pan is not a good idea (precisely for the
reasons Jim suggests) the separation of transformation from zooming
is, I think, generally good. Zooming should remain a straightforward
geometric operation. Operations such as 'show portion of map at more
detail while keeping the UI where it is' should be done using
transformation, and transformations might affect only parts of the
content, or be disabled for some elements, or some elements might use a
viewport coordinate system.

In other words, relying on the native zoom capabilities of the browser
to do this sort of detail management is suboptimal.

JL>  A specified method to do the
JL> invariance would remove the dependance on scripting and allow UA's to still
JL> provide a zooming mechanism.

Yes, it would. Its being discussed, but nothing was firm enough for
the current 1.2 draft.

JL>  Unfortunately I have no firm ideas on how this
JL> might be marked up, I don't think RAX provides the functionality, as it
JL> requires a UA to provide an alternative zooming mechanism to the default.

JL> Image size from the image...

JL>   This was a issue I had with SVG 1.0 and 1.1, which was rejected, it's
JL> still an issue, and it's also the thing about SVG that most irritates
JL> everyone I evangelise SVG to.  Many raster images have a size (especially if
JL> the UA can read the EXIF) this size should be useable when you include
JL> raster images in a document. I believe this should be by default, but I
JL> assume that's already a lost cause, so some attribute which would allow it
JL> would also be welcome. In fact anything that let it happen would be welcome.

Does http://www.w3.org/TR/SVG12/#imageDOM start to address what you
want?

EXIF is one possible format in which physical size could be
communicated. PNG and TIFF and etc have their own (in come cases
multiple different) ways of encoding this same information.


-- 
 Chris                            mailto:chris@w3.org

Received on Saturday, 7 June 2003 11:03:53 UTC