- Inkscape Devel - Inkscape Mailman

No default units in dev build Inkscape0805062005.7z
by worms invasion 20 May '08

20 May '08

I have downloaded http://inkscape.modevia.com/win32/Inkscape0805062005.7z yesterday, and tested it. It has a weird problem : no default units are showing, and nothing is showing when I try to use the drop-down menus to select a unit. I am on Windows 2000 - which is known to have problems with drop-down boxes, but nothing can be done at OS level, I believe. Anyway... Has someone the same problem on other OSs? Also, when I enter 10.00 in the box to transform, it becomes 1000000.00, but I can't select "pix". Same in the document properties. Screenshot at : http://www.corpsmoderne.net/~eve97/vertex/default_units_missing.png ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

4 4

GSL dependency
by unknown＠example.com 19 May '08

19 May '08

Hi all, I just updated Inkscape's copy to the latest 2geom svn rev. I tried to add the GSL dependency to configure.ac but have no way to check whether it has gone wrong or not. I am very sorry if this breaks your build :-( -Johan

4 7

isFinite() problem again
by Maximilian Albert 19 May '08

19 May '08

Hi all, recently there was a discussion about name clashes involving is_finite(). The problem appeared to be solved but now I ran into it (or something similar?) again. Namely, adding the line #include "live_effects/effect.h" to object-edit.cpp yielded the following compile error: object-edit.cpp: In function ‘void sp_spiral_outer_set(SPItem*, const NR::Point&, const NR::Point&, guint)’: object-edit.cpp:1121: error: ‘isFinite’ was not declared in this scope When I additionally changed the line #include "isnan.h" to #include "2geom/isnan.h" and replaced isFinite() with IS_FINITE(), compilation worked fine again. Thus it seems that there is some kind of clashing between isnan.h and 2geom/isnan.h. Has anyone else seen this and what should be done to avoid further difficulties in the future? Max

3 3

NEW: Spiro splines LPE
by bulia byak 19 May '08

19 May '08

Spiro splines are a novel way of defining curvilinear paths developed by Raph Levien. Recently, Spiro support was added to the FontForge font editor, and now it is available in Inkscape too. It takes some getting used to, but for certain tasks Spiros have a clear advantage over Bezier curves. http://www.levien.com/spiro/ A Spiro path is defined by a sequence of points, but unlike a regular path with Bezier curves, all Spiro points lie on the path and there are no off-path handles. The curvature of the path is defined entirely by the positions of the points and their types. The path behaves very similar to a springy rod which is forced to pass through the given points and which uses the minimum possible curvature to satisfy the requirement. As such, it feels quite natural and the resulting path is very smooth - with the kind of smoothness you can achieve with Beziers only after much tweaking. To create a Spiro path, select any path and assign the "Spiro spline" path effect to it. There are no parameters. Each node of your path becomes a point of a Spiro path, depending on the type of node: * Smooth nodes (those with two collinear Bezier handles) become curve points of the Spiro path; such points bend the curve but must remain smooth. Note that the length or direction of the Bezier handles of the source path is ignored; the only thing that matters is that the node is smooth. * Cusp nodes of the source path become corner points of the Spiro path. Between two corner points, the path is always a straight line. * Half-smooth nodes - those with one Bezier handle collinear with a straight line segment on the other hand - become "left" or "right" points on the Spiro path which behave exactly the same: they sit between a straight line and a curve and enforce that these two segments join smoothly without a cusp. Note that what matters is the actual collinearity of a node's handles, regardless of the node type that the node has in the Node tool; for example, if a cusp (diamond-shaped) node has collinear handles, it will become a curve point of the Spiro path. For creating half-smooth nodes, use Ctrl+dragging of the node handle to make it snap to the direction of the straight line segment on the other side, or press Shift+S to lock it to that direction. Some configurations of points do not converge and produce wild loop and spirals instead of a smooth curve. According to Raph, "The spline solver in this release is _not_ numerically robust. When you start drawing random points, you'll quickly run into divergence. However, "sensible" plates based on real fonts usually converge." Avoid too sharp changes in direction between points to prevent divergence. Hopefully, the robustness of the algorithm will be improved in future releases. For now, to edit Spiro paths viewing the result in real time, you have to use the Node tool. The Pen tool does not yet allow you to preview a Spiro as you draw, although you can paste the Spiro effect on the path and see the result as soon as the path is finalized. You can always use the Node tool to continue a Spiro path by duplicating and dragging away its end nodes. Also, when you have a Spiro path selected, you can add a new subpath to it with Pen or Pencil if you start drawing with Shift. Raph: Thanks for your code, and let me know when you have a new version :) I have copied only spiro.c/h and bezctx.c/h to Inkscape tree, renaming .c to .cpp and removing debug output, but otherwise unchanged. -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

