January 2011 - Inkscape Users

Re: [Inkscape-user] Inkscape Accuracy
by Susan Spencer 14 Jan '11

14 Jan '11

On Fri, Jan 14, 2011 at 6:17 AM, Susan Spencer <susan.spencer@...155...>wrote: > crjw and John Culleton, > > Your examples and information were fantastic and useful. > > My biggest reason for using printer's points is to sidestep > the differences between Gimp's ppi/ppcm v. Inkscape's ppi/ppcm. > I use Gimp to clean up scanned images before working in Inkscape. > Many older patterns are exactly 1/4th scale, so the Gimp to > Inkscape workflow results in a bit of extra work. > Gimp uses 72ppi, Inkscape uses 90ppi for the time being. > > As John pointed out, the value of 72.72 for a printer's point > is outdated. So I did some research: > > Printer's points, inches, cm's, mm's, etc. are reconverted > back to pixels by each rendering platform according to its > own ppi/ppcm definition. So yes, they're always > accurate. > > Also, Inkscape defaults numeric precision to 8, > and will pad numbers with 0's to match the precision > setting. > > Wikipedia's page <http://en.wikipedia.org/wiki/Point_%28typography%29>explains that 72.72 was set in 1886, > and was changed in 1959. > "...The desktop publishing<http://en.wikipedia.org/wiki/Desktop_Publishing>point (DTP point) is defined as 1/72 of the > Anglo-Saxon compromise inch <http://en.wikipedia.org/wiki/Inch> of 1959 > (25.4 mm)..." > > Still, Donald Knuth <http://en.wikipedia.org/wiki/Donald_Knuth> used 72.72 > in Tex in the 1970's. > The inventors of Adobe <http://en.wikipedia.org/wiki/Adobe_Systems> > PostScript <http://en.wikipedia.org/wiki/PostScript> used 72. > This discussion may seem overkill to some, but it > does make a difference, and thanks to everyone for > pointing out the precision issues. > > - Susan > > > On Fri, Jan 14, 2011 at 3:47 AM, < > inkscape-user-request(a)lists.sourceforge.net> wrote: > >> Date: Fri, 14 Jan 2011 05:50:38 GMT >> From: "crjw" <crjw@...2789...> >> Subject: Re: [Inkscape-user] Inkscape Accurancy >> > > >> <snip> >> > > >> Consider the following: >> -a road map >> -a circuit board design >> -a floor plan >> -a sewing pattern >> All of these drawings accurately reflect some physical entity. >> Usually measurements or coordinates of the physical entity are known and >> can be expressed in standard units such as meters, miles, inches, mils, >> etc. >> >> My only reason for writing this post is to point out that it is possible >> to enter coordinates into an SVG drawing in their native values... >> regardless of how big or how mall the unit is. >> > > >> <snip> > > > >> -crjw >> > >

1 0

Re: [Inkscape-user] Inkscape-user Digest, Vol 56, Issue 11
by Susan Spencer 14 Jan '11

14 Jan '11

