SVG Paper Size

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