- Inkscape Devel - Inkscape Mailman

please test before committing
by Alexandre Prokoudine 22 Dec '09

22 Dec '09

make[4]: Entering directory `/home/avp/soft/build/graphics/vector/inkscape/inkscape-bzr20091221/share/extensions/Barcode' make[4]: *** No rule to make target `EAN5.py', needed by `all-am'. Stop. Please test your builds before you commit stuff :) Alexandre

2 1

'Datamatrix Encoder' and 'Wireframe Spheres'
by Alvin Penner 21 Dec '09

21 Dec '09

There are two interesting, new, extensions that have been proposed by inductiveload, namely: - 'Datamatrix Encoder', LP bug 465571 - 'Wireframe Spheres', LP bug 461964 Any objections if I commit them? -- View this message in context: http://old.nabble.com/%27Datamatrix-Encoder%27-and-%27Wireframe-Spheres%27-… Sent from the Inkscape - Dev mailing list archive at Nabble.com.

3 2

Mac OS X: Shift- mouse wheel (scroll right/left) doesnt work
by Wolf Drechsel 20 Dec '09

20 Dec '09

Hi everybody, up to now every inkscape version I tried on my Mac OS X 10.4.11 PPC had this annoyance: Scrolling up and down by mouse wheel works nice - zooming by ctrl - mouse wheel as well - but scrolling vertically (right-left) by shift - mouse wheel doesnt work. Is that a question of preferences - or does anybody know how to solve it? Greetings, Wolf

2 1

[Fwd: Re: Help with cubicsuperpath.parsePath and format formatPath in an extension]
by Aaron Spike 18 Dec '09

18 Dec '09

Oops. -------- Original Message -------- Subject: Re: [Inkscape-devel] Help with cubicsuperpath.parsePath and format formatPath in an extension Date: Thu, 17 Dec 2009 14:04:34 -0600 From: Aaron Spike <aaron@...749...> To: Rob Antonishen <rob.antonishen@...400...> References: <3644709b0912170707n29d9e56p7792f768996a5a9@...401...> <3644709b0912170834h47bf4ef4s1530569d71f3a227@...401...> Rob Antonishen wrote: > OK - it isn't just me. > > I tested the fractalize extension, the add nodes extension, and the > jitter nodes extension. > > In all cases, when starting with a closed path the result is an open > path with two additional nodes. > > So these are all broken. For example, jitter nodes on a 4 node closed > shape (use a large jitter) will create a shape with 6 nodes, with the > last 2 open (attached) You are correct. cubicsuperpath.py does not maintain the open/closed property of paths. I wouldn't say that it is broken because it has always been this way. It makes other changes to the path data too; it converts all segments to one or more cubic bezier segments. Its just not as good for round tripping path data as simplepath. > This is on windows in inkscape .47 release. This is not platform or version specific. So what can you do? Well, I haven't thought through this yet. But maybe you could make csp's inner lists a special list subclass that has a property for the closedness. Or maybe you could add an optional parameter to formatPath (or a new function, if that is better API) that closes the path if the first and last points are coincident. Aaron Spike

4 4

spray tool question
by Alexandre Prokoudine 18 Dec '09

18 Dec '09

Hi, How does "Spray objects in a single path" option actually work? Maybe the students could fill the ReleaseNotes048 page with description? :) Alexandre

5 6

Help with cubicsuperpath.parsePath and format formatPath in an extension
by Rob Antonishen 17 Dec '09

17 Dec '09

I'm trying to get the nodes using: p = cubicsuperpath.parsePath(node.get('d')) For a 4 node closed path I am getting 6 sets of coordinates (first handle, node, second handle) returned. Here is an example of a rectangle: [[ [[0.0, 0.0], [0.0, 0.0], [0.0, 0.0]], [[100.0, 0.0], [100.0, 0.0], [100.0, 0.0]], [[100.0, 200.0], [100.0, 200.0], [100.0, 200.0]], [[0.0, 200.0], [0.0, 200.0], [0.0, 200.0]], [[0.0, 0.0], [0.0, 0.0], [0.0, 0.0]], [[0.0, 0.0], [0.0, 0.0], [0.0, 0.0]] ]] Though experimentation, I have discovered these correspond to : [[ Node 1, as the start node ( first handle coords = node coords) Node 2 Node 3 Node 4 Node 1, as the end node (second handle coords = node coords) Node 1, as if it is inline, with the handles correct. ]] Now, if I take exactly the returned list p, and just try setting the path back: node.set('d',cubicsuperpath.formatPath(p)) I end up with a 6 node, open path. If I just try to feed it 4 coordinates, I end up with a 4 node, open path. How do I get the formatPath to create a closed path? -Rob A>

1 1

Re: [Inkscape-devel] spatial solutions
by Vangelis Katsikaros 16 Dec '09

16 Dec '09

