- Inkscape Devel - Inkscape Mailman

OS X build
by MenTaLguY 01 Jun '05

01 Jun '05

Just as a matter of interest, I now have CVS building on a 10.3 machine with fink unstable. The only dependency that wasn't in fink was libgc; I downloaded and installed 6.5 the old-fashioned way and it worked fine. Note that (when building using fink libraries) you will need to specify -I/sw/include and -L/sw/lib in your CXXFLAGS and LDFLAGS when running configure. -mental

4 3

RE: [Inkscape-devel] sp_document_new
by De Winne, Joris 01 Jun '05

01 Jun '05

Hello, This is the backtrace I get from gdb Starting program: /users/software/jdewinne/sandboxes/iStudioNG/src/svgViewer [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 2355)] [New Thread 32769 (LWP 2356)] [New Thread 16386 (LWP 2357)] [New Thread 32771 (LWP 2358)] Start rendering Trying to receive Created new window Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16386 (LWP 2357)] 0x4007f713 in GC_mark_from () from /usr/lib/libgc.so.1 Joris On Tue, 2005-05-31 at 11:59, De Winne, Joris wrote: > Hello, > > I'm trying to create a viewer based on the inkscape SVG viewer. I > based my viewer on the code in inkview.cpp. But during execution I > always get a segmentation fault when I call sp_document_new. Can you get a backtrace from gdb? It would help to know where the segmentation fault is happening. -mental - - - - - - - DISCLAIMER - - - - - - - - Unless indicated otherwise, the information contained in this message is privileged and confidential, and is intended only for the use of the addressee(s) named above and others who have been specifically authorized to receive it. If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this message and/or attachments is strictly prohibited. The company accepts no liability for any damage caused by any virus transmitted by this email. Furthermore, the company does not warrant a proper and complete transmission of this information, nor does it accept liability for any delays. If you have received this message in error, please contact the sender and delete the message. Thank you.

1 0

Building inkscape under cygwin.
by Franz Haeuslschmid 30 May '05

30 May '05

Hello, I'm lately trying to compile inkscape using the latest edition of cygwin. However the build process is permanently aborting: make all-recursive make[1]: Entering directory `/cygdrive/d/Src/inkscape' Making all in src make[2]: Entering directory `/cygdrive/d/Src/inkscape/src' depbase=`echo object-edit.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`; \ if g++ -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/include/freetype2 -I/usr/X11R6/include -I/usr/include/freetype2 -I/opt/cxclient/usr/X11R6/include -DPOTRACE=\"potrace\" -DXTHREADS -DXUSE_MTSAFE_API -I/home/haeuslsc/local/include/gdkmm-2.4 -I/home/haeuslsc/local/lib/gdkmm-2.4/include -I/home/haeuslsc/local/include/glibmm-2.4 -I/home/haeuslsc/local/lib/glibmm-2.4/include -I/home/haeuslsc/local/include/pangomm-1.4 -I/home/haeuslsc/local/include/gtk-2.0 -I/home/haeuslsc/local/lib/gtk-2.0/include -I/usr/X11R6/include -I/home/haeuslsc/local/include/sigc++-2.0 -I/home/haeuslsc/local/lib/sigc++-2.0/include -I/home/haeuslsc/local/include/glib-2.0 -I/home/haeuslsc/local/lib/glib-2.0/include -I/home/haeuslsc/local/include/pango-1.0 -I/usr/include/freetype2 -I/opt/cxclient/usr/X11R6/include -I/home/haeuslsc/local/include/gtkmm-2.4 -I/home/haeuslsc/local/lib/gtkmm-2.4/include -I/home/haeuslsc/local/include/atkmm-1.6 -I/home/haeuslsc/local/include/atk-1.0 -I/usr/include/libxml2 -I../cxxtest -Wall -W -Wpointer-arith -Wcast-align -Wsign-compare -Woverloaded-virtual -Wswitch -Wno-unused-parameter -g -O2 -MT object-edit.o -MD -MP -MF "$depbase.Tpo" -c -o object-edit.o object-edit.cpp; \ then mv -f "$depbase.Tpo" "$depbase.Po"; else rm -f "$depbase.Tpo"; exit 1; fi object-edit.cpp: In function `void sp_spiral_outer_set(SPItem*, const NR::Point&, const NR::Point&, unsigned int)': object-edit.cpp:846: error: `isfinite' undeclared in namespace `std' make[2]: *** [object-edit.o] Error 1 make[2]: Leaving directory `/cygdrive/d/Src/inkscape/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/cygdrive/d/Src/inkscape' make: *** [all] Error 2 Any ideas? Franz.

3 4

Re: [Fontforge-devel] Bug report: space size
by unknown＠example.com 30 May '05

30 May '05

