Gary Hawkins wrote: ---- Check out the Preferences Import/Export option "dpi" setting. You could set this to the value you use for your printing resolution and then export the image and print it (maybe the print function uses this value directly, though I don't know. Ideally, you want the dpi set to the dpi of your screen (whatever your screen resolution is, divided by #inches of your screen) for displaying things on your screen -- but printers usually use alot higher (like 300 dpi is common) resolution for printing. That's one of the biggest 'features' with SVG -- it's easily scalable to any size without loss of clarity! -linda

Gary Hawkins wrote: You do realize you can convert SVG to PNG from the command line? Type `inkscape --help` and it will list a large number of options, especially --export-width and --export-height. -- Just my 0.00000002 million dollars worth, Shawn Programming is as much about organization and communication as it is about coding. I like Perl; it's the only language where you can bless your thingy.

Jon Cruz wrote: ---- A follow-up to youe follow-up. An errata was posted in 2001. http://www.w3.org/Style/css2-updates/REC-CSS2-19980512-errata.html Section 4.3.2 Lengths [2001-08-28] The suggested reference pixel is based on a 96 dpi device, not 90 dpi. The visual angle is thus about 0.0213 degrees instead of 0.0227, and a pixel at arm's length is about 0.26 mm instead of 0.28 -- I really had never heard of the 90dpi number, but CSS was just a TLA-buzzword to me before 2001. Maybe inkscape could update it's references? (Thanks to LucaDC who found the errata).

Jon Cruz wrote: --- You could, but then you'd be violating the new HTML5/CSS3 spec, which defines pixels as having a device independent value of 96 dpi in order to get around the the severe trauma pixel-addressing addicts have been inflicting upon hires screen users. Get a 144dpi display and watch large portions of the web be suddenly be 2/3rd's their intended size and much more difficult to read. Thus was born the idea of redefining pixels to have a fixed, device independent size so users wouldn't have their interfaces mucked up by web designers who couldn't use points, millimeters, centimeters, or inches. That's where the number 96 comes from -- it's not that it was a best guess, it's a redefinition of 'pixel' in CSS (and HTML5) to fix the size problem when moving to different devices. Content writers shouldn't be concerning themselves with the hardware addressing resolution of the output device. They should be disassociated, and people can then tell the unit's display manager to 'scale' the output (usually larger, but I don't see why smaller shouldn't be legal -- maybe it isn't -- MS doesn't support DPI's under 96 in Win7 (my Viewsonic is 94DPI) so I now suffer horribly on a display where everything is about 2-3% larger than it should be! The horror of it! (I did have my XP value set to 94DPI)). So I don't know if smaller values are legal or not just supported by MS, but if you really want things to be larger, you'll be able to do it with a device independant scaling factor. pixels will become a 'defined' value in CSS/HTML. So inkscape might want to spare themselves the work of trying to detect a hardware value that won't be supported. ? Is that good news or just freaky? :-)

Jon Cruz wrote: --- Dots != pixels. I almost mentioned that. But pixels are the CSS entity, not dots. Dots, as you quite rightly say would represent the physical attributes of the display device. --- Not relevant when you say that something is 1" high and it better be 1" high when measured at 96 pixels (not 96 dots -- but dots aren't referenced in the spec). --- True. I fight for people (including in 'firefox/Tbird' that still sets default font sizes in old hardware based pixels (they are moving to CSS3, just haven't fully gotten there yet). When they get in canvas support it'll have to be there. --- Hopefully they aren't measuring furniture in pixels. That's the hair-splitting we are engaged in. We are pretty much on the same page, I'm just talking about the use of the word / unit, 'pixel', as it refers to a screen technology where HTML and CSS will be dominant. But dpi, lpi, you are getting into real world measurements not made up units. I didn't like the idea of them redefining the word 'pixels', but it's a done deal years ago. It's bigger than me and I got more important things to worry about. I just try to relay my information from disparate sources to the appropriate people. I'm spread far too thin to follow through on most things. What I was jazzed about in the HTML5 spec were the examples that showed <img src=xxx.svg> as a standard image format. Looked so much simpler than all the embedded stuff needed now... :-) -linda

Jon Cruz wrote: Of course, if you are using Inkscape to author SVG then your only choice is to specifiy font sizes in Inkscape Pixels [1], even if the UI gives no indication of the unit being used. I think this is still one of my favorite bugs. [1] https://bugs.launchpad.net/inkscape/+bug/168164 Cheers, Jed -- View this message in context: http://old.nabble.com/printing-from-inkscape-not-the-expected-size-tp2721... Sent from the Inkscape - User mailing list archive at Nabble.com.

Linda A. Walsh wrote: I find it strange that anyone is concerned about SVG size. After all, it's scalable. It's size is arbitrary. It has no "native" size. All that's important is maintaining the proportions. And you can use the command-line interface to scale the image to any size. See `inkscape --help`. Perhaps what is needed is the same ability in the GUI. -- Just my 0.00000002 million dollars worth, Shawn Programming is as much about organization and communication as it is about coding. I like Perl; it's the only language where you can bless your thingy.