- Inkscape Devel - Inkscape Mailman

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

Re: [Inkscape-devel] SVGFonts: lot's of questions
by Richard Hughes 15 May '08

15 May '08

>> The difficulty we're having is that not enough of Inkscape's rendering >> has been converted to Cairo for it to be easy for us to use Cairo's >> user-fonts for output. Do you think it would be possible for us to >> create a fake Cairo user-font which only has a partially-implemented >> render_glyph_func (returns the extents but doesn't draw anything) and >> then we figure it all out later and send it to our own renderer? I'm >> just looking for a more incremental approach to this feature rather >> than having to bundle in a complete Cairo conversion at the same time. > How do you use Pango currently? You can do the same approach with > pangocairo. I assume you use pangoft2 to extract glyph outlines and > render them yourself. You can do the same with pangocairo. You don't > have to use cairo for everything... Yeah, something like that. I reckon the conversion for existing system fonts should be quite easy, but what about user-fonts? Do I understand that your design for Pango will not call the render_glyph_func at all, i.e. we can leave it as NULL until we've figured out how to do things properly? Richard.

2 1

Re: [Inkscape-devel] SVGFonts: lot's of questions
by Richard Hughes 14 May '08

14 May '08

> No. There's no way to implement a feature like this without help from > the backends, and I'm only going to do it in the cairo backend as that's > pretty much the only supported backend at this time. What other backend > do you have in mind? pangoft2? Inkscape really should just use the > cairo backend. Many cool new features (like vertical text support) are > only implemented in the cairo backend. OK, I was just trying to figure out what our options were. Of course Inkscape should be using the Cairo backend, we just don't at the moment. The difficulty we're having is that not enough of Inkscape's rendering has been converted to Cairo for it to be easy for us to use Cairo's user-fonts for output. Do you think it would be possible for us to create a fake Cairo user-font which only has a partially-implemented render_glyph_func (returns the extents but doesn't draw anything) and then we figure it all out later and send it to our own renderer? I'm just looking for a more incremental approach to this feature rather than having to bundle in a complete Cairo conversion at the same time. Changing the subject slightly, I can't see any mention of kerning in the current Cairo API. Is this something for later, or am I just ignoring things right in front of me again? Richard.

1 0

adaptiveThreshold.cpp:20: error: 'image' was not declared in this scope
by Jeff Kowalczyk 14 May '08

14 May '08