> 2009/12/16 Krzysztof Kosiński: > >> Memory-and-disk indexing is not necessary for graphics applications. >> We are not going to process GIS-like quantities of data, and even then >> we can just use virtual memory. > > No, *you* are not going :) Please don't speak for others :) With SVG > quickly evolving as native file format for GIS on the Internet (just > check the list of talks at SVG Open for last two years) there is no > reason why Inkscape couldn't be authoring tool. I also think that SVG and GIS is not fully explored yet. >> By the way, the current R-tree implementation in 2Geom is somewhat >> ugly, for example it exposes naked pointers to nodes, so I'd be >> hesitant to use it right now. I'd be also hesitant to use it in Inkscape now. I wanted to have an r-tree working properly and then see what I can do. Some things I want to change, might cause change to the public part of the class. I was actually planning to resume work on the trees (my semester ends with the end of the year). I'll need a visual testing and 2geoms toys are perfect for that. >> Making heavy use of spatial indexing requires some significant >> architectural changes, so it gives me another thought. Our current >> double-tree architecture, where every element stores both its >> "semantic" content (SVG) and "representation" content (XML) is rather >> wasteful when it comes to memory, particularly when it comes to >> embedded images. Storing only the semantic representation and >> generating the XML representation on demand when saving could help >> with the memory hog problem. It would also make easier e.g. >> conditionally writing <svg:path> instead of <svg:rect> when the given >> rectangle has markers, or using <svg:polyline> instead of <svg:path> >> when a path has straight segments only. Abandoning the 1:1 XML-SP >> correspondence could give us more flexibility, and promote better >> coding (right now some places use XML tree calls where they should >> evidently operate on the SP tree). >> >> On the other hand, this approach is more bug-prone. It's not clear to >> me now how to implement undo. We would most likely need to sacrifice >> the editing capability of the XML Editor and turn it into an XML >> Inspector. >> >> Another area of potential improvement is the renderer. I heard from >> others that migrating to Cairo could halve the total memory usage. > > Well, whatever improves the situation, really :) __________________________________________________ �� Yahoo!; �� (spam); �� Yahoo! Mail �� http://mail.yahoo.gr

1 0

Anyone using btool on Linux?
by Joshua A. Andler 16 Dec '09

16 Dec '09

If so, would you be willing to check the second patch in: https://bugs.edge.launchpad.net/inkscape/+bug/488862 ? If you do and it's safe, please commit or give word that it caused no problems. Cheers, Josh

1 0

Re: [Inkscape-devel] [Inkscape-user] Slow performance on 4.5 MB file [SOLVED]
by Jasper van de Gronde 16 Dec '09

16 Dec '09

And please be sure to file a bug/feature request at http://bugs.launchpad.net/inkscape/ In the end there will obviously always be cases where Inkscape is too slow, but Inkscape could most definitely be faster in some cases. And just locking/unlocking the layer should (from an intuitive standpoint) NOT cause such a big pause. Dave M G wrote: > Donn, > > Thank you for responding. > >> I have long moaned that "Nodes mean slow" :( I have a fast machine and 2gigs >> of RAM. It makes no difference. I think it's all the looping through those long >> lists of nodes.... >> >> You are doomed. Unless you can simplify or chop-up your comic page into frames >> and assemble them later in Gimp. > > Okay. While it's a little disappointing that there isn't a way to > optimize the file for better performance, it's good to know that at > least I'm not doing something wrong. > > I'll export the paths into a PNG and handle the colouring in Photoshop > or GIMP. It means committing to rasterizing the images sooner in my > process than I had hoped, but hey, life is full of compromises. >

4 6

Fw: SVG output device for Poppler
by Luca Bruno 11 Dec '09

11 Dec '09

I'm acting as a bridge for Pino and Jan here, regarding a definitive solutions to the continuous poppler-pdf breakage due to our and karbon's use of poppler's internal helpers. Please remember to keep them both on Cc: when replying. Date: Wed, 9 Dec 2009 23:54:43 +0100 From: Pino Toscano <pino@...1199...> To: inkscape-devel(a)lists.sourceforge.net, Jan Hambrecht <jaham@...240...> Subject: SVG output device for Poppler Hello Jan (Karbon developer), Hello Inkscape developers, (Jan and me are not subscribed to the Inkscape ML, so please remember to CC us in the replies.) for those who do not know me, my name is Pino Toscano, and I am a KDE and Poppler developer. I am writing you because of both Inkscape and Karbon use the core API of Poppler, but fundamentally to do the very same task: create SVGs for pages of a PDF document. Both the application do it using a custom OutputDev, Inkscape's one creating a XML document using the Inkscape API + GLib, while Karbon's one outputting the XML document to file using Qt4. As you also might know, Poppler's core is considered private, so not API- nor ABI- stable, so your work can break at any time, even on patch releases of Poppler (as you Inkscape developers already experienced). So, my proposal is the following: if possible, join the forces and provide a C++-only (so no GLib nor Qt4, although libxml2 could be considered usable) SvgOutputDev directly in the Poppler core. The benefits would be clear: - single point of development for an SVG export for Poppler - nicely frontend wrapping (poppler-qt4 and poppler-glib) for the SVG export - no more Poppler core usage, less breakages! The work needed would consist in the following steps: 1) develop a SvgOutputDev in the Poppler core (so in the Poppler repository) 2) add the wrapping API in the qt4 and glib frontends 3a) adapt Inkscape's filter to use the new API 3b) adapt Inkscape's filter to use the new API After looking briefly at the two filters, it seems 3a and 3b should be more or less trivial to do If you would like to start the job (especially a), which is the most important step :) ), you are invited to join us at the Poppler mailing list; remember we (Poppler developers) can always offer support. -- Pino Toscano -- .''`. ** Debian GNU/Linux ** | Luca Bruno (kaeso) : :' : The Universal O.S. | lucab (AT) debian.org `. `'` | GPG Key ID: 3BFB9FB3 `- http://www.debian.org | Debian GNU/Linux Developer

2 1