W3C home > Mailing lists > Public > www-svg@w3.org > June 2003

Re: SVG 1.2 10 Alternate content based on display resolutions

From: Thomas E Deweese <thomas.deweese@kodak.com>
Date: Wed, 4 Jun 2003 08:15:24 -0400
Message-ID: <16093.58076.148215.652309@frog.rl.kodak.com>
To: Dean Jackson <dean@w3.org>
Cc: Jim Ley <jim@jibbering.com>, www-svg@w3.org

>>>>> "DJ" == Dean Jackson <dean@w3.org> writes:

DJ> On Fri, 09 May 2003, Jim Ley wrote:

>> I think in general the Alternate content section could be simply
>> extended to cope with low bandwidth aswell as different display
>> resolutions - it may also be possible to extend it in such a way
>> that you can specify different images for different sub-regions for
>> when zooming in/out without forcing the download of a complete more
>> accurate map and the bandwidth costs of that.  (basically doing
>> what we do in Level-of-Detail script changing situations)

DJ> I like the idea.

    I agree that this is a useful addition.

>> Exactly how that extension might be managed I'm not sure...  For
>> the bandwidth case, a simple advisory content-size attribute on the
>> subImage element would provide a hint to the UA, which it could
>> then use in the decision making process.

DJ> But we'd probably have to specify the behaviour. Can you make any
DJ> suggestions? (ie. what algorithm is the UA using).

    I agree with Jim's later statements that User Agents should be
allowed to make these tradeoffs.  The intent of the element is to
provide multiple versions 'of the same thing'.  The author can suggest
which should be used when but I think UserAgents should have a fair
amount of room to 'make the right choice' for them.  Of course a
dynamic implementation should not be conformant if it is only ever
capable of displaying a single branch.

>> For the more complicated LOD regional part, then the subImage
>> elements could also have x/y/w/h attributes defining the region of
>> the parent Image element that they refer to, looking something like
>> this:
>> 
>> <image x="200" y="200" width="100px" height="100px"
>> min-pixel-size="1" max-pixel-size="1" xlink:href="myimage.png">
>> <subImage xlink:href="myimage-lg.png" min-pixel-size=".5"
>> max-pixel-size=".5" x="25px" y="25px" height="50px" width="50px">
>> <desc>An alternative image for the central portion of the parent
>> Image</desc> </subImage> </image>
>> 
>> The UA can then choose to switch to the subIamge if the zoomed
>> region would be better served by it.  This would give us
>> Level-of-detail functionality without needing scripting.

DJ> Nice suggestion. Thomas, who originally proposed this feature, had
DJ> implemented something like this with nested SVG images (which
DJ> included nested SVG images, etc).

    Yes, this is one of the issues the element is intended to address
- LOD and 'tiling'.  I put tiling in quotes as a complete solution to
tiling would require a 'tile grid' object as well so the user agent
can determine an appropriate pixel based coordinate system to compose
the tiles, where the tile boundaries lie on pixel boundaries so you
don't get visible seams (think patterns in the Adobe viewer).

>> What would happen in situations where the zoom overlaps regions
>> which don't have a subImage is something else I don't know about,
>> rendering both images would be possible, or you could just use the
>> parent one.

DJ> I'd prefer it to show both, since I don't want a 1-pixel pan to
DJ> radically change the display.

    You should never show both, the child definition should always
'cover' the parent's area - that is why you generally need a group of
child elements to get the region of interest benefits (so one parent
image is replaced with four child images covering each quadrant, these
could then be replaced by four more images covering each subquadrant,
etc)
Received on Wednesday, 4 June 2003 08:17:28 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:25 GMT