On Fri, Dec 30, 2005 at 01:03:59PM -0400, bulia byak wrote:
On 12/30/05, Eric Wilhelm <scratchcomputing@...400...> wrote:
height="792.00000pt" width="612.00000pt" viewBox="0 0 765 990"
I don't remember details (Mental, can you remind us?), but we did some experiements and found that this does not work. ViewBox stretches all units in the same way, so px/pt ratio is not affected. At least that was the case in Batik and Adobe SVG viewer that we tested.
The px/pt ratio is unaffected in the document (at least for children of the <svg> element) in the sense that
<svg width="612pt" height="792pt" viewBox="0 0 612 792"> <rect width="10" height="10pt" /> </svg>
typically won't give a square: somewhat surprisingly, the width will be 10pt as a result of the viewBox (if the viewer honours the width & height requests) whereas they height typically won't be 10pt!: the width/height aspect ratio will be the same as for
<svg> <rect width="10" height="10pt" /> </svg>
because the px/pt ratio within the document (at least for children of the <svg> element) is unaffected by the viewBox attribute.
However, I wouldn't say that "this does not work": it should indeed give predictable real-world sizes for all objects that are dimensioned in user units: e.g. the rect should predictably have a width of 10pt in that first example SVG document I gave.
(I write "should" because SVG user agents are free to ignore the request that the document be scaled to 612pt wide & 792pt high. Of course one would expect conversion from SVG to postscript/pdf to honour the request despite this not being strictly required for SVG conformance.)
So I think that the "paper-size" documents in share/templates should be changed to use a viewBox, and width/height be specified in mm or in or pt. Possibly the web_banner, desktop, and icon documents should also use a viewBox (and sized in px as at present), depending on whether we want these documents to scale by default when displayed in a different size.
(Any opinions on whether they should be scaled, and if so whether they should be scaled maintaining their aspect ratio, and if so whether to truncate or pad with whitespace and whether to align centred or left/top: i.e. what value to use for preserveAspectRatio http://www.w3.org/TR/SVG11/coords.html#PreserveAspectRatioAttribute if we use a viewBox for these px-sized document templates ?)
More controversially, I wonder whether the default document should not be A4 or any other "paper" size, but should be sized in px and not have a viewBox attribute. This is motivated partly by the fact that not all paper-using people use A4 as their document size: so A4 may well be a minority size; whereas document size when not using a viewBox is of less importance than when using a viewBox (e.g. because viewBox entails scaling); and we might choose to change the specified document size dynamically to match the drawing size when not using a viewBox.
Another controversial matter is how to convey that mm etc. are only approximate if we aren't using a real-world-sized <svg> element with viewBox, and that px is only approximate if we are using one (a real-world-sized <svg> element with viewBox). And what to do if the <svg> element's width is specified as a real-world unit but not its height, or vice versa?
A first step is to make the default units be `mm' for A4 page size, `in' for US Letter, and `px' for icon/desktop/web_banner. (E.g. make the default units be the same as unit of the page size, if width & height use the same unit, and if width&height are indeed specified and use a real-world or px unit rather than e.g. percentage.)
Other possible steps (more obtrusive and hence more questionable) would be
- to add a label to the document preferences warning which units are merely approximage;
- for units menus to explicitly say "est. mm" or "est. px" as the case may be. (Immediate reaction is that this could be annoying, but remember it should only be visible when one tries to use a unit that doesn't make sense, so might still be OK.)
pjrm.