- Inkscape Devel - Inkscape Mailman

Need to work in color spaces other than RGB
by Jon Cruz 22 Dec '09

22 Dec '09

I think we've hit the point where we need to revisit our rendering and such to include more than just RGB. This bug is one example: "Export to TIFF to support CMYKA color" https://bugs.launchpad.net/inkscape/+bug/492402 It looks like to be able to solve this case, we would need to be able to have our engine render to four-channel CMYK in order to preserve data. Simply rendering to RGB and then converting to CMYK using LittleCMS won't work, since black ink separation will be lost, etc. Am I seeing this wrong? Also, could we perhaps get away with export by rendering n channels, each being grayscale? Thanks.

5 15

Step-by-step debugging with Code::Blocks
by Yann Papouin 22 Dec '09

22 Dec '09

Hi, As a Delphi developer I'm used to debug my apps in a step by step way. I worked with Code::Blocks 2 years ago in a student project and I found it really easy to use. Today I'm using it to understand how Inkscape works and what methods are related to a specific work. [image: usshot-148.png] I'm posting here the Code::Blocks project that I'm using (it must be put in the "inkscape/src" directory): http://ftpmerou.free.fr/inkscape/codeblocks/Inkscape.cbp The nightly (monstly?) build of Code::Blocks can be found here: http://forums.codeblocks.org/index.php/board,20.0.html Note that it's no a replacement of the btool, you steel need it to create the config.h, the dist directory, and targets not included in the CB project (inkview, cxxtest, ...). Note that if a file is added/removed from the repository, you will have to add/remove it yourself from the CB project or wait for an updated project version. Note that the config.h needs to be moved the "inkscape/src" directory too. http://ftpmerou.free.fr/inkscape/codeblocks/config.h If btool is working fine, you should not have any problem to build targets as paths are still the same but: C:\devlibs can be changed in "Build Options" [image: usshot-145.png] c:\mingw can be changed in "Settings" - > "Compiler and debuggers..." [image: usshot-146.png] Finally, there is still one thing that I don't know how to realize in CB, so you may need to set a global var in your OS for pkg-config: [image: usshot-147.png] And now you are ready, after building LIB target and EXE target, to start debugging the EXE target by pressing F8. Yann.

1 0

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