On 5/27/05, Ralf Stubner <ralf.stubner@...128...> wrote: > That looks ok in principle. The space character has a width of 377 > units. The two lines with '74 304 rmoveto' and 'closepath' look strange > and are unnecessary, but I would be surprised if they cause any harm. > You can test this though by removing these two lines and assembling the > font again with t1asm. I added for tests a point to the space character, to see if it helps with the problem. These two lines probably describe that point. > > Another wierd possibility is encoding. Maybe space is not encoded or in > an unsual position in your font, and the application you are using uses > code positions instead of glyphnames. So look out for /Encoding near the > begining of the disassembled file. What does it say there? /Encoding 256 array > > If those ideas don't help, then i am lost. Can you make the font in > question available so that others can have a look at it? > I made a new test font with the space, exported it as pfa and this time it worked. So I exported the original font again in pfa and, as previously, the space width was zero. So the program is able to generate pfa with non--zero space width, but for some reason either it can not do it for a particular font, or the font system does not interpret the particular font file correctly. So I send the original PFA: http://www.iitis.gliwice.pl/~arataj/test.pfa Thanks, Artur

1 0

filter for inkscape and OpenDocument
by Jon Phillips 28 May '05

28 May '05

Heya, I just read your nice interview at groklaw (http://www.groklaw.net/article.php?story=20050130002908154). First of all, this is really exciting, but I wonder if you could write up more about what is needed of Inkscape for this new format. I see in your interview you note that there is a needed filter for Inkscape, but it is not clarified what this means. I'm cc'ing the Inkscape development list about this. I just wonder how this OpenDocument format (the newly standardized open office xml format) relates to Inkscape and what you are asking to be done. Or do you want a filter that say one has an SVG file, then one can convert that to an OpenDocument file. I don't think that would be difficult. But, what about OpenOffice support for the SVG file format? Please copy me and/or the Inkscape-devel list and I will make sure they get the response. Or, please reply to me and the list if you are on Inkscape's list. Thanks, Jon -- Jon Phillips USA PH 510.499.0894 jon@...235... http://www.rejon.org Inkscape (http://inkscape.org) Open Clip Art Library (www.openclipart.org) CVS Book (http://cvsbook.ucsd.edu) Scale Journal (http://scale.ucsd.edu)

7 31

Re: [Inkscape-user] Re: Nuevos Traducciones de Tutoriales/New Tutorials Translations
by unknown＠example.com 26 May '05

26 May '05

Quoting "R. Alan Monroe" <amonroe@...813...>: > Since it's vector art, couldn't you just put any additional > language texts in the svg file as a tiny micro-paragraph beside > the normal text? You could just zoom in to the alternative texts > or stretch them to read them. I don't think that would really be helpful, but it is an interesting idea. A similar approach would be to put all language texts in the same document (overlaying one another) and use the SVG <switch> element so that only the one matching the current language gets rendered. I'm not sure how well that would work, though, since different languages will have different paragraph lengths and to look nice might require the documents to be relaid-out depending on language (which <switch> can't do). Admittedly, we don't support the <switch> element yet, but it is planned. -mental

1 0

dialogs cleanup
by bulia byak 26 May '05

26 May '05

Before we can think about a release, one thing we absolutely must do is clean up the current mess with dialogs. Everyone who did dialogs recently (and there were a lot) did it in their own incompatible way. (Personally, I attribute this to the lack of attention and leadership from the initiators of the gtkmm transition, but there's no use to argue about that now; let's just fix what we have.) Recently I've been working on the Dialog and DialogManager classes in ui/dialog, and I almost fixed them with regard to things like transientizing, remembering geometry, and F12 behavior. There are remaining issues still but I'm pretty sure I'll be able to fix them. Unfortunately, many dialogs do not use these classes or use them in a wrong way. The old gtk dialogs need not be touched at this time; they are OK as they are, and we can always convert them later. What needs to be fixed urgently is the recenty added gtkmm dialogs, all of which are broken in different ways. The simplest dialog to use as a template is ui/dialog/messages.cpp; another is ui/dialog/memory.cpp. To create a dialog, you need to pass the prefs path (path in the preferences.xml for the dialog settings; make sure it exists in preferences-skeleton.h) and the verb that creates the dialog (make sure it exists in verbs.h/cpp). E.g.: Messages::Messages() : Dialog ("dialogs.messages", SP_VERB_DIALOG_DEBUG) You also need to register the dialog's factory in DIalogManager constructor and to make sure its verb in verbs.cpp does the right thing: case SP_VERB_DIALOG_DEBUG: dt->_dlg_mgr->showDialog("Messages"); break; Also don't forget to remove your own F12 handlers, event handles, transientizing code, title setting, size setting etc. if you have it in your dialog classes. This is all in Dialog now. Not only will this stuff finally work as it must, but this will lead to a significant reducing of code. Here are the dialogs that need to be converted: Align: Unless Aubanel Monnier (who coded it initially) shows up, I think I'll have to take this one. View/Scripts and Path/Trace Bitmap: Bob, these are yours, so please take them. This needs to be done ASAP because currently these two are totally disfunctional - they don't show up when you call them. (This may be because they used ui/dialog code in some partial way and this is now broken after my changes there.) Object/Grid Arrange: John, this one is yours, please convert it - also ASAP because it's broken in the same way as Bob's ones. Object/Swatches and Help/About Extensions: Jon, these are yours. I know you did your own implementation but we now need to unify things. You can move whatever useful code you have into Dialog, but _that_ must be the root class of all dialogs now. No more duplication please. This will also fix the many problems your dialogs now have (such as popping up after being closed when any new dialog is opened). Jon, Bob, John: Please respond to this message with your estimate as to when you will be able to work on this. If you cannot handle this now or in foreseeable future, we'll need to call up volunteers for this work. Of course, please also voice any questions or objections you might have. Oh, and if anyone creates a new dialog now, please use ui/dialog/messages.cpp as a template. Don't copy from any other dialogs until they are fixed. -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

9 22

translatable strings
by Gazal, Geraud (GE Healthcare) 26 May '05

26 May '05

As you may know, Inkscape strings are facing a small problem : at the moment, the string _"H" is used in different contexts: as an abbreviation for Hue and for Height (see my clumsy patch proposal : http://sourceforge.net/tracker/index.php?func=detail&aid=1203796&group_id=9…) After taking a look at different mailing list and at Inkscape's wiki, it appears that the wiki links offers some good indications (cool). See http://www.gtkmm.org/gtkmm2/docs/tutorial/html/ch20s03.html in "Same strings, different semantics" But the solution suggested (adding some extra characters) is not really welcome. A much better approach can be foud here : http://developer.gnome.org/doc/tutorials/gnome-i18n/developer.html in "Don't use too short messages". So if you are OK with it, I'd be very interested at: - first improve the current state with short strings (XYWH, RGB, RGBA, HSV...): my plan would be creating some xywh_string = _"XYWH", rgb_string = _"RGB"... strings that would be translatable and then pick from those strings in the code replace H by xywh_string[4] or hsv_string[3] depending on the context - then improve our conformance against gnome HIG with : - increase the use of plural syntax (see "Plurals" in gnome-i18n) - improve the way Inkscape manages marked up string (see "Avoid markup wherever possible" in gnome-i18n) It would be a good opportunity for me improving my understanding of the code of Inkscape without the hazard of breaking everything. Regards, Matiphas

1 0

Re: [Inkscape-user] Re: Nuevos Traducciones de Tutoriales/New Tutorials Translations
by bulia byak 26 May '05

26 May '05

Spanish translators suggest that we include the html/png versions of all tutorials into the Inkscape distribution as well. What do others think? I'm afraid this will blow the size considerably, especially if we include all languages (as we do for SVG tutorials). Maybe it's time to create language-specific distributions, at least for French and Spanish? Does anyone have experience with automating such things? On 5/25/05, jeffrey steve borbon sanabria <jeff_kerokid@...36...> wrote: > yes Bulia We want that- this translations would be > able to access in the inkscape application. Can you > include it on InkScape? > > "Por la libertad del hombre pensante, usemos software libre" > > > > > _________________________________________________________ > Do You Yahoo!? > Información de Estados Unidos y América Latina, en Yahoo! Noticias. > Visítanos en http://noticias.espanol.yahoo.com > > > ------------------------------------------------------- > SF.Net email is sponsored by: GoToMeeting - the easiest way to collaborate > online with coworkers and clients while avoiding the high cost of travel and > communications. There is no equipment to buy and you can meet as often as > you want. Try it free.http://ads.osdn.com/?ad_id=7402&alloc_id=16135&op=click > _______________________________________________ > Inkscape-user mailing list > Inkscape-user(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/inkscape-user > -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

3 3

Path Parsing
by unknown＠example.com 24 May '05

24 May '05

Bulia, this morning there was another path parsing bug in the tracker and so there is another patch. I have a path parsing question that I do not think is answered by the svg spec. All commands may be followed by any number of sets of parameters. So L0,0 3,4 7,2 is actually L0,0 L3,4 L7,2 Moveto implies Lineto. So M0,0 3,4 7,2 is actually M0,0 L3,4 L7,2 How should one interpret this: L0,0 L3,4 L7,2 Z 1,5 It would seem to me that it should be L0,0 L3,4 L7,2 Z M0,0 L1,5 Because Moveto implies Lineto and Closepath should imply Moveto because the spec says that any following commands begin a new subpath at the previous subpaths initial point. Answers? Aaron Spike

6 25