- Inkscape Devel - Inkscape Mailman

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

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

23 Dec '04

Whoa, it amazes me what people are doing with Inkscape these days... ---------- Forwarded message ---------- Date: Thu, 23 Dec 2004 12:54:22 -0500 From: Chris <fltk@...78...> To: Carl Worth <cworth@...573...> Cc: cairo@...278... Subject: Re: [cairo] Very slow performance On Thu, 2004-12-23 at 12:34 -0500, Carl Worth wrote: > It is slow, and we'll need to fix that. > > But cairo does render the whole thing correctly, right? That's > encouraging. Actually, it doesn't render quite right. At least compared to Inkscape. Inkscape render: http://www.functionalfuture.com/radical/centi_unfinished.png Cairo render: http://www.functionalfuture.com/radical/centi_test.png It seems like it draws everything OK. At least for the stuff you can see. However, the layering/ordering is not correct and some things are hidden that shouldn't be. -- // Chris _______________________________________________ cairo mailing list cairo@...278... http://lists.freedesktop.org/mailman/listinfo/cairo

1 0

io compile problem
by Bryce Harrington 23 Dec '04

23 Dec '04

<ddiaz> i'm getting: io/GzipStream.cpp:17:20: zutil.h: No such file or directory io/GzipStream.cpp: In member function `bool Inkscape::IO::GzipInputStream::load()': io/GzipStream.cpp:160: warning: unused variable 'srcCrc' io/GzipStream.cpp: In constructor `Inkscape::IO::GzipOutputStream::GzipOutputStream(Inkscape::IO::OutputStream&)': io/GzipStream.cpp:256: error: `OS_CODE' undeclared (first use this function) io/GzipStream.cpp:256: error: (Each undeclared identifier is reported only once for each function it appears in.) make[1]: *** [io/GzipStream.o] Error 1 make[1]: Leaving directory `/elresto/inkscape/inkscape.win32/src'

2 1

Fwd: Re: [Inkscape-devel] element namespaces
by bulia byak 23 Dec '04

23 Dec '04

On Thu, 23 Dec 2004 12:48:28 -0500, MenTaLguY <mental@...3...> wrote: > http://troi.hous.es3.titan.com/~rjamison/inkscape/builds/Inkscape0412221011… It needs to be explained that this builds uses a version of boehm that may fix the Windows freeze bug: http://sourceforge.net/tracker/index.php?func=detail&aid=1073459&group_id=9… So Windows folks who experienced this bug, please test this build and report your results here.

1 0

Build errors in CVS
by Trent Buck 23 Dec '04

23 Dec '04

I just tried to build Inkscape from CVS for the first time in a couple of weeks. I noticed the following Debian-specific problems: - AFAICT, python-dev and libperl-dev are now build dependencies; they should be added to the Build-Depends line in debian/control. - After building, dh_strip attempts to strip an ar archive, causing packaging to fail. From the build log: $ dpkg-buildpackage -rfakeroot [...] dh_installmime dh_link dh_strip strip: debian/inkscape/usr/lib/inkscape/plugins/stcstnTn/DynaLoader.a: Invalid operation dh_strip: command returned error code 256 make[2]: *** [binary-arch] Error 1 make[2]: Leaving directory `/alt/foo/pkg/cvs/inkscape/WORKING/inkscape' make[1]: *** [buildpackage] Error 2 make[1]: Leaving directory `/alt/foo/pkg/cvs/inkscape/WORKING/inkscape' -- -trent Look -- a diversion! It's shiny! -- Daniel Stone

4 4

filedialog change
by bulia byak 21 Dec '04

21 Dec '04

In file dialogs, I removed the name of the file above the preview: - it's a bit tautologic, as the file is already selected in the list anyway - removing it frees a bit more space for the preview itself - most importantly, long filenames stretch the preview and thus distort the dialog layout, and there's no way to ellipcize the filename label (at least yet, as of GTK 2.6) I like this change, but I realize there may be different opinions, so comments are welcome.

5 9

Re: [cairo] cairo backend for xpdf - first drop (fwd)
by Bryce Harrington 21 Dec '04

21 Dec '04

More evaluation info about the PDF backend in Cairo ---------- Forwarded message ---------- Date: Tue, 21 Dec 2004 16:40:10 -0500 From: Carl Worth <cworth@...43...> To: Alexander Larsson <alexl@...43...> Cc: cairo <cairo@...278...> Subject: Re: [cairo] cairo backend for xpdf - first drop On Mon, 20 Dec 2004 19:54:12 +0100, Alexander Larsson wrote: > I found an embarrasing bug in it. It kept reading the fonts over and > over again. With that fixed, and with all the performance fixes in Cairo > cvs xpdf-cairo now feels faster than the standard xpdf on my machine. > > I'm attaching the new patch. Alexander, This is fantastic work. I think I may have found a new favorite PDF viewer. The rendering of the glyphs is so much nicer compared to standard xpdf. Though I notice that the improved hinting allows some extra room in which the intra-word spacing could be improved. To my eye, intra-word problems, (such as two adjacent letters colliding) stand out more with the hinting of xdpf-cairo, whereas with xpdf-standard the words are just blurry everywhere. Do you generally still have word structure available in PDF files? Or is every glyph already placed individually? Meanwhile, line art appears to have better snapping with xpdf-standard, (or more likely that's just the lack of antialiasing). I've been meaning to propose a cairo_set_snapping API for some time and I think this application gives us perfect justification and some great test cases for that. Oh, and we still need to add sub-pixel rendering to cairo fonts, (geometry too!), to make things even more legible. Once we get all that done, I think it might even be pleasant to read many documents on a display instead of printing them out. I'm quite happy to see this area improve. -Carl _______________________________________________ cairo mailing list cairo@...278... http://lists.freedesktop.org/mailman/listinfo/cairo

1 0