Is anyone else seeing the following build error on inkscape trunk? depbase=`echo extension/internal/bitmap/adaptiveThreshold.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\ i686-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I.. -I/usr/lib/perl5/5.8.8/i686-linux/CORE -I/usr/include/freetype2 -pthread -DORBIT2=1 -I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include -I/usr/include/gconf/2 -I/usr/include/orbit-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -DRELAYTOOL_CRYPTO='static const int libcrypto_is_present = 1; static int __attribute__((unused)) libcrypto_symbol_is_present(char *m) { return 1; }' -DRELAYTOOL_SSL='static const int libssl_is_present = 1; static int __attribute__((unused)) libssl_symbol_is_present(char *m) { return 1; }' -DHAVE_SSL -I/usr/include/freetype2 -I/usr/include/poppler -I/usr/include/poppler/glib -I/usr/include/poppler -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/pixman-1 -DPOTRACE=\"potrace\" -pthread -I/usr/include/gdkmm-2.4 -I/usr/lib/gdkmm-2.4/include -I/usr/include/glibmm-2.4 -I/usr/lib/glibmm-2.4/include -I/usr/include/pangomm-1.4 -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/cairomm-1.0 -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/pango-1.0 -I/usr/include/cairo -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/pixman-1 -I/usr/include/gtkmm-2.4 -I/usr/lib/gtkmm-2.4/include -I/usr/include/atkmm-1.6 -I/usr/include/atk-1.0 -I/usr/include/libxml2 -I/usr/include/gtkspell-2.0 -I../cxxtest -Werror=format-security -Wall -Wformat -Wformat-security -W -D_FORTIFY_SOURCE=2 -Wpointer-arith -Wcast-align -Wsign-compare -Woverloaded-virtual -Wswitch -Wno-unused-parameter -O2 -march=i686 -pipe -MT extension/internal/bitmap/adaptiveThreshold.o -MD -MP -MF $depbase.Tpo -c -o extension/internal/bitmap/adaptiveThreshold.o extension/internal/bitmap/adaptiveThreshold.cpp &&\ mv -f $depbase.Tpo $depbase.Po In file included from extension/internal/bitmap/imagemagick.cpp:29: extension/internal/bitmap/imagemagick.h:14:22: error: Magick++.h: No such file or directory In file included from extension/internal/bitmap/adaptiveThreshold.h:9, from extension/internal/bitmap/adaptiveThreshold.cpp:12: extension/internal/bitmap/imagemagick.h:14:22: error: Magick++.h: No such file or directory In file included from extension/internal/bitmap/adaptiveThreshold.h:9, from extension/internal/bitmap/adaptiveThreshold.cpp:12: extension/internal/bitmap/imagemagick.h:24: error: 'Magick' has not been declared extension/internal/bitmap/imagemagick.h:24: error: expected ',' or '...' before '*' token In file included from extension/internal/bitmap/adaptiveThreshold.cpp:12: extension/internal/bitmap/adaptiveThreshold.h:23: error: 'Magick' has not been declared extension/internal/bitmap/adaptiveThreshold.h:23: error: expected ',' or '...' before '*' token extension/internal/bitmap/adaptiveThreshold.cpp:20: error: variable or field 'applyEffect' declared void extension/internal/bitmap/adaptiveThreshold.cpp:20: error: 'Magick' has not been declared extension/internal/bitmap/adaptiveThreshold.cpp:20: error: 'image' was not declared in this scope make[2]: *** [extension/internal/bitmap/adaptiveThreshold.o] Error 1 make[2]: *** Waiting for unfinished jobs.... In file included from extension/internal/bitmap/imagemagick.cpp:29: extension/internal/bitmap/imagemagick.h:24: error: 'Magick' has not been declared extension/internal/bitmap/imagemagick.h:24: error: expected ',' or '...' before '*' token extension/internal/bitmap/imagemagick.cpp:39: error: 'Magick' has not been declared extension/internal/bitmap/imagemagick.cpp:39: error: expected ',' or '...' before '*' token extension/internal/bitmap/imagemagick.cpp:43: error: 'Magick' has not been declared extension/internal/bitmap/imagemagick.cpp:43: error: ISO C++ forbids declaration of 'Image' with no type extension/internal/bitmap/imagemagick.cpp:43: error: expected ';' before '*' token extension/internal/bitmap/imagemagick.cpp: In constructor 'Inkscape::Extension::Internal::Bitmap::ImageMagickDocCache::ImageMagickDocCache(Inkscape::UI::View::View*)': extension/internal/bitmap/imagemagick.cpp:57: error: class 'Inkscape::Extension::Internal::Bitmap::ImageMagickDocCache' does not have any field named '_images' extension/internal/bitmap/imagemagick.cpp:72: error: '_images' was not declared in this scope extension/internal/bitmap/imagemagick.cpp:72: error: expected type-specifier before 'Magick' extension/internal/bitmap/imagemagick.cpp:72: error: expected `;' before 'Magick' extension/internal/bitmap/imagemagick.cpp:85: warning: deprecated conversion from string constant to 'char*' extension/internal/bitmap/imagemagick.cpp:87: error: expected type-specifier before 'Magick' extension/internal/bitmap/imagemagick.cpp:87: error: expected `;' before 'Magick' extension/internal/bitmap/imagemagick.cpp: In destructor 'virtual Inkscape::Extension::Internal::Bitmap::ImageMagickDocCache::~ImageMagickDocCache()': extension/internal/bitmap/imagemagick.cpp:104: error: '_images' was not declared in this scope extension/internal/bitmap/imagemagick.cpp:105: error: type '<type error>' argument given to 'delete', expected pointer extension/internal/bitmap/imagemagick.cpp: At global scope: extension/internal/bitmap/imagemagick.cpp:111: error: 'Magick' has not been declared extension/internal/bitmap/imagemagick.cpp:111: error: expected ',' or '...' before '*' token extension/internal/bitmap/imagemagick.cpp: In member function 'void Inkscape::Extension::Internal::Bitmap::ImageMagickDocCache::readImage(const char*, int)': extension/internal/bitmap/imagemagick.cpp:118: error: 'Magick' has not been declared extension/internal/bitmap/imagemagick.cpp:118: error: expected `;' before 'blob' extension/internal/bitmap/imagemagick.cpp:119: error: 'blob' was not declared in this scope extension/internal/bitmap/imagemagick.cpp:120: error: 'image' was not declared in this scope extension/internal/bitmap/imagemagick.cpp:123: error: 'image' was not declared in this scope extension/internal/bitmap/imagemagick.cpp: In member function 'virtual void Inkscape::Extension::Internal::Bitmap::ImageMagick::effect(Inkscape::Extension::Effect*, Inkscape::UI::View::View*, Inkscape::Extension::Implementation::ImplementationDocumentCache*)': extension/internal/bitmap/imagemagick.cpp:156: error: 'Magick' has not been declared extension/internal/bitmap/imagemagick.cpp:156: error: expected `;' before 'effectedImage' extension/internal/bitmap/imagemagick.cpp:157: error: 'effectedImage' was not declared in this scope extension/internal/bitmap/imagemagick.cpp:159: error: 'Magick' has not been declared extension/internal/bitmap/imagemagick.cpp:159: error: 'blob' was not declared in this scope extension/internal/bitmap/imagemagick.cpp:159: error: expected type-specifier before 'Magick' extension/internal/bitmap/imagemagick.cpp:159: error: expected `;' before 'Magick' extension/internal/bitmap/imagemagick.cpp:197: error: expected type-specifier before 'Magick' extension/internal/bitmap/imagemagick.cpp:197: error: expected `)' before '::' token extension/internal/bitmap/imagemagick.cpp:197: error: expected `{' before '::' token extension/internal/bitmap/imagemagick.cpp:197: error: '::Exception' has not been declared extension/internal/bitmap/imagemagick.cpp:197: error: 'error_' was not declared in this scope extension/internal/bitmap/imagemagick.cpp:197: error: expected `;' before ')' token ./util/glib-list-iterators.h: In member function 'T* const& Inkscape::Util::GSListConstIterator<T*>::operator*() const [with T = SPItem]': extension/internal/bitmap/imagemagick.cpp:222: instantiated from here ./util/glib-list-iterators.h:47: warning: dereferencing type-punned pointer will break strict-aliasing rules

3 8