crjw and John Culleton, Your examples and information were fantastic and useful. My biggest reason for using printer's points is to sidestep the differences between Gimp's ppi/ppcm v. Inkscape's ppi/ppcm. I use Gimp to clean up scanned images before working in Inkscape. Many older patterns are exactly 1/4th scale, so the Gimp to Inkscape workflow results in a bit of extra work. Gimp uses 72ppi, Inkscape uses 90ppi for the time being. As John pointed out, the value of 72.72 for a printer's point is outdated. So I did some research: Printer's points, inches, cm's, mm's, etc. are reconverted back to pixels by each rendering platform according to its own ppi/ppcm definition. So yes, they're always accurate. Also, Inkscape defaults numeric precision to 8, and will pad numbers with 0's to match the precision setting. Wikipedia's page <http://en.wikipedia.org/wiki/Point_%28typography%29>explains that 72.72 was set in 1886, and was changed in 1959. "...The desktop publishing <http://en.wikipedia.org/wiki/Desktop_Publishing>point (DTP point) is defined as 1/72 of the Anglo-Saxon compromise inch <http://en.wikipedia.org/wiki/Inch> of 1959 (25.4 mm)..." Still, Donald Knuth <http://en.wikipedia.org/wiki/Donald_Knuth> used 72.72 in Tex in the 1970's. The inventors of Adobe <http://en.wikipedia.org/wiki/Adobe_Systems> PostScript <http://en.wikipedia.org/wiki/PostScript> used 72. This discussion may seem overkill to some, but it does make a difference, and thanks to everyone for pointing out the precision issues. - Susan On Fri, Jan 14, 2011 at 3:47 AM, < inkscape-user-request(a)lists.sourceforge.net> wrote: > Date: Fri, 14 Jan 2011 05:50:38 GMT > From: "crjw" <crjw@...2789...> > Subject: Re: [Inkscape-user] Inkscape Accurancy > > <snip> > > Consider the following: > -a road map > -a circuit board design > -a floor plan > -a sewing pattern > All of these drawings accurately reflect some physical entity. > Usually measurements or coordinates of the physical entity are known and > can be expressed in standard units such as meters, miles, inches, mils, > etc. > > My only reason for writing this post is to point out that it is possible > to enter coordinates into an SVG drawing in their native values... > regardless of how big or how mall the unit is. > > <snip> > -crjw >

1 0

inkscape autosave directory
by Adam Ambrus 14 Jan '11

14 Jan '11

hello, i was just wondering about the autosave path's options. would it be possible to add a variable to the autosave path, so all of the autosaved files would be put into one directory with the same name as opened file? for example, if i would be working on /random/directories/someFile.svg, i would want all of the autosaves in /random/directories/someFile_autosave thanks for any answers, ~Adam

1 0

Re: [Inkscape-user] Inkscape Accurancy
by crjw 14 Jan '11

14 Jan '11

Consider the following: -a road map -a circuit board design -a floor plan -a sewing pattern All of these drawings accurately reflect some physical entity. Usually measurements or coordinates of the physical entity are known and can be expressed in standard units such as meters, miles, inches, mils, etc. My only reason for writing this post is to point out that it is possible to enter coordinates into an SVG drawing in their native values... regardless of how big or how mall the unit is. e.g. a map can be created where path coordinates are specified in miles. -in this case: 1user_unit=1mile. e.g. a sewing pattern can be created where path coordinates are specified in cm. -in this case: 1user_unit=1cm. If necessary the drawing can be scaled with a transform, a viewBox, or a combination of a transform and a viewBox. As pointed out by others: when using a viewBox the whole 90DPI issue goes away! Below are a couple of examples of how a sewing pattern can be done with SVG using a "user unit" of 1cm. Don't try sewing the pattern at home! Both drawings are identical when printed (except for color). Both drawings will print on 8.5"x11" (letter size) paper. Line thickness is exactly 0.05cm (half a mm). The drawings both consist of: 2 squares exactly 8cm x 8cm 2 circles with radii of exactly 4cm For variety I used a "<rect>" element for one square and a "<path>" element for the other. (No reason for this other than to show there are different ways of drawing objects). And likewise, I used a "<circle>" element for one circle and a "<path>" element for the other. Note that the coordinates and line lengths are entered in units of cm and thus should be easy to read. # drawing #1 # this drawing makes use of a transform and a viewBox. <?xml version="1.0" standalone="no"?> <svg version="1.1" width="8.5in" height="11in" viewBox="0 0 8.5 11" xmlns="http://www.w3.org/2000/svg" xmlns:svg="http://www.w3.org/2000/svg"> <g style="fill:none;stroke:red;stroke-width:.05"> <g transform="scale(.39370079)"> <rect x="2" y="2" width="8" height="8"/> <circle r="4" cx="14" cy="6"/> <path d="m 2,12 h8 v8 h-8 z"/> <path d="m 14,12 a 4,4 0 1 1 0,8 4,4 0 1 1 0,-8 z"/> </g> </g> </svg> # drawing #2 # this drawing uses a viewBox but no transform to achieve the same effect as drawing #1. # the parameters for the rect, circle, and path elements are identical to those in drawing #1. <?xml version="1.0" standalone="no"?> <svg version="1.1" width="8.5in" height="11in" viewBox="0 0 21.59 27.94" xmlns="http://www.w3.org/2000/svg" xmlns:svg="http://www.w3.org/2000/svg"> <g style="fill:none;stroke:green;stroke-width:.05"> <rect x="2" y="2" width="8" height="8"/> <circle r="4" cx="14" cy="6"/> <path d="m 2,12 h8 v8 h-8 z"/> <path d="m 14,12 a 4,4 0 1 1 0,8 4,4 0 1 1 0,-8 z"/> </g> </svg> I have have attached copies of drawing #1 and #2 for those of you that are too lazy to copy and paste (that includes me). There are also two attached bonus drawings that show how the height and viewBox parameters can be adjusted to print the drawing at proper scale on two half size pieces of paper. Admittedly this would be more useful for drawings that don't already fit on 8.5"x11" paper! All drawings will load into Inkscape... and they can all be converted to PDF. But it can be a little awkward using Inkscape to modify a drawing with a viewBox. -crjw

