- Inkscape Devel - Inkscape Mailman

[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

Re: [cairo] New PDF backend snapshot (fwd)
by Bryce Harrington 21 Dec '04

21 Dec '04

---------- Forwarded message ---------- Date: Tue, 21 Dec 2004 15:41:47 -0500 From: Carl Worth <cworth@...573...> To: Kristian HÃ¸gsberg <krh@...618...> Cc: cairo@...278... Subject: Re: [cairo] New PDF backend snapshot --[[text/plain]] Kristian, Thanks so much for all your hard work on the PDF backend! I'm sorry I've been so slow to review it. I think this is good work, and I want it to land in CVS soon. I have a few comments, (most importantly with respect to the public API). On Wed, 15 Dec 2004 12:52:38 -0500, Kristian HÃ¸gsberg wrote: > I've pondering the cairo_document_t idea a bit and restructured the PDF > backend so that it's split into a cairo_pdf_document_t object and a > cairo_pdf_surface_t object. I believe this makes the code easier to > follow, but I'm no longer sure we need to expose a cairo_document_t in > the user API. If it's easier to have two objects in the backend, that is fine. > public API. 2) It will be a nice way to set metadata and other PDF > specific information for the document. Can't we just do that with cairo_pdf_surface functions? What advantage does the user get from having two different objects? So far, it seems the user just has to do more work before being able to use the PDF backend, (compared to the others). > +void > +cairo_set_target_pdf (cairo_t *cr, > + cairo_pdf_document_t *document); The notion behind the cairo_set_target family of functions is to allow the user to select a backend without having to create any new object. So the cairo_set_target_pdf function should accept the same arguments as cairo_pdf_surface_create. So, I think I would like to see the new public cairo_pdf API match the existing cairo_ps API exactly: cairo_surface_t * cairo_ps_surface_create (FILE *file, double width_inches, double height_inches, double x_pixels_per_inch, double y_pixels_per_inch); void cairo_set_target_pdf (cairo_t *cr, FILE *file, double width_inches, double height_inches, double x_pixels_per_inch, double y_pixels_per_inch); > There are two significant changes outside cairo_pdf_surface.c in this > patch: I've added the set_clip_trapezoids surface method which is > supposed to let cairo pass the absolute clipping path to the backends. (Kristian and I discussed this off-list and he has now proposed a new patch without the set_clip_trapezoids method. See: http://people.redhat.com/krh/cairo-pdf/cairo-pdf-4.patch ) > The other change is the addition of cairo_array_t implemented in > cario_array.c. This is an standard autogrowing array, doubling the > allocation size when it runs out of space. I was using chained lists > before in the PDF backend, but I converted those to arrays. I added the > array as a general data type, since cairo uses the same type of array in > other places and it might make sense to rewrite those places to use this > array type. Eliminating some code duplication seems like a good thing. But I don't like giving up type safety, and worse, I don't want to give up direct access of arrays using C [] notation. This kind of thing is always a tough call since C has no support for what we really want here. Regardless, if the code is to stay, then: > + if (old_size == 0) > + new_size = 1; > + else > + new_size = old_size * 2; > + > + while (new_size < required_size) > + new_size = old_size * 2; should be: new_size = new_size * 2; to eliminate the infinite loop. And these three functions: > +static cairo_status_t > +_cairo_pdf_surface_set_matrix (void *abstract_surface, > + cairo_matrix_t *matrix) > + > +static cairo_status_t > +_cairo_pdf_surface_set_filter (void *abstract_surface, > + cairo_filter_t filter) > + > +static cairo_status_t > +_cairo_pdf_surface_set_repeat (void *abstract_surface, > + int repeat) merit at least a comment stating they are unsupported. This isn't *too* big a deal as I want to eliminate these functions from the surface interface anyway, (they really only belong on patterns). Once the issues above are resolved I'd like to get this into CVS. I haven't actually played with the PDF output yet, but we can have fun playing with that after it lands in the tree. Thanks again. -Carl _______________________________________________ cairo mailing list cairo@...278... http://lists.freedesktop.org/mailman/listinfo/cairo

1 0

Re: [Inkscape-user] Textbox
by Bryce Harrington 21 Dec '04

21 Dec '04

On Tue, 21 Dec 2004, John Cliff wrote: > > On Thu, 16 Dec 2004 13:56:59 +0100, Imre Vida > > <Imre.Vida@...617...> wrote: > > > Do you plan to implement such a feature? > > > > Yes. In fact it already works, though there's no UI for it yet. See > > share/examples/flowsample.svg > > > > Theres no decent, complete UI, but to add the elements needed to put > text into shapes you can select them, right click and do 'add text to > shapes' to add the text itself you currently need to use the xml > editor. better than starting from scratch tho. What sort of UI does this need to have? Is this something that'll be easy to do, or will it need to be planned out? Bryce

2 1

Mozilla/Firefox SVG now has <image> tags
by Bob Jamison 21 Dec '04

21 Dec '04

This is so cool. The code for implementing the <image> tag in Mozilla SVG, which was previously a set of patches, apparently has made it into the mainline. Previously, the Mozilla guys were forced to use the <foreignObject> tag. Here is the SVG file w/images that I always use to test this stuff. Ignore the text alignment; obviously I need to convert it to curves. http://troi.hous.es3.titan.com/~rjamison/inkscape/files/ff_ccp_dump.png Bob

1 0

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

21 Dec '04

Can anyone suggest how to fix/work around this problem compiling the latest CVS version? It seems to be related to python extensions. TIA! ======================================================================================= [snip] Traceback (most recent call last): File "<string>", line 1, in ? ImportError: No module named distutils.sysconfig if g++ -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/include/freetype2 -I/usr/include/fre etype2 -I/usr/X11R6/include -DPOTRACE=\"potrace\" -DXTHREADS -I/usr/include/gt k-2.0 -I/usr/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/include/atk-1.0 -I/ usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/glib-2.0 -I/usr/li b/glib-2.0/include -I/usr/include/libxml2 -I/usr/include/sigc++-2.0 -I/usr/lib/s igc++-2.0/include -I/usr/include/gtkmm-2.4 -I/usr/lib/gtkmm-2.4/include -I/usr/i nclude/glibmm-2.4 -I/usr/lib/glibmm-2.4/include -I/usr/include/gdkmm-2.4 -I/usr/ lib/gdkmm-2.4/include -I/usr/include/pangomm-1.4 -I/usr/include/atkmm-1.6 `p erl -MExtUtils::Embed -e ccopts` -I`python -c "import distutils.sysconfig ; prin t distutils.sysconfig.get_config_var('INCLUDEPY')"` -Wall -W -Wpointer-arith -Wc ast-align -Wsign-compare -Woverloaded-virtual -Wswitch -Wno-unused-parameter -g -O2 -MT extension/script/extension_script_libscript_a-inkscape_perl_wrap.o -MD -MP -MF "extension/script/.deps/extension_script_libscript_a-inkscape_perl_wrap. Tpo" -c -o extension/script/extension_script_libscript_a-inkscape_perl_wrap.o `t est -f 'extension/script/inkscape_perl_wrap.cpp' || echo './'`extension/script/i nkscape_perl_wrap.cpp; \ then mv -f "extension/script/.deps/extension_script_libscript_a-inkscape_perl_wr ap.Tpo" "extension/script/.deps/extension_script_libscript_a-inkscape_perl_wrap. Po"; else rm -f "extension/script/.deps/extension_script_libscript_a-inkscape_pe rl_wrap.Tpo"; exit 1; fi Traceback (most recent call last): File "<string>", line 1, in ? ImportError: No module named distutils.sysconfig if g++ -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/include/freetype2 -I/usr/include/fre etype2 -I/usr/X11R6/include -DPOTRACE=\"potrace\" -DXTHREADS -I/usr/include/gt k-2.0 -I/usr/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/include/atk-1.0 -I/ usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/glib-2.0 -I/usr/li b/glib-2.0/include -I/usr/include/libxml2 -I/usr/include/sigc++-2.0 -I/usr/lib/s igc++-2.0/include -I/usr/include/gtkmm-2.4 -I/usr/lib/gtkmm-2.4/include -I/usr/i nclude/glibmm-2.4 -I/usr/lib/glibmm-2.4/include -I/usr/include/gdkmm-2.4 -I/usr/ lib/gdkmm-2.4/include -I/usr/include/pangomm-1.4 -I/usr/include/atkmm-1.6 `p erl -MExtUtils::Embed -e ccopts` -I`python -c "import distutils.sysconfig ; prin t distutils.sysconfig.get_config_var('INCLUDEPY')"` -Wall -W -Wpointer-arith -Wc ast-align -Wsign-compare -Woverloaded-virtual -Wswitch -Wno-unused-parameter -g -O2 -MT extension/script/extension_script_libscript_a-InkscapePython.o -MD -MP -MF "extension/script/.deps/extension_script_libscript_a-InkscapePython.Tpo" -c -o extension/script/extension_script_libscript_a-InkscapePython.o `test -f 'exte nsion/script/InkscapePython.cpp' || echo './'`extension/script/InkscapePython.cp p; \ then mv -f "extension/script/.deps/extension_script_libscript_a-InkscapePython.T po" "extension/script/.deps/extension_script_libscript_a-InkscapePython.Po"; els e rm -f "extension/script/.deps/extension_script_libscript_a-InkscapePython.Tpo" ; exit 1; fi Traceback (most recent call last): File "<string>", line 1, in ? ImportError: No module named distutils.sysconfig extension/script/InkscapePython.cpp:13:20: Python.h: No such file or directory extension/script/InkscapePython.cpp: In member function `virtual bool Inkscape::Extension::Script::InkscapePython::interpretScript(Glib::ustring&, Glib::ustring&, Glib::ustring&)': extension/script/InkscapePython.cpp:62: error: `Py_Initialize' undeclared (first use this function) extension/script/InkscapePython.cpp:62: error: (Each undeclared identifier is reported only once for each function it appears in.) extension/script/InkscapePython.cpp:67: error: `PyRun_SimpleString' undeclared (first use this function) make[2]: *** [extension/script/extension_script_libscript_a-InkscapePython.o] Er ror 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 -

2 1

Re: File Chooser
by Bryce Harrington 21 Dec '04

21 Dec '04

On Tue, 21 Dec 2004, John Taber wrote: > For some reason I can subscribe to get the Inkscape mail list but my posts get > rejected so am sending this direct.... Can you forward us one of the rejection emails? Maybe we can figure out what's going wrong. > Yes, Gtk filechooser is a total DISASTER as seen by anyone in our office. In > fact it will probably surface more with Firefox as 10 million converts start > trying to download files. It even took me several weeks before I realized > the listbox on left is a bookmark list and it seems like now I just have to > go thru more keystrokes. So you have our vote to modify it to allow > filenames to be typed in. This type of Gtk weirdness really hurts Gtk > adoption. > > btw We now depend on Inkscape for our graphics work and thank all of you for > the great job you are doing on it - it is simply one of the most energetic > and best managed open source projects. How can we convince Fedora folks to > include it ? When Firefox hopefully soon supports SVG, Inkscape will be a > must and hot ticket. > John Cool, good to hear. I don't know how Fedora decides what to include, but perhaps you can send an email to them requesting it? An email to encourage Firefox's SVG efforts would probably be worthwhile too. Bryce

1 0

Multiple page documents in SVG
by Bryce Harrington 20 Dec '04

20 Dec '04

This question came up a couple times this past week. SVG 1.2 (which we don't yet support) provides a method for doing multiple paged documents: http://www.w3.org/TR/SVG12/multipage.html Example: <svg xmlns="http://www.w3.org/2000/svg" version="1.2"> <pageSet>  <page> <circle cx="100" cy="100" r="20" fill="blue"/> </page>  <page> <rect x="100" y="100" width="20" height="20" fill="red"/> </page> </pageSet> </svg> Bryce

4 3

-users -developers test please ignore
by vellum 20 Dec '04

20 Dec '04

1 0

test ignore
by vellum 20 Dec '04

20 Dec '04

1 0

RESEND: Bug with EPS-sizing upon import...
by Daniel 20 Dec '04

20 Dec '04

[Please cc: me on replies] Hi, I'm resending this after not hearing any responses to my first email over a period of two weeks... :) I'm using Inkscape 0.40 packaged for Debian unstable. If its an issue, I'm also using the AFPL-licensed version of ghostscript, version 8.14. I have noticed the following issue/bug, since I started using Inkscape, with version 0.39. Whenever I place EPS files into a new Inkscape document, they appear to be smaller (in pixel size or actual size, based upon bounding box) than they should be. For example, if I create both an EPS file and an SVG file produced by the command line version of potrace (which I was using with inkscape before it was included in the program as of version 0.40), using the exact same options and the exact same input file, they will import into Inkscape (both 0.39 and 0.40) with different sizes. The svg imported file will accurately reproduce the size of the EPS that I see when I use that EPS with other members of my tool chain (scribus, epstopdf, xpdf, acroread, etc.). Any ideas? Do you need anything else to quantify this? It appears very reproducible to me. Furthermore, when I export EPS from Inkscape (both 0.39 and 0.40), they appear (at least according to the "file" utility, to be regular postscript, rather than encapsulated postscript). I've tentatively tracked this down to be the lack of the full first-line of "%!PS-Adobe-3.0 EPSF-3.0" and instead only having "%!PS-Adobe-3.0". Ghostscript utilities, such as eps2eps, produce the full line, while inkscape produces the shorter version. Changing the latter to the former seemed to convince the Linux "file" utility that the file was now EPS. Any ideas on what's the right thing to do? Thanks again for a truly magnificent product. How it has wonderfully surpassed my expectations. Take care, Daniel PS I"ve given it to 6-8 of my less Linux-aware friends for use on their Windows boxen in the past few weeks. They are grateful.

3 2

Re: [Inkscape-devel] RESEND: Bug with EPS-sizing upon import...
by Daniel 20 Dec '04

20 Dec '04

Hi Bulia, Thanks for the reply... I'm guessing that you shouldn't need skencil to reproduce this bug and do a test EPS import, since I don't have it on my system and EPS imports work (I always assumed that you'd use ghostscript for EPS imports). Anyway, that bug looked familiar but the consensus was that something might be wrong due to an Adobe Illustrator issue. Mine however are EPS outputs produced only using Free Software tools (potrace from gimp-based input scan). If it really helps you, I could probably send you the inputs off-list, but I'd prefer to keep them private unless necessary. For the record, I can make it do this with any sample EPS file I gave it (comparing it to size in ghostview or through import into scribus). Thanks for the help. Let me know if there's anything else I can do. Any ideas about Postscript versus EPS recognition issue I mentioned also? Take care, Daniel > Whenever I place EPS files into a new Inkscape document, they appear > to be smaller (in pixel size or actual size, based upon bounding box) > than they should be. It seems to be this bug: http://sourceforge.net/tracker/index.php?func=detail&aid=1027699&group_id=9… If you attach there your comments and the sample EPS and SVG files from potrace it would be very helpful. The bug seems to be easy to fix (apparently the px and pt units are confused somewhere, we had several bugs of this kind) but I can't fix it now because I don't have Skencil installed (afaik we can only import EPS via Skencil).

2 1

Inkscape on LWN
by Bryce Harrington 20 Dec '04

20 Dec '04

Peter pointed out that LWN is featuring Inkscape on its Front page this week. http://lwn.net/ Bryce Vector graphics with Inkscape December 8, 2004 This article was contributed by Joe 'Zonker' Brockmeier. With the release of Inkscape 0.40, we decided to take a look at the latest release and get up to speed with the status of the project. Inkscape started as a fork of the Sodipodi project, but has evolved into a robust project in its own right. Inkscape is a drawing tool that uses the Scalable Vector Graphics (SVG) specification for its native format, and also exports to PNG, as well as saving in Adobe Illustrator format, PostScript, Encapsulated PostScript and PovRay formats. Inkscape will open or import graphics from Adobe Illustrator and Dia, other programs' SVG documents and a wide array of bitmap graphics formats. Inkscape runs on Linux, Windows and Mac OS X. We installed the Inkscape static RPM on a SUSE 9.2 system to see what the program is capable of, and whether Inkscape was stable and feature-complete enough for productive use. The Inkscape download page on SourceForge includes source packages, RPMs and Windows binaries. To test Inkscape we started off by creating basic basic shapes using Inkscape's rectangle and ellipse tools and fiddling with color fills, stroke styles, rotation and so forth just to get a feel for Inkscape's tools. It took about fifteen minutes for this writer to get comfortable with the Inkscape interface. With an application like Inkscape, using a mouse (or tablet) is almost unavoidable. However, Inkscape's shortcut keys allow the user to perform a lot of actions, such as selecting different tools or raising and lowering an object from one layer to another, from the keyboard -- rather than having to grab the mouse to switch between tools or adjust layers. For example, to toggle the current tool from Inkscape's path tool to the select tool, all that's necessary is to hit the space bar or F1. To move an object up one layer, simply hit "Page Up" or "Page Down" to move it lower. Speaking of layers, layer management is one of the major new features in Inkscape with the 0.40 release, according to the release notes. Another new feature in 0.40 is a "text-on-path" feature. This allows the user to conform text to a path -- which is useful for creating interesting logos and other artwork that requires text to wrap text to a shape other than a rectangle. The feature is certainly easy to use. All that's required is to select a path and the text object that is to conform to the path. Rectangles, ellipses and other objects must be converted to a path before the user can wrap text to fit that object. By manipulating that object, the user can change the flow of the text even if the text has been removed from the object or if the object is "invisible" because there is no fill color or stroke color associated with the object. The only thing we couldn't figure out was how to specify a starting point on a path for the text. We also enjoyed Inkscape's "Trace Bitmap" feature, which allows the user to trace an imported bitmap. By importing a photo or other bitmap, it's possible to create an scalable object that can then be turned into paths or otherwise edited in Inkscape. Inkscape has incorporated the potrace utility for this. The trace bitmap feature works best with line art, but can be used to produce some fun effects with photos or other artwork. Inkscape's performance and stability are excellent. We created a number of documents using Inkscape, exported our documents and some of the Inkscape tutorials to PNG, EPS and PS, and didn't see any glitches. The program never crashed while we were testing, and all of the features that are currently in Inkscape seem to work as advertised. We did noticed that some detail was lost when exporting to EPS from the tutorials, but this may not be an Inkscape limitation. Though Inkscape doesn't have a full user manual at this stage, it does include several useful tutorials for basic and advanced concepts when working with Inkscape, as well as an excellent man page. It also features an "Elements of Design" document, which may be useful for users who lack a background in art and design. The Inkscape interface also features context help for most tools as well as context-sensitive tips in the bottom status bar. For the most part, this writer found the interface to be straightforward and intuitive. The "Vacuum Defs" item under the File menu was a bit of a puzzler at first, though it was finally determined that it was for removing unused information from the defs tags in a document. We presume this is a good thing. Some of Inkscape's functions can be used without even needing to start the Inkscape GUI. For example, inkscape file.svg -e file.png will convert an SVG file to a PNG. This can be particularly useful for users who wish to convert a number of SVG files into PNG format. SVG experts can edit an SVG document directly, if they so choose, by using Inkscape's built-in XML editor. Very few users will be likely to need this tool, but it's there for those who need or want to edit a document's elements directly. Inkscape may not be at the same level of functionality as Adobe Illustrator or Corel Draw, but it's certainly capable of creating some excellent graphics -- even if this writer isn't quite up to the task of fully exploiting its potential. With other open source applications like The Gimp and Scribus, Linux is a serious contender for users who are looking for a desktop publishing platform.

10 38

Extensions stuff
by Ted Gould 19 Dec '04

19 Dec '04

Hey all, First, I'll apologize for my disappearing -- I've been crazy busy, but I hope that it will start to be getting better. I've not read through most of the Inkscape lists, and there seems to be some discussion on extensions, I'm going to try to hit everything I remember in one mega e-mail. -- It seems that there are problems loading the GIMP gradient plugin. Who is getting those? Is there a consistent set? Is this related to people who are/aren't compiling in the bin relocate code? I'm sure the extensions stuff isn't thread safe. This worries me, as I'd like to move alot more functionality into being plugins in the near future. -- There seemed to be a few "where are extensions going?" type of e-mails. I guess my 'grand goal' is to have them pretty much everywhere, but in the short term I'd like to get functionality similar to GIMP's filters working. This would involve having a menu item which would cause modifications to the document based on some plugable functionality. I hope this can be done with scripts and plugins, and made to 'just work' for every user of Inkscape. This goal may seem overly ambitious, but there is tons of the infrastructure already in place. Some solid documentation has been started on this by Bryce. Find it here: (it also explains the terminology that we've been using) http://cvs.sourceforge.net/viewcvs.py/inkscape/inkscape/doc/extension_syste… -- Extensions dialog -- I think that this is a really good idea. I'd like to be able to load and unload the extensions from a dialog -- for testing also. If someone could mock up the dialog and take care of all "the GUI stuff" I'd be happy to help with the tying it into the rest of the system part of it. Otherwise, this has lower priority for me to getting effects working happily. One thing that I'd like to see in this dialog is a place to put a textual "Why this extension didn't load" so we can explain missing dependencies to users somewhere. -- API for extensions, this is still in flux. But, it is something that needs to be figured out. I know at one point we'd discussed using the SVG DOM from the W3C. I don't know how that would work out, or how difficult it would be. Bryce and I outlined some general functions that would be needed for "Command and Control" in the document above, but those ideas are definitely not fleshed out. -- Now that we're XSLTized -- should we be adding that as an extension type? I could see it working for input/output extensions, perhaps as effects also? Okay, that is all I can remember right now... tell me more, I should be more responsive now! --Ted PS -- If anyone is looking for "bite-sized" extensions task to do over winter break or something similar, ask, I think that I have a few.

4 5

layer display
by bulia byak 18 Dec '04

18 Dec '04

When you enter a group, the layer selector in the statusbar shows only the ancestors of the group, while regular layers that are siblings of the parent layer disappear. Is there a reason for this? I would much prefer it to always show siblings of each ancestor layer. Without this, to go to the layer above, I have to use the widget twice: once to go up from the group and then again go to the layer above.

2 3

Re: [Inkscape-devel] Re: [Inkscape-user] RPM build errors
by Ted Gould 17 Dec '04

17 Dec '04

On Mon, 2004-12-06 at 16:07 +0000, Jonathan Leighton [Turnip] wrote: > #7 0x0828ab18 in Inkscape::Extension::Dependency::check () > #8 0x082890e8 in Inkscape::Extension::Extension::check () > #9 0x0828c50f in Inkscape::Extension::Input::check () > #10 0x0828b0f9 in Inkscape::Extension::Dependency::check () > #11 0x08289e69 in Inkscape::Extension::DB::foreach () > #12 0x0828b20e in Inkscape::Extension::init () > #13 0x080c53b2 in sp_main_gui () > #14 0x080c55ae in main () Hmm, I can't find anywhere that Inkscape::Extension::Dependency::check calls Inkscape::Extension::Extension::check() (and thus, Inkscape::Extension::Input::check()). Can someone look at src/extension/dependency.cpp just to make sure I'm not insane? Anyone have any other ideas? --Ted

7 14

[Fwd: [cairo] 10000% performance increase for clip surfaces]
by Bob Jamison 17 Dec '04

17 Dec '04

Hi, all. Saw this today on the Cairo list. I don't know if the patch is valid, but it seems to improve performance for me on Cairo, too. Open Source at work. BOb

1 0

script for embedding raster images
by Ben Crowell 17 Dec '04

17 Dec '04

The following patch to sp-image.cpp allows Inkscape to read Adobe Illustrator files that have the "data:;base64" syntax for embedded images. The embedded images are displayed correctly on the screen. However, if you save the file, the resulting svg output still has "data:;base64", which is obviously a Bad Thing. I started looking around in the code for where the output happens, but C++ isn't a language I'm very comfortable with, and I rapidly got lost. I'd be grateful for any insight from anyone who understands the code and the language better. I'd prefer not to commit the patch for the input without making the output standards-compliant. ===================== patch to sp-image.cpp ======================= 902a903,913 > // bcrowell, 2004 dec 13: > // Adobe Illustrator writes output like this: > // data:;base64, > // This is illegal according to the SVG standard, but there seems to be a consensus > // on inkscape-devel that Inkscape should allow input like this anyway. It would > // be nice to do a better syntax check here, but Lauris Kaplinski's old-school C parser > // is already pretty complicated; probably we should be using a C++ regular expression > // library instead. The following line allows input of lame Illustrator SVG: > data_is_image = 1; > // However, the output isn't any more correct than the input. >

5 5