printing from inkscape not the expected size
Hi I'm posting this for a friend so if you need more info I'll have to ask her <grin>
My friend has a canon IP5200 printer and when she prints from inkscape the image comes out smaller.
For e.g. trying to print and cut a 14 x 28 oblong. All measures up in inkscape, paper set to A4 both in inkscape and the printer, convert to png, print and hey ho.... my oblong has printed out as a 13 1/2 by 27 oblong.
Does anyone have any ideas how to get the canon to print at 100%, she does not seem to have a 100% setting or it is not printing at this, I'm not sure which.
she is having problems printing direct from inkscape so is exporting to png and printing that as I understand it.
Thanks for any help
Gaz(UK)
Gary Hawkins wrote:
Hi I'm posting this for a friend so if you need more info I'll have to ask her <grin>
My friend has a canon IP5200 printer and when she prints from inkscape the image comes out smaller.
---- 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
Thanks Linda, I'll pass the info on and see what she gets.
so far only way she has had a little success is by exporting as png but it's still not right
Gaz
2010/1/20 Linda A. Walsh <inkscape@...2679...>
Gary Hawkins wrote:
Hi I'm posting this for a friend so if you need more info I'll have to ask her <grin>
My friend has a canon IP5200 printer and when she prints from inkscape the image comes out smaller.
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 (whateveryour 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 easilyscalable to any size without loss of clarity!
-linda
Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev _______________________________________________ Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
Gary Hawkins wrote:
Thanks Linda, I'll pass the info on and see what she gets.
so far only way she has had a little success is by exporting as png but it's still not right
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.
On Jan 21, 2010, at 10:12 AM, Linda A. Walsh wrote:
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.
As just a minor FYI here, I did a follow up on Inkscape's hardcoded DPI.
SVG 1.1 is based on CSS2, not CSS3, and it mentions a 90 DPI reference pixel.
Of course, Inkscape needs to have all the hardcoding removed, and to query the running *monitors* (note the plural) for their physical size.
Jon Cruz wrote:
On Jan 21, 2010, at 10:12 AM, Linda A. Walsh wrote:
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.
As just a minor FYI here, I did a follow up on Inkscape's hardcoded DPI.
SVG 1.1 is based on CSS2, not CSS3, and it mentions a 90 DPI reference pixel.
Of course, Inkscape needs to have all the hardcoding removed, and to query the running *monitors* (note the plural) for their physical size.
---- 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).
On Jan 21, 2010, at 11:29 PM, Linda A. Walsh wrote:
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
ahh... that might be interesting, although the proper fix is to get Inkscape properly dynamic about DPI and remove all hardcodings.
I think the 90 DPI hardcodings came from SVG 1.0 timeframe... but only has recently been removed enough to make full dynamic possible.
Jon Cruz wrote:
On Jan 21, 2010, at 11:29 PM, Linda A. Walsh wrote:
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
ahh... that might be interesting, although the proper fix is to get Inkscape properly dynamic about DPI and remove all hardcodings.
--- 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? :-)
On Jan 22, 2010, at 12:26 AM, Linda A. Walsh wrote:
Jon Cruz wrote:
On Jan 21, 2010, at 11:29 PM, Linda A. Walsh wrote:
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
ahh... that might be interesting, although the proper fix is to get Inkscape properly dynamic about DPI and remove all hardcodings.
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.
But that would only be CSS3 which in turn is not yet involved in SVG. Even SVG 1.2 Tiny still references CSS2.
To go along with that we would need to get CSS media selectors and many other fun things we *really* want to have. However, we could not call that SVG 1.x
Additionally, SVG allows for the user agent (that's us) to decide on what DPI to use. Specify an inch and you might get 72 dots or you might get 96, but you as a designer should not care.
Additionally, what is legible text to one person is often *not* legible to another, even when the monitor DPI remains the same.
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.
Well... that depends. If one defines a font in point sizes, then as the density of the display increased the number of pixels used in letters would correspondingly increase.
And, yes, I have used 144dpi systems and have done many tests, especially with Inkscape and SVG in mind.
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? :-)
Freaky. However, until SVG 2.0 we might be a bit stuck on things.
But... remember that we are dealing with the SVG world here, and not the HTML world. The pragmatic solution is to involve view boxes and such to pin things down to specific user needs. HTML is not often sent out to a laser cutter for creating home furniture, but SVG is :-)
Jon Cruz wrote:
To go along with that we would need to get CSS media selectors and many other fun things we *really* want to have. However, we could not call that SVG 1.x
Additionally, SVG allows for the user agent (that's us) to decide on what DPI to use. Specify an inch and you might get 72 dots or you might get 96, but you as a designer should not care.
--- 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.
Additionally, what is legible text to one person is often *not* legible to another, even when the monitor DPI remains the same.
--- 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).
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.
Well... that depends. If one defines a font in point sizes, then as the density of the display increased the number of pixels used in letters would correspondingly increase.
--- 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.
Freaky. However, until SVG 2.0 we might be a bit stuck on things.
But... remember that we are dealing with the SVG world here, and not the HTML world. The pragmatic solution is to involve view boxes and such to pin things down to specific user needs. HTML is not often sent out to a laser cutter for creating home furniture, but SVG is :-)
--- 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
Linda A. Walsh wrote:
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.
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.
Jon Cruz wrote:
Well... that depends. If one defines a font in point sizes, then as the density of the display increased the number of pixels used in letters would correspondingly increase.
Fonts have a size, usually stated in points. This size is fixed; you cannot change it. Fonts of similar glyphs but of different sizes compose a typeface. Fonts of different sizes but of the same typeface have differently proportioned glyphs. Larger fonts have narrower strokes. SVG is not good for typography since it can be scaled to any dimension and type cannot.
Jon Cruz wrote:
On Jan 22, 2010, at 12:26 AM, Linda A. Walsh wrote:
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.
Well... that depends. If one defines a font in point sizes, then as the density of the display increased the number of pixels used in letters would correspondingly increase.
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
On Jan 22, 2010, at 5:18 AM, Jed Frechette 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.
Of course, we could always change the resoultion to be 72.27 DPI instead of 90. Then your type problems would be solved.
Oh, or if you don't want the precise type values, we could go with just 72 instead. :-)
But, yes, the UI at least should present things in pt... however at the same time the program also needs to use a viewbox properly so physical size can be locked down.
participants (5)
-
Gary Hawkins -
Jed Frechette -
Jon Cruz -
Linda A. Walsh -
Shawn H Corey