10 17

I knew Bryce was talented, but...
by rygle 19 May '08

19 May '08

I hadn't seen this yet... http://www.youtube.com/watch?v=wKz7ZVZR2mE Rygle =^D -- View this message in context: http://www.nabble.com/I-knew-Bryce-was-talented%2C-but...-tp17316637p173166… Sent from the Inkscape - Dev mailing list archive at Nabble.com.

1 0

envelope LPE
by bulia byak 19 May '08

19 May '08

Thanks to whoever added this, it's fantastic! I have one request though: can you please combine the four envelope paths into one four-sided envelope? It will be much easier to edit this way. I understand that this may introduce the ambiguity as to where one side of the envelope ends and another starts, because the envelope sides may be more than 2 nodes long. But I have a rough idea on how to handle this: Imagine a line that goes at 45 degrees from SW to NE, and imagine that that line moves from infinity in the SE direction. The first node of the envelope path that it touches will be considered the top of the left side and the left end of the top side. Same for finding the 3 other corners. I think it will be relatively easy to implement - and much easier to use than the four separate sides. Thanks again, and by the way please add a description of the new feature to http://wiki.inkscape.org/wiki/index.php/ReleaseNotes047 -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

2 1

LPEs/paths and knotholders
by Maximilian Albert 18 May '08

18 May '08

Hi, I was experimenting with additional knotholders for items carrying an LPE but I'm having problems. What I did was simply to add another case distinction to sp_item_knot_holder() in object-edit.cpp. It checks whether an object has an LPE applied to it, in which case it returns a different knotholder than the standard one. The handling methods for the new knotholder are minimal (a 'set' method which does nothing and a 'get' method wich just returns a constant point) but Inkscape keeps crashing when handles corresponding to the "ordinary" knotholder are moved. I suspect that the new knotholder somehow interferes with the one that is created for paths in nodepath.cpp but I can't seem to find the exact cause of the problem. The backtraces don't look very helpful to me either since the crash happens in different places and I haven't yet found the common cause (see below for 2 sample backtraces; note that the line numbers may slightly vary due to my changes to the code). I wonder if anyone has an idea what could be wrong. Really some kind of interference between the two knotholders? How do the knotholders for paths work anyway? Is object-edit.cpp the wrong place to alter them? Thanks in advance, Max Backtraces: #0 0xb7376c77 in g_str_hash () from /usr/lib/libglib-2.0.so.0 #1 0xb73484db in g_hash_table_lookup () from /usr/lib/libglib-2.0.so.0 #2 0xb7341271 in g_quark_from_string () from /usr/lib/libglib-2.0.so.0 #3 0x087b783e in Inkscape::XML::SimpleNode::attribute (this=0x9ef1600, name=0x40240000 <Address 0x40240000 out of bounds>) at xml/simple-node.cpp:222 #4 0x081eae1d in update_repr_internal (np=0xaee6c00) at nodepath.cpp:578 #5 0x081ee47c in sp_nodepath_update_repr (np=0xaee6c00, annotation=0x884685c "Move nodes") at nodepath.cpp:613 #6 0x081eeb4b in node_ungrabbed (data=0xb2a1c40) at nodepath.cpp:3363 #7 0xb741265a in g_cclosure_marshal_VOID () from /usr/lib/libgobject-2.0.so.0 #8 0xb74056f9 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #9 0xb7419c3d in ?? () from /usr/lib/libgobject-2.0.so.0 #10 0x09a99b00 in ?? () #11 0x00000000 in ?? () #0 0x081a122c in sp_document_maybe_done (doc=0xb08eb40, key=0x0, event_type=111, event_description=@0xbfbff160) at document-undo.cpp:173 #1 0x081a14f0 in sp_document_done (doc=0xb08eb40, event_type=111, event_description=@0xbfbff190) at document-undo.cpp:125 #2 0x081ee4c4 in sp_nodepath_update_repr (np=0xb08eb48, annotation=0x884685c "Move nodes") at nodepath.cpp:617 #3 0x081eeb4b in node_ungrabbed (data=0xb7f8ae0) at nodepath.cpp:3363 #4 0xb73c865a in g_cclosure_marshal_VOID () from /usr/lib/libgobject-2.0.so.0 #5 0xb73bb6f9 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #6 0xb73cfc3d in ?? () from /usr/lib/libgobject-2.0.so.0 #7 0x0b974be8 in ?? () #8 0x00000000 in ?? ()