1 0

fantastic lxml
by Alessandro Antonello 14 Jan '11

14 Jan '11

Hi, all. Last week I tried to use, for the first time, the perspective extension. A message was complaining about the *num* Python package. I use a MacBook so, to install the num package I use MacPort. I use MacPort a lot and never had a problem before. After installing the num package the extension complained about the lxml package for libxml2 library. So I installed it using, again, MacPort. Now I cannot use any extension. Every single extension complains about the *lxml* package, but it is installed. I am aware about the bug of Inkscape in this matter. What I didn't know is that it will affect every extensions. Before that I was able to use others extensions like the *lorem ipsum* text generation. Now I am not. Someone had solved this issue? Please help. Alessandro Antonello

2 2

[Linux] Inkscape 0.48 ruler graphic artifacts
by NoOp 13 Jan '11

13 Jan '11

I currently am only experiencing this on 0.48 Ubuntu 10.10 64bit: Whenever I move the mouse cursor across the horizontal or vertical rulers, the rulers fill with the ruler point (triangle) artifacts. I've posted a screenshot here: http://img257.imageshack.us/img257/3473/screenshotinkscape1.png Same machine (laptop) running 0.48 in WinXP (at the same time) on a VMWare virtual machine does not experience the same. Screenshot here: http://img526.imageshack.us/img526/8378/inkscape2winxp.png Nor do I experience this on my Ubuntu 10.4 32bit machine with 0.48. Can anyone verify that the same is occurring on their 10.10 64bit Inkscape 0.48, or please point me to an already filed bug? If a bug is not filed, I'll be happy to do so if I can verify that someone else has the same issue. Thanks. Gary Lee

5 6

Re: [Inkscape-user] Inkscape Accurancy (was: Doublesided Print Alignment)
by crjw 13 Jan '11

13 Jan '11

> >I guess for print resolutions (300 dpi and above) the accuracy when working with pixels is below 1/10 of a millimetre so working in mm should not be a pr oblem. Or am I mistaken again? > >Andi SVG drawing accuracy is only limited by the number of significant digits you choose to use. It is not limited by the choice of units! Inkscape has a setting to control the number of significant digits (I think the default is eight). Look under "Inkscape Preferences --> SVG output". SVG syntax allows lengths to be specified with one of the following units: px, em, ex, pt, pc, cm, mm, and in. The SVG spec defines 1in=90px. Thus one thousandth of an inch can be spcified as 0.09, .09px, 0.001in, or 0.0254000mm. You may find when you specify units other than pixels that Inkscape will silently convert to pixels; this is a good thing because not all programs honor the 1in=90px standard. Firefox will assume 1in=96px. The following drawing yeilds three equal sized squres in Inkscape but in Firefox the first square is smaller. ########################################### <?xml version="1.0" standalone="no"?> <svg version="1.1" width="8.5in" height="11in" xmlns="http://www.w3.org/2000/svg" xmlns:svg="http://www.w3.org/2000/svg"> <g style="fill:none;stroke:green;stroke-width:5px"> <rect x="1in" y="1in" width="90" height="90"/> <rect x="1in" y="2.1in" width="1in" height="1in"/> <rect x="1in" y="3.2in" width="25.4mm" height="25.4mm"/> </g> </svg> ########################################### Note: SVG syntax does not allow "<path>" elements to contain units. i.e. path elements can use pixels only. -crjw

