W3C home > Mailing lists > Public > www-svg@w3.org > April 2009

Re: how should 'top' width/height larger than screen be handled?

From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
Date: Tue, 21 Apr 2009 18:15:58 +0100
To: Ruud Steltenpool <svg@steltenpower.com>, www-svg@w3.org
Message-Id: <200904211915.58813.Dr.O.Hoffmann@gmx.de>
Ruud Steltenpool:
> >> Say i have <svg width="10in" height="10in" ......... </svg> ,
> >> what does the spec say about how to put this on screen?
> >
> > I think, some viewers provide scrollbars and a few rescale it to
> > the available viewport, if it is too large.
> Opera seems to rescale (though this might be the 'dpi wrong' matter, i
> didn't test) until only a vertical screenbar is needed.

With px Opera provides scrollbars as the Geckos do (they have sometimes
problems with other units like em or ex, if the SVG is embedded as an
object or directly within XHTML).
Batik/Squiggle rescales. The adobe-plugin has indeed the problem, that
parts of the SVG are not directly accessible, if it is too large - the user
has to rescale manually, if this is allowed by the author (zoomAndPan).

For inches or (milli)meters what a viewer can do is typically only a
guess, if there is no information about the physical size of the screen
is available - and this guess is typically wrong, at least for most of
resolutions and scrrens I use ;o)
Therefore I typically use either px or percentages for the width and
height of the root-svg element ;o)

A precise meaning for inches or (milli)meters is more useful for
printing, because the printer has to know somehow, how large
the paper is and people take more care, that the printer really
knows this. And it is obviously useful too, if you want to create
a map of your office or town on a scale of 1:1 ...

> > Typically the first solution
> > seems to be more useful - at least for my applications...
> I agree. Also think of augmented/enhanced reality applications for mobiles.
> >> Say i want to show a circular 'painting' at the same physical scale, on
> >> every screen size. It should be centered on screen.
> >> For example: On a huge TV it would show completely with leftover space
> >> surrounding it, on a desktop monitor it would just fit, on a laptop
> >> screen it would have cut-offs top and bottom, on a netbook it would have
> >> cut-offs on left,right,top and bottom, on a mobile you'd see only a
> >> rectangular middle part.
> >>
> >> What ways can you do that?
> >
> > You can use
> > preserveAspectRatio="xMidYMid slice" (in SVG 1.1 full, not in tiny)
> > to ensure, that the viewport is completely filled with parts of the
> > viewBox and that it is centered.
> I did that. But the vertical scrollbar was not in the middle of the
> scroll range, to the least.

Oh - I forgot to note, that you have to remove width and height,
or note 100% for both of them to cut off something symmetrically -
or without 'slice' (what means the default 'meet') to center it without 
cut off.
preserveAspectRatio is for the scaling behaviour between viewBox 
and width and height of the root-svg, not directly the available part 
of the viewport, if other units are used ;o) To get the relation between 
the viewBox and the viewport, the percentage notation is required - 
and this helps too to adjust the scaling to the used device.

The main advantage of the approach with viewBox, 
preserveAspectRatio and additionally width and height is, that
it is pretty simple to adjust the size of the output just by
changing width and height to meet the capabilities of the
output device, whatever they are. The 100% are ok for
many situations, for the few others a skilful user will have
no problem to adjust this for example for printing, if needed.
And this change does not require any understanding of the
other content inside the SVG document.
Received on Tuesday, 21 April 2009 17:18:37 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:17 UTC