January 2009 - Inkscape Devel

Error "Too many heap sections" on Windows
by unknown＠example.com 15 Jan '09

15 Jan '09

Hello, I encounter serious problems running inkscape with larger files, or using inkscape to build OpenStreetMap binaries. When the files become to large, I get the error message "Too many heap sections" and inkscape exits. There is a way to fix this, I found this: http://osdir.com/ml/programming.garbage-collection.boehmgc/2006-01/msg00006… And there is already a bug against inkscape: https://bugs.launchpad.net/inkscape/+bug/168914 Now I wanted to compile my own binary on windows, using the instructions in the Wiki. But the (usually helpful) devlibs already contain libgc.a, and I found no docs how to create this file :( I wanted to create libgc with the LARGE_CONFIG parameter in the makefile, and then build inkscape with this new libgc to check if the problem is gone ... Can anyone help me to do this, or point me to the appropriate docs? Thanks in advance! bbackde -- __________________________________________________ GnuPG key: (0x48DBFA8A) Keyserver: pgpkeys.pca.dfn.de Fingerprint: 477D F057 1BD4 1AE7 8A54 8679 6690 E2EC 48DB FA8A __________________________________________________

2 4

potracelib.cpp breaking svn since r20512(?)
by Bernard Gray 15 Jan '09

15 Jan '09

Hi Folks, I'm trying to build inkscape on debian(sid) from the svn trunk - it fails with the error detailed below[1]: The last time that potracelib.cpp was touched was r20512: Revision: 20512 http://inkscape.svn.sourceforge.net/inkscape/?rev=20512&view=rev Author: tweenk Date: 2009-01-13 02:27:04 +0000 (Tue, 13 Jan 2009) Log Message: ----------- Improved version reporting. Add SVN revision and custom status to version string on Linux. ... inkscape/trunk/src/trace/potrace/potracelib.cpp ... That was over 2 days ago now, so I'm assuming others will be having the same issue - Am I missing something obvious wrong with my build process or is it broken? Regards, Bernie (cleary) [1]: 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 -g -O2 -fopenmp -MT trace/potrace/greymap.o -MD -MP -MF $depbase.Tpo -c -o trace/potrace/greymap.o trace/potrace/greymap.cpp &&\ mv -f $depbase.Tpo $depbase.Po depbase=`echo trace/potrace/potracelib.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\ g++ -DHAVE_CONFIG_H -I. -I.. -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/libwpg-0.1 -I/usr/include/libwpd-0.8 -I/usr/include/poppler -D_REENTRANT -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/directfb -I/usr/include/libpng12 -I/usr/include/pixman-1 -DPOTRACE=\"potrace\" -D_REENTRANT -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/directfb -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 -g -O2 -fopenmp -MT trace/potrace/potracelib.o -MD -MP -MF $depbase.Tpo -c -o trace/potrace/potracelib.o trace/potrace/potracelib.cpp &&\ mv -f $depbase.Tpo $depbase.Po trace/potrace/potracelib.cpp: In function 'char* potrace_version()': trace/potrace/potracelib.cpp:114: error: 'g_strdup_printf' was not declared in this scope make[2]: *** [trace/potrace/potracelib.o] Error 1 make[2]: Leaving directory `/media/store/tmp/inkscape-0.46+svn20090115-cle.2/src'

2 2

Re: [Inkscape-devel] CMYK Proposal
by Guillermo Espertino 15 Jan '09

15 Jan '09

> * I think that we should remove the CMS tab from fill&stroke dialog. > Color profiles should be selected globaly for the whole document. > * Then, I think that we should display the palletes and the color > pickers with colors transformed by the currently selected profile. I made these mockups some time ago (sorry the spanglish :) http://www.ohweb.com.ar/screenshots/Inkscape My idea was to define the profiles and rendering intents for soft proofing in a per document basis. When I showed JonCruz the mockups, he explained to me that each graphic element in an SVG document can have its own profile, and gave me some reasons of why that dialog was better (which I didn't understand very well at the time and I can't remember now). I don't know any possible scenario where one could need different profiles in the same document, but I guess there is one (I'd really appreciate if someone explains it). When I worked with proprietary packages I only needed an RGB and CMYK profile for the document, and conversion between RGB and CMYK where performed considering those profiles. Maybe I'm missing some other usage cases that may need another combination. Gez

6 7

Extension system
by Krzysztof Kosiński 15 Jan '09

15 Jan '09

