Re: SVG Paper Size

Andrew,

Are you currently happy with the output when printing SVG and setting 
the width and height in units such as cm, mm? If you want consistent 
printable output you should certainly use cm/mm for width/height not 
percentage units.

Is your problem that when you view these SVG's in a browser/viewer they 
do not fill the screen well, for instance, if you specify A3 paper size 
you will not see much of the image? Is the behaviour you want to see 
when viewing the SVG on a screen is as though width and height are set 
to 100%?
I think your problem could be solved in the viewer by allowing a "best 
fit" or "fit to page" zoom setting that sets the zoom level such that 
the whole viewport is viewable on the screen. This shouldn't be the 
default behaviour of an SVG viewer, but it could do this functionality. 
In fact in the view menu of Inkscape, option 5 Page, gives this behaviour.

I'm not sure your problem requires a change in the specification. 
Perhaps I do not completely understand your requirements.

Thanks,
Craig


Andrew Main wrote:

> PROPOSAL
>
> Include a hint as to the ideal size of paper, as an addition to the 
> viewPort specification, in order to assist the production of SVG drawings
>
> Eg <svg width=”100%” height=”100%” paper-width=”297mm” 
> paper-height=”210mm”
>
> (syntactic sugar version <svg width=”100%” height=”100%” paper-size=”A4” )
>
> RATIONALE
>
> Like many people, I print SVG via a browser, showing the SVG either 
> native, or embedded as an object in XHTML. Because of that, I pretty 
> much always use the “100%” width and height, so that the graphic fills 
> the object space, or the browser print-out.
>
> If one uses, in order to identify that A4 paper is preferred for the 
> drawing, <svg width=”297mm” height=”210mm”, then it displays badly on 
> a browser monitor.
>
> At the moment, the user agent is without a paper size hint when it prints.
>
> Hence my suggestion that a hint is added that indicates the intended 
> paper size. Then if the user views in via browser, or on paper, the 
> user-agent can give the user more nearly what they want.
>
> This is a proposal for SVG, but it obviously relates to SVG Print as 
> well, and a relevant reference into SVG Print is section 5.1.2 “Using 
> percentage of viewport sizing”, which states this: if the SVG image 
> size is specified as a percentage value, it is considered to be a 
> percentage of the available viewport. In such cases, the SVG Print 
> device chooses the default paper size. (By default paper size, they 
> mean the printer’s default paper size, which may not be what is wanted 
> at all).
>
> _______________________
>
> SUPPORTING ARGUMENT
>
> I have been encouraged to send this supporting argument, by a fellow 
> SVG correspondent to whom I sent it for initial ‘vetting’, and who 
> agrees that paper size is a problem currently with SVG.
>
> I use SVG for a general set of graphics tasks, but I have a great deal 
> of experience with computer graphics for Technical Drawings, and I use 
> Technical Drawings to illustrate the need for paper size to be 
> specifiable in SVG.
>
>    1. It is a truism of Technical Drawings that drawing paper size is
>       of primary importance. When one draws any thing, the way one
>       sets it out relates strongly to paper dimensions. An A2 drawing
>       is simply not a scaled version of an A3 drawing; the same goes
>       for any size of paper. That fact can not be stressed enough.
>    2. Character height, for example, does not scale with paper size:
>       it stays the same size, and is independent of paper size:
>       draughts-people in my experience (I started as a graphics
>       programmer in 1968, by the way) typically use 3mm high letters
>       as their default, with 5mm for headings and important notes
>       (with maybe even bigger characters for major titling). And they
>       keep their characters the same height whatever size of paper
>       they use. An important point here is that character size is
>       determined by the function of the text. If we in the IT
>       community force draughts-people to use character sizes that they
>       regard as ‘wrong’ we are forcing users to bend to our inability
>       to cope with their needs – and we know that never works in the
>       long run. If character height stays the same on different paper
>       sizes, it therefore does not scale with paper size.
>    3. Given that character height relates very strongly to white-space
>       around letters, it is a fact (again) that **the positions of**
>       drawing annotations do not simply scale with paper size. That
>       is, it is not just the text that does not scale, it is where it
>       is put on the drawing, too. So layout does not scale with paper
>       size.
>    4. Thus the whole layout of a drawing , **and** its internal
>       elements, do not scale with paper size. There is, then, no doubt
>       that all drawings have a size of paper that the originator
>       **intended** them to have. It would behove SVG, therefore, to
>       have a mechanism by which the originator can convey his/her
>       intention.
>
> I am reminded of Don Knuth’s comments back in the 70’s and 80’ about 
> computing pushing the world towards low-grade forms of printing (which 
> drove him to develop Tex and LaTex); it would be a great pity if SVG 
> came in for the same criticism 25 years later. I do not pretend that 
> all graphics is Technical Drawing, but unless SVG is intended to be 
> only a partial solution (with perhaps webCGM recommended as a 
> parallel) — and I would be very sorry if that is the intention — SVG 
> does need to allow such users to have this, small but important, facility.
>
> ______________
>
> I realize that it is very late in the cycle for this proposal to be 
> accepted, but I think that there is an important practical issue here, 
> and I hope it can be accepted for the future, even if it is too late 
> right now.
>
> Andrew Main
>

Received on Monday, 16 August 2004 23:35:57 UTC