- Inkscape Devel - Inkscape Mailman

possible bug
by Makurin Roman 26 Dec '04

26 Dec '04

When I trying to export my *.svg into *.png and path contains white spaces I`ve got an error. -- JID: drolyk@...189... ICQ: 105266647

1 0

SVG prefix commit
by MenTaLguY 25 Dec '04

25 Dec '04

Okay, I've comitted the change; from now on, name SVG elements in Inkscape like "svg:g" rather than "g". Important note: attribute naming has not changed, it's just elements I was pretty careful not to break anything, but I can't guarantee it; it was a pretty wide-ranging change. Let me know if anything broke. -mental

2 5

brief history of namespace support in Inkscape
by MenTaLguY 25 Dec '04

25 Dec '04

Just as a bit of background... Originally, in Sodipodi, namespaces were ignored entirely. Any element without a prefix was assumed to be SVG, xlink: was always assumed to be XLink, and sodipodi: always Sodipodi stuff. We did add xmlns declarations just to keep parsers happy, but that was it. Obviously that was deeply wrong to do. It was difficult for me to get buy-in for a sweeping change, however. What I did finally did get accepted was a simple hack -- I remapped the prefixes on load to what Sodipodi expected. So, at that point, if you loaded a document where the SVG namespace was bound to the blah: prefix, "blah:g" would become "g" in memory. Similarly, if ook: were bound to the Sodipodi namespace, "ook:namedview" would become "sodipodi:namedview" in memory. This is the code we inherited from Sodipodi, and the approach I refer to as "normalized qnames". Now, there were a couple shortcomings that remained: One, this was only done on load. The serialization code still didn't know anything about namespaces and we simply relied on stuffing a bunch of xmlns attributes in the document and hoping that covered everything. Not a simple thing to fix, unfortunately. Two, non-namespaced elements would appear to be in the svg namespace. This means that some non-SVG elements would get interpreted (and saved) as SVG elements. Thankfully, that was trivially fixable by normalizing svg elements to use the prefix svg: instead of none. As I noted on the Sodipodi list at that time, I did want to go back and address those two shortcomings, but Things Happened, and a year or two later I'm writing this. We did inherit both shortcomings, so it's high time I did something about them. I just knocked out the second one, and I'm hoping I can spend some time on the first one soon. The serializer improvements shouild actually afford a lot of opportunity to make our XML output prettier, including using shorter prefixes (e.g. maybe just i: for inkscape's namespace) in serialized files. And of course using SVG as the default namespace again, where practical to do so. -mental

1 0

I'm leaving a debug message in
by Ted Gould 25 Dec '04

25 Dec '04

Hey, I know that this is annoying, but I think it is important for a short while. The message that I'm leaving is a notice that an extension is being unloaded. This is because now extensions are getting unloaded if they aren't used for a while -- and this code has never been used before. But, since it happens seemingly randomly, I don't want people to start debugging something that is actually a bug in these unload routines. Now, I think that I've tested all the cases, but I'd like to keep it in for a while to make sure. -- Ted

1 0

Problems with XML Editor
by Valentin Cristescu 24 Dec '04

24 Dec '04

Hi, I can't start the XML Editor. The message is: Inskcape encountered an internal error and will close now. I'm using Fedora Core 3.

2 1

Non-coder tasks
by Bryce Harrington 24 Dec '04

24 Dec '04

Today a question came up regarding how non-coders can help improve Inkscape. This info has been added to the Inkscape FAQ, under 'Are there non-coding ways to help?': http://www.inkscape.org/faq.php Let me know if you have other ideas we could list there. Bryce

2 2

element namespaces
by MenTaLguY 24 Dec '04

24 Dec '04

FYI, now that things are sort of quiescent, I'm going to start on disambiguating the SVG and null namespaces, as I have threatened to do in the past. This means that (internally) we'll start using the svg: prefix to refer to SVG element names. "g" will become "svg:g" etc. Probably we will hide the "svg:" prefix in the XML editor though. Important things to remember: * this only affects the way we name elements, not attributes -- attribute names should remain unchanged as most standard SVG attributes are supposed to be in the null namespace (except for the xlink: ones) * only elements in the SVG namespace will be affected; the remainder are already named unambiguously * there is no inherent relationship between prefixes and namespaces; for practical reasons we have enforced one within inkscape, and we rewrite existing prefixes to match this mapping when we load documents -mental

5 16

[cairo] Very slow performance (fwd)
by Bryce Harrington 23 Dec '04

23 Dec '04

---------- Forwarded message ---------- Date: Thu, 23 Dec 2004 09:54:59 -0500 From: Chris <fltk@...78...> To: cairo@...278... Subject: [cairo] Very slow performance I have some fairly complex SVG artwork that I created. I have noticed that the performance of Cairo is quite a bit slower than some other svg libraries. My image has about 3500 paths and on my machine this image takes less than a second to load and render in Inkscape (librsvg/libart based?). Even Inkscape feels slow compared to commercial applications when handling this file. I made a simple test program that loads this file and renders it to an image buffer in Cairo. It takes over 30 seconds to do this. That's incredibly slow and makes me wonder about the usability of Cairo in everyday applications. Would rendering to OpenGL or xlib be faster? I'm planning on adding SVG support to FLTK by using Cairo so even if those are faster that might not help me as FLTK has it's own cross-platform drawing functions that I will be using. Where is the bottleneck? Is libart just that much faster at doing the rendering? The source code for my simple test is here: http://www.functionalfuture.com/radical/cairotest.c The SVG image I'm using is here: http://www.functionalfuture.com/radical/centi_unfinished.svg.gz -- // Chris _______________________________________________ cairo mailing list cairo@...278... http://lists.freedesktop.org/mailman/listinfo/cairo

3 2

Linking suggestion
by Bob Jamison 23 Dec '04

23 Dec '04

Hi, all, again. Now that Ted and I are going through the headaches of linking, extensions, shared objects, and their ilk, I have a suggestion about how we are linking Inkscape. Currently, the main Makefile.am is built at automake time to Makefile.in by reading all of its Makefile_insert files from the various subdirectories. The final 'inkscape' target is made as the result of libinkpre.a, all of the sub-libraries from each of the Makefile_inserts, then libinkpost.a. This is because of link-order problems. This is just my opinion, but wouldn't it be easier/cleaner to make one large libinkscape.a by concatenating it from each of (pick one) libBlah_a_SOURCES or libBlah_a_OBJECTS ... in each of the Makefile_inserts??? Then we would have one nice reference library that can be used by other projects, can be made into a .so or .dll, and that can more easily export its symbols. And best of all, there would be no link-order problems. This would in no way alter the set of Makefile_inserts that we have in the build tree. The main Makefile would merely use different information from them. The small .a's would still be built (or be buildable) and everyone can still do their private testing. It would only change the makeup of the large libinkscape.a lib. Any thoughts? This would not affect the majority of devs, but would -GREATLY- simplify the world for those of us who need to worry about link issues. Bob

5 7

problem compiling from CVS, python-related
by Ben Crowell 23 Dec '04

23 Dec '04

Thanks, Bob, for the hint about --with-python=no. I'm now experiencing a different error, shown below, which seems to be related to Perl. I'm trying now with both python and perl disabled. I actually have a modicum of Perl expertise, so if you can tell me what it is about my Perl install that's causing this failure, I might be able to add something to the configure script to autodetect it and give an informative error message. ============================================================== /bin/sh ../libtool --mode=link g++ -Wall -W -Wpointer-arith -Wcast-align -WsignWswitch -Wno-unused-parameter -g -O2 -o extension/plugin/libgimpgrad.la -rpatns extension/plugin/gimpgrad.lo -lgc -lpthread -ldl -Wl,-E -L/usr/local/lib /r/DynaLoader.a -L/usr/lib/perl/5.8/CORE -lperl -ldl -lm -lpthread -lc -lcrypt *** Warning: Linking the shared library extension/plugin/libgimpgrad.la against *** static library /usr/lib/perl/5.8/auto/DynaLoader/DynaLoader.a is not portabl g++ -shared -nostdlib /usr/lib/gcc-lib/i486-linux/3.3.4/../../../crti.o /usr/libginS.o extension/plugin/.libs/gimpgrad.o /usr/lib/libgc.so -L/usr/local/lib /u/DynaLoader.a -L/usr/lib/perl/5.8/CORE -lperl -ldl -lpthread -lcrypt -L/usr/lib//lib/gcc-lib/i486-linux/3.3.4/../../.. -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc-libr/lib/gcc-lib/i486-linux/3.3.4/../../../crtn.o -Wl,-E -Wl,-soname -Wl,libgimpgrbs/libgimpgrad.so.0.0.0 /usr/bin/ld: cannot find -lperl collect2: ld returned 1 exit status make[2]: *** [extension/plugin/libgimpgrad.la] Error 1 make[2]: Leaving directory `/home/bcrowell/Documents/sw/inkscape/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/bcrowell/Documents/sw/inkscape' make: *** [all] Error 2

5 7