Migrating to GIO for file handling means modifying the extension system rather extensively, so I think it might be worth refactoring it as well, keeping compatibility with existing extensions. Currently there is a class for every type of extension, but they don't define much - everything of substance is handled by the "implementation" class which contains methods for everything. A subclass of it is mandatory for every extension. I understand the reason for this was to support XSLT and script extensions transparently, but I don't think this is the proper way to do it. Since each extension only provides one function (either an effect, or an input filter, etc. but not more than one of those types at a time) the proper inheritance would be e.g.: Extension -> Output -> XsltOutput Extension -> Effect -> ScriptEffect Extension -> Input -> SvgzInput If there are common methods among XSLT or scripted extensions, those could be put in a separate class from which all other extensions implemented in this way derive (multiple inheritance). This wouldn't preclude putting more than one function/effect in the .inx file, since more than one object could be created for a given .inx file by the manager. There should also be a proper manager object, instead of some things being done via Extension::DB (which BTW is not a singleton but a statically constructed object) and some via global functions. GIO would be used in input and output extensions - parameters to save() and load() would be GInputStreams or GOutputStreams instead of filenames. This way extensions could save to memory and to remote locations without any special handling in the extensions themselves. Do you have any other ideas for improvements or changes? Regards, Krzysztof Kosiński -- View this message in context: http://www.nabble.com/Extension-system-tp21448270p21448270.html Sent from the Inkscape - Dev mailing list archive at Nabble.com.

2 4

spiro mode in freehand tool
by Thomas Holder 14 Jan '09

14 Jan '09

Hi, spiro mode in freehand pen tool does not make sense. I'd suggest to remove the button. Even for bezier tool the spiro mode is not that useful, as you don't see the spiro while drawing (which would be nice indeed). But since you still draw beziers and spiro just gets applied _after_ path finishing, you could likewise apply it via the path effects dialog. Thomas

4 4

CMYK Proposal
by Felipe Sanches 14 Jan '09

14 Jan '09

* I think that we should remove the CMS tab from fill&stroke dialog. Color profiles should be selected globaly for the whole document. * Then, I think that we should display the palletes and the color pickers with colors transformed by the currently selected profile. Comments, please. Juca

2 1

Re: [Inkscape-devel] Tango Icon Theme - Renewed - ALL ICONS MADE (I hope!)
by Guillermo Espertino 14 Jan '09

14 Jan '09

JonCruz wrote: > This does seem to match the behavior of one bug I'm working through. And after that is it finally possible that the Tango set will be the default icon set? The new Tango set needs a couple of minor bug fixes, but it looks pretty finished to me. I'm already using it, and I'd love to have it as default for 0.47 These icons look very professional and polished. The current set is ok, but it really doesn't honor the quality of Inkscape as the awesome program it is. I think a lot of people overlooks Inkscape because its look. Besides, the default icon sets in Scribus and Gimp are already Tango, so unifying them would be a nice step towards the idea of a truly free-software design workflow. Kudos to Jesusda and the Michael Grosberg for the excellent work in this theme. Gez

2 1

Tango Icon Theme - Renewed
by jEsuSdA 8) 14 Jan '09

14 Jan '09

Hello! I'm working hard to complete and bug-free the tango icon theme for Inkscape. Some bugs are solved, new icons are added and some old icons are retouched. Now I'm working to finish it, but some bugs are depending to the way the icons are show on toolbars and may be solved. ;) Please, report me the bugs and ideas you have to this work. Thanks! ;) INKSCAPE TANGO ICON THEME: http://jesusda.com/files/inkscape-tango-theme/ Salu2 de jEsuSdA 8)

10 22

Disable the snapping toolbar
by Krzysztof Kosiński 14 Jan '09

14 Jan '09

I never use snapping, and this toolbar takes up lots of space (which I have in very short supply on a 1024x768 display)! Please add a way to turn it off ASAP. I haven't noticed any in the preferences. It would be best if right-clicking it brought up an option to disable the toolbar. Regards, Krzysztof Kosiński. -- View this message in context: http://www.nabble.com/Disable-the-snapping-toolbar-tp21446041p21446041.html Sent from the Inkscape - Dev mailing list archive at Nabble.com.

2 2

Inkscape dll imports
by Jasper van de Gronde 13 Jan '09

13 Jan '09

I've had a quick look at Inkscape's dll imports using dependency viewer, and it looks like it imports libpoppler3 about a dozen times or so... Any idea why it behaves like this? It might not directly give problems, but it seems a bit odd nonetheless.

2 1