- Inkscape Devel - Inkscape Mailman

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