# from bulia byak # on Monday 26 December 2005 06:27 am:

In Inkscape, 1px = 0.8pt. This is fixed and cannot be changed from SVG. Viewbox does not affect that.

This means that svg's from other authoring programs may get scaled up or down?

The only problem is that other SVG renderers can and do use other fixed values for this (e.g. in Batik it's 0.75 I think).

ouch!

It's a badly defined part of SVG standard.

Yes. It actually reads as if it is dependent on the graphics display, which means any concept of a "page" (e.g. US Letter) is doomed to get misinterpreted.

However, it's not a good SVG practice to mix abs units ans px, so this discrepancy rarely bites you.

Unless you want to convert to pdf, ps, etc :-) Guess I may have to put an option in svg2crs to allow the user to explicitly scale their document (hmm, though maybe it would be useful to be able to perform this on the hub, but I already have some trouble inverting the coordinate system :-| .)

Unfortunately the answer is no. But you give me an idea - maybe it's indeed worthwhile to add a comment to Inkscape SVG files stating our assumed px/pt ratio?

Is that something that can be done with the dtd and/or namespaces? If so, it might be worthwhile to get in touch with other svg library maintainers and agree on an ad-hoc standard for this.

Thanks, Eric

# from Jasper van de Gronde # on Friday 30 December 2005 02:02 am:

Doesn't the viewBox property along with a width and height on the svg element give you a way to specify this as precisely as you want? (assuming absolute units are only used in the width and height properties of the svg element)

Yeah. That would at least allow us to communicate a value for PT_PER_PX to other agents.

height="792.00000pt" width="612.00000pt" viewBox="0 0 765 990"

--Eric

On Fri, 2005-12-30 at 13:03 -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.

Correct. Rather than changing the "dpi", viewBox just applies a scaling transformation to the document.

-mental

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.