8 27

Re: [Inkscape-user] Inkscape Accuracy
by Susan Spencer 12 Jan '11

12 Jan '11

Here is how I use Inkscape to achieve precise measurements. The following conversions are global definitions at the top of my Python scripts: *# measurement constants in_to_px = ( 90 / 1 ) #convert inches to pixels - 90px/in cm_to_in = ( 1 / 2.5 ) #convert centimeters to inches - 1in/2.5cm cm_to_px = ( 90 / 2.5 ) #convert centimeters to pixels in_to_pt = ( 72.72 / 1 ) #convert inches to printer's points - 72.72pt = 1in cm_to_pt = ( 72.72 / 2.5 ) #convert centimeters to printer's points border = ( 3 * in_to_pt) # 3" document borders * The client measurement data from the Inkscape extension is converted to printer's points. ('self.options' is how the Python script understands the input fields from the .inx extension file) * # if customer's data is in centimeters ** if ( self.options.measureunit == 'cm'): conversion = cm_to_pt else: conversion = in_to_pt height = self.options.height * conversion ** chest = self.options.chest * conversion chest_length = self.options.chest_length * conversion waist = self.options.waist * conversion back_waist_length = self.options.back_waist_length * conversion back_jacket_length = self.options.back_jacket_length * conversion back_shoulder_width = self.options.back_shoulder_width * conversion back_shoulder_length = self.options.back_shoulder_length * conversion back_underarm_width = self.options.back_underarm_width * conversion back_underarm_length = self.options.back_underarm_length * conversion back_waist_to_hip_length = self.options.back_waist_to_hip_length * conversion nape_to_vneck = self.options.nape_to_vneck * conversion sleeve_length = self.options.sleeve_length * conversion neck_width = (chest/16) + (2*cm_to_pt) ** ****# **19th century patterns are very strange...* At the end of the script, the document is resized to the drawing, adding borders. The current script expects a maximum of 36" wide paper. It's possible to print to 8.5 x 11 letter paper and tape it together. Inkscape displays a small part of the lower left document corner because this is a man-sized coat, but manual zoom is done with 'view/zoom/page' - no problem. Save to .pdf regardless of zoom level, then send to the 36" wide printer. - Susan * *

3 2

Unbold text.
by John Culleton 12 Jan '11

12 Jan '11

INkscape 0.48 I have a string of ocrb10 text over some bar code. I got everything right except it is in bold. I want to get it in normal. I tried selecting the text string (little arrows all around) and using shift control T. I get the text window but "apply" is grayed out. I can put in italic and then in normal . But I still get bold. -- John Culleton Create Book Covers with Scribus: http://www.booklocker.com/p/books/4055.html Typesetting and indexing http://wexfordpress.com book sales http://wexfordpress.net Free barcode: http://www.tux.org/~milgram/bookland/

1 0

ai to png -> error in the blend mode
by Benoit DECHERF 11 Jan '11

11 Jan '11

Hi, I'm trying to automate the transformation of adobe illustrator files to png. I have problems with some object that have a blending mode to multiply. When importing in inkscape, these objects have a blend mode to normal. I can send you an exemple of an ai file that show this problem if you need. The blending mode is supported correctly (If I change it manually, it works). I can"t see this bug in the database. I use inkscape 0.48 Thanks, Benoit

1 0