- Inkscape Users - Inkscape Mailman

bug when importing ai
by Benoit DECHERF 17 Jan '11

17 Jan '11

Hi, When importing an .ai file with an object having a "blend mode" to multiply, the "blend mode" is lost. I can't find a bug on this. Is it a known issue ? Can I open a bug ? Benoit

2 1

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

15 Jan '11

Shawn, I think we all understand that the problem you're addressing is a serious one. Inkscape will render older images based on 90ppi at a smaller size when it changes its definition for pixels per unit. Since there had been discussion of absolute size in the thread, I thought that the conversions might be of interest to those who might have a project that requires absolute sizing, even though it is of no help to you. <snif> And thanks for the heads up about 2.54cm/inch. I've been using some sewing books which make recommendations of rounding to the 10th rather than 100th perhaps because they were using pencil & paper, and it worked well enough for them personally. This is ultimately garbage advice, so thanks for pointing that out. Question: Are there differences between Inkscape and other tools regarding pixels per inch? - Susan > Date: Wed, 12 Jan 2011 08:57:09 -0500 > From: Shawn H Corey <shawnhcorey@...155...> > Subject: Re: [Inkscape-user] Inkscape Accuracy > > Conversion is not the problem. The problem is that the number of pixels > per inch keeps changing. It's currently 90, schedule to change to 96, > and may change again. That means that old SVGs will become 7% smaller > when the new scale is implemented. And that's *all* the old ones since > Inkscape stores their measurements as pixels. > > BTW, it's 2.54 cm per inch. :) > > > -- > Just my 0.00000002 million dollars worth, > Shawn >

7 9

Call for SCALE 9x participation
by Jon Cruz 15 Jan '11

15 Jan '11

Hello all, Inkscape is setting up once again to exhibit at SCALE this year Feb 25-27. http://www.socallinuxexpo.org/scale9x/ We get a few passes to help man the booth, so if anyone might be able to travel to the conference to help us out, we can get you in. Just let me know off-list if you happen to be interested and able to attend. Thanks.

1 0

tablet software (MacOS only)
by unknown＠example.com 15 Jan '11

15 Jan '11

Hi Can someone using Inkscape on MacBook test this thing? We could then ask them to add Inkscape to the list of supported software http://www.tenonedesign.com/inklet.php Cedric

2 1

tablet emulation (MacOS only)
by unknown＠example.com 14 Jan '11

14 Jan '11

Hi Can someone using Inkscape on MacBook test this thing? We could then ask them to add Inkscape to the list of supported software http://www.tenonedesign.com/inklet.php Cedric

1 0

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