4 6

Re: [Inkscape-devel] [Clipart] tutorials in Galician
by Jon Phillips 18 May '08

18 May '08

Cool, that is so great! I'm fwd'ing this to the inkscape list which handles this type of inkscape specific tutorial. Any takers on this and/or for blogging it on inkscape site? Jon On Thu, 2008-05-15 at 10:12 +0200, alberte mendez lopez wrote: > Hi All! I hope I'm doing this allright, since is my first e-mail to a > list. > I'm a Secondary school teacher, and this is just to say that i've made > some tutorials about inkscape for my pupils, based on all the great > stuff that i've found on this community. Now I'm putting them on the > web here , they're all in Galician (my little country language), so i > suppose they won't be very useful for the most of you :( , and they > are all on inkscape 0.45. > Just wanted to thank (and so do my pupils) to everybody who keep this > alive. > _______________________________________________ > clipart mailing list > clipart@...626... > http://lists.freedesktop.org/mailman/listinfo/clipart -- Jon Phillips San Francisco, CA + Guangzhou + Beijing GLOBAL +1.415.830.3884 CHINA +86.1.360.282.8624 jon@...235... http://www.rejon.org IM/skype: kidproto Jabber: rejon@...896... IRC: rejon@...897...

1 0

Re: [Inkscape-devel] PDF import crash, but not in 0.46
by Bob Jamison 16 May '08

16 May '08

Yes, I believe that all of the patches made it into the trunk. However, I don't think that any of them applied to Poppler. This sounds like simply a typical common regression here. ^^ We haven't done a "debug" upload in a few weeks. Time to do another one, I guess. bob -----Original Message----- >From: J.B.C.Engelen@...1578... >Sent: May 14, 2008 8:10 AM >To: inkscape-devel(a)lists.sourceforge.net >Subject: [Inkscape-devel] PDF import crash, but not in 0.46 > >Hi all, > >PDF import crashes for me on Windows with current trunk. It does not crash in the Inkscape 0.46 binary that I just downloaded. > >Have all windows patches been applied to trunk? > >Thanks, >Johan > >------------------------------------------------------------------------- >This SF.net email is sponsored by: Microsoft >Defy all challenges. Microsoft(R) Visual Studio 2008. >http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >_______________________________________________ >Inkscape-devel mailing list >Inkscape-devel(a)lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/inkscape-devel

2 2

Program too big to fit in memory
by Marcin Floryan 16 May '08

16 May '08

Hello! On today's compile of Inkscape (XP, SVN 18630) I got an unpleasant surprise. My system complains: Program too big to fit in memory with inkscape.exe being 224,113,108 B Although I have 2G of RAM I might have starved my XP of it a bit running quite a few programs already but nevertheless... are we going towards a boundary (or is it just my compilation). Regards, -- Marcin Floryan http://marcin.floryan.pl/ [GPG Key ID: 0D5581C5]

3 4