Forum: Inkscape 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@tlinx.org>

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.


--
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.

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:
> 
> 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:
> 
---
  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? :-)

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.


--
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.

On Jan 22, 2010, at 12:26 AM, Linda A. Walsh 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.  
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:
> 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.


--
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:
> 
> 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

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-tp27218964p27260376.html
Sent from the Inkscape - User mailing list archive at Nabble.com.

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.
> 
> [1] https://bugs.launchpad.net/inkscape/+bug/168164

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.