- Inkscape Devel - Inkscape Mailman

Inkscape BOF @ Siggraph LOS ANGELES - MON, AUG 9, 4-5 PM
by Jon Phillips 06 Aug '04

06 Aug '04

*PLEASE FORWARD* Inkscape: An Open Source Vector Graphics (SVG) Editor Overview Birds of a Feather Meeting in Co-operation with Siggraph 04 at the Los Angeles Convention Center http://www.siggraph.org/s2004/conference/birds/index.php?pageID=conference Monday, 9 August 4 - 5 pm Holiday Inn City Center Santa Monica Room Jon Phillips + Jon Cruz ### Inkscape: Draw Freely. (http://www.inkscape.org/) Inkscape is an open source SVG editor with capabilities similar to Illustrator, CorelDraw, Visio, etc. Supported SVG features include basic shapes, paths, text, alpha blending, transforms, gradients, node editing, svg-to-png export, grouping, and more. Inkscape's main motivation is to provide a fully XML, SVG, and CSS2 compliant SVG drawing tool. Additional planned work includes conversion of the codebase from C/Gtk to C++/Gtkmm, emphasizing a lightweight core with powerful features added through an extension mechanism, and establishment of a friendly, open, community-oriented development processes. The specific emphasis of this talk will be for intermingling between attendees and to allow for suggestions and discussions about where Inkscape is heading...draw freely! -- Jon Phillips USA.PH.858.361.2811 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/)

1 0

Inkscape BOF @ Siggraph LOS ANGELES - MON, AUG 9, 4-5 PM
by Jon Phillips 06 Aug '04

06 Aug '04

*PLEASE FORWARD* Inkscape: An Open Source Vector Graphics (SVG) Editor Overview Birds of a Feather Meeting in Co-operation with Siggraph 04 at the Los Angeles Convention Center http://www.siggraph.org/s2004/conference/birds/index.php?pageID=conference Monday, 9 August 4 - 5 pm Holiday Inn City Center Santa Monica Room Jon Phillips + Jon Cruz ### Inkscape: Draw Freely. (http://www.inkscape.org/) Inkscape is an open source SVG editor with capabilities similar to Illustrator, CorelDraw, Visio, etc. Supported SVG features include basic shapes, paths, text, alpha blending, transforms, gradients, node editing, svg-to-png export, grouping, and more. Inkscape's main motivation is to provide a fully XML, SVG, and CSS2 compliant SVG drawing tool. Additional planned work includes conversion of the codebase from C/Gtk to C++/Gtkmm, emphasizing a lightweight core with powerful features added through an extension mechanism, and establishment of a friendly, open, community-oriented development processes. The specific emphasis of this talk will be for intermingling between attendees and to allow for suggestions and discussions about where Inkscape is heading...draw freely! -- Jon Phillips USA.PH.858.361.2811 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/)

1 0

Glib::ustring
by Bob Jamison 05 Aug '04

05 Aug '04

With my short education into Gtkmm recently, I have become acquainted with the Glib::ustring class. It is a clone of the std::string class, with the addition of supporting unicode in utf8 format. This sounds like it might be a nice replacement for our many g_blah_blah_utf8() calls, and also a nice storage for our internal strings. Anyone have any thoughts? Maybe Jon could look at it to see if it is sufficient/valid. Just wondering.... (I'm sitting in a boring meeting right now ;-) Bob

3 2

Re: spalah + inkscape?
by bulia byak 04 Aug '04

04 Aug '04

I'm cc'ing my reply to inkscape-devel, where more people will be able to comment. On Sun, 25 Jul 2004 20:30:52 +0300, Anatoly Podlesnuk <beerubeer@...466...> wrote: > Hi > > It's good idea to join spalah and inkscape. > > There is some questions. > > 1. I'm not use in spalah "items tree" of SVG nodes from sodipodi. Spalah > items tree is much simple. So I will need some help with inkscape items > tree. We haven't yet departed too far from Sodipodi's system of SPObjects tree and repr tree that are synced periodically, though we did a lot of incremental changes to it (mostly in the direction C++fying it). I don't think anything simpler than that will actually work for interactive SVG editing. Of course we will be glad to help you with it. > 2. Spalah uses ming library (ming.sourceforge.net) for flash generation, > so inkscape will require this library. No problem. SWF export is a good thing to have, even if for static SVGs at first. > 3. What is role spalah code in inkscape? It will a part of ExportDialog > or inkscape will able to add animation to SVG objects? As I know > inkscape does not support some SVG nodes that responses for animation. Our goal is to be a complete SVG editor, and that includes animation. So we'll need to add support for all the corresponding elements and attributes. As for the UI, what I had in mind is a timeline control selecting one of the frames for editing, plus a separate preview window (based on inkview?) with actual animation. Of course, at this stage all this requires lots of thinking, planning, and experimenting. > 4. What about release planning, code formatting, > classes/functions/variables names? I guess the main development principle is that CVS must always remain compilable and workable, without bad regressions. Releases are done when there's enough stuff for a new release, usually every 2 to 3 months. There's a period of code freeze and bug hunt before a release, but at other times you're free to work on your stuff. For coding style, we have a few guidelines here: http://inkscape.sourceforge.net/doc/coding_style.php Let me know what you think.

5 9

new open dialog
by bulia byak 04 Aug '04

04 Aug '04

First off, I wanted to say thank you to Bob for this work. The preview on open is fabulous! It gives a whole new perspective on my files. A very important addition. Still there are problems. I know some of them may not be fixable due to GTK limitations, but still. 1 The dialog is modal but not transient. It's a very dangerous combination: it sinks under your document and you can't understand why the document is unresponsive. Please make it transient as it was before. 2 The dialog opens in some unpredictable place on the screen. Before, it opened centered over the document window. Can we restore that? (Maybe it's a consequence of its not being transient.) 3 BUG: when I press Ctrl+O for the first time, there are no files listed at all in the directory where it opens, only subdirectories. If I go e.g. to the parent dir and then back, the files appear. 4 After some thinking I'm convinced that (as suggested here) we must replace the "Autodetect" with two new options, "All images" and "All files". That makes much more sense and is more consistent with typical Windows/Mac programs. Both these options would do autodetect and differ in filtering the list: no filtering for "All files" and showing only Inkscape-supported images for "All images". The bad thing about "Autodetect" is that it speaks about what the program does, not about what the user needs. Autodetect is not something I ever want to be off; it must always work behind the scenes. What I want to control is what files are shown and what not, and this is what this menu must affect. 5 The menu should be reordered more logically so that the most frequently used options are at the top: All images <-- default All files SVG Compressed SVG ---------- (separator) AI EPS PS Dia Sketch WMF text rest of bitmap formats... 6 Also it would be nice to group the same formats with different extensions as proposed here: https://sourceforge.net/tracker/index.php?func=detail&aid=990674&group_id=9… 7 If I want to go e.g. to /home/me/inkscape and browse files here, I go to the filename field, type "/home/me/inkscape" and press Enter. Nothing happens. In other programs (and I believe in Inkscape with the old dialog) this caused the dialog to switch to that dir. 8 I get these warnings whenever I open it for the first time: (inkscape:7505): Gtk-WARNING **: Could not find the icon 'gnome-fs-home'. The 'hicolor' theme was not found either, perhaps you need to install it. You can get a copy from: http://freedesktop.org/Software/icon-theme/releases (inkscape:7505): Gtk-CRITICAL **: file gtksettings.c: line 447 (gtk_settings_get_for_screen): assertion `GDK_IS_SCREEN (screen)' failed (inkscape:7505): GLib-GObject-WARNING **: invalid (NULL) pointer instance (inkscape:7505): GLib-GObject-CRITICAL **: file gsignal.c: line 1726 (g_signal_handler_disconnect): assertion `G_TYPE_CHECK_INSTANCE (instance)' failed I installed http://freedesktop.org/Software/icon-theme/releases/hicolor-icon-theme-0.5.… but this did not help. Any ideas? Preview: 9 There's no way to turn the previews off. 10 The open/close dance of the preview pane as you go through image/non-image files is a bit disconcerting. Can't we always have the preview widget on (that is, unless you turn it off, see 8), even if inactive for the current file, with the same unchanging size? 11 Bob, you mentioned that you did preview for the bitmap files as well, but this does not work for me, only SVGs. That's it for now, perhaps I'll find more when I test it more thoroughly.

5 13

Adobe Illustrator 7/10, Photoshop CS and Postscript (probably eps)
by Tuukka Pasanen 04 Aug '04

04 Aug '04

hi, A long story short. AI7 files aren't in PDF format and AI10 uses PDF 1.4 as native saving format. I Have also heared that Photoshop CS uses PDF 1.4 as saving format. So i looked in pstoedit program and finded out (Author pointed out) there is GPL svg output plugin. So it would be neat to have this option in inkscape but is it too much to ask for http://www.gnu.org/software/plotutils/ and pstoedit be installed to have this input?? There is also one problem in SVG because it doesn't put fill:none in style inkscape just fills everything in black:P.. I still look how good plot-svg output is but seems good enouhg to me.. Then i just have to think how to find AI7 and AI10 in ill2svg.pl;) So should we use it or not? In Gnu/Linux and *BSD (*nix) world it's easy to install but windoze is biggest problem.. Tuukka.

3 4

convention for XML names
by MenTaLguY 04 Aug '04

04 Aug '04

Although it's not crucial, could we settle on using XML names that adhere to a specific convention? I'm a little worried that having: inkscape:one-thing inkscape:another_thing inkscape:YetAnotherThing as element/attribute names in the same SVG file, while permissible, looks unprofessional. I personally favor using lowercase words separated with dashes (-). -mental

4 3

[Fwd: Re: [gnome-core] gtkmm 2.4 + inkscape + YOU]
by Jon Phillips 03 Aug '04

03 Aug '04

bulia, et al. fyi...contact this person directly to encourage moving package to unstable and then stable fink... Jon -----Forwarded Message----- > From: Martin Costabel <costabel@...26...> > To: Jon Phillips <jon@...235...> > Cc: fink-gnome-core(a)lists.sourceforge.net > Subject: Re: [gnome-core] gtkmm 2.4 + inkscape + YOU > Date: Tue, 03 Aug 2004 12:20:08 +0200 > > Jon Phillips wrote: > [] > > I'm sending this to encourage the move up to gtkmm2 project's current > > stable version 2.4. > > There is a gtkmm24.info in > fink/experimental/gnome/2.6/main/finkinfo/gnome/ on CVS. Have you tried > it? It has been there since 2004/05/16. -- Jon Phillips PO BOX 948667 LA JOLLA, CA 92037 USA USA.PH.858.361.2811 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/)

1 0

Re: flowtext
by bulia byak 03 Aug '04

03 Aug '04

> - flowRegion makes flow-go.svg render "correctly" Actually from my reading of the spec, the old rendering was correct: each flowregion filled from top to bottom, even if it contains multiple shapes. > - fixed the lost word problem. note that you need to > put spaces at the beginning of a flowSpan (or the end > of the previous) otherwise the words at both ends will > be glued together Yes, that's reasonable > - a preliminary convert_to_text() verb is in sp-flowtext Excellent, I put it on Shift+Alt+W as "Unflow text", with the Alt+W reserved for "Flow text" (convert text + shape into a flowed text). There were a few problems: - compilation errors on char conversions again - fixed - the text style only worked if set on flowRoot, not flowDiv - fixed by adding SP_STYLE_FLAG_ALWAYS to sp_style_write_string (line 787), so that it writes the entire style of each chunk, including inherited style - space after flowSpan was lost - partially fixed by adding xml:space="preserve" to the created text, but the start positions of spans are still sometimes off (convert the attached one and watch the words "as well as" and "kinsoku" - they jump off a bit) Plus a few other small changes, so please take the files from CVS if you want to change something. I also thought about the best way to create flowed texts. I think using clones is indeed the best method, as it will let us avoid adding flowtext parsing code to a million places. So when you select a shape and a text, here's what happens: - the shape is cloned, clone placed exactly over the original - the clone gets inkscape:use-move="parallel" and inkscape:use-delete="unlink" attribs to ensure these behaviors regardless of user prefs (sp-use support required, but it's simple to add) - tspans with sodipodi:role="line" are merged together, separated by spaces - an empty tspan with sodipodi:role="line" (i.e. empty line) is converted into <flowLine/> - the flowRoot is constructed from the clone and the text thus prepared; original text is deleted The original shape thus remains and is editable as usual, and the text shape will be updated via the clone. This means the paths in "foreign" (non-Inkscape) flowed texts that do not use clones will not be editable at all, but this is OK (at least for now). This approach has the advantage of relative simplicity, and two more commands can be easily added based on the same mechanism - "Flow around" (adds exclusion shape to an existing flowed text) and "Chain flow" (adds a new region to an existing flowed text), with all these shapes remaining editable (i.e. only their clones are added into the flowtext).

2 4

Re: flowtext
by bulia byak 03 Aug '04

03 Aug '04

> - reintroduced the *_update() functions in > sp-flowdiv.cpp; apparently they're needed to have > flowRoot reflow when text is edited > - print uses the text-to-path method, that is you can > print any font in flowRoot > - better convert_to_text(), including partial dx/dy > support (need to figure a way to get the sum of the dy > shifts at the end of a tspan) Thanks, committed. The jumping flowspans bug on convert-to-text seem to be fixed. Please use the version from CVS! I now had to re-type several small fixes I had in sp-flowtext (such as _() for description). What remains to be done: - word-spacing CSS property must be supported as well as letter-spacing. This needs to be added to style.cpp and then to sp-text. - justification must be achieved, first, by squeezing/stretching spaces, and only if this is not possible, by modifying letterspacing. To this end, inkscape:layoutOptions must support 4 parameters: squeezability of space; stretchability of space; squeezability of letterspacing; stretchability of letterspacing (all four are in % relative to the normal value). Some sensible defaults can be found by playing with various texts.

1 0

GNOME HIG
by Lucas Vieites 03 Aug '04

03 Aug '04

Hi all, I just read about the new release of the GNOME HIG (Human interface guidelines) 2 and suddenly I asked myself if Inkscape was taking these into consideration. I browsed the mailing list a bit and found some postings mentioning them. Thinking a bit about the future and the possibility of Inkscape becoming part of GNOME, or even if this is not on the roadmap, I think these guidelines are a "good thing". So, are the developers using these guidelines as they design the user interface? What do you think about them? Greetings, -- Lucas Vieites Fariña Asix Informática <info@...212...> http://www.asixinformatica.com/ Tel/Fax: +34 986 54 26 98

8 13

Re: [Inkscape-user] Re: Crash on startup
by MenTaLguY 03 Aug '04

03 Aug '04

Sorry for taking so long to get back to you; emails about compilation problems will probably get answered quicker on the development mailing list... On Thu, 2004-07-22 at 16:05, Florent wrote: > But maybe, the problem come from the new libs version ? > Is there anyone who can run the last CVS on a Linux ? Yes, I've been running it since I did the library conversion. > And what is his lib versions ? gtk+-2.0 = 2.4.3 gobject-2.0 = 2.4.2 gmodule-2.0 = 2.4.2 glib-2.0 = 2.4.2 pango = 1.4.0 gtkmm-2.4 = 2.4.4 gdkmm-2.4 = 2.4.4 glibmm-2.4 = 2.4.3 pangomm-1.4 = 2.4.4 > I don't know if it can help but when I run the "ddd inkscape", it gives me : > > Program received signal SIGSEGV, Segmentation fault. > SPDesktop::_layer_hierarchy_changed(SPObject*, SPObject*, SPDesktop*) > (top=0x84023d0, bottom=0x84023d0, desktop=0x86bc208) at stl_list.h:397 > /usr/include/c++/3.2.3/bits/stl_list.h:397:10573:beg:0x815f4c4 void SPDesktop::_layer_hierarchy_changed(SPObject *top, SPObject *bottom, SPDesktop *desktop) { desktop->_layer_changed_signal.emit(bottom); } That place for the crash looks a little strange to me. Could you try compiling without optimization and see if it yields the same backtrace (and give me some more of the actual backtrace as well..). The only reason I can think of that it would crash here is if SPDesktop::_layer_changed_signal were not initialized properly for some reason. -mental

2 7

[Fwd: Fwd: mozilla svg meeting log 26.July 2004]
by Jon Phillips 03 Aug '04

03 Aug '04

Sorry for the long email, but this will be of interest to several of you about Mozilla + SVG involvments. This is from the Mozilla SVG team meeting log. -----Forwarded Message----- > From: jon phillips <phillipsjd@...400...> > To: jon@...235... > Subject: Fwd: mozilla svg meeting log 26.July 2004 > Date: Sun, 01 Aug 2004 00:36:09 -0700 > > ---------- Forwarded message ---------- > From: Alex Fritze <alex@...488...> > Date: Sun, 01 Aug 2004 08:34:18 +0100 > Subject: mozilla svg meeting log 26.July 2004 > To: phillipsjd@...400... > > Jul 26 18:39:50 <afri> anyway, shall we start with item 1) "Criteria > for switching on"? > Jul 26 18:39:55 <jwatt> is there any way to search for bugs that have > patches that modify a given file? > Jul 26 18:40:06 <jwatt> oops, never mind, later > Jul 26 18:40:17 <Scooter> 1 seems like a good beginning > Jul 26 18:40:19 <afri> Anybody got any thoughts? > Jul 26 18:40:36 <jwatt> don't we really need a brendan or someone > similar here for that? > Jul 26 18:40:42 <afri> tor: you had some contact with m.org about this? > Jul 26 18:40:45 <jwatt> since they will have a major say in that? > Jul 26 18:41:09 <tor> afri: just the normal moz2 meetings > Jul 26 18:41:51 <Scooter> Well, lets start with which profile we are > shooting for: Tiny or Basic? > Jul 26 18:42:01 <tor> turning it on will depend on the feature set > and size > Jul 26 18:42:11 <tor> 1.2 doesn't have basic, fwiw > Jul 26 18:42:11 <jwatt> or should we do Tiny > Basic > Full? > Jul 26 18:42:23 <tor> (not that we should be shooting for 1.2) > Jul 26 18:42:56 <Scooter> Agreed -- I'm a little uncertain about > 1.2. There seems to be a lot of debate surrounding it. > Jul 26 18:43:02 <afri> do you reckon that feature set is important? > Isn't stability and footprint the issue? > Jul 26 18:43:11 <tor> is anyone interested in working on animation or > svg fonts, which are a couple of the big points we're short of 1.1 tiny? > Jul 26 18:43:30 <tor> stability is definitely important > Jul 26 18:44:01 <tor> we need to be featureful enough so that people > can start do interesting things > Jul 26 18:44:05 <jwatt> I'd be interested in animation in the long > run, but feel I'm still finding my feet > Jul 26 18:44:28 <afri> who do we need to press for criteria? i guess > they are being decided by brendan et al? > Jul 26 18:44:52 <jwatt> yeah, an email to drivers would be a good idea > Jul 26 18:44:59 <tor> brendan was floating the idea of turning on svg > for 1.8, but that causes problems with platform prereqs > Jul 26 18:45:03 <jwatt> or should we /invite some folk now? > Jul 26 18:45:14 <tor> mail to drivers is likely not to get anywhere > Jul 26 18:45:22 <jwatt> oh > Jul 26 18:45:51 <Scooter> OK, so it sounds like there are some > platform issues that need to be on the list -- what are they? > Jul 26 18:46:14 <tor> requiring gdi+ on windows > Jul 26 18:46:27 <jwatt> as in for the installer? > Jul 26 18:46:30 <tor> (unless maybe we can try dynamically loading it?) > Jul 26 18:46:49 <jwatt> I was working on getting the installer script > to do the right thing for that > Jul 26 18:47:05 <Scooter> So, we have requirement #1 -- we need to > deal with gdi+ on windows, right? > Jul 26 18:47:11 <afri> IANAL, but i think technically we are allowed > to redist gdiplus.dll for older windows > Jul 26 18:47:32 <tor> we can't ship libart bits under trilicense > Jul 26 18:47:35 <jwatt> for win me, 98, nt and 2000 > Jul 26 18:47:44 <jwatt> all others aren't allowed > Jul 26 18:47:57 <afri> but we could use cairo for linux, right? > Jul 26 18:48:23 <tor> yes, but we'd have to link it in statically > given that they're still changing the api > Jul 26 18:48:29 <afri> ah > Jul 26 18:48:54 <afri> i guess the other problem is the mac > Jul 26 18:49:11 <Scooter> Perhaps we should focus on listing the > issues and postpone trying to solve them? > Jul 26 18:49:56 <afri> so is it fair to say then that the real first > hurdle for getting svg switched on is sorting out a backend on each > platform? > Jul 26 18:50:04 <tor> how about we ask the question another way - > ignoring distribution issues, would we be happy subjecting users to our > svg at this point? > Jul 26 18:51:00 <afri> i guess that comes down to stability... > Jul 26 18:51:04 <Scooter> I would really like to see us get closer to > *at least* Tiny before we roll this out. > Jul 26 18:51:31 <Scooter> Then we can focus on stability. Things are > clearly still changing pretty rapidly. > Jul 26 18:51:32 <afri> i think the current feature set looks pretty > ok for users > Jul 26 18:52:14 <tor> once gradients are in things are looking good > Jul 26 18:52:16 <Scooter> Even without animation and SVG Fonts? > Jul 26 18:52:21 <tor> <use> would be nice > Jul 26 18:52:45 <jwatt> yeah, gradients and use I think would be > necessary > Jul 26 18:53:16 <afri> yeah, gradients & <use> would be nice. > animation i think will take quite a long while and svg is pretty useful > even without it > Jul 26 18:53:35 <Scooter> Fair enough -- what about SVG Fonts? > Jul 26 18:54:25 <afri> hmm, it sounds tricky getting it right for > several backends... > Jul 26 18:55:03 <afri> do you think without fonts, SVG is not really > worth much to the end user? > Jul 26 18:55:45 <Scooter> Not at all -- I'm just sort of playing > devil's advocate here. I'm happy to see it turned on without that. > Jul 26 18:55:54 <tor> I think svg fonts were probably added to tiny > for platforms that didn't have native scalable/tranformable fonts > Jul 26 18:55:54 <Scooter> What about <switch>? > Jul 26 18:56:26 <afri> well we have your patch for that, so i guess > it will be going in soon > Jul 26 18:57:02 <Scooter> OK, so what we have is: Stability, Platform > issues, <use>, Gradients, and <switch>, right? > Jul 26 18:57:37 <afri> ...of which platform issues are probably the > most difficult > Jul 26 18:57:51 <afri> i don't have a clue how to go about this > Jul 26 18:58:08 <Scooter> Which this? The requirements list or the > platform issues? > Jul 26 18:58:10 <afri> will cairo work on windows/mac? > Jul 26 18:58:25 <afri> Scooter: the platform issues > Jul 26 18:58:52 <afri> can we even link to it statically on linux? > Jul 26 18:59:04 <afri> wouldn't that mean it needs to be checked into > the tree? > Jul 26 18:59:29 <tor> the software path of cairo should work on mac > Jul 26 18:59:51 <tor> if we're allowed to redistribute gdi+ then that > might not be a problem > Jul 26 19:00:06 <afri> fair enough > Jul 26 19:00:20 <afri> so let's assume windows is sorted for now... > Jul 26 19:00:30 <jwatt> as I said, we can only redistribute > gdiplus.dll on WinME, Win98, WinNT and Win2k > Jul 26 19:00:34 <afri> how do we go about linux/mac then? > Jul 26 19:00:43 <tor> jwatt: what else is there? > Jul 26 19:00:53 <afri> tor: XP > Jul 26 19:00:54 <jwatt> nothing that we need to cater for > Jul 26 19:00:57 <jwatt> XP has it > Jul 26 19:01:04 <tor> there's a quartz wip backend > Jul 26 19:01:18 <afri> wip? > Jul 26 19:01:27 <tor> work in progress > Jul 26 19:01:32 <afri> ah > Jul 26 19:01:57 <afri> i think we'd need to find a developer for that > Jul 26 19:02:06 * Lightkey cracks his wip > Jul 26 19:02:12 <afri> it seems to have stalled > Jul 26 19:02:42 <afri> Lightkey: you are a mac developer? > Jul 26 19:02:54 <Lightkey> I am the lowest > Jul 26 19:03:02 <Lightkey> internet reporter :D > Jul 26 19:03:14 <tor> we have a mac here > Jul 26 19:03:18 <Lightkey> no, I'm just a user > Jul 26 19:04:14 <afri> so if we have as a working assumption that > someone will fix the quartz backend, that still leaves linux... > Jul 26 19:04:42 <Scooter> And the issue with Linux is the license > restrictions on libart? > Jul 26 19:04:52 <afri> with libart not being an option, how would we > proceed with cairo? > Jul 26 19:04:57 <tor> statically linking cairo is just a build problem > Jul 26 19:05:10 <afri> what about the cairo license? > Jul 26 19:05:12 <tor> though cairo does feel slower than libart > Jul 26 19:05:28 <Lightkey> changing croczillas licenses to the one > libart uses? *scnr* > Jul 26 19:05:46 <tor> still MIT style, though they keep threatening > to change to LGPL (which would sink the static link solution) > Jul 26 19:06:35 <afri> is MIT compat with tri-license? > Jul 26 19:06:43 <tor> yes > Jul 26 19:07:06 <afri> so we could check this into the tree then? > Jul 26 19:07:10 <Lightkey> MIT is like FreeBSD > Jul 26 19:08:37 <tor> if it gets to that point, yes > Jul 26 19:08:51 <afri> to which point? > Jul 26 19:09:04 <afri> LGPL relicensing> > Jul 26 19:09:07 <afri> ? > Jul 26 19:09:15 <tor> where we're going to take the static link approach > Jul 26 19:09:23 <afri> ah yeah, ok > Jul 26 19:09:34 <afri> well, is there any other way? > Jul 26 19:09:44 <lsmith> afri: are those performance issues solved > that matthias found afri? > Jul 26 19:09:51 <lsmith> (iirc he send you a test case) > Jul 26 19:09:54 <tor> not that I can think of offhand > Jul 26 19:10:12 <lsmith> those might also be a little showstopper > Jul 26 19:10:26 <afri> lsmith: no, we'll get to that later > Jul 26 19:10:46 * lsmith nods > Jul 26 19:10:49 <afri> so shall we run this past brendan et al then? > Jul 26 19:11:23 <Scooter> Makes sense to me. > Jul 26 19:11:35 <jwatt> yeah, good to keep him informed if nothing else > Jul 26 19:11:50 <jwatt> But do we really have enough contributors to > deal with the development cycle that would be imposed on us if SVG was > turned on by default? > Jul 26 19:12:14 <tor> what development cycle? > Jul 26 19:12:43 <jwatt> having to stabalise, etc a1, a2, b, rc, > milestone > Jul 26 19:13:27 <jwatt> there are certain benefits to not being build > by default, and therefore not having to meet the same standards as the > rest of the code > Jul 26 19:14:41 <jwatt> or is it better that we should start to be > forced to those standards? > Jul 26 19:15:10 <afri> so is it fair to summarize then: stability, > backend are the major issues. course of action: gdi+ on win, quartz on > mac, statically-linked cairo on linux? run past brendan et al. find out > other criteria from them? > Jul 26 19:15:36 * lsmith notes while he doesnt have the know how to > contribute code we (my co-worker and I) will definately be willing to > help on the testing front > Jul 26 19:15:53 <jwatt> lsmith: cool > Jul 26 19:15:57 <jwatt> afri: seems right > Jul 26 19:16:12 <Scooter> afri: sounds right to me. We should also > mention <use>, which is an outstanding feature on the list. > Jul 26 19:16:45 <tor> afri: and getting the current features working > through reviews (gradient, switch) > Jul 26 19:17:11 <Scooter> afri: and font-size > Jul 26 19:17:21 <afri> ok > Jul 26 19:17:44 <afri> then there is the issue of getting the current > code sr'ed... > Jul 26 19:17:55 <jwatt> fun > Jul 26 19:18:39 <lsmith> may i ask what timeframe you are hoping for? > (slap me if i am intruding btw) > Jul 26 19:18:41 <afri> so is anyone volunteering to run these issues > past brendan et. al. ? > Jul 26 19:19:10 <tor> afri: sure, I send something to the moz2 list > and talk to brendan > Jul 26 19:19:34 <jwatt> where is the moz2 list? > Jul 26 19:19:37 <afri> tor: cool > Jul 26 19:19:39 <jwatt> is that public? > Jul 26 19:19:53 <tor> unfortunately no > Jul 26 19:19:57 <jwatt> shame > Jul 26 19:20:19 <afri> anybody got an idea what timeframe we are > aiming for? i don't... > Jul 26 19:20:43 <Scooter> I will volunteer to take on <use> as soon > as I can clear out some of the other patches. <use> looks a lot like > the some of the gradient reference stuff. > Jul 26 19:20:52 <afri> cool > Jul 26 19:21:14 <jwatt> afri: no, I'm in no rush, I just wanted to > clarify things to aim for in the long run > Jul 26 19:21:35 <afri> ok, i guess that's item 1 sorted then as well > as we can atm > Jul 26 19:21:55 <jwatt> scooter's only here for another 40 min > Jul 26 19:21:57 <tor> brendan was floating 1.8 - if we were serious > about that, of that list, we might be able to get everything except for > <use> > Jul 26 19:22:07 <jwatt> what do we need to discuss while he's here? > Jul 26 19:22:32 <afri> cool > Jul 26 19:22:59 <Scooter> Do you really think we could get the > stability and platform issues worked out for 1.8? > Jul 26 19:23:03 <afri> tor: how about if you run this past brendan > and we talk about it again next week? > Jul 26 19:23:26 <tor> afri: sure > Jul 26 19:23:36 <afri> if there's a commitment by mozilla.org to get > this in, i guess we could make it > Jul 26 19:23:47 <tor> Scooter: do we have serious stability problems? > Jul 26 19:24:26 <Scooter> Not sure -- there's a lot of work in > progress. Until its all in a single build, we really haven't done much > to shake things out. > Jul 26 19:24:28 <afri> AFAICS many stability problems on linux are > libart-specific > Jul 26 19:24:51 <afri> there are issues with very large SVGs > Jul 26 19:25:03 <afri> we don't do any culling or clipping... > Jul 26 19:25:28 <Scooter> Should clipping be on our requirements list? > Jul 26 19:25:37 <tor> oh, speaking of which cairo is in the midst of > redoing their trianglization algorithms, so some fills mess up now > Jul 26 19:25:39 <afri> so if the SVG viewport is larger than the > client area we still build all the paths > Jul 26 19:26:14 <afri> i guess visual glitches are one > thing...crashing/hanging is another > Jul 26 19:27:10 <afri> shall we move to the other items then? > Jul 26 19:27:12 <Scooter> I don't know...I guess I'd feel more > comfortable enabling SVG right *after* 1.8. That way we could get in at > the start of a cycle. > Jul 26 19:27:23 <Scooter> Sure, lets move on. > Jul 26 19:27:50 <afri> "currentColor" > Jul 26 19:28:07 <afri> Scooter: you had a question about the intent > of the specs? > Jul 26 19:28:35 <afri> isn't "current" just the value of the "color" > property? > Jul 26 19:29:14 --> shaver (~shaver@...489...) has joined #svg > Jul 26 19:29:28 <Scooter> Sort of. The question is, is it the value > of the color property of the surrounding elements (i.e. inherited) or > just the last set value? > Jul 26 19:30:27 <afri> is there a difference? > Jul 26 19:31:24 <Scooter> Internally, I think that there is. For > example, I could set the "color" property on an HTML element then not > set the property again and then use it inside of SVG as "currentColor". > Jul 26 19:31:48 <afri> ah, i see > Jul 26 19:31:58 <afri> i haven't got a clue > Jul 26 19:32:23 <afri> don't the specs say anything about this? > Jul 26 19:32:29 <afri> (the css specs) > Jul 26 19:32:38 <Scooter> I *believe* that that is the intent of the > spec -- a way to maintain color between different document elements. > Jul 26 19:33:12 <Scooter> The only example (in the test suite) just > sets the color inside of SVG and then references it using "currentColor" > Jul 26 19:33:43 <afri> hmm, i guess noone here knows... > Jul 26 19:34:09 <jwatt> maybe ask in www-svg, or mail chris/dean > directly > Jul 26 19:34:10 <Scooter> The css specs (2.1) don't talk about > "currentColor". That's supposed to be coming in CSS3 (I'm told). > Jul 26 19:34:19 <Scooter> OK, will do. > Jul 26 19:34:26 <afri> great > Jul 26 19:34:38 <afri> 3. ICC Color - do we do it? Should we? > Jul 26 19:34:50 <afri> i don't even know what ICC color is > Jul 26 19:35:00 <tor> color profiles for color correction > Jul 26 19:35:12 <afri> ah > Jul 26 19:35:14 <Scooter> And its part of the SVG spec > Jul 26 19:35:40 <afri> i guess we should then > Jul 26 19:35:44 <Scooter> My take is to wait for somebody to ask for it. > Jul 26 19:35:47 <afri> at some point > Jul 26 19:35:51 <tor> somewhat low priority, I woudl think > Jul 26 19:35:57 <afri> yeah > Jul 26 19:35:58 <jwatt> btw, I found their specs online some years > ago, I downloaded them if they can't be found now > Jul 26 19:36:19 <Scooter> They are still online. > Jul 26 19:36:39 <Scooter> OK, I agree that this should be low priority. > Jul 26 19:36:40 <jwatt> cool, anyway, low priority > Jul 26 19:36:44 <afri> cool - so ICC color=low priority. 4) patterns > Jul 26 19:36:56 <Scooter> Any takers? > Jul 26 19:37:00 <jwatt> ugh > Jul 26 19:37:17 <afri> i think we need to sort out clipping before > patterns > Jul 26 19:37:23 <Scooter> Agreed. > Jul 26 19:37:27 <afri> that's something i wanted to do next > Jul 26 19:38:19 <Scooter> Great! Getting clipping would be really good. > Jul 26 19:38:26 <afri> so I guess we wait until clipping is sorted > out then > Jul 26 19:38:35 <afri> 5. SVG text > Jul 26 19:39:09 <Scooter> What's missing besides textPath? > Jul 26 19:39:12 <tor> textPath seems hard > Jul 26 19:39:36 <afri> selection is only partially implemented atm (i > got bored) > Jul 26 19:40:23 <afri> i think before we ship in default builds, > selection either needs to be disabled or finished > Jul 26 19:40:32 <afri> it's kind-of screwy atm > Jul 26 19:41:04 <afri> font-size we have Scooter's patch for, so i > guess that will go in soon > Jul 26 19:41:51 <Scooter> That's sort of minor (although you wouldn't > know it by the number of comments). > Jul 26 19:41:56 <afri> All the other stuff (textPath, tref, glyphs) > would be nice, but does anybody want to work on that? > Jul 26 19:42:05 <Scooter> So, I guess we don't have any takers for > working on SVG Text? > Jul 26 19:42:27 <jwatt> why disable it? I'd prefer not to, even if it > doesn't get finished. > Jul 26 19:42:58 <afri> disable selection, not text > Jul 26 19:43:06 <jwatt> I know > Jul 26 19:43:10 <Scooter> So, should we submit a bug for the missing > stuff with helpwanted? > Jul 26 19:43:30 <afri> it doesn't work - some of the machinery is > there, that's all > Jul 26 19:43:39 <jwatt> but sometimes it works, and the worst thing > that can happen is that the user can't select what they want and files a > bug > Jul 26 19:43:54 <afri> fair enough > Jul 26 19:44:40 <Scooter> If I'm going to do <use> I'll take a look > at <tref> also. > Jul 26 19:44:45 <afri> cool > Jul 26 19:45:08 <afri> tor: text is working on cairo, right? > Jul 26 19:45:13 <Scooter> That still leaves textPath (and glyphs) > Jul 26 19:45:39 <jwatt> these things are out of my league at the mo > Jul 26 19:45:49 <tor> afri: yes, though i18n text doesn't work > Jul 26 19:46:17 <tor> afri: font size tends to be off > Jul 26 19:46:37 <afri> i guess that's stuff we can live with > Jul 26 19:47:29 <afri> so shall we move on to the next then? > Jul 26 19:47:30 <tor> probably fixable - I'm using the "wimp api" for > cairo fonts > Jul 26 19:47:38 <Scooter> So, file a bug for textPath and move on? > Jul 26 19:48:09 <afri> cool > Jul 26 19:48:17 <Scooter> What's next? > Jul 26 19:48:24 <jwatt> item 6 > Jul 26 19:48:29 <tor> <defs> > Jul 26 19:48:39 <afri> <defs>: why on earth are they stylable? > Jul 26 19:48:54 <afri> & transformable? > Jul 26 19:49:14 <tor> good batch of crack at the w3c? > Jul 26 19:49:24 <tor> I mean, I'm sure they had a good reason > Jul 26 19:49:43 <jwatt> another one for chris/dean? > Jul 26 19:50:01 <afri> it looks to me as if everything that goes into > a <defs> has its style and/or xforms applied whereever it's referenced from > Jul 26 19:50:10 <afri> yeah, i'll mail the list > Jul 26 19:50:25 <afri> although i usually don't get any answers > Jul 26 19:50:50 <Scooter> Maybe all of us can sort of push for > answers. I'm on the svg list also (mostly been lurking). > Jul 26 19:50:54 <tor> <use> is supposed to use a combined cascade, > which makes the style make a bit of sense > Jul 26 19:50:57 <jwatt> then follow it up with personal emails > Jul 26 19:51:42 <afri> ok, i guess i should take a look at the <use> > specs before i complain about anything > Jul 26 19:51:56 <Scooter> I've got to go get ready for my > presentation. I'll be back in a couple of hours (if you all are still > at it), but if not, will somebody summarize via E-Mail? > Jul 26 19:52:25 <jwatt> yeah, somebody will > Jul 26 19:52:29 <-- lsmith has quit (Read error: Connection reset by > peer) > Jul 26 19:52:33 <afri> Scooter: have fun > Jul 26 19:52:42 <Scooter> Thanks! Talk to you soon. > Jul 26 19:52:45 <-- Scooter (~chatzilla@...490...) has left > #svg > Jul 26 19:53:19 <afri> so shall we carry on ... or wait for scooter > to come back ... or leave it for another day? > Jul 26 19:53:53 <jwatt> I'm happy to carry on or wait 'til scooter > gets back > Jul 26 19:54:10 <tor> either is fine for me > Jul 26 19:54:17 <jwatt> I'd rather not leave it until another day though > Jul 26 19:54:37 <afri> ok > Jul 26 19:54:47 <afri> what's next? > Jul 26 19:54:48 <tor> no 7 - svg matrices > Jul 26 19:55:00 <afri> should they be live or not? > Jul 26 19:55:23 <afri> the specs say nothing > Jul 26 19:56:02 <afri> does anybody have any strong feelings on this? > Jul 26 19:56:18 <jwatt> but it seems that at least dean and the other > SVG WG members that work on batik say they aren't > Jul 26 19:56:30 <afri> if not, then i'd prefer to leave them as they > are now... > Jul 26 19:56:34 <jwatt> I would like to maintain compatibility with > batik > Jul 26 19:56:51 <jwatt> but to be honest I don't understand your > reasons in the bug > Jul 26 19:56:54 <afri> yeah but i think they just say that because > that's how they implemented them in batik > Jul 26 19:57:18 <jwatt> does dean work on batik? > Jul 26 19:57:24 <afri> i don't know > Jul 26 19:58:01 <jwatt> is there no other way of doing what you want > them to do? > Jul 26 19:58:52 <afri> do you think the compatiblity issue is a real > issue? > Jul 26 19:59:10 <afri> i mean in 'normal' svg usage this is unlikely > to come up > Jul 26 19:59:43 <jwatt> it's the kind of thing that I would be likely > to come up against > Jul 26 19:59:58 <jwatt> but then dom scripting is really what I like > to do most > Jul 26 20:00:06 <jwatt> I don't know about other users > Jul 26 20:00:31 <afri> the way i see it is, the specs don't say > anything, so anybody scripting in this area can't make any assumptions > about it being live or not > Jul 26 20:00:41 <jwatt> what I would be worried about is that people > would start to take advantage of the fact that one matrix could be > referenced by multiple transforms in mozilla > Jul 26 20:01:12 <jwatt> and then it becomes impossible to change it > without annoying a whole load of people > Jul 26 20:01:15 <jwatt> maybe not, but they will > Jul 26 20:01:43 <afri> the thing is I don't see why we should cripple > our api because batik implemented something that is outside the specs in > a particular way > Jul 26 20:01:52 <afri> batik should change > Jul 26 20:02:23 <jwatt> heh > Jul 26 20:02:32 <afri> also, i think it is really inconsistent with > other datastructures that have to be live > Jul 26 20:02:35 <afri> e.g. points > Jul 26 20:02:37 <tor> what does adobe do? > Jul 26 20:02:49 <jwatt> adobe doesn't do that part of the dom > Jul 26 20:02:51 <afri> why are points live and transforms aren't > Jul 26 20:03:03 <jwatt> afri: yeah, I agree with that bit > Jul 26 20:03:46 <jwatt> to be frank this is another WG mess that has > no good solution > Jul 26 20:03:58 <afri> i really think this is not a big > interoperability issue > Jul 26 20:04:24 <afri> live matrices are nearly a superset of > non-live matrices > Jul 26 20:04:46 <jwatt> well for the moment let's leave it as it is, > and perhaps come back to it in the future > Jul 26 20:04:56 <jwatt> I'll just get on with that bug and ignore the > liveness aspect > Jul 26 20:04:57 <afri> what i mean is, any code that is coded with > non-live matrices in mind is likely to work in Moz as well > Jul 26 20:05:06 <jwatt> brb > Jul 26 20:05:21 <afri> not vice versa of course > Jul 26 20:06:32 <jwatt> back > Jul 26 20:06:35 <jwatt> afri: right > Jul 26 20:06:37 <afri> so would you guys be ok with leaving it as it > is for now? > Jul 26 20:07:27 <tor> I'd be curious to hear what others thought > about <embed> content > Jul 26 20:07:28 <jwatt> for now yes, but I'd like to go over how much > of a problem this would be for crocodile-maths with you later > Jul 26 20:07:40 <jwatt> so <embed> > Jul 26 20:08:03 <tor> oh, thought you were talking about the end of > the meeting, not the item > Jul 26 20:08:27 <afri> i think we should do <embed> > Jul 26 20:08:37 <jwatt> I think we should allow the use of <embed> > for svg content in html, but not in xhtml > Jul 26 20:08:51 <afri> i don't agree with dbaron's objections > Jul 26 20:09:10 <jwatt> I do for xhmtl > Jul 26 20:09:10 <tor> is <embed> even in xhtml? > Jul 26 20:09:23 <jwatt> actually I don't know > Jul 26 20:09:36 <jwatt> come to think of it, probably not > Jul 26 20:10:11 <jwatt> In which case I would support implementing it > Jul 26 20:10:18 <jwatt> (your patch) > Jul 26 20:10:40 <tor> but should we always use the internal svg? > Jul 26 20:11:13 <tor> or should we <span class="quiet voice">add a > pref</span>? > Jul 26 20:11:23 <afri> heh > Jul 26 20:11:44 <afri> does the abobe stuff work with moz? > Jul 26 20:11:58 <afri> i've never tried it > Jul 26 20:12:22 <tor> it did last time I tried > Jul 26 20:12:23 <afri> from my point of view, always running native > svg would be just fine > Jul 26 20:12:57 <afri> it probably depends on how much people use asv > with moz > Jul 26 20:13:08 <tor> it would be a problem for a customer currently > happily using svg beyond the capablities of mozilla > Jul 26 20:13:21 <jwatt> does <embed> not have an attribute for > specifying the prefered plugin? > Jul 26 20:13:33 <afri> but are there customers like that? > Jul 26 20:13:49 <afri> in which case, yeah, we'd probably need a pref > Jul 26 20:14:30 <afri> sorry i got to go as well in a minute > Jul 26 20:14:52 <afri> tor: what do *you* think about embed? > Jul 26 20:14:59 <jwatt> afri: will you be back later when scooter > gets back? > Jul 26 20:15:14 <afri> if we had a pref would dbaron be ok with it? > Jul 26 20:15:23 <tor> afri: I think we should handle embed content > Jul 26 20:15:28 <afri> jwatt: hopefully > Jul 26 20:15:52 <tor> afri: maybe we should check if a plugin can > handle it first, then go to the browser? > Jul 26 20:16:09 <afri> sounds good > Jul 26 20:16:20 <afri> would that be easy to implement? > Jul 26 20:16:43 <tor> not sure offhand - have to check the code > Jul 26 20:17:27 <afri> ok, sorry gtg - talk to you later > Jul 26 20:17:33 --- You are now known as afri_away > Jul 26 20:19:49 <jwatt> tor: enumerate the gecko-content-viewers > category for supported mime types? > Jul 26 20:20:32 <jwatt> practically a quote > Jul 26 20:36:44 --> santamarta > (juanjo@...491...) has joined #svg > Jul 26 20:40:53 <-- shaver (~shaver@...489...) has left #svg > Jul 26 21:14:56 <tor> mailed the quartz guy to check the status of > that backend > Jul 26 21:23:18 <jwatt> cool > Jul 26 21:23:23 <jwatt> afri: ping > Jul 26 21:23:50 --> Hixie_ (~ianh@...492...) has > joined #svg > Jul 26 21:24:13 --> rocWork (roca@...493...) has > joined #svg > Jul 26 21:28:55 <jwatt> tor, we might come short of some aspects of > svg tiny, but aren't there things we do that are only in basic or full? > Jul 26 21:31:00 <tor> jwatt: yes, gradients are the big one > Jul 26 21:31:14 <rocWork> mmm, gradients > Jul 26 22:30:29 --> Scooter (~chatzilla@...490...) has > joined #svg > Jul 26 22:37:11 <-- DaaWk has quit (Ping timeout: 372 seconds) > Jul 26 22:37:15 <jwatt> hi scooter > Jul 26 22:37:35 <-- Daa has quit (Ping timeout: 372 seconds) > Jul 26 22:39:18 <tor> did my mail get through? I haven't gotten the > bounce back from drivers, but apparently gila is suffering from spammage > Jul 26 22:39:44 <jwatt> tor: that's what my previous comment was about > Jul 26 22:46:55 --> DaaWk (daa@...494...) has joined #svg > Jul 26 22:48:08 --> Daa (daa@...494...) has joined #svg > Jul 26 22:49:19 --- You are now known as afri > Jul 26 22:56:21 <jwatt> afri: can you expand on what you mean by: > 'Live' matrices that can be shared amongst several transforms come in > very handy for things like implementing dynamic canvases where part of > the objects should be transformation-invariant. > Jul 26 22:57:16 <jwatt> particularly the part about "part of the > objects should be transformation-invariant" > Jul 26 22:57:29 <-- Scooter has quit (Remote host closed the connection) > Jul 26 22:59:52 <afri> jwatt: well e.g. imagine a map where cities > are displayed by some icon > Jul 26 23:00:20 <afri> jwatt: as you zoom into the map you want the > icons to stay at the same size > Jul 26 23:01:14 <afri> ... but everything else should zoom > Jul 26 23:01:45 <afri> so you need a different xform for the city > icons and for everything else > Jul 26 23:02:41 <jwatt> afri: I see, that makes sense -- Jon Phillips PO BOX 948667 LA JOLLA, CA 92037 USA USA.PH.858.361.2811 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/)

1 0

flowing text support is in
by bulia byak 03 Aug '04

03 Aug '04

I just committed another exciting patch from Fred: support for flowing text! http://www.w3.org/TR/SVG12/#flow So far it's pretty much read-only, i.e. there's no UI yet for creating flow objects. But they are rendered already, and you can partially edit the envelope shape. Load share/examples/flowtext.svg from CVS, select the object, switch to node tool. and node-edit the envelope - the text will reflow into whatever shape you give it, preserving all the paragraph divisions and applied styles. Really exciting. There are two flow shapes in that example; when the text does not fit entirely in the first one, the rest will go to the second shape (to the right). There's also an "excluded" shape in the middle that the text flows around. You can only edit the first shape so far. You also cannot yet edit the flowed text by text tool - this is yet to be done. Note that this is a feature from SVG 1.2, which itself is not final yet and may change. This means that Batik or Adobe can't yet render that example. And yes, I know, we don't support all of 1.1 yet :) Now with Pango and this new patch, I hope to find time for rewriting the rest of the text system for the next version, to finally make it usable.

3 6

'No Preview' drawing
by Bob Jamison 02 Aug '04

02 Aug '04

Here is the file open dialog again, with a default preview SVG image, for when a preview cannot be displayed: http://troi.titan-aeu.com/~rjamison/inkscape/files/filedialog5.png That is what I meant by the "Preview not available" drawing. It would be nice if someone were to replace this (imho) unattractive placeholder I made, with something simple (small SVG code), elegant, and understated. Something like the Gimp dialog, only nicer. The only constraint is that the words are a single text string that can be localized. Any volunteers? Bob

3 6

Re : comments on fr.po
by Gazal, Geraud (MED) 02 Aug '04

02 Aug '04

>I"m not a native french speaker; can someone please check the following > comments and diff? Thanks. I'm :) > What"s the preference between normal space and non-breaking space before >e.g. `:" ? I"d have thought that it would be bad to have a line break >just before `:", which suggests that non-breaking space (  /   >/  ) is better. In French, the 'typographic" rule is to place a space before (and after) ":". But no line break. -> preference is "non-breaking space" I think I'll try to have a second look on the French translation. (I don't always agree with some translations, or would like to shorten some of them) But haven't had time enough recently to do so. Plus did not manage to synchronize with Frederic Rodrigo. (I think he has done a great job, and I don't want to break this) Regards, Matiphas

1 0

Inkscape Status 2004-08-01
by Bryce Harrington 02 Aug '04

02 Aug '04

Statistics Nov 15 May 15 Jun 15 Jul 15 Aug 1 ========== ====== ====== ====== ====== ====== Lifetime Rank on SourceForge: 4391 1028 928 845 844 (68.5%) (92.7%) (93.4%) (94.0%) (94.0%) Max Week's Rank on SourceForge: 62 36 41 33 17 (99.6%) (99.8%) (99.8%) (99.8%) (99.9%) Total SF Page Views * 475,000 616,263 741,681 838,154 Total SF Downloads * 27,400 34,015 39,359 44,068 Total Freshmeat URL Hits 746 * 7,333 7,946 9,034 Total Freshmeat Subscriptions 16 74 87 93 112 Lines of Code in src/: 115,901 189,116 280,263 264,418 273,381 Code lines 147,471 210,119 192,240 199,473 Comment line 16,757 40,620 41,926 42,411 Blank 25,886 34,677 35,422 36,717 Lines of Docs in doc/: 1,135 4,544 15,170 15,217 16,117 Lines of content in website: 1,173 6,008 6,372 6,784 6,953 Size of the Inkscape wiki: 3,700 18,638 17,176 17,854 19,096 Minutes since last ChangeLog mod: 360 * * 54 30 Bugs open/total: 9/15 57/365 63/401 73/496 103/548 Features open/total: 18/18 183/238 210/285 242/331 253/347 Patches open/total: 1/ 6 4/ 83 5/ 88 8/110 6/117 CVS Commits (as per inkscape-cvs): 481 3391 5549 6314 6,528 Inkscape-devel membership: 49 78 84 95 98 Inkscape-announce membership: 9 43 53 60 65 Inkscape-user membership: 71 76 90 98 Num Translations : 32 33 Ave Translation Ratio: 40.5% 43.8%

1 0

Boehm Garbage Collector
by Jon Phillips 02 Aug '04

02 Aug '04

Hello all, In my attempt at being able to build CVS once again and upgrading to Fedora Core 2 from FC1 (intermediate b4 gentoo), I found several errors which many users and developers have been complaining about not working. Upon some research and acting as JoeUser, it appears that this collector is not available as an RPM or common package!!! I'm reacting to this as JOE USER and this is probably not good for our next release. There are only old rpms for SUSE available and Bryce has tried (and they did not work). Also, Ted says that this garbage collector is avail. for debian. But, there are not packages available for Fedora Core as far as I can see and not many listings elsewhere. Thus, we really need this to be more widely available. There are three options I see: 1.) EASY: Drop Boehm Garbage Collector as a dependency (or replace with something more widely avail) 2.) MED: Push changes upstream and try and get packages for current version of this collector at common repositories. 3.) HARD: Supply our own along with Inkscape as a package or in our main build tree. Please voice your opinions, as our current dependencies are a little too bleeding edge it seems right now, and I totally understand why these are needed. However, if by the time we do a release these dependencies are not widely available on the dominant distros (fedora core, windows, etc), then there will be a problem (aka, loss of users). Thoughts and solutions? Jon -- Jon Phillips PO BOX 948667 LA JOLLA, CA 92037 USA USA.PH.858.361.2811 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/)

3 3

Notes with 0.40 dependencies
by Bryce Harrington 02 Aug '04

02 Aug '04

A couple notes regarding some of the new libs, that Ted, Rejon, and I have been talking about... * We need to think about maybe providing a package for the boehm gc dep. The packages available through rpmseek are for an old version and don't have the cplusplus option. * Our 0.40 release timeframe is going to be gated by having packages of gtkmm 2.4 and its deps available for all major distros. The package availability for SuSE (and other distros) isn't pretty right now. Hopefully it'll get better within a couple months, but regardless, it would not be wise to release *until* those packages are posted and sufficiently available. Bryce

2 1

comments on fr.po
by Peter Moulder 02 Aug '04

02 Aug '04

Thanks for the recent updates to fr.po! I'm not a native french speaker; can someone please check the following comments and diff? Thanks. What's the preference between normal space and non-breaking space before e.g. `:' ? I'd have thought that it would be bad to have a line break just before `:', which suggests that non-breaking space (  /   /  ) is better. However, some of the recent diffs explicitly changed non-breaking space to normal space. Are there problems with non-breaking space, or were the changes just because normal space is easier to type? "metadata": obi used "métadonnées" "lors des déplacement": surely either "de" or "-ments" "Pas sélection d'indication d'objet pers" (yet display-settings.cpp:223 discards "Indication de sélection pour chaque objet" translation) "Tous les objets sélectionnés" : suggest "Chaque objet sélectionné". Similarly in other "Tous les" translations. This can reduce confusion as to whether e.g. `leur foo'/`leurs foos' means that each has a foo/foos or whether there's a shared foo/foos. "avec certain gestionaire": I'd have expected plural. display-settings.cpp:624: why suppress "Montrer l'indication de sélection" translation? #: src/dialogs/display-settings.cpp:642 -#, fuzzy msgid "Picking colors:" -msgstr "Choisissement de couleurs :" +msgstr "couleurs capturé:" Why lower-case, and no space before colon? It seems a different meaning from the original. I haven't looked at how this phrase gets used in inkscape though. #: src/dialogs/display-settings.cpp:653 msgid "Pick visible color (no alpha)" -msgstr "" +msgstr "Capture de couleurs visibles (pas d'alpha)" why plural? Should original be changed? #: src/dialogs/display-settings.cpp:653 msgid "" "Pick the visible color under cursor, taking into account the page background " "and disregarding the transparency of objects" -msgstr "" +msgstr "Pipette la couleur visible sous le curseur, tient compte de la couleur du fond et ne tient pas compte de la transparence des objets" I don't like the punctuation: "Pipette" is presumably imperative, whereas tient looks indicative. So I'd put "tient...objets" in a separate sentence: "curseur. (Tient...objets.)" I'm not sure that it should be indicative though: it could be an instruction to the user to take into consideration rather than an observation as to what the computer does. In some cases mouse is translated as "souris", other places "sourie". I don't recall encountering the spelling "sourie" elsewhere. #: src/dialogs/display-settings.cpp:755 -#, fuzzy msgid "Grab sensitivity:" -msgstr "Proximité de sélection de la souris" +msgstr "Saisir la sensibilité :" This change looks wrong. The sense of the original is "sensitivity of mouse grab". "Sensitivity" isn't really a very good word. What it means is "how close should the mouse pointer be to an object for it to be considered selecting that object". "Distance à partir de la quelle peut saisir" looks strange to me. "Déplacement de sourie maximal": I'd consider "Déplacement maximal de sourie". "Gardé appuyé Ctrl+flèches augmente" looks strange to me. Would make sense to me if there were a comma after "appuyé". "tire un objet au dehors": suggest add "de la fenêtre". "en points": Out of curiosity, why write "en pixel" but "en points" ? Whereas elsewhere we have "en point par pouce", "La largeur en pixels" (ou hauteur), "(en degrés)". "zoomme ou dézoumme"; "zoom": appear to be three different ways of translating the verb "zoom". (The noun seems fairly consistently translated as "zoom".) #: src/dialogs/display-settings.cpp:999 -#, fuzzy msgid "Save window geometry" -msgstr "Enregistrer la géométrie de la fenêtre" +msgstr "Enregistre la taille de la fenêtre" "geometry" in X means both size and position. AFAIK, geometry/géométrie mean the same thing (outside of X at least), i.e. "geometry" is an artificial word coined for this purpose. I'd guess that géométrie in French is just as suitable as "geometry" is in English. "Save the window size and position with each document (only for Inkscape SVG " "format)" -msgstr "" +msgstr "Enregistrment la taille de la fenêtre et ça position pour chaque document (seulement pour le format SVG d 'Inkscape)" Presumably s/ça/sa/, and "Enregistre(r)". "Sont déplacé": "déplacés" ? Similarly, "Ne bouge pas" -> "Ne bougent pas" below, and similarly for "Déplacé". "du même vecteur comme l'original" : "que l'original" ? "Deviennent indépendant": "indépendants" ? "rempli avec" : "rempli de" ? "la menu fichier" : "le menu Fichier" ou "« Fichier »" ou "‘Fichier’". "une appel": "un appel" ? (I haven't checked dictionary.) "Impossible de suaver" : either "sauver" or "enregistrer". #. TRANSLATORS: "%s" is replaced with "exact" or "partial" when this string is displayed -#: src/dialogs/find.cpp:320 +#: src/dialogs/find.cpp:317 #, c-format msgid "%d object(s) found (out of %d), %s match." -msgstr "" +msgstr "%d objet(s) trouvés (sur %d), correspondant à %s." Did you notice the TRANSLATORS comment? I'd have thought ", match %s." (or whatever the translation for "match"). -#: src/dialogs/find.cpp:493 +#: src/dialogs/find.cpp:490 msgid "Search in all object types" -msgstr "" +msgstr "Recherché dans tous les types d'objets" "Rechercher" ? "Rechercher des groupes", "Rechercher des clones", etc.: other similar-looking translations use "les". I haven't checked whether the similar-looking strings are on the same dialog box or not. -#: src/dialogs/find.cpp:635 +#: src/dialogs/find.cpp:632 msgid "Find objects by the value of the id attribute (exact or partial match)" -msgstr "" +msgstr "Rechercher des objets par leurs valeurs ou leurs id (exact ou partiel)" I think you misread "of" as "or". (I haven't checked whether there's a mistake in the original.) I'd expect something like "par la valeur de l’attribut ‘id’". (If you use the punctuation "attribut ‘id’" then change "attribut de style" similarly. Btw, "the style attribute" means "the attribute whose name is written ‘style’ in the XML"; I'm not sure that "l’attribut de style" captures this.) -#: src/dialogs/find.cpp:663 -#, fuzzy +#: src/dialogs/find.cpp:660 msgid "Clear values" -msgstr "Effacer les valeurs" +msgstr "Valeurs de nettoyage" I'd have thought this change to be wrong, but I haven't looked at how the string is used. -#: src/dialogs/find.cpp:664 -#, fuzzy +#: src/dialogs/find.cpp:661 msgid "_Find" -msgstr "Chercher" +msgstr "Trouver (_f)" Personally I prefer "Chercher" (e.g. considering the case where the search is unsuccessful: requesting that one "trouve" `foo' might imply adding `foo' to the document if necessary, which of course one does not want. (Granted, the original has the same problem, but English doesn't have a single-word equivalent of "chercher".) Similarly elsewhere. #: src/dialogs/object-properties.cpp:212 -#, fuzzy msgid "Stroke paint" -msgstr "Peinture du trait" +msgstr "Couleur du tracé" "Stroke paint" allows either a simple single colour or a gradient or a pattern or absence of stroke. It would be nice to find a word that encompasses all of these. Even "Couleurs" or "Couleur(s)" would suffice. "Impossible de le rechargé" : "recharger" ? "Document non modifier" : "modifié" ? #: src/inkscape.cpp:1152 msgid "" "Although Inkscape will run, it will use default settings,\n" "and any changes made in preferences will not be saved." msgstr "" "Toutes fois Inkscape va démarrer, il va utiliser les paramètre par défaut,\n" "et toutes les modifications de préférences ne seront pas enregistré." I've already changed "Toutes fois" to "Bien qu'" and "enregistré" to "enregistrés" in the below diffs. I suspect "paramètre" -> "paramètres" and "par défaut" -> "de défaut". -#: src/interface.cpp:789 +#: src/interface.cpp:782 msgid "Show or hide the main toolbox (on the left)" -msgstr "" +msgstr "Afficher ou cacher la boite à outils principale (à droite)" Please confirm the left/droite translation. Does the original string need changing? "vous devez avoir sélectionnés deux nœuds": either "avoir sélectionné deux nœuds" or "avoir deux nœuds sélectionnés". I quite like the latter adjectival form, and am inclined to change the original accordingly ("must have two nodes selected"). #: src/select-context.cpp:808 #, c-format msgid "Move by %s, %s" msgstr "Déplacé de %s, %s" Does the original need changing to "Moved" ? Similarly "Center at" / "Centré en" elsewhere. #: src/selection-chemistry.cpp:1357 msgid "Select a single clone to go to its original." msgstr "Sélectionner un seul clone pour aller à l'original." "son original" ? #: src/verbs.cpp:883 msgid "Difference of selected objects (bottom minus top)" msgstr "Différence entre les objets sélectionnes (dessus moins dessous)" Please confirm "dessus moins dessous". Does the original string need changing? Similarly the "bottom" -> "dessus" translation for: #: src/verbs.cpp:887 msgid "Cut the bottom object into pieces" msgstr "Découper l'objet de dessus en morceau" (and should it be morceaux ?) #: src/interface.cpp:925 msgid "Leave Group" msgstr "Laisser le groupe" "Quitter" ? I believe this string means "stop editing this group", i.e. "close group" in xfig; the opposite of "Enter group" / "Entrer dans le groupe". So perhaps "Sortir du groupe". Finally, appended are some diffs to check. Thanks in advance for correcting my french & improving the french translation. Comments on French-speaking web sites show that people do appreciate recent French translation work. pjrm. Index: fr.po =================================================================== RCS file: /cvsroot/inkscape/inkscape/po/fr.po,v retrieving revision 1.49 diff -d -u -r1.49 fr.po --- fr.po 27 Jul 2004 11:53:50 -0000 1.49 +++ fr.po 1 Aug 2004 09:14:48 -0000 @@ -1,5 +1,3 @@ -# translation of fr.po to -# translation of fr.po to # translation of fr.po to Français # French translation of Inkscape. # Copyright (C) 2000-2003, 2004 Free Software Foundation, Inc. @@ -90,14 +88,14 @@ "\n" "If you close without saving, your changes will be discarded." msgstr "" -"<span weight=\"bold\" size=\"larger\">Enregister les changements du " +"<span weight=\"bold\" size=\"larger\">Enregistrer les changements du " "document \"%s\" avant de fermer ?</span>\n" "\n" -"Si vous fermez sans enregistre vos changements seront perdus." +"Si vous fermez sans enregistrer, vos changements seront perdus." #: src/desktop.cpp:1078 src/desktop.cpp:1137 msgid "Close _without saving" -msgstr "Fermer _sans enregister" +msgstr "Fermer _sans enregistrer" #: src/desktop.cpp:1122 #, c-format @@ -109,7 +107,7 @@ msgstr "" "<span weight=\"bold\" size=\"larger\">Le fichier \"%s\" a été enregistré dans un format (%s) qui peut causer des pertes de données !</span>\n" "\n" -"Voulez vous enregistrer ce fichier dans un autre format ?" +"Voulez-vous enregistrer ce fichier dans un autre format ?" #: src/desktop.cpp:1486 msgid "No previous zoom." @@ -418,7 +416,7 @@ #: src/dialogs/display-settings.cpp:201 msgid "When transforming, show:" -msgstr "Lors des transformations afficher :" +msgstr "Lors des transformations, afficher :" #: src/dialogs/display-settings.cpp:212 msgid "Objects" @@ -495,7 +493,7 @@ msgid "" "Rotating with Ctrl pressed snaps every that much degrees; also, pressing " "[ or ] rotates by this amount" -msgstr "Les rotations avec Ctrl appuyé sont de tan de degrés; ensuite en appuyant sur [ ou ], les rotations ce font de cette valeur" +msgstr "Les rotations avec Ctrl appuyé sont de tan de degrés; ensuite en appuyant sur ‘[’ ou ‘]’, les rotations ce font de cette valeur" #: src/dialogs/display-settings.cpp:386 msgid "Rotation snaps every:" @@ -506,7 +504,7 @@ "None: dialogs are treated as regular windows; Normal: dialogs stay on top of " "document windows; Aggressive: same as Normal but may work better with some " "window managers." -msgstr "Aucun : les dialogues sont traités comme des fenêtres; Normal :les dialogues restent sur la fenêtre du document; Agressif : comme Normal, mais marche mieux avec certain gestionaire de fenêtre." +msgstr "Aucun : les dialogues sont traités comme des fenêtres; Normal : les dialogues restent sur la fenêtre du document; Agressif : comme Normal, mais marche mieux avec certain gestionaire de fenêtre." #: src/dialogs/display-settings.cpp:430 msgid "Normal" @@ -791,7 +789,7 @@ "Zoom drawing when document window is resized, to keep the same area visible " "(this is the default which can be changed in any window using the button " "above the right scrollbar)" -msgstr "Le dessin est rezoommé lors que le fenêtre est redimentionné, pour garder la même aire visible (c'est l'option par défaut qui peut être changé dans n'importe quelle fenêtre en utilisant le boutton au dessus de la barre de défilement de droite)" +msgstr "Le dessin est rezoommé lors que la fenêtre est redimentionné, pour garder la même aire visible (c'est l'option par défaut qui peut être changé dans n'importe quelle fenêtre en utilisant le boutton au dessus de la barre de défilement de droite)" #. Clones #: src/dialogs/display-settings.cpp:1024 src/dialogs/find.cpp:561 @@ -827,7 +825,7 @@ "Each clone moves according to the value of its transform= attribute. For " "example, a rotated clone will move in a different direction than its " "original." -msgstr "Chaque clones est déplacé en fonction de ça transformation = attribut. Par exemple, un clone tourné va être déplacé dans une direction différente de l'original." +msgstr "Chaque clone est déplacé en fonction de son attribut ‘transform=’. Par exemple, un clone tourné va être déplacé dans une direction différente de l'original." #: src/dialogs/display-settings.cpp:1060 msgid "When the original is deleted, its clones:" @@ -890,7 +888,7 @@ msgid "" "If possible, apply transformation to objects without adding a transform= " "attribute" -msgstr "Si possible, appliquer la transformation aux objets sans ajouter de transformation = attribut" +msgstr "Si possible, appliquer la transformation aux objets sans ajouter d’attribut ‘transform=’" #: src/dialogs/display-settings.cpp:1138 msgid "Preserved" @@ -898,7 +896,7 @@ #: src/dialogs/display-settings.cpp:1138 msgid "Always store transformation as a transform= attribute on objects" -msgstr "Toujours enregistrer la transformation comme une transformation = attribut de l'objet" +msgstr "Toujours enregistrer la transformation comme un attribut ‘transform=’ de l'objet" #. To be broken into: Display, Save, Export, SVG, Commands #: src/dialogs/display-settings.cpp:1146 @@ -1196,7 +1194,7 @@ #: src/dialogs/find.cpp:631 msgid "Find objects by their text content (exact or partial match)" -msgstr "Rechercher des objets par le texte qu'il contiennent (exact ou partiel)" +msgstr "Rechercher des objets par le texte qu'ils contiennent (exact ou partiel)" #: src/dialogs/find.cpp:632 msgid "_ID: " @@ -1742,14 +1740,14 @@ #: src/draw-context.cpp:1834 msgid "Finishing pen" -msgstr "Terminier le crayon" +msgstr "Terminer le crayon" #. alpha of color under cursor, to show in the statusbar #. locale-sensitive printf is OK, since this goes to the UI, not into SVG #: src/dropper-context.cpp:271 #, c-format msgid " alpha %.3g" -msgstr " alpha % 3g" +msgstr " alpha %.3g" #. where the color is picked, to show in the statusbar #: src/dropper-context.cpp:273 @@ -1787,7 +1785,7 @@ #: src/extension/internal/eps-out.cpp:82 msgid "Make bounding box around full page" -msgstr "Faire une boite tout au tour de la page" +msgstr "Faire une boite tout autour de la page" #: src/extension/internal/eps-out.cpp:90 msgid "Convert text to path" @@ -1820,8 +1818,8 @@ "file size and can be arbitrarily scaled, but alpha transparency, gradients " "and patterns will be lost." msgstr "" -"Utiliser les opérateurs vectoriels PostScript, l'image résultante sera (en " -"général) plus petite tout en restant redimentionnable; par contre, la " +"Utiliser les opérateurs vectoriels PostScript. Le fichier d'image résultant sera (en " +"général) plus petit tout en restant redimentionnable; par contre, la " "transparence alpha, les dégradés, les marqueurs et les motifs de remplissage seront perdus." #: src/extension/internal/ps.cpp:139 @@ -1834,7 +1832,7 @@ "size and cannot be arbitrarily scaled without quality loss, but all objects " "will be rendered exactly as displayed." msgstr "" -"Tout imprimer en tant que bitmap, l'image résultante sera (habituellement) plus grande et sa qualité dépend du facteur de zoom; Mais tous les graphismes " +"Tout imprimer en tant que bitmap. Le fichier d'image résultant sera (habituellement) plus grand et sa qualité dépend du facteur de zoom; Mais tous les graphismes " "seront rendus identiques à l'affichage." #: src/extension/internal/ps.cpp:155 @@ -1878,7 +1876,7 @@ #: src/file.cpp:184 #, c-format msgid "Changes will be lost! Are you sure you want to reload document %s?" -msgstr "Les changements vont être perdu ! Êtes-vous sûr de vouloir recharger le document %s ?" +msgstr "Les changements vont être perdus ! Êtes-vous sûr de vouloir recharger le document %s ?" #: src/file.cpp:203 msgid "Document reverted." @@ -1901,7 +1899,7 @@ msgid "" "No Inkscape extension found to save document (%s). This may have been " "caused by an unknown filename extension." -msgstr "Pas d'extensions Inkscape trouvé pour enregistrer le document (%s). Cela peut venir du fait que l'extension est inconnue." +msgstr "Pas d'extensions Inkscape trouvé pour enregistrer le document (%s). Cela peut venir du fait que l'extension est inconnue." #: src/file.cpp:313 src/file.cpp:319 msgid "Document not saved." @@ -1940,7 +1938,7 @@ #: src/help.cpp:55 msgid "about.svg" -msgstr "à propos de svg" +msgstr "about.svg" #: src/help.cpp:71 src/verbs.cpp:1033 msgid "About Inkscape" @@ -2075,7 +2073,7 @@ msgid "" "Automatic backups of unsaved documents were done to the following " "locations:\n" -msgstr "Les enregistrments automatiques des documents non enregistrés sont effectuées à cet emplacement : \n" +msgstr "Les enregistrments automatiques des documents non enregistrés sont effectuées à cet emplacement :\n" #: src/inkscape.cpp:494 msgid "Automatic backup of the following documents failed:\n" @@ -2159,8 +2157,8 @@ "Although Inkscape will run, it will use default settings,\n" "and any changes made in preferences will not be saved." msgstr "" -"Toutes fois Inkscape va démarrer, il va utiliser les paramètre par défaut,\n" -"et toutes les modifications de préférences ne seront pas enregistré." +"Bien qu'Inkscape va démarrer, il va utiliser les paramètre par défaut,\n" +"et toutes les modifications de préférences ne seront pas enregistrés." #: src/interface.cpp:605 msgid "Open _Recent" @@ -2224,7 +2222,7 @@ #: src/interface.cpp:827 msgid "Interactive Inkscape tutorials" -msgstr "Tutoriel interactifs d'Inkscape" +msgstr "Tutoriaux interactifs d'Inkscape" #: src/interface.cpp:853 msgid "_File" @@ -2268,7 +2266,7 @@ msgid "" "The file %s already exists. Do you want to overwrite that file with the " "current document?" -msgstr "Le fichier %s existe déjà. Voulez vous que le document courant écraser ce fichier ?" +msgstr "Le fichier %s existe déjà. Voulez-vous que le document courant écrase ce fichier ?" #: src/knot.cpp:567 msgid "Node or handle drag canceled." @@ -2521,7 +2519,7 @@ #: src/path-chemistry.cpp:73 msgid "You cannot combine objects from different groups or layers." -msgstr "Vous ne pouvais pas combiner des objets de différents groupes ou calques." +msgstr "Vous ne pouvez pas combiner des objets de différents groupes ou calques." #: src/path-chemistry.cpp:157 msgid "Select some path(s) to break apart." @@ -2603,7 +2601,7 @@ #: src/selection-chemistry.cpp:253 msgid "You cannot group objects from different groups or layers." -msgstr "Vous ne pouvais pas grouper des objets de différents groupes ou calques." +msgstr "Vous ne pouvez pas grouper des objets de différents groupes ou calques." #: src/selection-chemistry.cpp:301 msgid "Select a group to ungroup." @@ -2620,7 +2618,7 @@ #: src/selection-chemistry.cpp:408 src/selection-chemistry.cpp:486 msgid "You cannot raise/lower objects from different groups or layers." msgstr "" -"Vous ne pouvais pas faire remonter/descendre des objets de différents " +"Vous ne pouvez pas faire remonter/descendre des objets de différents " "groupes ou calques." #: src/selection-chemistry.cpp:452 @@ -2689,7 +2687,7 @@ #: src/selection-chemistry.cpp:1507 msgid "No pattern fills to untile in the selection." -msgstr "motif de remplissage dans la sélection à dépaver." +msgstr "Pas de motif de remplissage dans la sélection à dépaver." #: src/selection-describer.cpp:30 msgid "Click selection to toggle scale/rotation handles" @@ -2881,7 +2879,7 @@ #. TRANSLATORS: "to outline" means "to convert stroke to path" #: src/splivarot.cpp:738 msgid "No stroked paths to outline in the selection." -msgstr "Pas de chemin à agrandir dans la sélection." +msgstr "Pas de chemin tracé dans la sélection." #: src/splivarot.cpp:825 msgid "Selected object is not a path, cannot inset/outset." @@ -2928,7 +2926,7 @@ #: src/text-context.cpp:432 msgid "Non-printable character" -msgstr "Caractère non Imprimable" +msgstr "Caractère non imprimable" #: src/toolbox.cpp:380 msgid "Insert new nodes into selected segments" @@ -3237,7 +3235,7 @@ #: src/verbs.cpp:805 msgid "Revert to the last saved version of document (changes will be lost)" -msgstr "Recharger le dernier enregistrement du document (les changement serons perdu)" +msgstr "Recharger le dernier enregistrement du document (les changements seront perdus)" #: src/verbs.cpp:806 msgid "_Save" @@ -3305,7 +3303,7 @@ #: src/verbs.cpp:822 msgid "P_revious Window" -msgstr "F_enêtre d'aperçus" +msgstr "Fenêtre p_récédante" #: src/verbs.cpp:823 msgid "Switch to the previous document window" @@ -3887,7 +3885,7 @@ #: src/verbs.cpp:995 msgid "D_uplicate Window" -msgstr "D_upliquer le fenêtre" +msgstr "D_upliquer la fenêtre" #: src/verbs.cpp:995 msgid "Open a new window with the same document" @@ -4045,7 +4043,7 @@ #: src/verbs.cpp:1039 msgid "Advanced Inkscape tutorial" -msgstr "Tutorial avancés d'Inkscape" +msgstr "Tutorial avancé d'Inkscape" #. "tutorial_advanced" #: src/verbs.cpp:1040 @@ -4063,7 +4061,7 @@ #: src/verbs.cpp:1043 msgid "Miscellaneous Tips and Tricks" -msgstr "Divers truc et astuces" +msgstr "Divers trucs et astuces" #: src/widgets/dash-selector.cpp:104 msgid "Dash pattern"

2 2

CVS autogen error
by Florent 02 Aug '04

02 Aug '04

Hi all, I've tried to compile the latest CVS; but an error appear : After a while, I made a "rm -rf inkscape" and an "./autogen.sh" and this give me the error : checking for autoconf >= 2.52 ... yes (version 2.59) checking for automake >= 1.7 ... yes (version 1.8.5) checking for glib-gettextize >= 2.0.0 ... yes (version 2.4.4) checking for intltool >= 0.17 ... yes (version 0.30) Running aclocal-1.8 ... Running autoheader ... Running automake-1.8 --add-missing ... configure.in: installing `./install-sh' configure.in: installing `./missing' configure.in:5: installing `./config.guess' configure.in:5: installing `./config.sub' Makefile.am: installing `./INSTALL' configure.in:25: required file `./ltmain.sh' not found src/Makefile.am: installing `./depcomp' Please fix the error conditions and try again.

3 5

Linux Journal link
by Robert Crosbie 01 Aug '04

01 Aug '04

I get the digest so excuse me if this has already been posted: http://linuxjournal.com/article.php?sid=7564 Check out the first post: "The Gimp wins in the graphics category again, it seems like it always does but Inkscape is getting really good, maybe next year?" Cheers, Rob. http://members.rogers.com/rcrosbie _________________________________________________________________ Take charge with a pop-up guard built on patented Microsoft� SmartScreen Technology http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht… Start enjoying all the benefits of MSN� Premium right now and get the first two months FREE*.

1 0

Re: sp-typeset
by bulia byak 01 Aug '04

01 Aug '04

> i will reuse a lot of it for flowtext stuff, that's a > given. the purpose of the SPTypeset object, though, > was to be a testbed for flowtext stuff, and an object > to which you would give marked-up text like LaTeX > source or RTF and get a nice layout of it. this last > part is a huge amount of work... i advise for a > removal for simplification of the codebase, and to > avoid confusions with SVG flowtext. OK, that makes sense. > that is also a big amount of work, unless some parts > of it can be lifted from a preexisting text editor. i > feel sorry for the guy who will have to do it. It's not really that bad, imho. I thought about how to do it, and I'm definitely willing to give it a try when I have more free time. Just a child of text-context holding the start and end character positions of the selection in the text object, and a list of canvas items, each being an inversion rectangle overlaying one character. The tricky part is how to make it so that when you choose a color (by whatever means) it gets applied to the text selection instead of the entire selected text object, but there is now a solution for that: desktop issues _style_signal for any style change, and the text selection would intercept that signal and apply the style to the text selection (creating tspan(s) as needed); and when the signal is intercepted, the style is not applied to the selected objects (see sp_desktop_set_style in desktop.cpp). So it's doable. > wrt > mathematical markup, i was more thinking to stuff like > indices/exponents: dx/dy give you the possibility to > do either exponent or indices, not both. Not to > mention the cases where you want the text to be > stacked below some other piece of text. this is where > latex shines. the simplest solution is probably to do > some sort of "Equation Service" > (http://www.esm.psu.edu/mac-tex/EquationService/) with > the scripting possibilities of inkscape, and insert > the complex stuff as images in the flowtext. Yes, it would be cool. Just build a robust chain of tools to do TeX -> PS -> SVG conversion, and automatically run it and import into a <g> with an inkscape: attribute storing the source TeX code, with a command to edit it. Worth an RFE, and would not be very difficult to implement. Except that such "embedded TeX" will not be able to be part of an SVG text object, but only an independent object. > the problem on osx is having several trees with unix > software cohabitating with each other. since i have a > fink tree with all my gnome stuff, installing gtkmm2.4 > and friends requires me to either package it myself > (no thanks) or to mess with the install and header > search paths (my previous attempts were complete > failures). in any case it's simpler and safer to just > wait for fink to get up to date. I really hope they will get up to date soon. We need you :) > regarding my flowtext work, here is a patch made > against the 0.39 release. Thanks, I will apply it ASAP. > flowtref, flowlinebreak and flowimage are missing, but > it's already able to eat styled text and handle > bidirectionality. it would be good for me if someone > could put it in the CVS tree and give it some > exercise, so that bugs get apparent. since flowtext > has the same text/tspan structure, parts of this patch > can also have some use for the current text implementation. Great, I will test it and report what I find.

2 4

Inkscape CVS on SuSE 9.1
by Bryce Harrington 01 Aug '04

01 Aug '04

I've compiled Inkscape on SuSE 9.1; I made a list of the changes I needed to do for getting all the deps & configuration issues in the SuSE section of: http://inkscape.org/cgi-bin/wiki.pl?CompilingInkscape Bryce

1 0

Re: [Sodipodi-list] thanks
by Jon Phillips 01 Aug '04

01 Aug '04

What version of inkscape did you try? Can anyone help Jimmy? Jon On Mon, 2004-08-02 at 00:23, Jimmy James wrote: > --- Jon Phillips <jon@...235...> wrote: > > > Try inkscape!!! > > > > www.inkscape.org :: Open Source SVG Editor as > > well... > > > > Jon > > > >I got a good feeling when I saw the installed > inkscape program. I tried to draw a rectangle and the > program just hanged up. I rebooted and tried the star > tool and it hanged up again. I rebooted. > I am using yoper version 2 operating system. > a little work on the inkscape probably will be a > good if not a perfect substitute to CorelDraw. > thanks again. > > Jimmy > > > > __________________________________ > Do you Yahoo!? > New and Improved Yahoo! Mail - Send 10MB messages! > http://promotions.yahoo.com/new_mail -- Jon Phillips PO BOX 948667 LA JOLLA, CA 92037 USA USA.PH.858.361.2811 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/)

1 0

FINK + MAC OS X + INKSCAPE
by Jon Phillips 01 Aug '04

01 Aug '04

Hello all, I had a chat with FINK developers (http://fink.sf.net) about our new dependencies. Here is what they said about gtkmm 2.4 which is in their unstable: (05:06:19) dmacks: "unstable" is actually quite stable, it's just users are typically too lazy to send positive feedback to let us know it works right. (05:06:53) dmacks: unstable + positive-feedback --> stable; stable in the next week or so --> in the next bindist. So, our OS X users/developers should use the unstable packages and give feedback to help push these packages into stable. Also, I hopefully convinced them to push to stable quicker. Also, for those wanting Boehm: search for gc jon -- Jon Phillips PO BOX 948667 LA JOLLA, CA 92037 USA USA.PH.858.361.2811 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/)

1 0

inkscape google search + articles
by Jon Phillips 01 Aug '04

01 Aug '04

Hello all, Sometimes it is interesting to run a google search on Inkscape after a release and see what is/has been written. I found this review of the app and there is talk that the Win32 version of Inkscape is only avail. in English. Is this true? http://www.framasoft.net/article2711.html Here is someone who has written a Mac OS X launcher for Inkscape: http://www.coswellproductions.org/index.php/code/inkscape_mac_os_x_launcher… Mac OS X portfile: http://inkscape.darwinports.com/ Interesting site of reviewers: http://www.stumbleupon.com/url/www.inkscape.org/ Next, Jon -- Jon Phillips PO BOX 948667 LA JOLLA, CA 92037 USA USA.PH.858.361.2811 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/)

3 2

Inkscape and the Gimp, gradients.
by Alan Horkan 31 Jul '04

31 Jul '04

Those of you who are also on the OpenClipart.org mailing list may have noticed that the Gimp now allows the use of SVG Gradients. http://bugzilla.gnome.org/show_bug.cgi?id=148127 The support is in CVS and there has not yet been a release that has included but there should be another 2.1.x release soon. Sven Neuman added the feature, and I'm well pleased. Now I'll be able to use the same files for both Inkscape and Gimp and use a standardised file format. The gradient file can contain a single gradient or multiple gradients. The parser has some flexibility with regards to the formatting used by the gradients. The gradients are read only for now. Another recently added feature that I requested was support for using standard file formats for Patterns. As GDKPixbuf was used and because there is an option to use librsvg to add SVG support to GDKpixbuf it should be possible to use SVG patterns directly in the Gimp too. http://bugzilla.gnome.org/show_bug.cgi?id=140443 Futher testing of and feedback on the SVG Gradient support would be very much appreciated. DND support could be added in time but it will require work from Inkscape. Sven would like to do this if Inkscape developers will do the necessary work on their side, and he asked me to pass on that request. I'm in a bit of a hurry otherwise i would have phrased this better and more clearly. There is also the distinct possibility that this account will be temporarily unavailable due to maintainance for the next few days so I may have to catch up on Monday or sign up with a different account. Sincerely Alan Horkan http://advogato.org/person/AlanHorkan/

2 2

using SVG-View Widget in gtkmm apps
by John Taber 31 Jul '04

31 Jul '04

First let me say what a great job the whole development team is doing - Inkscape is one of the best open source projects going. And it lets a non-artist like me make decent looking icons - it's simply fun to use. I would like to use SVG in a gtkmm geographic mapping application - is the SVG View Widget part of the gtk toolset now ? Does it use librsvg to blt back the svg or does it have it's own renderer ? (I tried to follow the code but got lost). Thks. John

2 1

[Fwd: Fwd: BOF: Inkscape: An Open Source Vector Graphics (SVG) Editor Overvi ew]
by Jon Phillips 31 Jul '04

31 Jul '04

SIGGRAPH BOF confirmed to my gmail account, arg! JC (not Jesus Christ, but JonCruz) are going to run a Birds of a Feather (BOF) meeting at SIGGRAPH on MON AUG 9. I'm pulling together notes and PR for this this weekend. FYI. I have a link for free passes to anyone in the LA area for this. Bryce and Co, are you going to have an Inkscape BOF at OSCON2004 in Portland? Jon -----Forwarded Message----- > From: jon phillips <phillipsjd@...400...> > To: jon@...235... > Subject: Fwd: BOF: Inkscape: An Open Source Vector Graphics (SVG) Editor Overvi ew > Date: Wed, 28 Jul 2004 21:34:26 -0700 > > ---------- Forwarded message ---------- > From: Villalba, Marisa <mvillalba@...481...> > Date: Tue, 27 Jul 2004 12:03:20 -0500 > Subject: BOF: Inkscape: An Open Source Vector Graphics (SVG) Editor Overvi > ew > To: "phillipsjd@...400..." <phillipsjd@...400...> > Cc: "Villalba, Marisa" <mvillalba@...481...>, "Milgram, Alison" > <amilgram@...481...>, "sandramachuca@...127..." > <sandramachuca@...127...>, "GERRAW@...482..." > <gerraw@...483...> > > > Hi Jon > > Below if you official email confirmation for your BOF to be held at > the Holiday Inn City Center. Your contact at the hotel is Sandra > Machuca and I have copied her on this email. Please work directly with > her on any food/beverage or AV you would like to order for your > meeting. Also I did not indicate the room set you required since on > BOF meeting request form you listed several setups you were fine with. > Please let Sandra know which setup you would like. > Also you have missed the deadline to have your BOF listed in the > Program and Buyer's guide and kiosk but I will get your BOF added to > the website today. > > Thanks > Marisa > > > > 27 July 2004 > > Dear Jon > > > Thank you for your interest in participating in SIGGRAPH 2004. We are > excited to be back in the city of Los Angeles and look forward to > another successful event. This is the official confirmation letter for > the assignment of space for your meeting. > > > Please review the information below carefully: > > Group Name: Inkscape: An Open Source Vector Graphics (SVG) Editor Overview > Organization: Inkscape > Contact: Jon Phillips > > Address: > PO Box 948667 > La Jolla CA 92037 > United States, CA > > > Telephone: 858-361-2811 > Fax: not entered > Email: phillipsjd@...400... > > Location: Holiday Inn City Center > Room: Santa Monica > Reservation Time: 3:30pm-5:30pm > > Meeting Time: 4pm-5pm > > Date : Monday, 9 August > > > Room Setup: TBD > Attendance: 20 > > Hotel Contact: Sandra Machuca > Phone: 213-743-7621 x6617 > > Please instruct the contact(s) listed above regarding room setup, > food/beverage and any other special requirements you may have. Please > be aware that the group is responsible for all charges related to this > function. > > If you require audio visual services, we would like to recommend AVW, > the official audio visual vendor of SIGGRAPH 2004. You may contact > Wylie Gerrard via email at GERRAW@...484... > > Any changes of date or time and all cancellations MUST be made in > writing NO LATER THAN 19 July 2004 to my attention at the address > below or via e-mail. SIGGRAPH 2004 reserves the right to reassign > meeting space as necessary. > > If you have any questions, don't hesitate to get in touch. We look > forward to seeing you at SIGGRAPH 2004! > > Sincerely, > Marisa Villalba > SIGGRAPH Conference Management > Fax +1.312.673.6980 > mvillalba@...481... -- Jon Phillips PO BOX 948667 LA JOLLA, CA 92037 USA USA.PH.858.361.2811 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/)

2 1

compiling CVS on windows
by John Cliff 31 Jul '04

31 Jul '04

Hi all, Just to let you know current CVS doesnt want to compile on native windows currently, got the latest libaries from bobs site, tried dling the latest mingw, but no joy. keep getting a bunch of token errors. The builds done by the cross compiler work fine, but aren't much help for doing devel. cheers John __________________________________ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail

1 0

external binaries ?
by herve couvelard 30 Jul '04

30 Jul '04

Hello, I use inkscape almost everydays. that is a really great application. I convert all the windows users at my office to linux users. That was not that hard. I was 'forced' :-) to convert them from paintshoppro/illustrator to inkscape. That was quite easy too. Inkscape is such an friendly-user-app. We use it for cartography means : drawing polygons on rasters images. ok let's come to the question : Would it be possible to 'execute' an external binary on the active document? i read every mails for such a long time and aware (it's good to be aware) of the coming extension stuff. how will it work ? would it be possible to provide a 'simple' binary that do the job and just put it in some place ? (like C or C++ or whatever) what could the junction with inkscape be ? will all the changes made by the binary be updated in the preview immedilately ? how could that come from a menu in inkscape ? ok... why all these question ?? in fact i will have some times and needs in adding new features related to GIS (of course openGis specs compliant) and some new 'magic' operation such areas and so... the problems is i am not a c nor c++ prog as anyone on the list. I am realy used to php and web. I started to implement these operations on php-web-based : you upload the file and the not-that-magic-stuff was done. i am considering to make a php extension for that and therefore it could be, for some, inkscape-inside implemented. BUT (here comes the BUT again..) i can not dive into inkscape (i have not enought time to do it) and i am not sufficiently competent to do it and i didn't succeded in having a configure-make-ready-box for inkscape (very much dependances on a redhat 9). the easy way would be such an extension stuff and when it works as expected someone with much more skills could add a new stuff in inkscape open-gis related. Sorry for that long and bad-english mail. What do you think of it ? hervé

6 9

0.39 release tells me 0.39cvs
by Taraben, Adib 29 Jul '04

29 Jul '04

When I use the inkscape win32 0.39 release (either zip or exe) I get the xml document attributes: inkscape:version 0.39cvs I wonder why? Adib.

6 5

File-open dialog with a text field
by Bob Jamison 29 Jul '04

29 Jul '04

Here is a screenshot of a first attempt at adding a text entry of the file name to the file open dialog. http://troi.titan-aeu.com/~rjamison/inkscape/files/filedialog2.png The events for selection changed--->text field and text field <return> ---->selection ...have already been connected. I am sure that we will tweak this a lot during this cycle, but at least this shows that modifications to suit our needs can easily be accomplished. What I am really anticipating is the use of the same code for all architectures. Bob

5 15

Thoughts about Patterns
by cedric 29 Jul '04

29 Jul '04

Hi everybody, Working on the Edit Menu part of the Manual (done but in french only, english version on CVS before end of July), i've made different tests on clone and patterns. These are great functionnalities. One may find pattern samples in the joined file. May be it could be incorporated as a library (the same way markers did). I leave it to our great developers. But, if alloweded, some things appeared to be difficult for me : - first of all : when creating many patterns, it is hard to remember the creation order, so that i've been 'confused' in the fillsettings dialog. Because there is no preview of the pattern in the dropdown menu, one may wish to name the pattern without using XML editor (some don't like coding!! or don't understand SVG at all) : may be the best could be to make a dialog appear to enter a name just after using the Edit/tile command. - second : The original object is set to rect filled with the pattern. It is OK, but often, i don't need it anymore in the drawing. It could be hidden. - third : (and it is not due to pattern filling i think but) but when a pattern is not used anymore, it is automatically cleared from defs. But should I always really want to remove it ? The autoClean functionnality is very good, but we may find rules about its use. I will now be working on a Symbol (clone) Library. I'll see from Sodipodi, I guess they've done may things this way since few months. Thanks a lot. Cedric

3 3

Compiling libGC with c++ support
by Steven P. Ulrick 29 Jul '04

29 Jul '04

Hello, Everyone :) While attempting to update Inkscape from CVS, I discovered the new dependency on libgc. I eventually found what I think is the right package: libGC-0.3-1.tar After untarring it, I ran ./configure --help, and I found nothing about how to compile libgc with c++ support. I proceeded to read README and INSTALL in the libGC directory, and I found nothing helpful. I then checked the Inkscape news groups, where I found references to the new libgc dependency, references to compiling with c++ support, but nothing about HOW to compile with c++ support. My next step was to subscribe to this list and ask this question :) I am running Fedora Core 2 with all official updates installed. This is a full installation, not an upgrade, and I chose to install EVERY package. Also, the prefix that I am attempting to compile libgc for is the same one that I am compiling Inkscape for: /usr If I've left anything out, please let me know, and I'll be glad to provide that information. For your information, I had been successfully compiling Inkscape on this system up till and including my last attempt preceding the addition of the libgc dependency. Oooops, almost forgot the error message I get when I attempt to configure Inkscape. I got the exact same message before and after my attempts at installing libgc: checking for GC_malloc in -lgc... no configure: error: libgc (the Boehm Conservative Collector), built with C++ support, is needed to compile inkscape In conclusion, my installation of libGC appeared to succeed, but since I didn't know how to build it with C++ support, I got the error message quoted above. Anyway, let me know if you need any more information on this. Steven P. Ulrick

4 5

To outline?
by Karl Ove Hufthammer 28 Jul '04

28 Jul '04

I've looked, but couldn't find where the message 'Select some paths to outline.' is used in the UI. The translators comment says that '"to outline" means "to convert stroke to path"'. Isn't this the same as the 'Convert stroke to path' command? The reason I'm asking is that I'm wondering what words to use in my translation. -- Karl Ove Hufthammer

3 2

Two small errors in 'Basic' tutorial
by Karl Ove Hufthammer 28 Jul '04

28 Jul '04

I'm currently translating the 'Basic' tutorial, and found two small errors: One place it says: The commands to open dialogs are all in the Dialogs menu [...] There are no such menu (anymore). And near the top it talks about the 'Help | Keys and mouse' menu-item, but the rest of the menu-items are written with a '>', e.g. 'File > New'. It should be changed to be consistent. (Personally I prefer a '|' everywhere. But perhaps there are style guidelines for this in GNOME?) -- Karl Ove Hufthammer

2 2

New language
by Arpad Biro 28 Jul '04

28 Jul '04

Hi, A new translation file, nn.po has been committed. I also modified (inserted the "nn" language ID) configure.in and po/Makefile.mingw. Please let me know if something else needs to be done. Arpad Biro __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

3 4

Article mentioning Inkscape
by Bob Jamison 28 Jul '04

28 Jul '04

I noticed another mention of Inkscape here: http://www.newsforge.com/article.pl?sid=04/07/19/214206 Bob

5 5

heartfelt thanks for creating inkscape (fwd)
by Bryce Harrington 28 Jul '04

28 Jul '04

---------- Forwarded message ---------- Date: Sun, 25 Jul 2004 21:38:55 -0400 From: Phil Shapiro <pshapiro@...467...> To: <bryce@...1...> Subject: heartfelt thanks for creating inkscape thanks a megabyte for your visionary work in creating inkscape. i discovered this amazing software last week and have been talking it up on various national email lists i'm on. (see below a message i sent this evening to the list of Community Technology Centers' Network - CTCNet), one of the largest nonprofit organizations working to bridge the digital divide.) CTCNet's annual conference is going to be in cleveland in june, 2005, in case you (or any of the othe inkscape developers) might be in the area at that time. it's likely more than 1000 technology access activists will be attending this conference. stephen quinn is the wonderful person organizing this conference. squinn@...468... thanks again. you've inspired many by creating inkscape and your creation will unleash a river of artistic creativity by many who cannot afford a commercial vector drawing program. - phil shapiro arlington, virginia ----- Forwarded message from Phil Shapiro <pshapiro@...467...> ----- Date: Sun, 25 Jul 2004 19:33:28 -0400 (EDT) From: Phil Shapiro <pshapiro@...467...> Reply-To: Phil Shapiro <pshapiro@...467...> Subject: [CTC] become known for teaching open source graphics software To: "" <ctcmembers@...468...> hi everyone - is your organization doing cool things with low-cost or no-cost graphics drawing software, such as http://www.inkscape.org? if so, one way to get public visibility for your pioneering work is to create some tutorials or articles for the graphics section of about.com. see http://graphicssoft.about.com/library/nosearch/blucsubmit.htm for example, tap into the creative talents of youth or adults at your center to create some beautiful art using inkscape. then use camtasia studio 2 (for windows) to create some narrated flash tutorials explaining how others can use the drawing tools in inkscape to create their own drawings. in these tutorials explain both the technical use of the drawing tools and explain artistic tips and techniques. people will be very grateful to learn both kinds of knowledge. create these tutorials in english and spanish, but also in vietnamese, amharic and korean. place these tutorials on the web and link to them from your organization's web site. submit them to the about.com graphics web site. after about.com accepts your submission (they probably will if has merit), send out a press release that your organization is helping to teach the world how to use open source drawing software. is there a journalist who would find it interesting to write a story that explains how the youths and adults at a nonprofit organization are creating knowledge to help unleash creativity and empowerment for people worldwide using no-cost software that anyone can use on donated computers? yes, i think there is. would a television station find it easy to do a news story where there is readily available, beautiful graphics that is an integral part of a story of community members teaching each other things? yes, it would. - phil what kind of art can you create with vector drawing programs? this gallery shows some nice examples. http://www.eazydraw.com/gallery.htm macromedia flash. adobe illustrator and macromedia freehand are all vector drawing programs, too. for extra credit points, organize a community event at a community meeting place (outside of your own site) where a no-cost workshop explains how to use a no-cost drawing programs. an appropriate title for such an event would be: "drawing the community together." would local civic leaders take notice of such a workshop? yes, they would. -- Phil Shapiro pshapiro@...467... http://www.his.com/pshapiro/ (personal) http://teachme.blogspot.com (weblog) http://guitarlessons.blogspot.com/ (guitar lessons) "Wisdom starts with wonder." - Socrates ------------------------------------------------ To unsubscribe, send a message to majordomo@...468... with the message: unsubscribe ctcmembers youremailaddresshere ----- End forwarded message ----- -- Phil Shapiro pshapiro@...467... http://www.his.com/pshapiro/ (personal) http://teachme.blogspot.com (weblog) http://guitarlessons.blogspot.com/ (guitar lessons) "Everything you can imagine is real." - Pablo Picasso

2 1

Re: [Inkscape-devel] Navigating on the canvas and other things
by bulia byak 28 Jul '04

28 Jul '04

> >> It's crutial that it zooms in, right where the cursor points! > > > > Sure. I just don't have a wheel mouse otherwise I would have fixed > > this long ago. > > How do you survive? Tablet + pen :) Actually, the funny thing is that I did put in the code for mousewheel to zoom into cursor point, and I have no idea why it does not work. It's very simple, see the sp_desktop_zoom_relative_keep_point() call in src/event-context.cpp line 517. The same function works OK for zooming by middle-click (see line 380), it does zoom into cursor point. Maybe the event->scroll.x/y fields are bogus for a wheel event. If someone can have a look at it for me that would be nice.

1 0

[Fwd: [Inkscape-user] Can`t build inkscape from cvs]
by MenTaLguY 28 Jul '04

28 Jul '04

-----Forwarded Message----- From: Makurin Roman <koshka_enott@...473...> To: Inkscape User List <inkscape-user(a)lists.sourceforge.net> Subject: [Inkscape-user] Can`t build inkscape from cvs Date: Wed, 28 Jul 2004 02:52:52 +0400 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I can`t build inkscape from cvs on my gentoo box. Here my configuration: sys-devel/autoconf-2.59-r4 sys-devel/automake-1.8.5-r1 sys-devel/gcc-3.3.4-r1 sys-libs/glibc-2.3.4.20040619 x11-libs/gtk+-2.4.4 dev-cpp/gtkmm-2.4.3 Any advice ? - -- Registered Linux User: 355904 ICQ: 105266647 JID: drolyk@...189... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBBtzHufAZCWBpz4kRAqo8AJ9/6GYlf2mdKYWB3PA71PZWyxlu3QCeN9N1 h0sO2HO7knxDOz5YdyRowNg= =hn1s -----END PGP SIGNATURE-----

1 0

Re: [Inkscape-user] Make fails - freetype problem?
by MenTaLguY 28 Jul '04

28 Jul '04

On Tue, 2004-07-27 at 07:21, John Mellor wrote: > Well, thanks for that, but does anyone know how to fix it? Am I the only > one with this problem, and if so why? I uninstalled my freetype2 and > installed the latest - 2.1.9 - from source and the error is the same. > Do I need an older freetype2 or what? For now, probably. I'm using version 2.1.5. IIRC, the fix, basically, is to include <ft2build.h> before any other freetype headers ... however, I am not sure whether that will break the build with older freetype versions. :/ -mental

1 0

Gtk2.4/gtkmm2.4 file dialogs
by Bob Jamison 28 Jul '04

28 Jul '04

Hi all. I started on a new pair of file dialogs, using the new Gtk2.4 stuff for which we have been waiting. Here is a screenshot of a File Open dialog with Gtk::FileChooserDialog. http://troi.titan-aeu.com/~rjamison/inkscape/files/filedialog.png I haven't committed it yet, but it is mostly done. It just needs some tweaks. If this works well enough, then we can throw away the buggy Win32 dialogs in the next few days. Any opinions? Bob

11 32

Re: [Inkscape-devel] Preview for image import
by Bob Jamison 28 Jul '04

28 Jul '04

Alan Horkan wrote: > >Is Inkscape genrating that preview from scratch or displaying a thumbnail >already created by another application? > >- Alan > Inkscape is its own renderer! :-) Actually, I thought that I would have a little bit of fun with SVG. I made a tiny SVG template that is dynamically filled in with the image (scaled to fit with its aspect) , the rectangle around it, and the text that indicates its size. The svg preview displays it as though it is an SVG file. Here is the snippet of code that does the trick, if anyone would like to see it. Just match up the %s's and the %d's with the printf() below it, to make sense of it. Bob ======== SNIP SNIP SNIPPITY SNIP ======== //Our template. Modify to taste gchar *xformat = "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n" "<svg\n" "xmlns=\"http://www.w3.org/2000/svg\"\n" "xmlns:xlink=\"http://www.w3.org/1999/xlink\"\n" "width=\"%d\" height=\"%d\">\n" "<image x=\"%d\" y=\"%d\" width=\"%d\" height=\"%d\"\n" "xlink:href=\"%s\"/>\n" "<rect\n" "style=\"fill:none;fill-opacity:0.75000000;fill-rule:evenodd;" "stroke:#000000;stroke-width:4.0;stroke-linecap:butt;" "stroke-linejoin:miter;stroke-opacity:1.0000000;" "stroke-miterlimit:4.0000000;stroke-dasharray:none;\"\n" "x=\"%d\" y=\"%d\" width=\"%d\" height=\"%d\"/>\n" "<text\n" "style=\"font-size:24.000000;font-style:normal;font-weight:normal;" "fill:#000000;fill-opacity:1.0000000;stroke:none;stroke-width:1.0000000pt;" "stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1.0000000;" "font-family:Bitstream Vera Sans;\"\n" "x=\"10\" y=\"26\">%dw x %dh</text>\n" "</svg>\n\n"; //Fill in the template gchar *xmlBuffer = g_strdup_printf(xformat, previewWidth, previewHeight, imgX, imgY, scaledImgWidth, scaledImgHeight, fName, rectX, rectY, rectWidth, rectHeight, imgWidth, imgHeight);

1 0

Navigating on the canvas and other things
by unknown＠example.com 27 Jul '04

27 Jul '04

Hi Inkscape folks, I'll skip the part, of thanking you for the great software in my emails from now on (I haven' in most so far...). I want to make point out that inkscape has become my favourite vector graphics program... just for one last time :) So anyways, I could be writing this each time I use it... and of course each time I use it, there are things that I like to complain about. Don't take it personally or anything, I just believe that pointing out what I don't like will eventually help improving the software. Well... navigation. I always liked the navigation in inkscape. I was very much used to it and know it from other programs. The mouse wheel scrolls up and down, when holding ctrl (or is it shift?) left and richt, for alt it is zoom in and out. Now I have been using autoCAD for a while, and while I first was very much annoyed with it's behaviour, I now think it's superior. It's simple... the mousewheel zooms by default. I zoom out turning it towards me and in, rotating it away. It's crutial that it zooms in, right where the cursor points! Well... to navigate on the canvas you zoom out, drag the canvas (pressing middlebutton) and zoom in. This is very efficient, and the best way to navigate on the canvas, I have used so far, as soon, as one is a little used to it. Also compare RFE [ 950537 ]. What do you think? Is the rendering to slow, maybe? Has any of you experience with this kind of navigation? And: could it be implemented, either as default (it's a very good default!) or as an option? Also: should I file an RFE? Other problems: - How do I add a pattern. The only way I have found so far is to import an image... that is kinda stupid. the pattern dialog has to allow one to import a new pattern. - Inkscape crashes on me frequently (mostly while trying to copy objects)... I can't tell the reason, and I don't care too much, since I have wonderful backups. But opening these backups is quite complicated... could inkscape ask, if I want to restore the files, when I restart it? - And, of course: How is the progress on text editing? I think text is the weakest part of inkscape atm. Take care David

4 3

Preview for image import
by Bob Jamison 27 Jul '04

27 Jul '04

I added previews for some types of images. We could probably add others. Here is yet another screenshot :-) http://troi.titan-aeu.com/~rjamison/inkscape/files/filedialog4.png Bob

1 0

libgc dependancy
by MenTaLguY 27 Jul '04

27 Jul '04

Just a quick note that I've added a dependency on libgc. Things look OK except for one issue I'm not sure of ... Debian puts the libgc header files in /usr/include/gc (they're good about segregating library header files that way). I'm not sure whether other distros do that, however. Let me know if your distro puts them someplace else.. -mental

2 2

Re: Inkscape 0.39 Slackware package
by Bryce Harrington 27 Jul '04

27 Jul '04

On Mon, 26 Jul 2004, Eustaquio Rangel de Oliveira Jr. wrote: > Get them here: > > http://200.211.78.140/taq/downloads/inkscape-0.39-i386-1.tgz > http://200.211.78.140/taq/downloads/inkscape-0.39-i386-1.tgz.asc > > It's a 3.9mb package, please tell me when you download it because I need to > erase it. :-) I've added these to the SF file tracker, so you can remove them now. http://sourceforge.net/project/showfiles.php?group_id=93438 > Don't forget that people need to compile sigc 1.2 to use it (I have also > this package). > > I'll get the CVS code and compile it with sigc 2.x this week. Okay cool, let us know. Thanks, Bryce

1 0

Re: Inkscape 0.39 Slackware package
by Bryce Harrington 26 Jul '04

26 Jul '04

Cool, sure send it to me (or give me a URL) and I'll add it to the website with the other packages. Thanks, Bryce On Mon, 26 Jul 2004, Eustaquio Rangel de Oliveira Jr. wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Yo! > > Hey, I built a Slackware package of Inkscape 0.39 (needs to compile sigc > 1.2), if you want I can send you. > > Regards, > > - -- > ~ .--. TaQ (Eustáquio Rangel) ((__-^^-,-^^-__)) > ~ |o_o | Usuário registrado GNU/Linux no. 224050 `-_---' `---_-' > ~ |:_/ | email : eustaquiorangel@...36... `--|o` 'o|--' > ~ // \ \ URL : http://beam.to/taq \ ` / > ~ (| | ) ICQ : 110103942 ): :( > /'\_ _/`\ PGP key: 0x784988BB :o_o: > \___)=(___/ Eu gosto de GNU/Linux, e vc ? ;) "-" > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.1 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org > > iD8DBQFBBWxVb6UiZnhJiLsRAg5bAJ4olaeFRBXQTAk6oWGNmsj3hSm1QQCaA7QC > oPEb0wm+MBw/FMsuEKU26c4= > =cwPL > -----END PGP SIGNATURE----- > >

1 0

grid lines
by bulia byak 25 Jul '04

25 Jul '04

Ted, excellent work on emphasized grid lines! The only suggestion is that I think they should be made more darker still, for better contrast. Darkening by 25 instead of 10 looks much better on my screen.

6 11

French translation
by Frederic Rodrigo 24 Jul '04

24 Jul '04

Hi, I have updated the french translation. Fred.

2 1

Extension Proposal (First Draft)
by Bryce Harrington 24 Jul '04

24 Jul '04

Ted, I've written up a first draft of a proposal specification for the Extensions System. This derives heavily from your extensions code, although I've made some tweaks here and there, such as using 'isx' instead of 'inkmod' and some terminology changes. There is still a good bit of work to be done on it. The API's need to be reviewed, displayed in a more consistent manner, and more thoroughly documented, for example. Also, it needs more and better examples. There are probably also a number of places where it is unclear or ambiguous, so those areas will need a lot more work. But I think it's fleshed out enough that it is ready for some review. Read it over when you get a chance, and we can talk about it more in a couple of weeks. :-) http://inkscape.org/cgi-bin/wiki.pl?ExtensionArchProposal Bryce === 1.0.0 Introduction === The extensions system in Inkscape is a way for adding functionality to Inkscape, without affecting the core of the program itself. We want Inkscape to follow a core-plus-modules approach similar to that adopted by many successful open source projects such as the Linux kernel, Perl, Apache, Gimp, and so on. There are many different types of extension mechanisms, including file format conversion tools, filter scripts that process SVG, user interface elements that can be added at runtime, and so forth. This proposal defines a design for handling this wide variety of extensions in a flexible manner. === 2.0.0 Terminology === * Extension - An extension is something that extends the functionality of Inkscape without being directly part of the core. This implies that it should be easy to remove or add, and nothing in the core should depend on it directly. * Extension Type - Establishes the functional interface that the Extension provides, including the types of messages it handles and what is contained in its data structures. * Extension Implementation - Defines how the extension is accessed; i.e. through message passing, pipe/exec calls with commandline arguments, direct function calls, etc. * Plug-in - An extension that is implemented through a loadable library. This is a .o file on Unix-like systems or a .dll on Win32. The libraries should not be loaded until they are used. * Script - A script is a type of extension that is implemented through an external program that recieves and sets SVG data through files and pipes. This allows Inkscape to use programs that handle SVG but are targeted differently, seemlessly inside of Inkscape. * Language Binding - A special type of plug-in that wrappers a script language interpreter such as Perl, Python, Lisp, etc. A user interested in programmatic access to Inkscape's internals via one of these languages can install (or create) the relevant Language Binding Plug-in to achieve this. * ISX - 'InkScape eXtension' - The filename extension used for XML metadata files that describe each Inkscape Extension. === 3.0.0 Requirements === * Uses a general language binding system so it's easy to add new language binding support * Allows direct interaction with the document object model including changing styles, adding/removing defs and elements, etc. * Allows some limited interaction with the Inkscape UI such as manipulating grids, overlays, etc. * Allows direct interaction with file load/save/export/print subsystem * Guaranteed to work properly with the undo system, even if the extension is not written carefully * Well documented so is easy for people to learn how to make new extensions * Each extension can be implemented, distributed, and managed independently of the core project * Icons, buttons, and other UI elements for extensions fit seamlessly into main application GUI * User can easily select which extensions to automatically load into application at startup * Loading of extensions shall not seriously slow startup time or make a major impact on memory footprint * Failure of a extension shall not leave the drawing in an inconsistent state * Main application must gracefully recover from extension crashes or other serious problems with extension execution * Dependencies for particular extensions must be clearly identified for user if missing === 4.0.0 Overview === Different kinds of extensions can be categorized in two ways. First, but what the extension does: File format converters, printing, SVG manipulation, symbol libraries, etc. Second, by how the extension is implemented: command-line scripts, dynamically loaded libraries, internal compiled-in code, etc. The first kind of categorization is called the Extension Type. This essentially establishes a calling interface and the set of messages the extension must be able to receive and handle. For example, extensions of type Print must have a way to handle 'print' message. The second is the Extension Implementation. This defines the mechanism Inkscape must use for passing messages to the extension. For example, commandline scripts would have messages passed as commandline arguments, whereas loadable plug-ins would have the messages passed to the plug-in's message handler routine. The categories of both Extension Types and Extension Implementations are left open ended. This way, if someone comes up with new ideas for ways to extend Inkscape that doesn't fit within the existing models, they can add these mechanisms in a straightforward fashion. For the purposes of this document, however, we focus on just the following Types and Implementations: Extension Types Input - loading various file formats Output - saving as various file formats Effect - apply some sort of change to SVG elements in the doc Print - prints using different drivers or modes Extension Implementations Internal - code callable directly within Inkscape, Script - a cmdline program that takes an SVG document to its STDIN and emits a modified SVG document to its STDOUT, with control messages given as commandline parameters. Plug-in - a loadable module with a message handler routine that receives messages and that operates on the Inkscape API functions directly. Library - a collection of SVG files that can be queried and loaded from the file system into the document. Each item in a library has a thumbnail and metadata. === 5.0.0 Extension System Basics === Leaving the topic of Types and Implementations aside, we can make some generalizations about how all Extensions work, and behaviors or attributes that all Extensions share. This includes how they are registered, how they handle preferences, how dependency resolution is achieved, and versioning. These common behaviors are all established via a base class that all Extension Types derive from. ==== 5.1.0 Extension Base Class ==== The Extension base class holds the attribute data that all extensions must have and establishes the base functionality that all extensions share. class Extension { gchar * id; gchar * name; state_t state; SPRepr * repr; GSList * parameters; public: void set_state (state_t in_state); state_t get_state (); bool loaded (); virtual bool check (); SPRepr * get_repr (); gchar * get_id (); gchar * get_name (); void deactivate (); bool deactivated (); void get_param (gchar * name, bool * value); void get_param (gchar * name, int * value); void get_param (gchar * name, gchar ** value); bool set_param (gchar * name, bool value); int set_param (gchar * name, int value); gchar * set_param (gchar * name, gchar * value); }; ==== 5.2.0 Extension Registry ==== Inkscape maintains a data structure of all the registered extensions. This registry can be queried against to retrieve lists of extensions meeting various conditions (such as recently-used extensions, or all Input extensions). ===== 5.2.1 Extension Attributes ===== name - the human readible name of the extension, with spaces and capitalization, suitable for display in dropdown menus. E.g. 'Dia Import' id - a unique key for identifying the extension, using the java-style naming convention. E.g., 'org.inkscape.input.dia' last_used - an indicator of the time that the extension was last invoked. This permits Inkscape to identify extensions not in regular use, and unload them to conserve memory. num_used - the number of times the extension has been used since program start-up. This allows Inkscape to keep heavily used extensions in memory, even if they've not been used in a while. ===== 5.2.2 Extension Functionality ===== load - allocates memory usage when extension is to be used. E.g., loadable libraries can be loaded up unload - deallocates memory when extension is not in use, to help conserve memory. E.g., loadable libraries can be freed register - called by the Extension constructor to add the extension to the Extension Registry unregister - called by the Extension destructor to dereference the extension from the Extension Registry ===== 5.2.3 Refreshing Registry ===== Inkscape will have a command accessible from its menus for reloading the entirety of the registry. This provides a mechanism for the user to access newly-installed extensions without needing to restart Inkscape. When the registry is refreshed, all currently-loaded extensions should first be unloaded. When refreshed, no extensions (except for the standard defaults) should be loaded in memory. ==== 5.3.0 Handling Preferences ==== Extensions may wish to persist certain values or settings selected by the user or specified at installation time. User settings can be handled via the Inkscape Preferences system. This is particularly appropriate for setting expected to change during use and that have suitable defaults that can be used if this is the first time the user has run it. See section 7.1.6 for details on use of this system. Installation settings are best handled by writing into the extension metadata file (*.isx, see below) during installation. These files are stored in a global location and shared by all users on the system, thus are appropriate for storing general defaults or values that won't change during use. This is covered in the following section. ==== 5.4.0 ISX File Format ==== Every Extension must have a definition file, *.isx. Inkscape loads these files during initialization (and subsequently as requested) to learn what extensions are available to it. The file is an XML format with a top-level element 'inkscape-extension', which contains the following sub-elements: name - required id - required version - required deps - optional; lists the dependencies type - "input", "output", etc. impl - "internal", "script", "plug-in", etc. The deps section contains a list of elements that indicate pre-requisites for use of the extension. For instance, it may require that other extensions be present, or require a certain version level of internal functionality, or require the presence of a certain file in the file system, or require a certain service be active like a database or mail service. Each dependency can also be marked as required or optional, or if it satisfies another dependency. Deps type - required; "extension", "file", "service", etc. id - required; the identity of the dependency it requires. E.g., 'org.inkscape.dia_import', '/etc/foo.conf', 'mysqld' version - optional; a simple regexp pattern used to find if the available version is sufficient to satisfy the dependency required - if present, the dependency is required; if not present, it's treated as an optional dependency satisfies - optional; gives a list of other deps that it will satisfy. For instance, either 'postgres' or 'mysql' could satisfy a 'sql_database' dependency. The type and impl elements can contain sub-elements of their own: Type extension mimetype filetypename filetypetooltip Impl command helper_extension check Also see section 8.4.0. ==== 5.5.0 Checking Dependencies ==== Inkscape loads all of the *.isx files by default. Later, it performs a dependency check on all of the extensions, dropping any whose dependency needs have not been met. This is performed by first checking that there is a valid extension id matching the deps->id, and then comparing each of the deps->version regexp patterns against the available extension version. ==== 5.6.0 Accessing the Inkscape Internal APIs ==== Extensions interact with the published API's of other extensions and with Inkscape itself. Inkscape provides its internal functionality via special "Internal" Extensions. See Section 7.1 for details of what is available. The manner that the internal API's are invoked is dependent on the kind of Extension Implementation. Plug-ins, for instance, generate messages that are returned to the application. Scripts, on the other hand, do not handle messages or work interactively, but instructions can be passed via commandline arguments. === 6.0.0 Extension Types === Each Extension is identified by it's 'Type'. This determines the type of programmatic interface that it adheres to, enabling Inkscape to know what functionality it can expect from the extension. ==== 6.1.0 Input ==== An input extension provides a way to get data into Inkscape. This type of extension creates a document given a filename. This is done by using the 'open' method within the class. Also, there is a 'prefs' function which will generate a GtkDialog. This dialog is then used to get any settings that the incomming file and extension my use. This function is executed, and the dialog returns, before the open method is called. There are also several other settings stored in an Input extension. This includes information on the type of file the input module can take in including its filename extension and mime type. Also, there is a space to store a tooltip for additional information on the file type in the file dialog. Lastly, there is the key of which Output extension is recommended for saving this filetype. This is useful, as there is no other direct links between the Input and Ouput functions, and a user expects to be able to open and save without using the 'Save As...' dialog. class Input : public Extension { gchar * mimetype; // What is the mime type this inputs? gchar * extension; // The extension of the input files gchar * filetypename; // A userfriendly name for the file type gchar * filetypetooltip; // A more detailed description of the filetype gchar * output_extension; // Setting of what output extension should be used virtual bool check (); SPDocument * open (gchar const *uri); gchar * get_extension (); gchar * get_filetypename (); gchar * get_filetypetooltip (); GtkDialog * prefs (gchar const *uri); }; ==== 6.2.0 Output ==== An output extension controls how SVG documents are exported from Inkscape. This type of extension creates a file given a document object. This is done using the 'save' method within the class. The method for how files are exported depends on what type of Implementation is used. For Scripts, the file is first saved as a temporary SVG file, and then processed by calling the commandline programs to convert it. For Plug-ins, the document object is passed to the extension with a 'save' message and a filename, and the extension program performs the file save operation itself. class Output : public Extension { gchar *mimetype; // What is the mime type this inputs? gchar *extension; // The extension of the input files gchar *filetypename; // A userfriendly name for the file type gchar *filetypetooltip; // A more detailed description of the filetype bool dataloss; // The extension causes data loss on save public: virtual bool check (void); void save (SPDocument *doc, gchar const *uri); GtkDialog * prefs (); gchar * get_extension(); gchar * get_filetypename(); gchar * get_filetypetooltip(); }; ==== 6.3.0 Effect ==== Effect extensions cause a modification of a loaded document. For example, it might add a new shape to the drawing, or change all selected objects to be purple with green dotted borders. class Effect : public Extension { public: virtual bool check (); GtkDialog * prefs (); void effect (SPDocument * doc); }; ==== 6.4.0 Print ==== The Print Extension Type is for extensions that interface with printing subsystems. Examples would be Win32, postscript, and GNOME Print. class Print : public Extension { SPItem *base; NRArena *arena; NRArenaItem *root; unsigned int dkey; public: bool check (); /* FALSE means user hit cancel */ unsigned int setup (); unsigned int set_preview (); unsigned int begin (SPDocument *doc); unsigned int finish (); /* Rendering methods */ unsigned int bind (NRMatrix const *transform, float opacity); unsigned int release (); unsigned int fill (NRBPath const *bpath, NRMatrix const *ctm, SPStyle const *style, NRRect const *pbox, NRRect const *dbox, NRRect const *bbox); unsigned int stroke (NRBPath const *bpath, NRMatrix const *transform, SPStyle const *style, NRRect const *pbox, NRRect const *dbox, NRRect const *bbox); unsigned int image (unsigned char *px, unsigned int w, unsigned int h, unsigned int rs, NRMatrix const *transform, SPStyle const *style); unsigned int text (char const *text, NR::Point p, SPStyle const *style); bool textToPath (); }; === 7.0.0 Extension Implementations === ==== 7.1.0 Internal ==== Access to Inkscape internals is provided through the Internal classes. These classes expose APIs for various compiled-in functionality that can be used by other extensions. The Internal functionality is grouped into different sets, as follows. ===== 7.1.1 File Operations ===== Ability to load/print/save/close documents doc file_open (gchar * uri, Inkscape::Extension::Input * ext) bool file_save (SPDocument * doc, gchar * uri, Inkscape::Extension::Output * ext) bool print_doc (SPDOcument * doc) ===== 7.1.2 SVG DOM Object Hierarchy ===== Access to the document's SVG::DOM object hierarchy array getElements(string element_name) string getElementName() string getElementByID(string id) string getElementID() hash getAttributes() string getAttribute(string attribute) bool SetAttribute(string name, string value) bool SetAttributes(hash) bool hasChildren() array getChildren() obj getFirstChild() obj getLastChild() array getSiblings() obj getNextSibling() obj getPrevSibling() int getChildIndex() obj getChildAtIndex(int index) obj getParent() array getParents() bool isAncestor(obj) bool isDescendant(obj) cdata getCDATA() ===== 7.1.5 Inkscape Verbs ===== A verb is an identifier used to retrieve standard Actions for particular views. Verbs are used to invoke a wide variety of operations, called Actions, in the Inkscape application. For instance, typical verbs include 'FileOpen', 'FileImport', 'EditDuplicate', 'SelectionLower', 'ObjectToCurve', 'DrawText', 'ToggleGrid', and the like. Essentially, everything invokable via a menu in Inkscape can be similarly activated using its verb. The following routines are provided to extensions in order to interact with the verb system: int verb_find(string verb_name) - looks up the numerical ID of the given verb name. (E.g., it could pull it out of the SPVerbActionDef props[] static object) action verb_get_action(int verb, view) - retrieves the Action object for the verb in the given view view action_get_view(action) - retrieves the view, given the action object void action_perform(action, data, pdata) - invokes the Action for the verb. It validates the parameters and calls the appropriate listener that will handle the action. void action_set_active(action, state, data) void action_set_sensitive(action, state, data) ===== 7.1.6 Inkscape Preferences ===== These Internal methods permit access to the Inkscape Preferences system. Extensions can look up, set, or add values to the user preferences, and they will be persistently stored in the file ~/.inkscape/preferences.xml void prefs_set_int_attribute(string path, string attr, int value); int prefs_get_int_attribute(string path, string attr, gint def); int prefs_get_int_attribute_limited(string path, string attr, int def, int min, int max); void prefs_set_double_attribute(string path, string attr, double value); double prefs_get_double_attribute(string path, string attr, double def); double prefs_get_double_attribute_limited(string path, string attr, double def, double min, double max); string prefs_get_string_attribute(string path, string attr); void prefs_set_string_attribute(string path, string attr, string value); void prefs_set_recent_file(string uri, string name); string[] prefs_get_recent_files(); See HandlingPreferences in Wiki for further details. ===== 7.1.7 Stock SVG Defs ===== These routines provide access to the default SVG defs in Inkscape, including things like gradients, markers, and patterns. Note that this does not cover the defs in the documents themselves, which can be accessed via the document's SVG DOM. obj get_stock_item(string urn) - returns a pointer to an instance of the desired stock object in the current doc, importing the object if necessary. void set_stock_item_from_svg(???) - adds a new stock SVG def to the Inkscape Application. All currently loaded and new documents will have access to the item. ===== 7.1.8 Extension based variables These are the variables that control settings for the individual extension. Things that are held internally, but should be saved with the Inkscape preferences. These are: get_param (gchar * name, [bool, int, gchar *] data) - This function gets the variable by the name 'name' with the data in 'data'. It can be a boolean, integer or a string. set_param (gchar * name, [bool, int, gchar *] data) - This function sets the variable by the name 'name' with the data in 'data'. It can be a boolean, integer or a string. In the case of the string it is copied. For examples of API functions, see the perl SVG, SVG::DOM, et al modules ===== 7.1.9 Extension Manager ===== The Extension Manager Extension enables extensions such as Plug-ins to access other extensions. acquireExtension(extension_name, extension_version, &ext_obj); releaseExtension(extension_name, extension_version); ==== 7.2.0 Scripts ==== Script Extensions are external executables that Inkscape can invoke to enact needed changes. A Perl script such as ill2svg.pl is a typical example, but the Script Extension actually need not be a scripting language at all - it could be a binary application such as Sketch. The key thing is that it must operate like a commandline utility, taking input from STDIN and producing its changed version to STDOUT. The class Extension::Implementation::Script is the interface to the scripts, and includes the following methods: SPDocument *open(Extension *key, gchar const *filename); void save(Extension *key, SPDocument *doc, gchar const *filename, bool setextension, bool check_overwrite, bool official); void filter(GtkObject *object, gchar const *key); Print * get_print(gchar const *key); Extension * build_from_file(gchar const *filename); Extension * build_from_mem(gchar const *buffer, Implementation *in_imp); ==== 7.3.0 Plug-Ins ==== Plug-ins are extensions implemented via loadable modules such as DLL's (on Windows) or .so's (on *nix), using C linkage. Each plug-in has a message handler function that Inkscape can call. A plug-in is able to request access to blocks of functionality, such as data structure functions or UI elements. The plug-in can use the blocks of functionality it has been granted access to. The plug-in can also publish its own block of functions, to be used by other plug-ins. Each block of functionality can be versioned, so that interfaces can change with backwards compatibility later. ===== 7.3.1 Plug-in Shared Object Format ===== A Plug-in must define a function with C binding to create the extension. This function creates an Extension object for itself and returns the memory pointer: extern "C" void *CreateExtension() { return (void *)new MyPluginExtension(); } The Plug-in's Extension returned by this function must behave according to the Extension base class; it must provide member functions for load, unload, register, and unregister. Additionally, Plug-ins must support the following interface: error do_message(char *message_sender, char *message_category, char *message_action, void *data, void *extensions) All Plug-ins must handle the following five message actions: 'load' - load into memory and setup or restore state info 'unload' - unload from memory, saving state info if appropriate 'startup' - allocate global memory, add UI elements, register, etc. 'shutdown' - flush files, preserve preferences, etc. 'about' - info about the plug-in Additionally, the Plug-in will receive messages particular to its Extension Type. File export extensions will receive the 'save' message, for example. Inkscape will indicate a message_action each time it calls the Plug-in, to specify what should be done or to signal it that an event has occurred. The Plug-in may register listeners for events that it would like Inkscape to notify it about. Plug-ins can also generate their own events to send to other extensions. The data argument of the do_message() routine permits passing an arbitrary structure to the Plug-in. The type of structure used is indicated by the message_category parameter. For example, this data object can provide a way for the plug-in to preserve information between calls (such as in a memory block allocated by the Plug-in during startup that will be preserved if the Plug-in is unloaded and loaded). The extensions argument is a collection of interfaces to other extensions that the Plug-in is allowed to call. These enable the Plug-in to access other functionality within Inkscape. Typically, these will be Internal Extensions (see Section 7.1), which provide access to core functionality in Inkscape, but from the Plug-in's perspective it is transparent whether the extensions it uses are internal core functionality or other external plugins. To use a function in another extension, the Plug-in must first 'acquire' the extension. This lets Inkscape know that it should load the extension into memory if it isn't already. When it has finished with the extension, the Plug-in should 'release' the extension, allowing Inkscape to recover the memory for other things if needed. When the Plug-in is first called, it will be passed a single extension, the ExtensionManager. The Plug-in can then request additional extensions through it. ===== 7.3.2 Plug-in Initialization Algorithm ===== On the application side, Inkscape uses the following pseudocode to load the Plug-in: // determine the path and filename of the shared object filename = "/usr/share/inkscape/extensions/foo/foo.so" // load the library and get the extension creation function #if USE_DLOPEN void *obj = dlopen(filename, RTLD_LAZY|RTLD_GLOBAL) f_createExtension = dlsym(obj, "CreateExtension") #else HMODULE obj = LoadLibrary(filename) f_createExtension = GetProcAddress(obj, "CreateExtension") #endif extension = (Extension *) f_createExtension() // When the extension is needed, load it into memory extension->load() // Pass messages to and from the extension extension->do_message(my_message) // When done, remove it from memory extension->shutdown() See experimental/extension_example in Inkscape CVS for a working example. ===== 7.3.3 Scripting Language Bindings ===== Scripting support is provided via special kinds of Plug-Ins called Language Bindings. These provide loadable script interpreter modules. These may be useful for users to quickly program custom functionality, for testers to automate testing procedures, and so forth. These bindings can be operated in one of three ways: Document - The code to be interpreted is embedded in the SVG document itself. The language interpreter thus parses the document and invokes a given function within it. For example, it could run some embedded ECMA script. User - The code to be interpreted is typed in by the user themselves. For example, this could be done via a pop-up text editor dialog the user types or pastes code into, or it could be passed to Inkscape via its STDIN when using inkscape in commandline mode, or it could be provided by another extension (such as one that loads it from a database). File - The code to be interpreted is loaded from a file stored in the file system. ===== 7.4.0 SVG Libraries ===== Library Extensions are interfaces to collections of data files that can be queried and loaded directly into the document. int library_count(query_condition) - returns the quantity of items meeting the query condition. item[] library_list(query_condition, int start, int end) - returns a list of items meeting the query condition. Optionally, the requestor can specify that a subset specified by [start,end] be returned (this is for paging purposes). doc library_get_item(id) - retrieves a specific item from the library. Each item in a library has the following data items associated with it: id - the unique identifier for the library item thumbnail - a rendered bitmap that illustrates what the item would look like in the document. metadata - a collection of RDF data for the object, including information such as the author, license, title, etc. === 8.0.0 Creating Extensions === In this chapter, we discuss how to create an extension from scratch, incorporate into Inkscape, and release it for the general Inkscape community to use. This chapter can be read independently of the rest of the document, using the rest as reference material. ==== 8.1.0 Selecting an Extension Strategy ==== First of all, you will need to select the method you'll use for creating your extension. Scripts are the simplest extensions to create, because they work through STDIN/STDOUT, so you need to know very little about Inkscape internals to make them work. However, their ability to interact with the Inkscape internals is limited compared with other approaches. For file format converters, this is usually fine. You can also create filters programs that take the entire document to its STDIN, process it, and return a modified copy to STDOUT. Some control of the extension is possible via its commandline arguments. One of the nice things about Scripts is that they can be written in any language. It need not even be a scripting language - as long as it handles STDIN and STDOUT and uses commandline arguments, you can write it however you wish. Plug-ins are more powerful than Scripts, but require more knowledge of Inkscape internals, and must be written according to specific criteria. Generally, since these are loaded as dynamic objects, they'll need to be written in a language that can generate them, such as C or C++. The best of both worlds can be available through Language Bindings, which are Plug-ins that wrapper a script interpreter. This enables you to call various Inkscape internal routines through your scripting language's functions. If someone has created a Language Binding for your language of choice, you're all set, otherwise you'll have to create a Plug-in for it. Language Binding Plug-ins have a few more requirements than ordinary Plug-ins, and require a greater amount of knowledge of the Inkscape internals, so it can take quite some time to do properly. Library Extensions are basically collections of symbols that can be queried, browsed, and imported into documents in Inkscape. An example might be drawing symbols for electrical diagrams. Internal Extensions are in a way the reverse of a normal Extension, in that instead of providing a way to hook into Inkscape from the outside, they provide hooks from inside Inkscape. These can be used directly by Inkscape, such as in the case of compiled-in printing modules, or used by other extensions, such as to provide access to the verb system. ==== 8.2.0 Writing Your Extension ==== This section provides some guidance and examples for implementing different kinds of Extensions. ===== 8.2.1 Writing Internal Extensions ===== # TODO ===== 8.2.2 Writing Script Extensions ===== # TODO ===== 8.2.3 Writing Plug-in Extensions ===== # TODO ===== 8.2.4 Writing Language Binding Plug-in Extensions ===== # TODO ===== 8.2.5 Writing Library Extensions ===== # TODO ==== 8.3.0 Creating an ISX File ==== Every extension must have a corrosponding *.isx file. This is an XML file that provides Inkscape with information about the module and allows it to load the info without needing to access the module itself. The *.isx file contains enough info for Inkscape to set up menu items and know what kinds of functionality to expect from the extension. # TODO: Insert an example ISX XML here ==== 8.4.0 Packaging Your Extension ==== ==== 8.5.0 Contributing Your Extension to the Inkscape Community ==== Once your extension is complete, you may wish to share it with the community. There are of course no hard and fast rules for how to share your work, but this section illustrates some approaches. ===== 8.5.1 Listing Your Extension ===== First, you will need to put your extension someplace that others can find and download it. If you have adequate webspace, you could simply upload it to your web server. More typically, you will want to upload it to a mirroring system like SourceForge (http://www.sourceforge.net), CPAN (http://www.cpan.org), and the like. The Inkscape project may also be willing to host your extension; contact the admins for more info. It can also be helpful to list your extension with one of the various software registries, such as Freshmeat (http://www.freshmeat.net). You should also list it on the Inkscape Wiki site. ===== 8.5.2 Announcing Your Extension ===== After posting your extension someplace from which it can be downloaded, you should also announce its availability, by sending an email to inkscape-announce@...460... You may also want to announce it on other related sites; for instance, if you've written a plug-in to allow operation of Imagemagick from within Inkscape, it could be a good idea to announce it to the Imagemagick list. ===== 8.5.3 Incorporating Your Extension to Inkscape ===== Because the intent with the extension system is to break things *out* from the core, most extensions should be packaged and distributed independently of the main Inkscape distribution. However, for ease of user installation, an extension-pack can be shipped along with the core Inkscape package. Also, certain extensions may be so critical to Inkscape operation (such as for printing) that they should be included in the core. If your extension seems like it should be incorporated into the Inkscape core, contact the Inkscape developers about this, and discuss how best to include it in the distribution with them. === 9.0.0 Conclusion === It is anticipated that the incorporation of this extensions capability will bring Inkscape added power and flexibility while avoiding bloating the core with cool-but-rarely-used functionality. Further, it empowers users and non-core Inkscape developers to extend the application with their own new capabilities, without needing to gain special access and acceptance by the project. Dynamic loading of functionality will also allow Inkscape to remain 'lean and mean', loading up functionality on an as-needed basis, and conserving memory by unloading functionality when it is not needed. The key point of this design specification is the architectural concept of separately identifying an extension's interface type, or 'Extension Type', from its implementation method, or 'Extension Implementation'. This feature enables Inkscape to be extended in a variety of mechanisms, including ways not yet foreseen.

8 21

generic tuples
by MenTaLguY 24 Jul '04

24 Jul '04

Just a quick heads-up that I've added a type for generic tuples to the codebase -- Inkscape::Util::Tuple. It consists of a simple struct template and a constructor function template. Tuples may contain up to six elements of arbitrary types. For example, a type for a two-element tuple containing an int and a char const * would be: Tuple<int, char const *> blah; Its constructor may optionally take initial values for its members: Tuple<int, char const *> blah(1, "foo"); The first member is named a, the second b, and so on: cout << blah.a /* int */ << blah.b /* string */ << endl; Also, for creating anonymous tuple values, there is a convenient constructor function which infers the types for you: tuple(5, "testing").b /* string "testing" */ To use tuples, #include "util/tuple.h". n.b. employ 'using' if you don't want to have to spell out Inkscape::Util::Tuple and Inkscape::Util::tuple -- e.g.: using Inkscape::Util::Tuple; using Inkscape::Util::tuple; ...but please keep 'using' out of header files! Inside class bodies is OK though. Just thought you all might find tuples useful.. -mental

1 0

Re:[Inkscape-devel] align comments
by aubi＠...373... 24 Jul '04

24 Jul '04

>I finally tried the new align dialog. I realize it's a work in >progress but still here are some comments: > >- BUG: when I open the align dialog, then switch to another >non-Inkscape window and then back to Inkscape, the dialog >disappears. >Even when I switch focus to the editing window, the dialog >disappears >(not only sinks but disappears completely). This does not happen >with >e.g. Fill&Stroke dialog, and it must be fixed as soon as possible. Yes, I know. This is because the dialog must be made transient (in the Docker.cpp init() method). But as the window is stil old c GTK, I can't perform it. I tried a first approach to convert the window (AFAIK, the widget member in SPCanvas struct) to a Gtk::Window, but failed to do it in the time I had. >- merging the two tabs into one makes sense, but then remove >the lone >"Align" tab My objective is to have drag and dropable toolboxes from one docker to another. Maybe Layout is a better tab name ? >- the new title "Docker" tells me nothing - Align and >Distribute is >what it does, so that is the title it should use; also don't >lose the >shortcut listed in the dialog title, as in all other dialogs I was wondering how to name the dialog : the name of the currently shown toolbox, or something like "InkScape Toolbox" ? >- the anchor menu must have an appropriate label, e.g. >"Relative to:" I agree >- the anchor meny only applies to alignment, not >distribution, and >therefore must be inside the Align frame Agree too, I've already done this on my local copy >- the old behavior corresponds to Selection, and therefore >Selection >must be the first and the default selected item in the >anchor menu; >it's also the most intuitive OK, I did not noticed that >- the Last/First Selected items may be confusing, because in >many >cases the order or selection is undefined (e.g. when you do a >rubberband around several objects), so please remove them >and add >Top/Bottom Object (referring to z-order) instead Good idea ! >- in the node mode, none of the anchor menu items make sense >(nodes >have no bigger/smaller, no z-order, etc) so the menu must be >removed, >instead it should always align within the bounding box of >the selected >nodes Agree too, I've already done this on my local copy >It looks very promising, so I look forward to your further >work on this! :) Glad to see you like it. Unfortunaltely (at least for you), I'll be on holydays for the next 3 weeks. I will not have network access and higly doubt I'll have time to code [hwo knows, I it rains all the day ?]. But as soon as it's finished, I 'll be back onboard. Let me know your thoughts, OBI ************************ ADSL ILLIMITE TISCALI + TELEPHONE GRATUIT ************************ Surfez 40 fois plus vite pour 30EUR/mois seulement ! Et téléphonez partout en France gratuitement, vers les postes fixes (hors numéros spéciaux). Tarifs très avantageux vers les mobiles et l'international ! Pour profiter de cette offre exceptionnelle, cliquez ici : http://register.tiscali.fr/adsl (voir conditions sur le site)

2 1

win32 installer
by Taraben, Adib 24 Jul '04

24 Jul '04

Hi All, I did an win32 installer. I took the installer script from the CVS changed the 38 to 39. Attached the script. But I only have a geocities account that allows me upload-chunks up to 5MB. The installer is 11 MB. How to proceed? HTH, Adib.

2 1

Release status
by Daniel Díaz 24 Jul '04

24 Jul '04

Hello there. I was just wondering where in the release process are we? It wasn't totally clear to me whether or not it is already official and to be announced in the wild. Is it? May I now? The download page states that many packages are "coming soon", yet they are in SF's filelist. Also, Bryce, I just noticed today that I sat in front of the computer, the MDK91 RPM shows Inkscape in the "Graphics" menu, yet MDK91 uses "Multimedia -> Graphics" for that. I'm still receiving a lot of hits in the bleeding-edge autobuilds, but they are all 0.39rc* builds. Should I put a note about SF there? Just for the statistics... # (egrep LATEST\|.nkscape-?[0-9]{10}\. /var/log/httpd/access_log | cut -f 10 -d \ | grep -v \- | tr \\n \+ && echo 0) | bc 34028559086 # egrep LATEST\|.nkscape-?[0-9]{10}\. /var/log/httpd/access_log | wc -l 4488 That is 34,028,559,086 bytes with 4488 hits (not including "à la carte" files.) Greetings! Daniel Díaz yosoy@...31...

5 5

Mandrake 10 rpm & autopackage issues
by Lucas Vieites 23 Jul '04

23 Jul '04

Hi, if I get the src.rpm and rebuild it to get an rpm for my Mandrake 10 system, is that usable for other Mandrake 10 users? Just asking in case it's useful for the download area. Thanks, PS. I tried to install the autopackage version but I got an error: err:waitForHELLO() failed to synchronize with front end: UHOH VERSION_MISMATCH It downloaded version 0.6 of autopackage an then issued this error. I had installed a cvs version of the inkscape autopackage before. If someone would like to get the full output after the ./inkscape-0.39.package command I can send it to the list. -- Lucas 'Basurero' Vieites Dept. Desarrollo <lucas@...212...> Asix Informática <http://www.asixinformatica.com/> Tel/Fax: +34 986 54 26 98

4 3

0.39 -> 0.40 + OLS
by Bryce Harrington 23 Jul '04

23 Jul '04

Hi All, With Inkscape 0.39 out the door, our next target is 0.40. Notice we're at #17 on SourceForge now :-) The 0.40 development process looks like it'll be pretty much like 0.39. We have a principle development focus - conversion to Gtkmm - plus as much freeform development as can be squeezed into the time we'll have. Gtkmm conversion looks like a lot of work, but then so did Pango, and look how swiftly the team knocked that out. ;-) I don't know if we need "a plan" for the Gtkmm conversion; if we do, then within a few weeks we can do so. Looking forward beyond 0.40, there are other big changes to come that we can start preparing for presently. The Extensions work is one example; the proposed spec will hopefully provide a starting point for this. Another example is the eventual rewrite of the style class and creation of a more complete CSS implementation for Inkscape. I'm also looking forward to seeing what we can do with improved testing systems and what potential Cairo holds. These are just a few of the cool things waiting in the wings. Speaking of Cairo, I've sat in on the two talks by Keith Packard and Jim Gettys on the rearchitecture of X. Keith did his presentation in SVG, but his Cairo-based viewer was very slow rendering it, compared with inkview. :-) A lot of interesting work is being done with X these days. In addition to Cairo (which they're hoping to see more apps pick up and use), they're also looking at LittleCMS (or something derived thereof) as a universal color management system (the one currently in X is very broken and nobody uses it.) As to my own presentation, if anyone's interested, it's here: http://developer.osdl.org/bryce/ols_testing_presentation/ Bryce

2 2

Re: [Inkscape-devel] Release status
by Bryce Harrington 23 Jul '04

23 Jul '04

On Thursday 22 July 2004 12:04 am, Daniel DC-az wrote: > I was just wondering where in the release process are we? It wasn't > totally clear to me whether or not it is already official and to be > announced in the wild. Is it? May I now? Yes, sorry, I meant to put out an announcement about this but connectivity here at OLS has been rather iffy. Now that all the packages are available and announcements have gone out, we're back to normal development. > The download page states that many packages are "coming soon", yet they > are in SF's filelist. Yes, that needs to be updated. I won't be able to work on the website until Sunday at the earliest, so if someone else could update it, that would be most appreciated. By the way, I'm wondering if we need to really put some work into making the download page quite specific. In the past, a link to the SF download page was probably sufficient, but now with fink, autopackage, dev autobuilds, etc. I am thinking we probably need a carefully laid out page pointing at the various packages people need. However, my first cut at doing so actually made it worse -- I'd very much appreciate it if someone with a good idea for how to make the download page clearer could come up with a scheme for us. > Also, Bryce, I just noticed today that I sat in front of the computer, > the MDK91 RPM shows Inkscape in the "Graphics" menu, yet MDK91 uses > "Multimedia -> Graphics" for that. Hmm, yes, you're right. When I next get a chance I'll updated it. Since this is distro dependent, we may need to figure out a way to variabalize this in the spec files. > I'm still receiving a lot of hits in the bleeding-edge autobuilds, but > they are all 0.39rc* builds. Should I put a note about SF there? Let's try to figure out what is causing people to select that file instead of the official build, and adjust links or whatever to promote the correct one. > Just for the statistics... > > # (egrep LATEST\|.nkscape-?[0-9]{10}\. /var/log/httpd/access_log | cut > -f 10 -d \ | grep -v \- | tr \\n \+ && echo 0) | bc > 34028559086 > > # egrep LATEST\|.nkscape-?[0-9]{10}\. /var/log/httpd/access_log | wc >-l > 4488 > > That is 34,028,559,086 bytes with 4488 hits (not including "C la >carte" > files.) Yow! That's pretty cool. :-) Bryce

1 0

Re: [Inkscape-devel] Re: Mandrake 10 rpm & autopackage issues
by Bryce Harrington 23 Jul '04

23 Jul '04

On Thu, 22 Jul 2004 10:13:45 +0200, Lucas Vieites wrote: Yes, if you create mdk10 rpm's, these can be added to the file tracker; I'll be happy to upload it for you if you send it my way (might be a couple days tho). Make sure to update the Groups variable in the spec file to install into Multimedia:Graphics instead of Applications:Graphics. On Thursday 22 July 2004 9:30 am, Mike Hearn wrote: > Please remove all trace of autopackage from your system before trying this > version. Previous versions of autopackage installed from the release > tarballs in the usual fashion will be upgraded for you - obviously we > can't do that with CVS installs, and this is what has gone wrong here. Can you write some documentation for "how to remove all traces of autopackage"? I think this issue was what was screwing up Carl's box too, but it was not apparent what to do to remove all the previously installed stuff. The docs would be quite helpful. > By the way, the Inkscape page still claims that autopackage is only for > "modern RPM based distros" ... there's nothing inherently RPM about > autopackage. We can update this as the downloads page gets fixed up. I wrote this because it seems to me that this is where autopackage's killer feature is. For Gentoo and Debian systems, the dependency resolution mechanisms are solid enough that autopackage may not be as necessary on those distros, IMHO. However yes we should clarify the download page to be more factually accurate. > I'd like to thank the Inkscape developers for bearing with us while we > iron out the teething problems here, I'm sure it must be annoying for > those who aren't interested in packaging to have the list filled up > with this stuff. It's appreciated though! I think the way we should think about autopackage is as an investment in our future - both for Inkscape and for Open Source in general. It addresses that big white elephant that few like to think about - it's painful for new Linux users to install ordinary apps like Inkscape. I think Autopackage is going to lead the way to inspiring the next generation of Linux installation technology. It's cool that Inkscape can help raise awareness for Autopackage while at the same time serving its own self-interest in making it easier for people to install the program. Anyway, so thanks back to you guys - keep up the good work! :-) Bryce

1 0

RE: [Inkscape-devel] RFEs
by Gazal, Geraud (MED) 23 Jul '04

23 Jul '04

> On Wed, Jul 21, 2004 at 04:41:02PM +0200, Gazal, Geraud (MED) wrote: > > My idea, in the long term, is to identify let's say 20 main > categories, > > sort/group the RFEs in those categories and attribute a > score to each > > category according to the number of RFEs it contains and > their priority. > > I've added each of the suggested high-level groups. I've started > marking, commenting, and scoring the "build" ones... Wow, did not think it would be 'accepted' as is. :)

2 1

Fwd: AW: [Inkscape-devel] win32 installer
by Daniel Díaz 23 Jul '04

23 Jul '04

Hello. Adib has just uploaded the Win32 installer here: http://cortijodelrio.net/~inkscape/win32/Inkscape-0.39-1.win32.exe Someone with CVS/SF access can now grab this one and the NSI script. Greetings! Daniel Díaz yosoy@...31... -----Forwarded Message----- From: "Taraben, Adib" <taraben.a@...50...> To: Daniel Díaz <al590349@...30...> Subject: AW: [Inkscape-devel] win32 installer Date: Fri, 23 Jul 2004 12:05:45 +0200 Done, thx. Cane someone also commit the installer script to the cvs? ________________________________________________________________________ Von: Daniel Díaz [mailto:al590349@...30...] Gesendet: Fr 23.07.2004 11:50 An: Taraben, Adib Betreff: Re: [Inkscape-devel] win32 installer Hi, Adib. You can upload it to my site temporarily. FTP to cortijodelrio.net, with ****/**** as username/password, and upload it somewhere in the public_html directory. After that, it won't be a problem for any developer to download it and push it to SourceForge. If you have any further comments, just drop me a line. Greetings! Daniel Díaz yosoy@...31... On Fri, 2004-07-23 at 04:41, Taraben, Adib wrote: > Hi All, > > I did an win32 installer. > > I took the installer script from the CVS changed the 38 to 39. > Attached the script. > > But I only have a geocities account that allows me upload-chunks up to > 5MB. The installer is 11 MB. > > How to proceed? > > HTH, > > Adib.

2 1

RFEs
by Gazal, Geraud (MED) 23 Jul '04

23 Jul '04

In order to make my mind on the functionalities and the software, i've spent a few moments on the RFEs. -> Read them, sorted, grouped (etc etc) It's far from perfect, but if it can help someone as it has helped, here it is. It can maybe help some of you removing the redundancy within the list of open RFEs ( especially layers, node editing...) My idea, in the long term, is to identify let's say 20 main categories, sort/group the RFEs in those categories and attribute a score to each category according to the number of RFEs it contains and their priority. A kind of "voice of the user". Plus doing the same things with bugs. So feel free to submit me any idea of categorisation (knowing that sorting this kind of items will never be perfect) Regards, Matiphas * Build/Compile/Dependancies/Code/Design [ 840075 ] BUILD: Mac OS X release [ 979876 ] Better ID handling on object copy [ 926588 ] Disable autogeneration of ID [ 979481 ] unique X11 window names [ 972981 ] New File Chooser (file open save as dialog) [ 968647 ] gnome/gtk commandline options [ 968644 ] X display cmdline options [ 967753 ] Comments/Suggestions from USERS magazine (Argentina) [ 956520 ] remove unaccessible files from "recent" list [ 956476 ] Add a build date to the config.in ? [ 933684 ] merge identical patterns/gradients/markers [ 933555 ] Win32 Installer "no GTK" option. [ 902254 ] [win32] Install to Program Files [ 902252 ] [win32] Install shortcut into menu for Inkscape [ 892670 ] "veto" callback system for SPRepr change notifications [ 874493 ] qtgtk support. [ 864252 ] EASY: detect running inkscape process before starting a new [ 859134 ] Ugly Gtk triangle border [ 986052 ] -e option must overwrite without asking <--************************************************************************* ***************************--> * Content [ 862701 ] PALETTE: Object Library [ 966771 ] Stock gradients [ 956035 ] A set of templates [ 927912 ] library of objects [ 991044 ] Default options / Template <--************************************************************************* ***************************--> * Desktop integration [ 989220 ] How can i export to illustrator? Copy/paste [ 856082 ] Viewer component [ 856083 ] Editor component (Bonobo) [ 981785 ] gimp & inkscape [ 862655 ] GIMP: Integration with INKSCAPE [ 862692 ] GIMP: Import gradients [ 909735 ] Support for copy/paste with system clipboard [ 950969 ] INPUT: Wacom Tablet + Pressure Sensitivity [ 984964 ] Wacom support [ 965568 ] Drag images from nautilus to inkscape window to import it [ 974117 ] Image Cropping [ 978465 ] cmdline options for initial settings [ 981785 ] gimp & inkscape <--************************************************************************* ***************************--> * Ideas of extensions and plugins [ 862657 ] PLUGIN Support [ 984081 ] Auto-updated, visible timestamps in drawings [ 982795 ] Autojoin tool [ 967843 ] Add Bone System [ 967312 ] Add a blend Tool [ 938707 ] please provide a plugin for image/svg-xml [ 925198 ] detect/bundle Frontline [ 897638 ] Node fillet / chamfer tools [ 880120 ] NEW TOOL: Cloud Tool [ 862752 ] TOOL: rounding object, or filter [ 862750 ] Standard shapes + Algorithmic Shapes + Math Formulas [ 862723 ] OBJECTS: bevel for object properties [ 989884 ] Mesh - CAD like [ 862751 ] TOOL: Tangential circles/curves and lines [ 864292 ] Measure tool [ 844329 ] Dimensions <--************************************************************************* ***************************--> * Fonts [ 863323 ] FONTS: embedded SVG font support [ 932954 ] SVG Fonts [ 980840 ] Add support fot math fonts (greek symbols) <--************************************************************************* ***************************--> * Import/Export (maybe handled as extension/plugin in the future ?) [ 993210 ] Exporting to .jpeg [ 840345 ] EXPORT DIALOG: NEED EPS, PDF, SWF, etc [ 847365 ] Import SVG embedded in other XML [ 863383 ] EXPORT: xfig format [ 864110 ] IMPORT: OpenOffice.org Draw import [ 864260 ] IMPORT/EXPORT: PDF [ 865058 ] EXPORTING: Ability to export 16-bit PNGs and OTHER PNG adds [ 899574 ] Inkscape should embed bitmaps for gradients in PS [ 922750 ] Inkscape ignores file extentions when exporting a file [ 942328 ] relative image paths instead of absolute [ 957916 ] Import/Export Encapsulated PostScript format [ 977339 ] default export image name for not-saved drawings [ 840030 ] CorelDraw Importer/Viewer (.cdr files) <--************************************************************************* ***************************--> * Object editing [ 969466 ] navigation through object in object properties menu [ 984961 ] Apply transformation to duplicate - Freehand/Calligraphic [ 965516 ] Abilty to draw splines [ 862725 ] CALLIGRAPHIC TOOL: units must be added (editable properties) [ 863375 ] CALLIGRAPHY TOOL: Tool Angle [ 902216 ] Freehand tool needs to work smoother [ 952134 ] A tool and a key [ 856085 ] curve editing and right click menu - Gradient [ 862708 ] GRADIENTS: improvements, and a bit more [ 979870 ] Gradient editor window does not show the gradients name [ 971415 ] gradient features [ 927490 ] non linear (exponential) gradient [ 897207 ] Gradient edit in-picture [ 863329 ] Gradient Angle and Aspect Ratio [ 986762 ] gradient and opacity - Marker [ 990860 ] Markers reference points should be moved [ 952769 ] MARKERS: Can't change marker color with line color [ 970270 ] UI: Browsing markers is too slow/inefficient [ 942486 ] make size of markers settable - Node [ 994975 ] Node transform [ 862691 ] NODE EDITING: Dragging curve segment [ 862753 ] DIALOG: Node Orientation [ 863731 ] NODE EDITING: Display start/end node [ 865050 ] NODE EDITING: properties, align nodes vert./horiz. [ 880110 ] TOOLS/NODE EDITING: Add/subtract nodes + scissor tool [ 898437 ] closed/unclosed state of path unclear [ 902731 ] Average nodes (node alignment) (w/screenshot) [ 903328 ] Snap to node/segment [ 907478 ] RFE: snap to nodes of existing objects [ 910817 ] NODE EDITING: Scaling, Mirroring, Rotation of Node Groups [ 933700 ] speed up node editing [ 949457 ] Node editing with mouse + layers [ 957936 ] selecting nodes as proper objects [ 976167 ] UI improvements and Node aligning [ 839065 ] Node Editing: Selecting nodes by clicking on path segments - Pattern [ 870837 ] pattern fills [ 980050 ] Repeat options in Fill and stroke dialogue for pattern fill - Shape [ 979490 ] "Whole object fill only" option [ 862731 ] TRANSFORMATION PREF: apply to several objects independently [ 863734 ] GUIDES: Copy+mirror with guides [ 863735 ] GUIDES: Snapping for 'shape editing nodes' [ 896514 ] Paint Brush / Eraser tool ala flash [ 926611 ] Circles and ellipses [ 936996 ] Group circles [ 954808 ] clockwise rotation of objects [ 957009 ] Splitting overlapping objects [ 856086 ] drag and copy - Text [ 986611 ] subscript, superscript [ 863325 ] TEXT bounding box and auto-wrap [ 863327 ] TEXT: Convert text to correctly-filled curve objects [ 865040 ] TEXT: Text on Path, in shape [ 952894 ] Text Effects like in Illustrator [ 966367 ] "Run length" text layout setting [ 857374 ] TEXT: Need support for text spacing properties <--************************************************************************* ***************************--> * Printing (maybe handled as extension/plugin in the future ?) [ 921531 ] Printing prints squares for gradients [ 965791 ] CUPS printing [ 967795 ] Multi-page printing <--************************************************************************* ***************************--> * SVG [ 949754 ] SVG Interactivity [ 862741 ] XML: put metadata in a metadata element; make valid [ 862744 ] SVG: animation [ 863380 ] Implementation of SVG Filters, specifically BLUR [ 864870 ] SCRIPTING: Sodipodi Script! or ECMAScript Support [ 864875 ] MASKING, or CLIPPING (CLIPPING PATH) NEEDED [ 865060 ] SVG: Implement support for data: URLs [ 893812 ] hyperlinking [ 899194 ] these svg dont render correctly (work in Abode SVG Viewer) [ 908792 ] NEW TOOL: Cloning/Spraypaint of Objects [ 909368 ] Less verbose markup, dont write unnecessary styles [ 944377 ] Inkscape .svg > plain .svg conversion tool [ 846335 ] allign coordinate systems - Styles [ 982095 ] CSS Support [ 862705 ] PALETTE: Object style chooser for primary toolbar [ 955788 ] Support Cascading Style Sheets [ 856716 ] STYLES: Giving styles a name and palette <--************************************************************************* ***************************--> * UI [ 994180 ] window size [ 863737 ] Snap indicator+ snap/guides dialog/palette [ 864868 ] UI: magnifying tool cursor, stock icons [ 865046 ] Inkscape REMOTE [ 899001 ] Use stock icons from Gnome [ 902217 ] Simpler process for theming icons [ 950128 ] A window for editing dash arrays [ 950537 ] Zoom out with right mouse button [ 959819 ] Tabbed interface for multiple documents [ 965592 ] fit drawing to page/fit page to drawing [ 981243 ] Allow to select units for displaying coordinates [ 992070 ] Interface Quirk [ 993367 ] UI for SVG accessibility features [ 862715 ] Initial value for "apply to:" in object style dialog - Dialog/Toolbars [ 995066 ] UI improvement [ 862662 ] Tear-off + dockable Menus (like gimp2) [ 874729 ] dialogs are too big [ 897187 ] Persistent/Custom Toolbars [ 978586 ] Abilily to choose font size for menu and dialogue [ 981544 ] [Win32] : dialogs always on top [ 992082 ] Tabbed Browsing Anyone? [ 838693 ] saving toolbars positions - Guide/Grid/Ruler [ 964668 ] Setting Zero Points on rulers [ 874731 ] GUIDES: Placement, Transformation [ 896820 ] "Lock guides" option [ 900270 ] isometric GRID type [ 903432 ] Snap selection to grid command [ 903437 ] Guides snap to grid [ 933675 ] double click on ruler opens guides dialog [ 933707 ] multi color grid [ 948307 ] guidelines rotate&clone [ 963828 ] gridlock instead of the cursor [ 859982 ] Inverted ruler co-ordinate system [ 928027 ] advanced snap features [ 933706 ] press alt to not snap - Lock [ 902729 ] Make insensitive/lock/unlock [ 979276 ] A "Unlock all" option [ 984633 ] A way to unlock a locked object - Palette/Color [ 994177 ] CMYK 0 - 100 not 0 - 255 [ 859147 ] Color Palettes [ 864545 ] HOWTO for Color Picker [ 865053 ] COLOR Preview (EASY ADD) [ 898822 ] wishlist: Palette Tool [ 903531 ] Makeshift palette [ 924655 ] user-defined named colors in fill/stroke dialog [ 969371 ] Named colors combo [ 973774 ] ability to copy color from dropper to clipboard [ 979214 ] a pot of painting tool [ 982981 ] Extended Color options [ 988419 ] Color picker doesn't bring color into gradient editor [ 989939 ] color components should be independent [ 856080 ] PALETTE: custom color swatches - Preferences [ 973295 ] storing main window size [ 932676 ] Save Preferences [ 937137 ] Set document defaults in preferences. [ 953325 ] pixel units [ 857373 ] PREFERENCES: New document setup prefs - Preview [ 985323 ] wireframe preview [ 862746 ] Document window icon [ 848230 ] editable viewBox, SVGs without width="" or [ 864290 ] Navigation window [ 955196 ] preveiw in file open/save dialogues [ 984071 ] preview window [ 839695 ] PRINTING: Need Preview - Selection/Group/Layer [ 991425 ] ADD LAYER MANAGEMENT, PLEASE! [ 856710 ] GROUPS: Enter and leaving groups [ 857357 ] LAYERS: Various ideas combined [ 897628 ] group extending for boolean operations [ 927908 ] REQ: display start.x,y end.x,y width height length angle [ 967363 ] Gray out unavailable commands [ 971537 ] visually distinct selection in focused/unfocused windows [ 971544 ] sets (named selections) [ 979866 ] "Extract from group" command [ 851464 ] Inconsitency in object style for multiple selects vs. groups [ 962564 ] lasso, polygon lasso selection tools - Shortcuts [ 989881 ] Customisable Shortcuts [ 877745 ] Keyboard shortcut to repeat last operation [ 902736 ] Shortcuts in button tooltips [ 914856 ] UI: Left-handed users [ 974180 ] Keyboard Mapping [ 863386 ] USABILITY (EASY) Tool options by double clicking tool button - Text [ 994189 ] text highlighting [ 864095 ] FONTS: Specifiy font size in mm, cm, m, in, ... [ 876892 ] no baseline-shift attribute [ 926591 ] Adding a text editor to inkscape [ 959816 ] Dropper tool for font attributes [ 962175 ] Add text search and replace feature [ 965421 ] A GUI to modify letter spacing [ 977533 ] text and font dialog redesign [ 979871 ] Text Editor lacks scrolled view [ 979875 ] Text editor: proposal new button "import text" [ 860118 ] TEXT: Text-tool properties toolbar - XML [ 847504 ] Ability to use external XML editors [ 899722 ] XML Editor changes [ 862720 ] XML EDITOR: RealTime Sync of Working and XML [ 960371 ] Syntax highlighting <--************************************************************************* ***************************--> * Others [ 848530 ] Wiki does not handle zero-space situation [ 865043 ] Illustrator Pathfinder [ 900436 ] Shape masking of objects and groups. [ 902711 ] PDF reference card [ 903342 ] Toggle visibility of object handles (View menu) [ 957129 ] Progressbar while opening files [ 956030 ] Welcome screen [ 956039 ] Make it faster [ 902519 ] Timed saves for backup

2 2

cannot compile
by bulia byak 23 Jul '04

23 Jul '04

I finally installed all the new libs and tried to compile CVS: Makefile:2804: *** missing separator. Stop. The line 2804 is: @am__fastdepCXX_TRUE@ if $(CXXCOMPILE) -MT $@ -MD -MP -MF "$(DEPDIR)/$*.Tpo" \ any ideas?

2 5

align comments
by bulia byak 23 Jul '04

23 Jul '04

I finally tried the new align dialog. I realize it's a work in progress but still here are some comments: - BUG: when I open the align dialog, then switch to another non-Inkscape window and then back to Inkscape, the dialog disappears. Even when I switch focus to the editing window, the dialog disappears (not only sinks but disappears completely). This does not happen with e.g. Fill&Stroke dialog, and it must be fixed as soon as possible. - merging the two tabs into one makes sense, but then remove the lone "Align" tab - the new title "Docker" tells me nothing - Align and Distribute is what it does, so that is the title it should use; also don't lose the shortcut listed in the dialog title, as in all other dialogs - the anchor menu must have an appropriate label, e.g. "Relative to:" - the anchor meny only applies to alignment, not distribution, and therefore must be inside the Align frame - the old behavior corresponds to Selection, and therefore Selection must be the first and the default selected item in the anchor menu; it's also the most intuitive - the Last/First Selected items may be confusing, because in many cases the order or selection is undefined (e.g. when you do a rubberband around several objects), so please remove them and add Top/Bottom Object (referring to z-order) instead - in the node mode, none of the anchor menu items make sense (nodes have no bigger/smaller, no z-order, etc) so the menu must be removed, instead it should always align within the bounding box of the selected nodes It looks very promising, so I look forward to your further work on this! :)

1 0

Re: freehand smoothing?
by Gazal, Geraud (MED) 23 Jul '04

23 Jul '04

Ainsi parlait Bulia Byak :" People keep complaining about the unsmooth freehand drawing in Inkscape and point out Sodipodi"s smooth drawing as its advantage over us: http://linuxfr.org/2004/07/20/16864.html (see comment "Sodipodi meilleur que Inkscape ?") " ------------------------------------------------------------------------ For info/tracking, RFE for this is [ 902216 ] Freehand tool needs to work smoother

2 1

RE: [Inkscape-devel] RFEs
by Gazal, Geraud (MED) 22 Jul '04

22 Jul '04

> On Wed, Jul 21, 2004 at 04:41:02PM +0200, Gazal, Geraud (MED) wrote: > > -> Read them, sorted, grouped (etc etc) > > This is great! Thank you, I will try tackling some of the > build/compile > issues. Cool It has also been a tool helping finding some redundancies : Some things that could be closed or explicited IMHO * [ 942328 ] relative image paths instead of absolute Can be closed. I think the issue with the path is now fixed. Example under win2k and Mandrake10 : a create a "project" directory, copy there the bitmaps needed, create there the SVG file(s) b work (!) (ie import some bitmaps) c create zip/tgz of the project directory, and send it somewhere else (mail/move) d unzip/untgz and open the svg file -> OK, the bitmaps are correctly linked/loaded in Inkscape * [ 922750 ] Inkscape ignores file extentions when exporting a file and [ 993210 ] Exporting to .jpeg The extension problems comes from the fact that Inkscape only bitmap-export to png. Maybe the use of a filter/pipe based on imageMagick or similar would allow to close this * [ 863323 ] FONTS: embedded SVG font support and [ 932954 ] SVG Fonts are quite similar * [ 952134 ] A tool and a key Seems Bulia has explicited all the necessary workarounds * [ 984633 ] A way to unlock a locked object [ 979276 ] A "Unlock all" option [ 902729 ] Make insensitive/lock/unlock Those three are quite close. Depending on the way Inkscape will handle layers, I think they might be closed with this new feature (if the layer UI allows user to (un)lock, set (un)printable, set(in)visible... each layer) And some others such as in "node editing", but they are hard to sort/reorganize... Regards, Matiphas

2 1

Re: [Inkscape-devel] Current libs in Win32 build
by bulia byak 21 Jul '04

21 Jul '04

> In addition to setting up the 0.40 win32 build today, > I also built the RELEASE_0_39_BRANCH with > the existing libs and put them in the 'builds' dir on the server. Thanks but it still includes the gtk-wimp. I cannot OK that because it is known to annoy people (me including) with endless warnings, see my earlier post. Please repackage without gtk-wimp (unless you know a solution to the warnings problem, of course).

2 2

Autobuilds working again
by Bob Jamison 21 Jul '04

21 Jul '04

Now that things have begun to settle down, it appears that the autobuilds are beginning to work once again. The cross-compiler and gtk2.4/gtkmm2.4 libs here: http://troi.titan-aeu.com/~rjamison/inkscape appear to be compiling Inkscape and linking it properly. You may notice the larger .zip file sizes. This is a result of the unstripped gtkmm .dll files in the distro. I experimented with linking the dll with the static gtkmm libs, then dynlinking the .exe's with that. The static libs for gtkmm/glibmm, unstripped, are > 120MB!!! So that is not an option for now. Maybe we can think of something else. Stripping is not an option, either. Why cripple the testers' ability to use GDB, the very reason to supply these binaries? However, this -is- development work, so hopefully our testing compatriots can bear with us for a while. Bob

1 0

download page
by Kees Cook 21 Jul '04

21 Jul '04

On here: http://inkscape.org/download.php Can we please not list autopackage first? Only a very few set of people will have the right libraries needed to make autopackage work. People should use it only if they have none specific for their distro and they feel like gambling. :) -- Kees Cook @outflux.net

3 6

W32 test with GTK2.4/gtkmm2.4
by Bob Jamison 21 Jul '04

21 Jul '04

I did a test build with the new libs, inkscape.dll, and inkview. However, I still do not have a Win32 box on which to test it. The file is at http://troi.titan-aeu.com/~rjamison/inkscape/builds : Inkscape24Test.zip It needs to be tested mostly because we need to make sure that the .zip has all of the necessary files in it. The new DLL package is gtk24.zip on the http://troi.titan-aeu.com/~rjamison/inkscape page. If any files are missing, that is where\ they would be. so.. someone might give it a try, and see if this thing is working! Hopefully we are making some progress. :) Bob

4 3

tagline
by bulia byak 21 Jul '04

21 Jul '04

Inkscape. Draw Freely.

7 11

[Fwd: Re: Inkscape 0.39 Released! : http://www.inkscape.org/]
by Jon Phillips 21 Jul '04

21 Jul '04

-----Forwarded Message----- > From: Philippe Lhoste <PhiLho@...463...> > To: Jon Phillips <jon@...235...> > Subject: Re: Inkscape 0.39 Released! : http://www.inkscape.org/ > Date: Tue, 20 Jul 2004 10:50:15 +0200 > > Jon Phillips wrote: > > Inkscape 0.39 > > ============= > > > > A Cross-platform Open Source Vector Graphics (SVG) Drawing Tool > > > > http://www.inkscape.org/ > [snip] > > Download your packages (Linux, Windows, Mac OSX): > > > > http://sourceforge.net/project/showfiles.php?group_id=93438 > > Good, I will test it when a Win32 exe will be released (I don't feel > like compiliing it myself...). > > I tested 0.38.1 but deleted it because it crashed on me after drawing a > simple curve. Sodipodi also crashed quickly. So right now, I have no > decent (free) tool to do complex SVG drawings... > > I hope this new version is more stable. I will try to be more patient > too, and to save frequently... (Did someone already suggested autosave > feature? Perhaps it is already there...) -- Jon Phillips PO BOX 948667 LA JOLLA, CA 92037 USA USA.PH.858.361.2811 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/)

4 5

Grad-Shaded Visio SVG export displays silhouette-only in inkscape
by Jeff Kowalczyk 21 Jul '04

21 Jul '04

Visio 2003 has some nice (gradient shaded isometric) computer and network shapes that I'd like to use in inkscape drawings. Visio 2003 does have an SVG export, and that SVG does display perfectly in Adobe acrobat reader. Inkscape (probably due to librsvg) only displays the silhouette of the shape, with solid black as the only visible color. Here is a simple one, pda.svg, that I thought would be short enough to post to the list. I stripped out the useless "v:" namespace where Visio stores additional information. Can anyone tell if this is simply a syntax issue, and that Visio's SVG export could be XSLT'd into a form that Inkscape (librsvg) could use? Or is it using svg features that librsvg isn't supporting yet. What about Cairo's xsvg? I have the png of pda.svg rendered in adobe svg viewer 3.0, if anyone wants a point of reference. Thanks. <?xml version="1.0" encoding="UTF-8" standalone="no"?> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.0//EN" "http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd">  <svg xmlns="http://www.w3.org/2000/svg" xmlns:v="http://schemas.microsoft.com/visio/2003/SVGExtensions/" width="0.524548in" height="1.07484in" viewBox="0 0 37.7675 77.3884" xml:space="preserve" color-interpolation-filters="sRGB" class="st9"> <style type="text/css"> <![CDATA[ .st1 {fill:#dddddd} .st2 {fill:url(#grad36-8);stroke:none;stroke-linecap:round; stroke-linejoin:round;stroke-width:0.72} .st3 {fill:url(#grad26-12);stroke:none; stroke-linecap:round; stroke-linejoin:round;stroke-width:0.72} .st4 {fill:#ffffff;stroke:#ffffff;stroke-linecap:round; stroke-linejoin:round;stroke-width:0.72} .st5 {stroke:#000000; stroke-linecap:round; stroke-linejoin:round;stroke-width:1} .st6 {fill:url(#grad39-21);stroke:#000000;stroke-linecap:round; stroke-linejoin:round;stroke-width:0.72} .st7 {stroke:#ffffff; stroke-linecap:round;stroke-linejoin:round; stroke-width:0.72} .st8 {fill:url(#grad35-31);stroke:#000000;stroke-linecap:round; stroke-linejoin:round;stroke-width:0.72} .st9 {fill:none;fill-rule:evenodd;font-size:12;overflow:visible; stroke-linecap:square;stroke-miterlimit:3} ]]> </style> <defs id="Patterns_And_Gradients"> <radialGradient id="grad36-8" cx="0" cy="0" r="1"> <stop offset="0" style="stop-color:#ffffff;stop-opacity:1"/> <stop offset="1" style="stop-color:#c0c0c0;stop-opacity:1"/> </radialGradient> <linearGradient id="grad26-12" x1="0" y1="0" x2="1" y2="0"> <stop offset="0" style="stop-color:#969696;stop-opacity:1"/> <stop offset="0.5" style="stop-color:#ffffff;stop-opacity:1"/> <stop offset="1" style="stop-color:#969696;stop-opacity:1"/> </linearGradient> <radialGradient id="grad39-21" cx="1" cy="1" r="1"> <stop offset="0" style="stop-color:#ffffff;stop-opacity:1"/> <stop offset="1" style="stop-color:#c0c0c0;stop-opacity:1"/> </radialGradient> <pattern id="grad35-31" x="0" y="0" width="1" height="1" patternContentUnits="objectBoundingBox"> <path d="M 0.5 0.5 L 0 0 L 0 1 z" style="fill:url(#grad27-32)"/> <path d="M 0.5 0.5 L 1 0 L 1 1 z" style="fill:url(#grad25-33)"/> <path d="M 0.5 0.5 L 0 0 L 1 0 z" style="fill:url(#grad30-34)"/> <path d="M 0.5 0.5 L 0 1 L 1 1 z" style="fill:url(#grad28-35)"/> </pattern> <linearGradient id="grad27-32" x1="1" y1="0" x2="0" y2="0"> <stop offset="0" style="stop-color:#ffffff;stop-opacity:1"/> <stop offset="1" style="stop-color:#c6d1e3;stop-opacity:1"/> </linearGradient> <linearGradient id="grad25-33" x1="0" y1="0" x2="1" y2="0"> <stop offset="0" style="stop-color:#ffffff;stop-opacity:1"/> <stop offset="1" style="stop-color:#c6d1e3;stop-opacity:1"/> </linearGradient> <linearGradient id="grad30-34" x1="0" y1="1" x2="0" y2="0"> <stop offset="0" style="stop-color:#ffffff;stop-opacity:1"/> <stop offset="1" style="stop-color:#c6d1e3;stop-opacity:1"/> </linearGradient> <linearGradient id="grad28-35" x1="0" y1="0" x2="0" y2="1"> <stop offset="0" style="stop-color:#ffffff;stop-opacity:1"/> <stop offset="1" style="stop-color:#c6d1e3;stop-opacity:1"/> </linearGradient> </defs> <g> <title>Page-1</title> <g id="group1-1" transform="translate(1,-22.4)"> <title>PDA</title> <g id="shape2-2" transform="translate(23.04,0)"> <title>Sheet.2</title> <path d="M7.26 77.39 A6.17383 6.13387 -147.42 0 0 10.09 66.05 L4.99 61.8 L0 77.39 L7.26 77.39 Z" class="st1"/> </g> <g id="shape3-5" transform="translate(0,0.994011)"> <title>Sheet.3</title> <path d="M0.01 64.98 A6.92177 6.46609 -173.26 0 0 1.96 68.95 A27.0149 25.2365 -173.65 0 0 18.82 77.39 A23.3148 21.7799 -13.91 0 0 23.04 75.67 L23.04 38.95 A110.542 103.264 -176.97 0 0 -0 25.73 L0.01 64.98 Z" class="st2"/> </g> <g id="shape4-9" transform="translate(23.04,-0.72)"> <title>Sheet.4</title> <path d="M-0 77.39 A9.04877 8.45306 -3.65 0 0 5.76 72.35 L5.76 37.43 A4.19595 3.91972 174.04 0 1 -0 40.67 L0 77.39 Z" class="st3"/> </g> <g id="shape5-13" transform="translate(0,-37.1654)"> <title>Sheet.5</title> <path d="M0 63.89 A110.543 103.266 3.02 0 1 23.04 77.11 A4.19685 3.92056 -5.85 0 0 28.8 73.87 A58.4628 54.614 -177.28 0 0 5.93 60.6 A5.55284 5.18728 -180 0 0 -0 63.89 Z" class="st4"/> </g> <g id="shape6-15" transform="translate(0,-2.78408E-005)"> <title>Sheet.6</title> <path d="M0.01 65.97 A11.1884 10.4518 -180 0 0 1.96 69.95 A25.0318 23.3838 -180 0 0 19.53 77.39 A10.5963 9.89872 -2.06 0 0 28.8 71.63 L28.8 36.71 A58.4348 54.5878 -177.35 0 0 5.9 23.43 A5.6639 5.29102 -0.98 0 0 -0 26.84 L0.01 65.97" class="st5"/> </g> <g id="shape7-18" transform="translate(-29.1787,7.51528) rotate(-30)"> <title>Sheet.7</title> <ellipse cx="3.29831" cy="72.7766" rx="3.29831" ry="4.61179" class="st6"/> </g> <g id="shape8-22" transform="translate(-21.03,4.1047) rotate(-30)"> <title>Sheet.8</title> <ellipse cx="1.36922" cy="75.4621" rx="1.36922" ry="1.92632" class="st6"/> </g> <g id="shape9-25" transform="translate(3.6,-11.52)"> <title>Sheet.9</title> <path d="M15.98 77.39 L0 68.17 L0 44.27" class="st7"/> </g> <g id="shape10-28" transform="translate(3.6,-11.52)"> <title>Sheet.10</title> <path d="M0.72 67.67 L15.98 76.52 L15.98 77.39 L15.98 53.56 L0 44.27 L0.72 44.7 L0.72 67.67 Z" class="st8"/> </g> <g id="shape11-36" transform="translate(-33.9645,-3.4758) rotate(-30)"> <title>Sheet.11</title> <ellipse cx="1.36922" cy="75.4621" rx="1.36922" ry="1.92632" class="st6"/> </g> <g id="shape12-39" transform="translate(-20.7104,-26.3426) rotate(-30)"> <title>Sheet.12</title> <ellipse cx="0.886417" cy="76.1414" rx="0.886417" ry="1.24708" class="st6"/> </g> </g> </g> </svg>

5 9

SVG Tiny Article and Question
by Jon Phillips 21 Jul '04

21 Jul '04

Hello All, There is an interesting post on Slashdot about MACROMEDIA's erroneous support of SVG Tiny. The O'Reilly article attached to the post mentions how many cell phone manufacturers are supporting SVG Tiny. http://slashdot.org/article.pl?sid=04/07/20/2250256&tid=152&tid=95 http://www.w3.org/TR/SVGMobile/ Oreilly's Post: http://oreillynet.com/pub/wlg/5212 Macromedia's Post about: http://www.macromedia.com/devnet/devices/articles/msvg_t.html Anyhow, we have been discussing on the chat channel, and I wonder the best way to implement support for this emerging market? Could we make it as simple as an export, or as simple as a save-as, like plain svg? Also, anyone in the know, how long would such a thing take to implement. I'm keeping my eyes on the watchout for where SVG will be supported, and it appears (and this comes from talking to industry folks in US, Japan, and KOREA) that the emerging market for SVG (at least initially) will be for cell phones. What is the best way to go about implementing this? I am going to seek out Macromedia folks and W3C folks at siggraph in a couple of weeks, and would love to have some thoughts and positions on this... Jon -- Jon Phillips PO BOX 948667 LA JOLLA, CA 92037 USA USA.PH.858.361.2811 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/)

1 0

Re: [Inkscape-user] Make fails - freetype problem?
by MenTaLguY 21 Jul '04

21 Jul '04

On Tue, 2004-07-20 at 10:18, John Mellor wrote: > I have freetype-2.1.8 installed. The error sounds quite explanatory but > not sufficiently so for my lack of experience. Can anyone help please? Specific versions of freetype seem to have different requirements for which header files to include. :/ -mental

1 0

The standard for PO files is now UTF-8
by Arpad Biro 20 Jul '04

20 Jul '04

Dear Translators, This is to let you know that all non-UTF-8 translation files have been converted to UTF-8 (and will automatically be in the future if needed). Please use this standard so that we will have fewer i18n problems. Thanks. Arpad Biro __________________________________ Do you Yahoo!? Vote for the stars of Yahoo!'s next ad campaign! http://advision.webevents.yahoo.com/yahoo/votelifeengine/

1 0

Tarball Release Sizes
by Bryce Harrington 20 Jul '04

20 Jul '04

Stats for how our tarball size has changed over different releases: 1.9M inkscape-0.35.tar.gz 1.9M inkscape-0.36.tar.gz 2.5M inkscape-0.37.tar.gz 3.2M inkscape-0.38.1.tar.gz 4.2M inkscape-0.39.tar.gz I think that's pretty good; I was expecting the size to be about double that. 4.2M should be very little trouble for folks to download. :-) In the current release, here's a rundown of the top 20 largest files: 1124712 ./share/tutorials/elementsofdesign.sl.svg 1097642 ./share/tutorials/elementsofdesign.svg 899283 ./configure 753019 ./src/Makefile.in 321787 ./share/screens/keys.svg 320641 ./share/tutorials/tutorial-advanced.sl.svg 319166 ./share/screens/keys.sl.svg 295727 ./share/tutorials/tutorial-advanced.svg 292340 ./share/tutorials/tutorial-advanced.fr.svg 266949 ./aclocal.m4 253315 ./share/tutorials/tutorial-basic.sl.svg 245013 ./share/icons/icons.svg 232963 ./share/tutorials/tutorial-basic.ru.svg 231423 ./share/tutorials/tutorial-basic.fr.svg 224177 ./share/tutorials/tutorial-basic.svg 184019 ./ltmain.sh 178732 ./share/tutorials/tipsandtricks.sl.svg 149112 ./share/tutorials/tipsandtricks.svg 142727 ./po/sr.po 141439 ./po/fr.po Directory sizes: 32K debian 288K doc 5.0M po 6.7M share (largely the tutorials section) 7.2M src We've batted around the idea of eventually breaking the tutorials out into separate language-specific distribution packages someday maybe in a few releases, especially as we gain additional translations of them. Looks like it isn't a problem right now though. Bryce

3 2

autopackage for 0.39, upcoming patches
by Mike Hearn 20 Jul '04

20 Jul '04

Hi guys, Firstly, some good news. On compiling Inkscape against the GTK 2.2 headers, which is a part of doing an autopackage release of it, my crash mysteriously vanished. So that's an interesting data point. Secondly, there is an package of 0.39 available here: http://navi.cx/~mike/inkscape/0.39/inkscape-0.39.package It's built against a new version of autopackage, 0.6, which will be released properly sometime tomorrow. Likewise the nightlies and the GTKmm/sigc++ packages have also been rebuilt against that release. I checked the server logs the other day, there have been ~1700 downloads of the inkscape autopackage. Of those approximately half also pulled in GTKmm as a resolved dependency. We've had very little feedback from this - I had assumed there simply weren't many people using the service, but clearly this is not the case. I guess it's simply working pretty well for people! :) Because of this I'm feeling pretty confident that the 0.6 release is likewise stable and reasonable compatible with a variety of setups - in fact we've fixed a few distro compatibility bugs in this release, especially for Slackware users. So, if you could link to the 0.39 package from the Inkscape website, that'd be great as I feel a lot of people would benefit from a package of the stable release. Hongli has created some stock HTML that people can embed/tweak for their websites which identify the fact that it's an autopackage and link to the instructions for how to install them: http://www.autopackage.org/docs/howto-install/index.html I don't have that right now, but I'd be interested in your opinions on the stock HTML idea later. Having packaged up Inkscape of course I wanted to play with it - that's where the crash report came from. So I drew an icon/logo for autopackage: http://autopackage.org/logos/logos.html Why not marvel at my lack of artistic talent? If any of the pros on this mailing list want to draw us a better one please feel free! :) Finally, I'm afraid I'm not finished with the patches yet! This: http://cvs.sunsite.dk/viewcvs.cgi/*checkout*/autopackage/apbuild/relaytool ... is likewise a non-work of art. I was originally going to submit a patch to make gtkspell dlopened at runtime, but realised that this was (a) tedious and (b) going to happen a lot. So I wrote relaytool which is designed to automate it. For those who haven't read the above URL, relaytool is a program which generates C files you can compile and link into your app, which replaces the -lfoo option you'd normally use with a "soft link". It uses assembly and ELF magic to perform the link at runtime using dlopen, but it won't fail if the library isn't present. The interesting thing about this approach is that it requires no code changes, and doesn't rely on icky stuff like header rewriting. Code like this: #ifdef HAVE_GTKSPELL gtkspell_attach( ... ) #endif can simply become: #ifdef HAVE_GTKSPELL if (libgtkspell_is_present) gtkspell_attach( ... ); #endif And as long as the binary was compiled in the presence of the gtkspell headers, at runtime Inkscape will use libgtkspell if it's present and continue without spell checking ability if it's not. Therefore we can cut down on the number of hard dependencies for Inkscape, so increasing the reliability and robustness of the installation. It works for exported variables too, though not many libraries use that. In theory it also works for C++ objects but I haven't tried it yet. You use it like this: gcc -o testapp testapp.c -lgtkspell becomes gcc -o testapp testapp.c `relaytool --relay gtkspell -lgtkspell` And the stub file will be generated and compiled transparently on systems that relaytool supports. On systems it doesn't support the -l option is passed through unchanged. relaytool isn't quite ready yet, in particular I need to write an autoconf check for ELF platforms so using it doesn't interfere with the build on Windows and MacOS X. We can use a similar technique to allow Inkscape to use the GTK 2.4 file picker but cleanly fall back to the GTK 2.2/2.0 APIs when GTK 2.4 isn't present. Hope that helps, thanks -mike

3 6

Re: Tarball Release Sizes
by Robert Crosbie 20 Jul '04

20 Jul '04

Can the svg tutorials be saved as svgz? That should reduce their size in the release a bit. Cheers, Rob. http://members.rogers.com/rcrosbie _________________________________________________________________ Take charge with a pop-up guard built on patented Microsoft� SmartScreen Technology http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht… Start enjoying all the benefits of MSN� Premium right now and get the first two months FREE*.

2 1

Re: [Scribus] linked text
by Jon Phillips 20 Jul '04

20 Jul '04

Hi Sebastian, We would love your help on the German translation. If you do, please make a patch and upload to our patch tracker. If you would like to join our project as a developer after that initial patch, then we will welcome you with open arms. (our policy is one good submission and then cvs access) INKSCAPERS: Could someone who deals with translations communicate with Sebastian further please. Thx! Jon On Sat, 2004-07-17 at 04:07, Sebastian Röder wrote: > Hi Jon, > > i didn`t manage to write to the inscape mailing list as annonymous user so > maybe I can write my short "feature request" here: > > I work a lot with Scribus (at least in last weeks) and want to work with > Inkscape to create graphics for my Scribus layouts. But the German > tranlation for inkscape is not up to date (I guess around 80% not translated) > so it is realy hard for the first steps to get to know how things work in > inkscape. I already wrote a Email to the former translater (I found an Email > adress in the .po file) but he was the old sodipodi translater and will nor > update the inkscape .po anymore. Seems like there is a German translater > missing! And seems like I have to sign for the inkscape mailinglist as well. > Maybe you can add my little request to the inkscape list for now? > > Thanks, > Sebastian Roeder - German Scribus (and one day Inkscape) user > _______________________________________________ > Scribus mailing list > Scribus@...119... > http://nashi.altmuehlnet.de/mailman/listinfo/scribus -- Jon Phillips PO BOX 948667 LA JOLLA, CA 92037 USA USA.PH.858.361.2811 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/)

2 1

Is there a reason to not upload the 0.39 autopackage to SF?
by bulia byak 20 Jul '04

20 Jul '04

2 1

Inkscape 0.39
by Ted Gould 20 Jul '04

20 Jul '04

= Inkscape 0.39 = We are pleased to announce the Inkscape 0.39 release. The most important change in this release is the switch to the Pango library for font handling and Unicode support; a lot of work also went into new SVG features, export/import, UI, and usability. Here are the highlights: * Pango: smoother text display, auto kerning, better i18n (automatic font substitution, right-to-left text, bi-directional text), less platform dependence * New SVG features: markers (aka arrowheads), clones (svg:use), pattern tiles, RDF metadata; many SVG compliance bugfixes * New dialogs: Preferences, Find, Metadata * New and improved import/export file formats: PS, EPS, AI, PNG, JPEG, TIFF, BMP, Sketch, Dia, and more * Pure convenience: usable dropper, scale switches, Commands bar, more tool controls (including rounded stars), more import formats, more paper sizes, Revert command, edit inside group, better selection cues, spell checking, window layout configurable, streamlined Fill & Stroke, snapping improvements, better rounded corners in rects, path reversing, persistent rotation crosshair, per-object export hints, and much more * Internals: speedups, more C++ification, garbage collection, SigC++ signals, wider use of new data structures, extensive cleanup * Plus: new documentation, new translations, lots of assorted bugfixes (the infamous "freeze when dragging outside of window" bug on Windows is gone!) The team has placed a great deal of scrutiny into fixing bugs, and while this was not a primary focus as it had been for 0.38.1, we expect this release will be at least as stable as the last. Many thanks go out to all of the users that took the time to write bug reports, you make Inkscape better. For tons more details, see the Release Notes for 0.39: http://www.inkscape.org/cgi-bin/wiki.pl?ReleaseNotes039 Screenshots: http://www.inkscape.org/screenshots/ Download your packages (Linux, Windows, Mac OSX): http://sourceforge.net/project/showfiles.php?group_id=93438

3 2

[Fwd: Re: [Scribus] linked text]
by Jon Phillips 20 Jul '04

20 Jul '04

SCRIBUS meeting after release of 0.40? If agree, I will place on roadmap. Jon -----Forwarded Message----- > From: Craig Bradney <cbradney@...242...> > To: Jon Phillips <jon@...235...> > Cc: Peter Linnell <scribusdocs@...84...> > Subject: Re: [Scribus] linked text > Date: Sat, 17 Jul 2004 11:38:16 +0200 > > Hi Jon > > yep.. for sure.. We will have another meeting. We just need to make a > date and have it. I guess it would be more worthwhile after your 0.39 > release and our 1.2 release. > > Of course.. we are always happy to have one before! > > Craig > > On Sat, 2004-07-17 at 06:36, Jon Phillips wrote: > > I like that. You guys are doing a great job. Hopefully sometime this > > summer we could have another get together between scribus and inkscape > > developers... > > > > Jon > > > > > > > > On Wed, 2004-07-14 at 04:53, Craig Bradney wrote: > > > Yes.. but we need some other code written first, as well as our 1.2 > > > targets to be met. Once the "other code", ie our new text importers are > > > finished, we can investigate the auto update stuff. At a guess it wont > > > be that hard, but no guarantees for before 1.2 at all. > > > > > > Craig > > > > > > On Wed, 2004-07-14 at 03:16, Jon Phillips wrote: > > > > But I've proposed this previously as a great addition to SCRIBUS. It > > > > would dramatically increase the ability for editors and designers to > > > > work together, but not in the same app. > > > > > > > > Jon > > > > > > > > > > > > On Tue, 2004-07-13 at 01:57, Craig Bradney wrote: > > > > > On Tue, 2004-07-13 at 09:58, vaise@...462... wrote: > > > > > > Hi everyone ! > > > > > > I use Scribus 1.0.1 on Mandrake 10. > > > > > > When I insert a text frame, I can Get Text, no problem. But I would like the > > > > > > scribus document to be "linked" to the text file. When the .txt file is > > > > > > modified, the scribus document should change too (next time it is opened of > > > > > > course). > > > > > > Maybe this fonctionality does not exist in 1.0.1 ? > > > > > > > > > > > > Dsant > > > > > > > > > > Hi > > > > > > > > > > No, there is no possibility to do this in any version. > > > > > > > > > > Craig > > > > > > > > > > ______________________________________________________________________ > > > > > _______________________________________________ > > > > > Scribus mailing list > > > > > Scribus@...119... > > > > > http://nashi.altmuehlnet.de/mailman/listinfo/scribus -- Jon Phillips PO BOX 948667 LA JOLLA, CA 92037 USA USA.PH.858.361.2811 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/)

2 1

0.39 PR
by Jon Phillips 20 Jul '04

20 Jul '04

Bryce and all, Could we circulate the PR for this release and place on the wiki prior to being sent. That way we can add our two cents. I think we need to be more descriptive in our releases about what is done and what could be accomplished with new features. http://www.inkscape.org/cgi-bin/wiki.pl?AnnouncementPR Jon -- Jon Phillips PO BOX 948667 LA JOLLA, CA 92037 USA USA.PH.858.361.2811 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/) -- Jon Phillips PO BOX 948667 LA JOLLA, CA 92037 USA USA.PH.858.361.2811 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/)

2 1

Current libs in Win32 build
by Bob Jamison 20 Jul '04

20 Jul '04

Getting the Win32 build working with the new libs is still a work-in-progress. However, here are the current libs I am using, FYI: atk 1.6.0 boehm-gc 6.2 freetype 2.1.7-1 gettext 0.13.1 glib 2.4.2 glibmm 2.4.3 gtk+ 2.4.3 gtkmm 2.4.4 gtk-wimp 0.6.0 jpeg 6b-3 libart_lgpl 2.3.14 libcroco 0.6.0 libiconv 1.9.1 libpng 1.2.5-1 libpopt ? <static> libtiff 3.6.1-2 libxml2 2.6.9 pango 1.4.0 sigc++ 2.0.3 zlib 1.2.1 A few of these I have built myself. Others are binaries built by others, over which we have no control. Bob

5 5

RE: [Inkscape-devel] Test strategy
by Gazal, Geraud (MED) 19 Jul '04

19 Jul '04

> Either Wiki or CVS would be suitable places for storing it. There are > roughly equal pros and cons both ways. Wiki would be more widely > accessible to more people, but CVS would allow a little more > flexibility > for manipulating the document (e.g., grep, txt2pdf, etc.) -> workaround : HTML format ( portable, plus support usefull things such as images, links, tables...) maintained in the CVS and linked to a wiki page ? > It may be worthwhile if we have better ideas for the > categorization, to > alter the bug tracker to match. Those categories were decided when we > first started the project, and probably need updated to match what we > people actually support bugs about. If anyone has ideas for > improvements let me know and I'll apply them. Yup, this is directly linked to the test process. I'm preparing (70% done) it. > A subcategory of this is 'Compliance testing', which validates the > features against a spec - in our case the W3C SVG spec. There may be > other specs we can test compliance against, although some (like the > GNOME Human Interface Guidelines) will generally not be automatable. Ok, got it. Will take a look at Gnome HIG see what can be done there (not my #1 priority, but kept on the list) Already diving in SVG standards, plus test tool suite. > There is also performance testing, which can be done in a variety of > ways. For example, startup timing, function-level profiling, etc. > > Also, we should include memory error testing ala purify and valgrind. Already in mind for the categories. > > > Tests: > > Build > > Linux (Debian / Gentoo / Slackware / Mandrake / Fedora > / Suse / Others) > > Windows (98 / 2000 / XP) > > MacOS (X) > > BSD (Free / Open) > > Other Unices (Solaris / Irix) > > Note that an important condition for distros is what installation > options were used. For example, a pure-base SuSE > installation will not > include developer tools like gcc. Most distros also have installation > options which will end up lacking the -devel libs that > Inkscape needs to > compile. So each of these will require specification as to which > installation options must be used during setup. Argh, sounds complicated. The best thing, I suppose is to identify a maintainer by distro (ala Mandrake) and ask them to write down the specs for their respective distro > > Notice : should be automated (example see : > > http://public.kitware.com/Dart/HTML/Index.shtml) > > Interesting - have you used this system? Yes, that's why I was thinking about it :) But I'm trying to find even better and flexible > > - open Inkscape, launch reference editing sequence, > export result as > > bitmap and compare with a reference bitmap provided by a reference > > application on the same sequence (Inkscape itself for non > regression, Batik > > ?) > > Previous sequences can be combined in one in order to save > time, but then > > analysis of results can become more complex. > > Note, I developed a way using motion tracker software to calculate a > "percent similarity" rating given an Inkscape-generated png against a > Batik-generated png, that makes the analysis work easier. There's a > glitch that'll need to be worked out, in that the original > SVG's contain > the description in the image, which throws off the comparison. Simply separate analysis of pixels and metadata (I'm quite used to it : have worked on the dicom standard for 3 years) > > > Verification of robustness > > - testing memory leaks (not a specialist of this : I need help) > > This is an area where our work as testers is really cut out for us, > because there is a ton of memory issues in the codebase, and > we need to > be able to categorize in a way that makes them accessible to the > developers. Right now there's such an overwhelming number that > developers wouldn't know where to start, so if in testing we can > triage and prioritize the "top 10" or whatever, it would make > the fixup > work more tractable. Right. But in fact, as for unit tests, this part of the verification is hard to manage by testing team. It's mainly up to coders to operate this. Testing team can provide help (crash report, reproducibility of malicious scenarii...) but (for example in my case) are not code/design wizzards able to slalom in the memory/architecture maze. > > - provide a shaker tool (this tool would launch > Inkscape and then start > > a predefined number of pseudo-random commands -logging each > action). The > > goal is to detect crashes and analyse their conditions with the logs > > Another idea along these lines is to fire a variety of signals at it, > and detect if it behaves correctly. Just need a few precisions so that I understand better > Again, this plan looks very good, I'm looking forward to > this. I have a > feeling that since there is a *huge* amount of improvement we can gain > by taking a systematic approach to it like this. I think > it'll also be > very intriguing to figure out how to effectively meld systematized > testing with open source practices, and to see how much can be > accomplished in doing so. Ok, I'm pleased if you find the approach interesting. Regards, Matiphas

2 1

Re: Extension Proposal (First Draft)
by Gazal, Geraud (MED) 19 Jul '04

19 Jul '04

Hi Bryce, just need a small precision (paragraph 8.1) You mention plugins as loaded as dynamic objects (so/dll) ans thus being c/c++ (or somewhat compiled). I was wondering about let's say, something written in Python (because I appreciate this language, and because it is availabe on nearly all platforms). Python (or perl, ruby...) programs can nearly behave as dynamic objects. Would it be considered as a script or a plugin ? Main only concern is will it be possible writting plugins in interpreted languages (small memory print, easier to develop/maintain, often more portable...) Regards, Matiphas

2 1

ATTENTION: libgc dependency
by MenTaLguY 19 Jul '04

19 Jul '04

Please note that sometime in the next few weeks we'll be introducing a dependency on the Boehm garbage collector (libgc), and that said library must be compiled with C++ support enabled. I'd encourage all packagers/autobuilders to investigate whether there will be any problems for them. -mental

2 1

Report for 2004-07-18 18:00 GMT-0500
by unknown＠example.com 19 Jul '04

19 Jul '04

Hi. I have some bad news. Unfortunately, the last build attempt at compiling Inkscape CVS was very unsuccesful. I'm sorry, I really tried hard. Really. Here is the LOG file, and I hope that helps.

6 5

AW: [Inkscape-devel] Plain svg format?
by Taraben, Adib 19 Jul '04

19 Jul '04

>On Sun, 2004-07-18 at 20:01, bulia byak wrote: >> Yes, and I'm thinking about _why_ this may be needed, and can only >> think of the two reasons above. > >IMO, the most fundamental (if not most common) reason is to yield an SVG >document which will validate against the SVG DTD. > >Having elements in any non-SVG namespaces would (afaiK) prevent that. > >Of course, I'm not really sure most folks care about DTDs much anymore, >given they don't play well with namespaces in general. > >-mental I care. In my special purpose inkscape is not only a drawing program but a (_THE_) svg-editor. Adib.

2 1

ATTENTION: gtkmm upgrade
by MenTaLguY 19 Jul '04

19 Jul '04

I've just comitted Aubanel's gtkmm upgrade patch. You will need to rerun autogen.sh. >From now on, libgtk+ >= 2.4, libsigc++ >= 2.0 and libgtkmm >= 2.4 are required for Inkscape. I have tried to carefully test and build, but this did require some autofoo changes I do not fully understand. So be aware, and if you have any problems please help me track them down and fix them. -mental

5 9

Plain svg format?
by Øyvind Hvamstad 19 Jul '04

19 Jul '04

Hi, I just dig this app. Good work. However, I have some problems with the new rdf metadata tags when storing plain svg in 0.39. It seems that no namespace declarations are present for rdf, dc and cc. Adding them to the top fixes the problem, but it's really a hazzle when you have some 30 figures in a thesis. :) I added these: xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:cc="http://web.resource.org/cc/" You probably know this already, but if not.. Well.. Jimi needs valid xml! Inkscape rocks! (more than sodipodi :)) -- Øyvind Hvamstad <oyvind@...457...>

5 6

All tasks for 0.39 Milestone Completed
by Bryce Harrington 18 Jul '04

18 Jul '04

All of the tasks for milestone 5 "Inkscape 0.39" are now complete (the extension proposal was the last, oft-procrastinated item). I've moved all the completed Milestone 5 tasks to the PastMilestones page. Bryce

1 0

Proposal for Hard Freeze Process
by Bryce Harrington 18 Jul '04

18 Jul '04

As mentioned in the freeze process proposal for this release, we will have a new 'Hard Freeze' step to give us better quality control for the run-up to the Release Phase. During the Hard Freeze, we all refrain from committing to CVS. Instead, necessary changes should be posted to the patch tracker. A couple people -- the "Change Control Team" -- have the responsibility to vet and apply patches if they're absolutely necessary. For this release, I'd like to propose Mental and Bulia as the Change Control Team, and that we rotate who is on this team in future releases. Because the Inkscape developers are trustworthy, I think we can rely on the honor system, rather than turning off everyone's access. If there happened to be any abuse, it can be handled on a case-by-case basis. Here's how the process would work: === Hard Freeze Phase === 0. The Hard Freeze will be announced once all of the Must Fix bugs have been addressed and the codebase passes its distcheck and tests. Nobody except Change Control commits into the release tree after this point - only to the patch tracker. 1. The Change Control Team reviews the status of the application and of recent bug fixes. They request patches for abnormalities found. 2. Only patches for key bug fixes, documentation, packaging, and translations will be taken at this point. 3. Once the Change Control Team is satisfied, they announce that the codebase is Good For Release, and branch the release candidate. (See CreatingDists.) This marks the end of the Hard Freeze phase. === Release Phase === 4. The Release Team creates the distribution source tarball package, and posts the GPG-signed tarball(s). 5. Packagers begin creating the 0.XX.0-1 packages of this release for their platforms. 6. The Release Phase should be treated like a Feature Freeze; everyone can resume committing to CVS, but should limit themselves to bug fixing, in case there are serious issues that will require making a new point release. 7. If issues are discovered during this packaging process, the Change Control Team will review the changes and their fixes and choose: a) Ignore the issue for this release. b) Put up an optional package for packagers to use as needed. The packagers increment their patch-number (i.e. 0.XX.0-1) c) Declare a minor-rev increase (i.e. 0.XX.1). All packages must be regenerated in this case. 8. Once a suitable number of working, tested packages have been posted to the file tracker, the Release Team announces that the codebase is Released. 9. Finally, announcements about the release are made. This also marks the end of the Release Freeze. 10. Normal development resumes. Bryce

3 5

tab -> 4 spaces
by Kees Cook 18 Jul '04

18 Jul '04

Is anyone interested it doing this to the source code? I made a test CVS tree to see how much would be changed. The file count is 565. :) I only processed files in /src, but it would be a giant commit. I personally find in valuable, but worry it would really disrupt other folks. On the other hand, doing it after a release seems like the best time to do it. Thoughts? -- Kees Cook @outflux.net

2 3

Re: [Inkscape-devel] Re: [Inkscape-devel] BUG and solution in align dialog
by bulia byak 18 Jul '04

18 Jul '04

> My SF name is o__b Done, you can commit your code now. Welcome to the team! :) > > One idea I had is this: Imagine you have a path consisting of strict > > horizontal and vertical segments, and you want to distribute (some of > > the) vertical segments (not nodes!) equi-spacely. I think it's a > > pretty common situation, but distributing _nodes_ will break the > > verticality of segments. So I propose to add a (perhaps optional) > > rule: If two or more nodes are aligned vertically (within some > > tolerance), consider them one node and move them as a whole during > > horizontal distributions, and the same for horizontal > > alignment/vertical distributions. Makes sense? > > > Looks weird to me, and could be surprising for the user. But I understand the > need for such a functionality. If we generalize a bit, this would be > distributing groups of nodes. But this is hard in terms of UI. Yes, what I propose is a subset of "distribute groups", and yes, fully generalized "distribute groups" is difficult to implement and may be overcomplex in terms of UI. Which is why I propose this special case - I think it's very common in practice and pretty intuitive once you get used to it. Just think of it as nodes "snapping together" when they're on one horizontal or vertical, so that distribution buttons treat them as a whole. This may be switched off by a checkbox in the align dialog (on by default, with the state remembered across sessions in a preference value). > > Another thing I always wanted to have is Random distribution. Maybe > > you can add it while you're working on that dialog, I think it should > > be easy enough? > > > > I'm not sure to understand what it means. Just throw each node on an random > position, or keeping the order and randomize the step size, or even > distribute against a distribution function (gaussian, poisson, etc.) ? In fact there may be many various approaches to randomization, but for practice, what I think will be the most useful is two buttons: Shake and Shuffle. 1. Shake: Each selected object moves by some small random distance from its current position. Here a Gaussian distribution would be appropriate, so that small displacements are more frequent than large ones. The default radius might be 0.05 of the total span (span == the distance between the outermost selected object), with this value ("the force of the shake") settable in preferences. Shake may sometimes change the order of objects if they're close together, but normally it will not. If you need a stronger shake, just keep pressing the Shake button. 2. Shuffle: All objects are placed at random points within the entire span between the outer objects. This does not preserve the order of the objects, but shuffles them like cards in the pack. For example, if you have a row of equispaced objects and you want to change their positions randomly but keep the equispaced distribution, you press Shuffle and then Distribute equispaced to space them evenly again. Note: it is obvious that the overall span of the objects will keep getting narrower if you press Shuffle repeatedly. I'm not sure if this is a problem that we have to live with, or it makes sense to try to compensate for it by artificially expanding the span before shuffling so that, _on average_, the span stays the same across many subsequent shuffles (it's an interesting mathematical problem, by the way - how much we need to expand the span for this condition to satisfy). Also note: in the above, "objects" may be nodes (in node tool) or object centers (otherwise); I don't think we need separate shake/shuffle buttons for left/right edges. However, when calculating the span, it makes sense to measure it between the outer edges of the bboxes of the outer objects, not between their centers. Let me know what you think of this plan. > Done. I'm just wondering why so many enums are anonymous and you pass plain > ints as parameters ? No idea, maybe just Sodipodi legacy... > > > Yes. But as we will refactor all the dialogs, that should be > > > the right time to do it. The only thing needed is to make > > > each dialog inherit from a class. > > > > That's a good idea, as currently there's much shared code that can be > > moved to the parent class (delete/destroy handlers, etc.). Some of the > > shared code is already factored out into dialog-events but not all. > > > OK, I'll look at this. Obviously what needs to go into that class is all the standard global variables in all dialog files (x, y, w, h, dlg, etc.).

2 1

gtkmm 2.4
by MenTaLguY 18 Jul '04

18 Jul '04

Now that we've branched for the release, HEAD is unfrozen. I think my first bit of work will be to merge Aubanel's gtkmm 2.4 patch sometime in the next few days. If this will cause undue problems for anyone, please scream now. -mental

4 6

RPM packaging issue
by Bryce Harrington 18 Jul '04

18 Jul '04

Btw, there was one issue I found in the inkscape.spec file that other RPM packagers will need to look to as well: * Remove the following line from the spec file: %{_libdir}/inkscape/extensions/* We have consolodated extensions into the /usr/share/inkscape directory with the other data files. Bryce

2 2

Crash on editing a circle
by Mike Hearn 17 Jul '04

17 Jul '04

Hi, I have a reproducable crash on CVS from a few days ago, when doing the following: * Start Inkscape * Zoom in a bit on the blank canvas * Add a new circle (made whole) * Press ctrl+shift+f (fill/stroke dialog). Here is the backtrace: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1087436352 (LWP 15995)] 0x080b1589 in SPObject::deleteObject(bool, bool) () at basic_ios.h:256 256 ~basic_ios() { } (gdb) bt #0 0x080b1589 in SPObject::deleteObject(bool, bool) () at basic_ios.h:256 #1 0x080b15c8 in SPObject::deleteObject(bool, bool) () at basic_ios.h:256 #2 0x0814be5a in sp_marker_prev_new(unsigned, char const*, SPDocument*, SPDocument*, char*, NRArena const*, unsigned, NRArenaItem*) (size=22, mname=0x87534a0 "Arrow1M", source=0x83134a8, sandbox=0x8313470, menu_id=0x822f56b "marker-start", arena=0x87db328, visionkey=7, root=0x875f600) at sp-object.h:173 #3 0x0814c51a in sp_marker_list_from_doc (m=0x8647700, current_doc=0x8313400, source=0x83134a8, markers_doc=0x0, sandbox=0x8313470, menu_id=0x822f56b "marker-start") at dialogs/stroke-style.cpp:1008 #4 0x0814c9b6 in ink_marker_menu (tbl=0x88c1e58, menu_id=0x822f56b "marker-start", sandbox=0x8313470) at dialogs/stroke-style.cpp:1126 #5 0x0814da4e in sp_stroke_style_line_widget_new() () at dialogs/stroke-style.cpp:1532 #6 0x081481cf in sp_object_properties_dialog() () at dialogs/object-properties.cpp:216 #7 0x081a00aa in sp_action_perform(SPAction*, void*) (action=0x879a3d0, data=0x0) at helper/action.cpp:132 #8 0x0809dcc6 in sp_shortcut_invoke(unsigned, SPView*) (shortcut=50331718, view=0x858b130) at shortcuts.cpp:33 #9 0x081a2816 in sp_window_key_press (widget=0x894c468, event=0x0) at helper/window.cpp:34 #10 0x405c427c in _gtk_marshal_BOOLEAN__BOXED (closure=0xbffff2d4, return_value=0xbffff190, n_param_values=2, param_values=0xbffff2c0, invocation_hint=0xbffff1b8, marshal_data=0x0) at gtkmarshalers.c:82 #11 0x40884dd6 in g_closure_invoke (closure=0x894c450, return_value=0xbffff190, n_param_values=2, param_values=0xbffff2c0, invocation_hint=0xbffff1b8) at gclosure.c:437 #12 0x4089698a in signal_emit_unlocked_R (node=0x831c268, detail=0, instance=0x894c468, emission_return=0xbffff260, instance_and_params=0xbffff2c0) at gsignal.c:2506 #13 0x40895a21 in g_signal_emit_valist (instance=0x894c468, signal_id=0, detail=0, var_args=0xbffff450 "h\2240\bx}\213j@...455...") at gsignal.c:2205 #14 0x40895eab in g_signal_emit (instance=0x894c468, signal_id=52, detail=0) at gsignal.c:2239 #15 0x406a8ebc in gtk_widget_event_internal (widget=0x894c468, event=0x8974620) at gtkwidget.c:3563 ---Type <return> to continue, or q <return> to quit--- #16 0x405c2a16 in gtk_propagate_event (widget=0x894c468, event=0x8974620) at gtkmain.c:2318 #17 0x405c1857 in gtk_main_do_event (event=0x8974620) at gtkmain.c:1582 #18 0x4079844a in gdk_event_dispatch (source=0x0, callback=0, user_data=0x0) at gdkevents-x11.c:2133 #19 0x408d1384 in g_main_dispatch (context=0x82c0000) at gmain.c:1895 #20 0x408d2349 in g_main_context_dispatch (context=0x82c0000) at gmain.c:2441 #21 0x408d266e in g_main_context_iterate (context=0x82c0000, block=1, dispatch=1, self=0x82c24c0) at gmain.c:2522 #22 0x408d2bd6 in g_main_loop_run (loop=0x8982d68) at gmain.c:2726 #23 0x405c11cb in gtk_main () at gtkmain.c:1172 #24 0x08089ead in sp_main_gui(int, char const**) (argc=1, argv=0xbffff6f4) at main.cpp:311 #25 0x08089d24 in main (argc=1, argv=0xbffff6f4) at main.cpp:233 thanks -mike

9 15

Test strategy
by Gazal, Geraud (MED) 17 Jul '04

17 Jul '04

Hi all, here is my workaround for the testing strategy of Inkscape. (sorry it's a copy paste of my doc in the mail, I can forward you the rtf document if you want)(easier to read) I'm currently listing the "specifications", in order to have a reference of features to be tested. The main things that should be defined if you agree with this : - establish a test process - establish communication/coordination tools (wiki / specific web page /mail list ?) - prepare/review specifications,test tools and test cases - begin tests Regards, Matiphas Preliminary note: This is a preliminary/draft document for defining a test strategy for Inkscape projet (http://www.inkscape.org) It is currently in Rich Text Format (rtf), for easy exchange purposes. -> Don't know yet how to manage this document (Dookbook ? Open Office)(specific web page ? wiki ? cvs ?) -> Any way this document will split for the following reasons : - separate specifications of software, test strategy, test traceability, test items, test results... - ease of maintenance - separation of features under test At the moment, it is mainly architectured according to the categories of bug tracking under sourceforge tool for Inkscape (see http://sourceforge.net/tracker/?group_id=93438) Reference: Inkscape testing framework: http://www.inkscape.org/cgi-bin/wiki.pl?TestingFramework (Missing) Inscape "specifications" (not really a pure specification of the software, this would be incompatible with the development process of Inscape, but somewhat a hierarchised and detailed list of features to be tested) Introduction: Why testing ? Just to ensure quality of the software (does it suits user needs ?) and even better the quality of the code/design What are the important concepts of testing : - measure: metrics (specifications and comparison to those specifications) are needed. This is important for the homogeneity of the tests and the correct interpretation of their results - coverage: what are the areas (design / code / features / architectures) covered by the tests. Stronly linked to the efficiency of the testing process - repeatability/reproducibility. The tests must provide coherent results, in order to to be correctly interpreted. Automatisation of the tests and well documented references (vocabulary, procedures...) help a lot. - periodicity: when shall the test be executed. This depends on the criticity, probability of bug and level of test. What is required for having efficient tests : - KISS : tests cases should be very simple in order to be easy to understand, easy to implement, and the results easy to interpret. - well maintained and documented Acronyms and abbreviations: (not used yet, but might become usefull) NA : Not Applicable TBD : To Be Done Levels of tests: Unit testing: at code level, providing tools/script in order to test classes/functions... Mainly depends on coding team Feature testing: the biggest part, and the largest amount of work. After definition of the features to be tested, establish precise test cases and execute them. Can be partially automated (see in this document) Non regression testing: the ability to check nothing has been broken in the code after important/critical development. Can be covered by feature and unit testing, but a non regression analysis after important/critical development is a great help. Plus after finding some new bugs covered by the test plan, prepare new test itemand ensure it covers properly the new bug. Reference tools: Purpose : define a list of reference tool against which the software should be compared. (especially for issues around import/export / rendering / printing / maybe UI) To be refined. At the moment : take a look at http://www.inkscape.org/cgi-bin/wiki.pl?OtherProjects SVG software Vector software Tests: Build Linux (Debian / Gentoo / Slackware / Mandrake / Fedora / Suse / Others) Windows (98 / 2000 / XP) MacOS (X) BSD (Free / Open) Other Unices (Solaris / Irix) Notice : should be automated (example see : http://public.kitware.com/Dart/HTML/Index.shtml) List of tasks : - establish a list of builders and link it with the architectures they can manage - establish a kind of "test contract" defining the tools to be used (compiler, dependancies, test report tool...) and the periodicity of the tests Import Bitmap Vector Export Bitmap Vector Printing Node editing Shape editing Transformations Color Management Internationalization Main tasks : - list the internationalization that are actively maintained - starting with http://www.inkscape.org/cgi-bin/wiki.pl?InkscapeTerminology, prepare a good dictionnary covering the maintained languages (can be very helpful for the reading of test procedures), plus the vocabulary of the application (messages, menus, etc etc) - establish a list of users with the languages they can check and define a kind of "test contract" UI SVG compliance See in 'specifications of software' plus SVG specifications The main idea is to provide a large repository of reference "SVG files" and "editing sequences". then two types of actions : - open reference files with inkscape, export it as bitmap and compare with a reference bitmap provided by a reference application (Batik ?) - open Inkscape, launch reference editing sequence, export result as bitmap and compare with a reference bitmap provided by a reference application on the same sequence (Inkscape itself for non regression, Batik ?) Previous sequences can be combined in one in order to save time, but then analysis of results can become more complex. Performance "Speed benchmarking" (can be automated) - provide a list of criterias to be tested (time to launch, time to open complex docs, time to save complex docs, speed of scrolling, speed of application of different types of transformations) - provide a benchmark tool - establish a list of users with the architecture on which they use the software, then define a kind of "test contract" defining the tools to be used and the periodicity of the tests Verification of robustness - testing memory leaks (not a specialist of this : I need help) - provide a shaker tool (this tool would launch Inkscape and then start a predefined number of pseudo-random commands -logging each action). The goal is to detect crashes and analyse their conditions with the logs - testing against severe conditions (corrupted files / out of memory / out of disk space ...)

2 1

Re: [Inkscape-devel] BUG and solution in align dialog
by aubi＠...373... 17 Jul '04

17 Jul '04

>> BTW, I finished refactoring the align dialog to use gtkmm and more >>OO code. >> Now I'll add the align nodes features. > >How is it going to look in terms of UI? I think the most intuitive >would be to make it work on selected nodes when the node edit tool >is >active on the active desktop, and on selected objects otherwise. >This >way you need no additional buttons or switches in the dialog. > >Also it would be nice to disable all or some of the buttons >depending >on what is selected. Thus, if no objects or only object is selected, >all align/distribute buttons are grayed out; if several nodes are >selected, "distribute top/bottom/right/left" are disabled because >they >make no sense for sizeless nodes (only distribute centers and >equi-spaced remain). That was what I was planning to do. But instead of grayed icons, I think I'll replace them by specific node align icons (node align vert, node align hor, node ditribute vert, node distribute hor). To do so, if it's not already here, I'll add a stdc::signal<void, ToolIdent> _tool_changed; for the desktop. >> I also would like to talk about the possibility to use the dialogs >>like in >> gimp2 (drag and dropable notebook tabs, multiple instances of the >>same >> dialog, etc) >> I started a very simple implementation, but I'm not sure you want >>to do that. >> Now I'm used to it, I find it easier to remember keyboard >shortcuts and have >> transient dialogs. No mess with tabs. PLease let me know your >>opinions. >Draggable notebook tabs may be a good idea - it will let one combine >all the tabs used frequently into one dialog and have only that >dialog >open, thus saving space. But it's likely to be rather difficult to >implement, it will very much disrupt our old dialogs code. > Yes. But as we will refactor all the dialogs, that should be the right time to do it. The only thing needed is to make each dialog inherit from a class. For me the main question is the impact on the GUI. Do we keep buttons for calling each dialog ? How much docker areas can you create? How do you create one ? What happens with keyboard shortcuts ? >Multiple instances of the same dialog does not sound like a good >idea >at all. I think it will be just confusing without any advantage. OK, so maybe a ctrl+shift+a shortcut could bring the align dialog in a new docker if it does not already exists. This way, you could still work as now, but w/ the ability to group several dialogs in one. I was also wondering if we could split the fill dialog in 3 different dialogs, strarting in the same docker, but you could rearrange that, eg if you want to see in the same time fills and strokes ... ************************ ADSL ILLIMITE TISCALI + TELEPHONE GRATUIT ************************ Surfez 40 fois plus vite pour 30EUR/mois seulement ! Et téléphonez partout en France gratuitement, vers les postes fixes (hors numéros spéciaux). Tarifs très avantageux vers les mobiles et l'international ! Pour profiter de cette offre exceptionnelle, cliquez ici : http://register.tiscali.fr/adsl (voir conditions sur le site)

2 1

Inkscape Status July 15, 2004
by Bryce Harrington 17 Jul '04

17 Jul '04

Inkscape 0.39 has been released! It has been amazing to watch everything coming together over the past few weeks. Users have been very attentive to locating, reporting, and following up on wide ranges of bugs across an impressive range of platforms. Meanwhile developers have been grinding away at the bug list; the rate of bug fixing is astounding - it is not unusual for bugs to be fixed the day they're reported. The number of translations that have come in has also been impressive. Statistics Nov 15 May 15 Jun 15 Jul 01 Jul 15 ========== ====== ====== ====== ====== ====== Lifetime Rank on SourceForge: 4391 1028 928 930 845 (68.5%) (92.7%) (93.4%) (93.4%) (94.0%) Max Week's Rank on SourceForge: 62 36 41 43 33 (99.6%) (99.8%) (99.8%) (99.8%) (99.8%) Total SF Page Views * 475,000 616,263 678,767 741,681 Total SF Downloads * 27,400 34,015 36,979 39,359 Total Freshmeat URL Hits 746 * 7,333 7,615 7,946 Total Freshmeat Subscriptions 16 74 87 91 93 Lines of Code in src/: 115,901 189,116 280,263 261,927 264,418 Code lines 147,471 210,119 190,519 192,240 Comment line 16,757 40,620 41,422 41,926 Blank 25,886 34,677 35,134 35,422 Lines of Docs in doc/: 1,135 4,544 15,170 15,201 15,217 Lines of content in website: 1,173 6,008 6,372 6,581 6,784 Size of the Inkscape wiki: 3,700 18,638 17,176 16,600 17,854 Minutes since last ChangeLog mod: 360 * * 28 54 Bugs open/total: 9/15 57/365 63/401 88/452 73/496 Features open/total: 18/18 183/238 210/285 222/307 242/331 Patches open/total: 1/ 6 4/ 83 5/ 88 6/ 91 8/110 CVS Commits (as per inkscape-cvs): 481 3391 5549 6033 6314 Inkscape-devel membership: 49 78 84 87 95 Inkscape-announce membership: 9 43 53 58 60 Inkscape-user membership: 71 76 84 90 Num Translations: Translated: 338 405 Fuzzy: 288 270 Untranslated: 349 325 Total number of PO files: 32 32 Ave Translation Ratio: 34.7% 40.5% * - Statistics unavailable

3 7

HELP WANTED: OSX packager for 0.39
by Bryce Harrington 17 Jul '04

17 Jul '04

Hi all, We have not had Mac OSX packages to provide in the past, but we'd certainly like to! OSX is an important platform for artists, and it would make sense for Inkscape to have a good presence there, as it does on Windows and Linux. Kees and others have verified that it builds and can be run on OSX, so the hardest part is done. The notes are available here: http://inkscape.org/cgi-bin/wiki.pl?CompilingInkscape What we need is someone who can create a package that other OSX users can easily download and install. This probably doesn't require any coding know-how, but does require someone knowledgeable of fink and in compiling under OSX. If you're interested, please go ahead, and when you've got a working package, announce it here, and we'll add it to the Download area. :-) Bryce

1 0

[Fwd: Autopackage: fantastic, thanks.] (fwd)
by Bryce Harrington 17 Jul '04

17 Jul '04

---------- Forwarded message ---------- Date: Sat, 17 Jul 2004 12:42:28 +0100 From: Mike Hearn <mike@...333...> Reply-To: autopackage-dev@...375... To: autopackage-dev@...375... Subject: [Fwd: Autopackage: fantastic, thanks.] -------- Forwarded Message -------- From: Leland McInnes <leland.mcinnes@...456...> To: mike@...333... Subject: Autopackage: fantatsic, thanks. Date: Sat, 17 Jul 2004 03:01:08 -0400 Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Hi, I've been keeping vague tabs on the autopackage project as it looked promising, but mostly it was still in the "unstable API" stage, so wasn't really much to use to me as an end user. I was looking at the latest inkscape however, and noticed an autopackage install. I figured this was a good chance to actually give it a try. It worked flawlessly and elegantly and did everything I would expect of it. I look forward with great anticipation to the 1.0 version and a wide variety of packages available. This is exactly the sort of things linux package management desperately needs. Thanks for all the great work. Leland McInnes. -- "The bitter apple and the bite in the apple. And the ragged and restless waters" -- The Dry Salvages (Four Quartets), T.S. Eliot --------------------------------------------------------------------- To unsubscribe, e-mail: autopackage-dev-unsubscribe@...375... For additional commands, e-mail: autopackage-dev-help@...375...

1 0

problems compiling in macosx
by Albert 17 Jul '04

17 Jul '04

Hi inkscapers Inkscape 0.38 compiled in MacOSX after djusting several details as I reported to the inkscape-users list some time ago. Now for 0.39: I have gone already over the gtkmm issue by doing what was suggested by Peter Moulder, that is change 'ink_gtkmm_pkg=gtkmm-2.0' to 'ink_gtkmm_pkg=' But just to find another issue: checking for png_read_info in -lpng... no configure: error: libpng >= 1.2 is needed to compile inkscape I know my system has libpng 1.2.5 installed. Note that 0.38 compiled without complaining about this. I've noted the failing test in configure.in has not changed since version 0.38, so I'm pretty lost here. Here the last terminal output lines from ./configure before failing: ... checking GNU compiler version... 3.1 checking locale.h usability... yes checking locale.h presence... yes checking for locale.h... yes checking for LC_MESSAGES... yes checking libintl.h usability... no checking libintl.h presence... no checking for libintl.h... no checking for pkg-config... /sw/bin/pkg-config checking for png_read_info in -lpng... no configure: error: libpng >= 1.2 is needed to compile inkscape Any help would be appreciated. Albert

3 7

One thing to do before a branch
by Bob Jamison 17 Jul '04

17 Jul '04

Whoever does the branch, I request you do one thing just before that. Please run: perl mkfiles.pl and perl mkdep.pl and commit make.* This will hopefully ensure that the tarball will compile under win32. Thanks. Bob

4 4

status?
by bulia byak 17 Jul '04

17 Jul '04

Looks like the freeze is going well, with nothing serious showing up. Is there anything preventing us from making a release, say, tomorrow? Actually, Ted, since you are our Release Technician (right? :) what is the best time for you to cut the release? Arpad, thanks for committing the translations. As for the assert, I think it's not very frequent, but its fix is likely to be too dangerous for so late in the freeze. I will fix it for the next version.

8 9

[Fwd: Re: siggraph?]
by Jon Phillips 17 Jul '04

17 Jul '04

Anyone in the LA area for SIGGRAPH. Here is a form for free exhibits + passes. I'm going to go on MONDAY AUG 9. If anyone is there, then we could do a BOFA on INKSCAPE, or just meetup for some rip-off expensive lunch or supper in rip-off-cost land. Jon > >https://reg.jspargo.com/siggraph04/invitations/general/default.asp > >Guest Password: 1208 > > -- Jon Phillips Graduate Researcher Visual Arts Department PO BOX 948667 LA JOLLA, CA 92037 USA cell.858.361.2811 jon@...235... http://www.rejon.org

4 4

First experiences with 0.39pre4
by Wolfram Quester 17 Jul '04

17 Jul '04

Hi alltogether! Yesterday I prepared an inkscape package for debian unstable from 0.39pre4. Now, always when I start inkscape I get the message "Couldn't find helper" in my terminal window. Using strace doesn't tell me anything: 3911 access("/usr/share/inkscape/extensions/roundhole", F_OK) = 0 3911 access("/usr/bin/perl", F_OK) = 0 3911 access("/usr/share/inkscape/extensions/ill2svg.pl", F_OK) = 0 3911 fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 1), ...}) = 0 3911 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x30274000 3911 write(1, "Couldn\'t find helper\n", 21) = 21 Is this message just supposed to appear after the last extension is initialized or did I something wrong? Additionally yesterday I had to play with bézier curves. It seems that I forgot to close one of these or inkscape could not properly determine which area is enclosed by the curve. The whole canvas turned black and inkscape became inresponsive. To me, it looked like it was filling infinity and it was to busy with that to react to any keystroke or whatever. I had to kill it at least. The output in the terminal was wolfi@...453...:~/simu $ inkscape Couldn't find helper failed to load unicode charmap ** (inkscape:2508): CRITICAL **: file display/curve.cpp: line 578 (void sp_curve_closepath_current(SPCurve*)): assertion `curve->end - curve->substart > 2' failed Private normalization of gradient linearGradient7951 requested Changing object g7308 fill to gradient linearGradient7952 requested ** (inkscape:2508): CRITICAL **: file color.cpp: line 95 (void sp_color_set_rgb_float(SPColor*, float, float, float)): assertion `b >= 0.0' failed ** (inkscape:2508): CRITICAL **: file color.cpp: line 95 (void sp_color_set_rgb_float(SPColor*, float, float, float)): assertion `b >= 0.0' failed ** (inkscape:2508): CRITICAL **: file color.cpp: line 95 (void sp_color_set_rgb_float(SPColor*, float, float, float)): assertion `b >= 0.0' failed I could not reproduce this with simple curves I drew today, so this is merely an information for you. Perhaps it helps. With best regards, Wolfi

9 23

Snapping
by Bryce Harrington 17 Jul '04

17 Jul '04

What is the difference between 'Snap to Grid' and 'Snap Points to Grid'? Bryce

2 5

Re: OSX packaging?
by Kees Cook 16 Jul '04

16 Jul '04

I asked a friend of mine about OSX packaging... I think we have a patch for a dmg, but I don't know what it means. :) ----- Forwarded message ----- Date: Thu, 15 Jul 2004 10:58:41 -0500 Subject: Re: OSX packaging? On Jul 15, 2004, at 08:10, Kees Cook wrote: >Hey, I want to try and get inkscape (inkscape.org) packaged for OSX. I >assume this is only possible via "fink", but I don't know where to >begin. How do I make an OSX package? :) There are two ways, really (maybe three): http://developer.apple.com/documentation/MacOSX/Conceptual/AppleSWDesign/Fi… 1) True Mac OS X way: drag and drop the .app from a .dmg file to your Application folder (or whereever else you want it) 2) More complicated OS X Way: Installer.app package. see Package Maker.app 3) UNIX way: fink. basically just a debian apt package. http://fink.sourceforge.net/doc/packaging/index.php If you want to target OS X users I would say 1 is the way to go. Otherwise 3. What are your dependencies? ----- End forwarded message ----- -- Kees Cook @outflux.net

5 6

Using imagemagick or graphicmagick as importer
by Tuukka Pasanen 16 Jul '04

16 Jul '04

Hi, I've been playing around about idea to provide support for Image/Graphicsmagick in inkscape. So we could import 88 Vector- and Imageformats used (http://www.graphicsmagick.org/www/formats.html or http://www.imagemagick.org/www/formats.html) but i been wondering should it been done like ill2svg or something deep cutting in inkscape code? Problem is that SVG output of programs isn't so good it should be. So what do you think? is this just a stupid idea? Tuukka ps. ImageMagick provides C++ bindings.. i think graphicmagick does also;)

2 1

Request for Adobe Illustrator files
by Tuukka Pasanen 16 Jul '04

16 Jul '04

Hi, Sorry about cross-posting.. but if anyone got AI files laying around (And have screenshot but it not must) that he/she could send me it/them to test ill2svg.pl. One could do it by Email (straight to me) or send URL to file (if file is bigger than 2M). I promise to use them only for testing ill2svg.pl script.. you can also create such documents if you have Corel Draw or Adobe Illustrator. Thanks, Tuukka

1 0

0.39 Release
by Bryce Harrington 16 Jul '04

16 Jul '04

Bulia has announced and finalized the 0.39 release, and Ted has established the release branch. What this means: * Packagers, please download the tarball and begin making packages * We will put out an announcement within a few days, once we've got some key packages up there. * We are in Release Phase. You can commit to CVS HEAD openly, but try to limit work to bug fixing for a couple days, just in case. * Users, please download and try out the packages as soon as they're ready. Let the packagers know of successful / unsuccessful installs. Congrats everyone! Bryce

1 0

no wimp please
by bulia byak 16 Jul '04

16 Jul '04

0.39 is up on SF. Whoever will be doing the windows package, please do not include gtk-wimp. The reason is that it gives me a lot of warnings about missing MS Sans Serif fonts. All these warnings flood the console window which therefore always jumps to the top and makes the program almost unusable. This is on windows 98. Normal builds without gtk-wimp work OK. I mentioned this on jabber but just want to reiterate. It's a nice thing but needs more testing before we can use it.

1 0

Linux Format Magazine has an article on Inkscape
by Alan Horkan 16 Jul '04

16 Jul '04

Linux Format Magazine has an article on Inkscape http://www.linuxformat.co.uk/ It has a strange lead in, I think they must have a regular section for the Gimp or something because of the way it is presented in relation to the Gimp. I only very quickly skim read the article (I'm not currently gainfully employed and have only pennies to my name) but it seemed favourable overall. I noted in particular that he found the user interface to be friendly. He mentions the Boolean operators and quotes one of the developers as having said that in the last while 'inkscape has improved 100%' (or suchlike). The article was written by Michael J. Hammel who appears to also be the author of "Essential Gimp for Web Professionals" and owner of the site http://graphics-muse.com/ and this page http://freshmeat.net/~mjhammel/ (his connections to the Gimp would explain the odd context of the Inkscape article). Perhaps someone might contact him and encourage him to write more about Inkscape. (Recommend some topics and I might try my hand at writing an article about Inkscape if I had a place to start). Sincerely Alan Horkan http://advogato.org/person/AlanHorkan/

3 4

OSX Compiling howto
by Kees Cook 16 Jul '04

16 Jul '04

If you need to run "./autogen.sh": fink install automake1.8 autoconf2.5 Otherwise: fink install \ intltool \ glib2 glib2-dev glib2-shlibs \ gtk+2 gtk+2-shlibs gtk+2-dev \ libpng3 libpng3-shlibs \ libtool14 libtool14-shlibs \ libpng-shlibs \ libsigc++12 libsigc++12-shlibs \ popt popt-shlibs export CPPFLAGS=-I/sw/include export LDFLAGS=-L/sw/lib # Run ./autogen.sh here if things break below... ./configure --prefix=/sw echo "#define ENABLE_NLS" >> config.h make make install -- Kees Cook @outflux.net

2 2

Adobe SVG Viewer 1.0 problems
by Alan Horkan 15 Jul '04

15 Jul '04

I had a problem getting _any_ of the SVG files from OpenClipart.org to display and thought I had stumbled on to a huge problem. Much later I realised that problem only effects Adobe SVG Viewer version 1.0 and updating to Adobe SVG Viewer version 3 made the problem seem to go away. After a lot of trial and error I was able to get the documents to display by removing the non-essential parameters from the opening <svg> tag Sample from OpenClipart.org Balloon_01.svg: <svg id="svg548" sodipodi:version="0.32" width="400pt" height="400pt" sodipodi:docbase="/home/nicu/svg_gal/happy/" sodipodi:docname="/home/nicu/svg_gal/happy/baloon1_01.svg" xmlns="http://www.w3.org/2000/svg" xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd" xmlns:xlink="http://www.w3.org/1999/xlink"> After even more trial and error I was able to narrow it down to just this line, the removal of which allows the file to display correctly: xmlns="http://www.w3.org/2000/svg" it can also be fixed by changing it to xmlns:svg="http://www.w3.org/2000/svg" Which looks to me more likely to be strictly valid and correct and I hope is the actual fix. Could someone please tell me if it is correct so because having gone to all the trouble of figuring out exactly what the problem was I'd like to finally submit a patch of my own to Inkscape (and then get back to poking holes in the Standard SVG). Sincerely Alan Horkan http://advogato.org/person/AlanHorkan/

3 4

Italian translation
by unknown＠example.com 15 Jul '04

15 Jul '04

Hi! I'm a "new" user of inkscape and I saw that the italian translation is not complete, there many words/expressions that aren't translated. I would to translate... But, what have I to do?? Is the first time that I work on a project and I'm not a programmer :-)) Let me know, Sergej Ps: greetings from italy Pps: forgive my english! __________________________________________________________________ Tiscali ADSL Senza Canone, paga solo quello che consumi! Non perdere la promozione valida fino al 19 luglio. Per te gratis il modem in comodato e l'attivazione. In piu' navighi a soli 1,5 euro l'ora per i primi tre mesi. Cosa aspetti? Attivala subito! http://abbonati.tiscali.it/adsl/prodotti/640Kbps/

3 2

export issues on windows - Bug 990349
by John Cliff 15 Jul '04

15 Jul '04

Hi folks, Bulia got me looking into ai import yesterday, and led me to realise that the import/export stuff seems pretty broke here on win. the import/open dialogs dont show anything but svg and bitmap formats, and the save as lists 3 formats which dont seem to work (svgz, ai, and epsi) The real problem is the latter as they still appear in the file type selector, and give all the right indications of having worked, but dont actually create any files. So you can think you've saved something when you havent. Saving to one of them then closing the doc causes my inkscape to crash. If anyone out there can confirm this on a windows box, I'd appreciate it. If we can confirm this isn't my box then I think we need to do something about it before cutting 0.39. Easiest is to simply add some lines to makefile.mingw to delete the extensions which are broke on windows so they dont get installed when you do make dist. This would eliminate the appearing to work while not really, and the crash bug. Cheers John __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail

6 7

inset path destroys clones.
by Christophe Combelles 15 Jul '04

15 Jul '04

Hello, I don't know whether it is a bug : - create an object (say, a square) - clone it with Alt-D - move the clone to see both objects - select the first original object - apply an "inset" or "outset" on it --> the clone disappears. with 0.39 pre4 on debian sid regards Christophe Combelles PS : please note I'm not subscribed to the list.

4 4

critical assert
by Arpad Biro 15 Jul '04

15 Jul '04

Hi, This gives critical assert with current CVS (and earlier versions also): 1. draw 2 objects 2. drag one of them over the other, but do not release the mouse button 3. press Esc Arpad Biro __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

3 2

problems compiling in macosx
by Albert 14 Jul '04

14 Jul '04

Hi inkscapers Inkscape 0.38 compiled in MacOSX after djusting several details as I reported to the inkscape-users list some time ago. Now for 0.39: I have gone already over the gtkmm issue by doing what was suggested by Peter Moulder, that is change 'ink_gtkmm_pkg=gtkmm-2.0' to 'ink_gtkmm_pkg=' But just to find another issue: checking for png_read_info in -lpng... no configure: error: libpng >= 1.2 is needed to compile inkscape I know my system has libpng 1.2.5 installed. Note that 0.38 compiled without complaining about this. I've noted the failing test in configure.in has not changed since version 0.38, so I'm pretty lost here. Here the last terminal output lines from ./configure before failing: ... checking GNU compiler version... 3.1 checking locale.h usability... yes checking locale.h presence... yes checking for locale.h... yes checking for LC_MESSAGES... yes checking libintl.h usability... no checking libintl.h presence... no checking for libintl.h... no checking for pkg-config... /sw/bin/pkg-config checking for png_read_info in -lpng... no configure: error: libpng >= 1.2 is needed to compile inkscape Any help would be appreciated. Albert

1 0

Today's autobuild
by Bob Jamison 14 Jul '04

14 Jul '04

Good morning, all! Since we are frozen, it is impossible to sync the makedep files and adjust paths for compilation, so autobuild will likely not run until the cut. So I did created a manual autobuild (oxymoron intended) this morning. It is on the site. After talking yesterday about syncing with the Makefile.am files, and running a script to generate a .def for making a .dll, I am thinking about requiring Perl for Win32 builds, both on Linux cross-compiling, and on native Windows. Windows users can download ActivePerl. I use it; it is very nice. I hate to add a dependency, but I think it is necessary. What we will likely do is: 1) In src/Makefile.mingw, add a dependency to all of the Makefile.am's in the /src dir. If any of them are touched, implying that files might have been added or deleted, then run mkfiles.pl and mkdep.pl. 2) After libinkscape.a is created, run mkdef.pl, which generates inkscape.def. This .def allows exporting the global symbols in our code without adding those nasty __declspec(dllimport) tags all through the .cpp files. 3) Create inkscape.dll 4) Create inkscape.exe and inkview.exe, both of which will use the dll. This will allow these two and other client apps of the dll to be packaged in the .zip without noticeably increasing download size. This will also eventually aid in providing that "inkscape widget" that other projects seem to want. After the cut, I will update mkfiles.pl with a "new improved" version that allows excluding directories, in addition to files. Just some thoughts. Later! Bob (ishmal) Bob

2 1

Metadata tab localization
by Arpad Biro 14 Jul '04

14 Jul '04

Hi, The captions and tooltips on the Metadata tab (in document prefs) seem to still not be localizable (except for 2 of them: "License" and "Proprietary"). Gettext does extract all the strings, but the translations aren't used on the UI. Arpad Biro __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail

2 2

import pdf, ps, eps pstoedit scribus
by John Griessen 14 Jul '04

14 Jul '04

I've searched and found pstoedit makes a partial import of pdf to svg, and several other perl scripts and postscript programs that choke on some pdf content when converting to ai or ps even. What I was looking for was a method of rearranging print articles from current magazines for my own use with margins to make notes in, and with editing and condensing in mind. Is pstoedit, (the gpl part), the best there is now? Can ps2ai be made to not die so easily? Since pstoedit has the best error handling even though output is not just right, is anyone interested to take the source of it and add more? Many pdfs are intended never to be editable, but often legitimate work is going to start with pdfs since adobe made them so popular by effective promotion and "free as in beer" viewers that worked. A big area of legitimate work is in catalogs whose typesetters are nowhere to be found, or not offering their editable layouts, or the layouts are made with ancient Mac SW that no one has anymore, and yet the paper catalog data needs to be mined for starting an online store web catalog. See the inkscape wiki under tutorial ideas for a couple of new images related to pstoedit -f plot-svg John Griessen -- John Griessen Cibolo Design Austin Texas linux counter #249315

2 1

[Fwd: [Inkscape-user] need help to compile inkscape 0.39 in macosx]
by MenTaLguY 14 Jul '04

14 Jul '04

-----Forwarded Message----- From: Albert <albert@...452...> To: inkscape-user(a)lists.sourceforge.net Subject: [Inkscape-user] need help to compile inkscape 0.39 in macosx Date: Wed, 14 Jul 2004 00:04:30 +0200 Hi all I'm trying to compile inkscape-039pre4 in macosx and I'm running into this problem: No package 'gtkmm-2.0' found configure: error: Library requirements (gtk+-2.0 >= 2.0.0 libxml-2.0 >= 2-2.4.24 sigc++-1.2 gtkmm-2.0 ) not met; consider adjusting the PKG_CONFIG_PATH environment variable if your libraries are in a nonstandard prefix so pkg-config can find them. I know I have gtkmm1.2 installed and than I need then to install 2.0, but the question is: inkscape 0.38 did NOT require neither gtkmm1.2 nor 2.0. I thought this would be necessary from 0.40 and onward, not before. When was this changed, or what did I miss? Also, which gtkmm should I install: 2.0-2.2, or 2.4 ? Does anyone know if any of this 2 libs have any problems in macosx ? Thank you for any help. Albert ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ Inkscape-user mailing list Inkscape-user(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user

2 1

2 Compile Issues
by Bob Jamison 14 Jul '04

14 Jul '04

Bryce told me to direct this to Mental or Bulia: Since we are clearing source changes now, I'll mention these two things that need tweaking. Nothing major, but they can break builds: 1. In satisfied_guide_cns.cpp, the prototype for void satisfied_guide_cns(SPDesktop const &desktop, std::vector<NR::Point> &snappoints, std::vector<SPGuideConstraint> &cns) ...needs to match the .h file. This can cause a linking problem in some situations, such as dynamic instead of static, or link order. 2. This one is my fault. I recoded prefix.cpp to use gthreads; it works nicely, but this file is not our responsibility. The original binreloc version needs to be put back. (OOPS. sorry) I'll not touch any sources until after the release :) Bob

4 3

configure patch
by Mike Hearn 14 Jul '04

14 Jul '04

Hi, The binreloc code uses gthread to achieve thread safety in the Inkscape tree, but gthread isn't passed to pkg-config. This patch fixes this. thanks -mike Index: configure.in =================================================================== RCS file: /cvsroot/inkscape/inkscape/configure.in,v retrieving revision 1.70 diff -u -r1.70 configure.in --- configure.in 11 Jul 2004 22:30:53 -0000 1.70 +++ configure.in 13 Jul 2004 16:42:58 -0000 @@ -221,7 +221,7 @@ dnl Unconditional dependencies dnl ****************************** -PKG_CHECK_MODULES(INKSCAPE, gtk+-2.0 >= 2.0.0 libxml-2.0 >= 2-2.4.24 $ink_sigc_pkg $ink_gtkmm_pkg $ink_spell_pkg) +PKG_CHECK_MODULES(INKSCAPE, gtk+-2.0 >= 2.0.0 libxml-2.0 >= 2-2.4.24 gthread-2.0 >= 2.0.0 $ink_sigc_pkg $ink_gtkmm_pkg $ink_spell_pkg) dnl Shouldn't we test for libpng and libz? INKSCAPE_LIBS="$INKSCAPE_LIBS -lpng -lz"

2 1

submitting freeze items
by MenTaLguY 14 Jul '04

14 Jul '04

I'd like to leverage the patch tracker to provide a work queue for bulia and me. To this end, I created an "0.39 FREEZE" tracker group. The proposed procedure is as follows: 1. create an entry in the patch tracker; if your change is complicated enough to warrant a patch, attach it. otherwise, just describe what you need done (as Bob did) -- make sure to select the aforementioned "0.39 FREEZE" group when you submit the entry. 2. also send an email to the mailing list so we can discuss the patch/change here 3. any updates/fixes to your patch go in the tracker item so they don't get lost -- be sure to include a note indicating the fix/change also 4. bulia or I can claim items to work on by assigning them to ourselves, and will close the tracker entry when the task is done Sound reasonable? -mental

1 0

Extra main() symbol
by Bob Jamison 14 Jul '04

14 Jul '04

Another Mental/Bulia thing: I have been working on the new build stuff for 0.40, such as making an inkscape.dll. This exercise in exporting symbols reveals some minor problems in our code, like I reported earlier. I just found another one. In the Win32 build, there is an extra main() being added to libinkscape.a. This is much easier to do manually than a patch. 1. Could you add this line: extension/script/js/js.c to src/make.exclude, 2. and then run perl mkfiles.pl and perl mkdep.pl 3. ...and then commit make.* (will be 3 or 4 files) Bob

2 1

Complete spanish po for 0.39
by Lucas Vieites 13 Jul '04

13 Jul '04

Do translations get into a hard freeze? Just in case, I finished the four or five pending strings in this file. Attached it goes... -- Lucas 'Basurero' Vieites Dept. Desarrollo <lucas@...212...> Asix Informática <http://www.asixinformatica.com/> Tel/Fax: +34 986 54 26 98

4 6

Explicit destructor calls for libstdc++
by Aubanel MONNIER 13 Jul '04

13 Jul '04

Somebody knows why there are so many explicit destructor calls like : sp_desktop_dispose (GObject *object) { SPDesktop *dt = SP_DESKTOP (object); dt->sel_modified_connection.disconnect(); dt->sel_modified_connection.~connection(); dt->sel_changed_connection.disconnect(); dt->sel_changed_connection.~connection(); dt->_set_colorcomponent_signal.~signal(); Why not a simple delete (dt->sel_modified_connection); ?

2 4

Re: Bug Stats
by Bryce Harrington 13 Jul '04

13 Jul '04

Date Reqd Crit Open Total Ratio ----------------------------------------- 7/1 88 452 19.5% 7/4 8 89 464 19.2% 7/5 21 86 464 18.5% 7/6 19 85 464 18.3% 7/7 20 88 467 18.8% 7/8 13 81 471 17.2% 7/9 10 78 471 16.5% 7/10 3 9 78 478 16.3% 7/11 2 6 74 479 15.4% 7/12 1 6 70 483 14.5% ------------------------------------------ Goals 0 10 (71) (15.0%)

2 3

Text writing and font changing
by Tuukka Pasanen 12 Jul '04

12 Jul '04

hi, Inkscapes font editing capabilities are getting better but there is two major problems. At least for me. 1. One can't change font in middle of text (If inkscape is using pango this should be so hard) 2. One can't put text in textbox (so you can't say be this large and if your text is longer cut it to next row) Have someone thought about this. I could take and make part 1 but thing i don't know how to mark up things when font changes?? part 2 should also be doable? Tuukka

2 1

Required bugs to fix for 0.39
by Bryce Harrington 12 Jul '04

12 Jul '04

The following bugs have been identified as 'required fixes' for the Inkscape 0.39 release: 984902 (CLOSED) "paint-selector.cpp: patternmenu getting destroyed" 979858 (OPEN 9) "image xlink: pixmaps linked with relative path don't work" 978391 (OPEN 9) "Autopackage installation" 978250 (OPEN 9) "mkinstalldirs error." Bulia also mentioned some export dialog issues, but there isn't a ticket number associated with it yet, so it's unclear what the status is. I've reduced the other other critical bugs to level 8. Bryce

2 4

testing...
by Bryce Harrington 12 Jul '04

12 Jul '04

Is this thing on...?

1 0

Re: [Inkscape-devel] autopackage now requires explicit --enable-binreloc
by Kees Cook 11 Jul '04

11 Jul '04

On Sun, Jul 11, 2004 at 03:34:39PM -0700, Mike Hearn wrote: > On Sun, 2004-07-11 at 14:04 -0700, Kees Cook wrote: > > We've disabled binreloc by default so that some of the other developers > > aren't disturbed by it. In the meantime, if your nightly builds can be > > changed to add "--enable-binreloc" to the "configure" run, Inkscape will > > correctly compile binreloc. > > Yes, I modified the specfile to do that. I tracked it down to header > ordering - in some cases config.h was being included after prefix.h > which was redefining the relevant macros. I think it's fixed now - I > guess prefix.h including config.h would fix that too. > > As to -D flags vs config.h entries, well, I don't know enough about > autoheader/autoconf to comment I'm afraid so I'll let Hongli deal with > that. Whoops, I'm not on the list, can you CC me on replies? :) Bryce forwarded me your response. I have an updated patch that makes prefix.c C++ type-safe. As for the config.h entries, I'd love to see where autoheader is considered deprecated. At least according to the documentation from autoconf 2.59, I see no mention of autoheader going away. Using "make" to detect changes in your build system won't pay attention to -D flags, but it will see changes in the config.h. With large packages (like inkscape), I don't want to have to do a full recompile. Also, for the end user who is attempting to compile the program, they shouldn't have to know which files to delete or to do a "make clean" if they decide to change a "configure" option. I should be able to run "configure --disable-binreloc", "make", and then "configure --enable-binreloc", "make" and have things correctly rebuild. Without the config.h entries, this is not happening. If people aren't using config.h, then they won't have an "AM_CONFIG_HEADER"/"AC_CONFIG_HEADER" call in their configure.ac, so my patch stands: for those using CFLAGS, it will work. For those using config.h it will work. And neither will step on the others' toes. :) -- Kees Cook @outflux.net

1 0

Re: [Inkscape-devel] autopackage now requires explicit --enable-binreloc (fwd)
by Hongli Lai 11 Jul '04

11 Jul '04

Bryce Harrington wrote: > - The code for enable-binreloc=auto (which was previously the default) > checked the build environment rather than the execution environment. ??? What does this mean? > - autopackage code prevents running inkscape from the build directory. > (This problem is reduced if the source directory and the build > directory are the same.) > > It should fall back to using the configure-supplied PREFIX value. I don't think this is possible except if you explicitly code fallback functions in the application. > - br_locate uses sscanf("%x-%x") and unsigned ints whereas > linux/fs/proc/array.c uses printf("%08lx-%08lx") and unsigned > longs. This presumably leads to bugs on 64-bit platforms. That's because Mike's patch uses an old version of BinReloc. The CVS BinReloc uses unsigned longs and "%lx" (maybe I should change that to "%08lx" instead? not sure). > - br_prepend_prefix needlessly requires that its path argument be > writable. It doesn't. br_prepend_prefix doesn't modify the content of the path argument in any way. I just didn't use the 'const' keyword, that's all. ;) > - br_strcat uses calloc, only to write over the space. It in > effect calculates strlen(str1) 3 times and strlen(str2) twice. Should be fixed in the autopackage CVS now. > - br_strndup has buffer overflow if size excedes the length of str > by more than one. Thanks for the tip. Fixed in CVS now. > - br_extract_prefix doesn't behave as its documentation indicates. This is a typo in the documentation. Fixed. > Also it does an unnecessary strndup when it could use memrchr. I'm not sure which line exactly you're referring to.

4 4

Clarification of 0.40 tasks?
by Bryce Harrington 11 Jul '04

11 Jul '04

Could someone elaborate on what the following task items mean? In particular, I'm wondering if they still belong in the 0.40 release todo list. * Make clones respond sensibly to original duplication * Reenable fuzzy font matching * Make gradient management & chaining work similar to patterns ** Fix fill-opacity ignored with gradients * Implement "Select Under" * Complete the cursor icons set * Redraw old icons to look decent Thanks, Bryce

4 5

Bug Stats
by Bryce Harrington 11 Jul '04

11 Jul '04

Date Crit Open Total Ratio 7/1 88 452 19.5% 7/4 8 89 464 19.2%

1 9

SEGV & SIGABRT handlers
by Bryce Harrington 11 Jul '04

11 Jul '04

Kees, Do you feel that the handlers for SEGV and SIGABRT reliably auto-save and put up crash dialogs? This is an item on the roadmap for 0.40, but I think you probably already took care of it. If so, we can cross that item off the list. Bryce

2 2

svg align icons
by Aubanel MONNIER 11 Jul '04

11 Jul '04

just to let you know I attached new svg align icons to the patch tracker.

1 0

gtkmm and sigc++ version
by Aubanel MONNIER 11 Jul '04

11 Jul '04

Hi list, while trying to resolve some basinc problems I had with tentatives of gtkmmification, I jumped on the #c++ channel on irc.gnome.org, and founs very nice people explaining that we should not rely on a deprecated version of gtkmm and sigc++. So with their help I made the port to gtkmm2.4 (nothing to do, configure.in was ready) and libsigc++2.0, which took a bit more time. This does not fix my problem, but it works. So if anyone is interested, I can semd a patch. Let me know what the procedure is. Thx, obi.

4 7

Proposal for 0.39 freeze
by Bryce Harrington 11 Jul '04

11 Jul '04

It feels like things are getting close to being ready for a freeze, and to start preparing for the release. There's a lot of work still going on, and we don't want to interrupt things abruptly, so it may be worthwhile to settle on some loose target dates. How does the following plan sound? 1. 'Feature chill' - June 28. No new features should be started, work should be wrapping up on existing features and code cleanup. Unfinished features should be hidden. Focus should be on bug fixing. 2. 'Feature freeze' - Sometime in first week of July. Only bug fixing should occur after this point. Focus should be on closing critical bugs and bugs in new features. 3. 'Hard freeze' - When all major bugs have been closed that we intend to close, we go into a short hard freeze period for a few days where no changes are allowed except under strict change control. We do final QA, verify on as many platforms as possible, create the packages and verify they work well, and make sure no last minute bugs slipped in. 4. 'Release' Bryce

12 28

Update on release process
by Bryce Harrington 11 Jul '04

11 Jul '04

There are still a few remaining Must-Fix items prior to going into the Hard Freeze, so we'll be giving it a bit more time. Hopefully by the end of the weekend we'll be ready. Tomorrow morning, I will send out a proposal for how to conduct the Hard Freeze segment of the release process. Bryce

1 0

Check ReleaseNotes
by Bryce Harrington 11 Jul '04

11 Jul '04

Just as a reminder, everyone who has done work on the codebase between 0.38.1 and now, please go review the ReleaseNotes and doublecheck that those changes are accounted for. Minor bug fixes, optimizations, etc. can be omitted, but it's worthwhile to include anything major, both for educating users about the new stuff, and for testing/troubleshooting purposes. http://inkscape.org/cgi-bin/wiki.pl?ReleaseNotes Thanks, Bryce

4 4

libccc: criawips' cairo-based canvas (using gtkcairo)
by Sven Herzberg 10 Jul '04

10 Jul '04

Hi all, I just started to play around with gtkcairo because I got stuck with some limitations of the gnome-canvas that I hope to be able to solve when developing a cairo based canvas. My current aims are: * get a high level canvas using cairo * get rid of issues like we have in gnome-canvas (e.g. text cannot zoom) * have a gnome-canvas-like api * use gobject interfaces for some things and lots of signals to make extending more easy (e.g. 'zoom canged' signal would have helped to fix the GnomeCanvasText things) I'm playing around within the criawips CVS repository on cvs.gnome.org. There's neither something that works yet nor much stuff, I just want to tell you about my plan to be able to get feedback before I introduce some issues that you had with something similar. The code is located in the criawips/src directory and consists of the cc-* files. Regards, Sven PS: I hate cross-postings, please continue this thread within criawips-devel@...448... and DO NOT reply to other lists. Thank you -- Sven Herzberg <herzi@...449...> · GNOME Deutschland <www.gnome-de.org> Jabber <herzi@...450...> · ICQ <177176642> GnuPG Fingerprint: <F020 B158 2696 6D6A 2870 F53C 0565 FD6B B1C3 0AFE>

1 0

export to bitmap: very bad behaviour
by Artemio 10 Jul '04

10 Jul '04

Hello all! I noticed several changes in the recent snapshot (20040706) that make my work much slower. 1. The exported image name defaults to drawing.svg.png instead of drawing.png. What is this for? Generally, you'll want shorted and simpler names, just drawing.png. Currently I have to delete the .svg portion each time. 2. The behaviour of the export dialogue is inconvenient. One thing it should be able to do IMHO is to detect whether a selection is active and automatically set the export mode to selection. 3. Also, compared to a snapshot of 20040628, Inkscape forgot how to update the export x/y/size on the fly. For example, I have three drawings on a single canvas and I want them exported to drawing[123].png. Previously, I could fire up the export dialogue, and hit export three times while selecting different drawings and changing 1 to 2 and then 2 to 3 in the target file name. In the current snapshot, if I change a selection while the export dialogue is up, the selection range is not updated. So if I want to do what I explained, I have to select a drawing, then hit "selection", then adjust the file name and hit export. This adds one exrta action which makes you work longer. I think the export x/y range should update on the fly. Just my 2 cents ;-) Artemio.

4 3

Working locally
by Gazal, Geraud (MED) 09 Jul '04

09 Jul '04

As my home internet connection is not up at the moment, I was wondering if there was a way for easily downloading the complete list of RFEs and Bugs in order to be able to read/sort it locally... Anyone having already done this ?

4 4

Updated spanish po
by Lucas Vieites 09 Jul '04

09 Jul '04

Hi, attaching updated spanish po. Will there be a 'translation freeze' before the 0.39 release so we can have translation at 100%? And now for something completely different: I found at least two strings containing "sodipodi" in the po file. Is this correct? msgid "Could not create sodipodi-svg-doc factory" msgid "Export document to plain SVG file (no sodipodi or inkscape namespaces)" -- Lucas 'Basurero' Vieites Dept. Desarrollo <lucas@...212...> Asix Informática <http://www.asixinformatica.com/> Tel/Fax: +34 986 54 26 98

4 3

AW: [Inkscape-devel] isnan
by Taraben, Adib 09 Jul '04

09 Jul '04

>> isnan without the std:: qualifier doesn't compile for me on mingw gcc >> 3.2.3. Are we going to need a platform-specific hack here? > Same for me (cross-compiling). Is there a way to change is so that > everyone is happy? using namespace std ??? Adib.

5 5

autopackage now requires explicit --enable-binreloc
by Peter Moulder 09 Jul '04

09 Jul '04

The autopackage code has the following problems: - The code for enable-binreloc=auto (which was previously the default) checked the build environment rather than the execution environment. - autopackage code prevents running inkscape from the build directory. (This problem is reduced if the source directory and the build directory are the same.) It should fall back to using the configure-supplied PREFIX value. - Also, there are a few problems with prefix.cpp code that make me wonder what other problems the autopackage code has: - br_locate uses sscanf("%x-%x") and unsigned ints whereas linux/fs/proc/array.c uses printf("%08lx-%08lx") and unsigned longs. This presumably leads to bugs on 64-bit platforms. - br_prepend_prefix needlessly requires that its path argument be writable. - br_strcat uses calloc, only to write over the space. It in effect calculates strlen(str1) 3 times and strlen(str2) twice. - br_strndup has buffer overflow if size excedes the length of str by more than one. - br_extract_prefix doesn't behave as its documentation indicates. Also it does an unnecessary strndup when it could use memrchr. Therefore I've changed configure.in to default to enable-binreloc=no. Autopackage binary builders, you may wish to add --enable-binreloc to your configure options. pjrm.

2 1

"layers"
by MenTaLguY 09 Jul '04

09 Jul '04

I think I've fixed most of the layer-related bugs I could find now. If you guys could give the "Edit group" feature a workout and see if there's anything I missed... (I think I still need to add transformation compenstation to Paste, at least) -mental

3 2

Re: [Inkscape-devel] Joining and help on gtkmm
by aubi＠...373... 09 Jul '04

09 Jul '04

On Wed, 2004-07-07 at 13:33, bulia byak wrote: > > this code works > > Gtk::Image *pImg= new Image ("/x/y/z/toto.png"); > > > > while this one don't > > Gtk::Image *pImg= new Image > > (Gdk::Pixbuf::create_from_file("/x/y/z/toto.png")); > > Judging by http://www.gtkmm.org/gtkmm2/docs/reference/html/classGtk_1_1Image.html, > both uses are valid. But we haven't yet used Gtkmm in this project so > I can't tell. Mental, can you comment? As far as I know both examples are valid (and should be essentially interchangable), but I've not tried either. There are occasionally some gotchas which the documentation does not make clear. Aubi, does "doesn't work" mean that it doesn't compile, or that it misbehaves when run? What are the error messages or deviations from expected behavior you encounter? -mental The failure is at run time. As far as I remember (I doesn't have my machine right now), there is an assertion on the Pixbuf, something like could not bind pixbuf. And of course, nothing is displayed. Talking about GTKmm doc, I was wondering if we could put it in a wiki, this way we could add comments as we gain experience. I also have more general questions about gtkmm ification and widgettery. Do we try to redo custom widgets (ie inheriting from drawables) for the SPIcon and SPButton thingies, or do we provide static Images widgets with the according content (ie pixbuf) already loaded ? I would vote for the second solution as I remarked an important performance hit since we display SVG icons in eg the Fill dialog. The result would be something like class SVGIcons { public : const Gtk::Image & get (std::string name); private : static const Gtk::Image &icon1; static const Gtk::Image &icon2; static const Gtk::Image &icon3; etc ... } ************************ ADSL ILLIMITE TISCALI + TELEPHONE GRATUIT ************************ Surfez 40 fois plus vite pour 30EUR/mois seulement ! Et téléphonez partout en France gratuitement, vers les postes fixes (hors numéros spéciaux). Tarifs très avantageux vers les mobiles et l'international ! Pour profiter de cette offre exceptionnelle, cliquez ici : http://register.tiscali.fr/adsl (voir conditions sur le site)

2 1

Re: inkscape - tspan - baseline-shift
by bulia byak 09 Jul '04

09 Jul '04

> Dear Mr. Buliabyak, thank you for the explanation of the complexity of > implementation of the "baseline-shift" tag and tspan sections into > inkscape. I'm ready for helping with the development of the application, > but there is one big obstacle: I can't do C language. There are many ways to help other than coding: testing, documentation, discussions... > I understand, that you - and the development team as well - are not > interested in the text part of SVG. This is wrong. We are doing a lot for text. Since we forked from Sodipodi, we added letterspacing and kerning, and recently switched to Pango for much better Unicode text support (not counting hundreds of bugfixes). All this is necessary for any further improvements of text support. > As the SVG is only suitable vector graphics format, many chemical > structure drawing programs have export to the SVG. And as we need some > other graphic elements (frames, boxes, splines) when we prepare chemical > structures for the presentations or publications, the only way is usage > of some vector graphic editor. Chemical structures are made of thin > lines, the chemical bonds, and the export to the raster image degrade > such lines completely. But alas, almost every such chemical structure > include the subscripted text. There is no way through. Right now you can approximate sub/superscripts by vertical kerning. For example type "H2O", position text cursor before 2 and press Alt+down a few times, then move after 2 and press Alt+up a few times. The only problem with this method is that you can't make "2" smaller than "H". See http://inkscape.org/screenshots/gallery/inkscape-0.38-linux-kerning.png for an example of what is possible using kerning. > I do not understand the reason for existence of two similar projects on > the sourceforge, inkscape and sodipodi. See the FAQ on our site. In short, Sodipodi was too closed and inflexible so we had to start a new project from Sodipodi codebase so we could all work freely on what we wanted to see in a vector editor. > I look into the sodipodi source code and in my opinion to extend the > tspan routines is not such a big problem (if you don't need GUI for > editing of tspans, but only the interpretation of it when drawing on the > canvas). Yes, the rendering part is easier to do, but what is the use if you cannot create a subscript except by manual XML editing?

2 1

isnan
by Carl Hetherington 09 Jul '04

09 Jul '04

Hi, isnan without the std:: qualifier doesn't compile for me on mingw gcc 3.2.3. Are we going to need a platform-specific hack here? Carl -- http://carlh.net/pony

2 1

Joining and help on gtkmm
by aubi＠...373... 08 Jul '04

08 Jul '04

Hi list, as a convinced Inkscape user and former C++ developper, I decided to at least try to join the developpment team. I don't want to promise anything, as real life work keeps me quite busy, but sure I could spend a few hours a week on it. So I pulled the code from cvs and started to look at something intersting me : aligning nodes. Well, this is C code. I'm not a great fan of C, so I wanted to start the C++ ification of the align dialog. And still pulling away, fall in front of SPButton and SPIcon. I first tried to wrap (GtkButton::wrap for example) them, but could not get it working. So I went deeper and figured that it could be a good idea to take it at the pixbuf level. But I can't understand how this works, even with a simple png image : this code works Gtk::Image *pImg= new Image ("/x/y/z/toto.png"); while this one don't Gtk::Image *pImg= new Image (Gdk::Pixbuf::create_from_file("/x/y/z/toto.png")); Looks like I missed something ... If you have some answers, or even pointers (google is not very talkative about this), please post them in my blog here : http://un.regne.net/dotclear/index.php/2004/07/01/20-firsts-tries-on-inksca… sorry for the inconvenience, I'm in trouble with my email setup. Thanks in advance for any answer, aubanel. ************************ ADSL ILLIMITE TISCALI + TELEPHONE GRATUIT ************************ Surfez 40 fois plus vite pour 30EUR/mois seulement ! Et téléphonez partout en France gratuitement, vers les postes fixes (hors numéros spéciaux). Tarifs très avantageux vers les mobiles et l'international ! Pour profiter de cette offre exceptionnelle, cliquez ici : http://register.tiscali.fr/adsl (voir conditions sur le site)

3 2

RE: [Inkscape-devel] General and Specific Meta-Data
by unknown＠example.com 07 Jul '04

07 Jul '04

> On Wed, 7 Jul 2004, Jon A. Cruz wrote: >> >> >> XMP >> >> >> XMP > > We left implementation of that for you... ;-) Why, how kind and thoughtful of you. Thanks. :-D (look for things after the thaw)

1 0

RE: [Inkscape-devel] General and Specific Meta-Data
by Jon A. Cruz 07 Jul '04

07 Jul '04

> -------- Original Message -------- > Subject: Re: [Inkscape-devel] General and Specific Meta-Data > From: "Bryce Harrington" <bryce@...260...> > Date: Sat, July 03, 2004 11:27 pm > To: "Kees Cook" <inkscape@...62...> > Cc: "inkscape" <inkscape-devel(a)lists.sourceforge.net>, "clipart-list" > <clipart@...330...> > > On Sat, 3 Jul 2004, Kees Cook wrote: > > On Sat, Jul 03, 2004 at 08:40:07PM -0700, Jon Phillips wrote: > > For now, I just want to get the "General" RDF editor working. :) > > *Nod* Agreed - this will take care of 99% of the cases; the last 1% > will be more challenging. XMP XMP

2 1

RE: [Inkscape-devel] Polyline and polygon point specification patch submitted
by Jon A. Cruz 07 Jul '04

07 Jul '04

> -------- Original Message -------- > Subject: [Inkscape-devel] Polyline and polygon point specification > patch submitted > From: "Mark Nyrup Mortensen" <nightcap@...58...> > Date: Fri, July 02, 2004 10:44 pm > To: inkscape-devel(a)lists.sourceforge.net > And then another question somewhat related to the patch (and probably > other places in Inkscape?): > Does anyone know whether the "g_ascii_strtod" function actually is > capable of reading and returning numbers sufficiently large to allow for > the numbers available in SVG? From what I have seen so far i would say > no, but again my knowledge of C/C++ and GTK+ is fairly limited. Ahhh..... This is where I'd suggest getting it in the unit tests. Just find out the range that could be needed, and then set up tests for those on either side of any boundary. Of course, we'd probably have to have some unit test framework first to make it easy. :-) But, seriously, it is good to at least make a note of the range that it would need to support, allong with samples to exercise it.

2 1

RE: [Inkscape-devel] General and Specific Meta-Data
by Jon A. Cruz 07 Jul '04

07 Jul '04

> -------- Original Message -------- > Subject: Re: [Inkscape-devel] General and Specific Meta-Data > From: "Kees Cook" <inkscape@...62...> > Date: Sat, July 03, 2004 10:09 pm > To: "inkscape" <inkscape-devel(a)lists.sourceforge.net>, "clipart-list" > <clipart@...330...> > > > > I wonder how we can have it so that when an object or collection of > > objects is copied and pasted, imported and transformed, that its > > specific meta-data (beyond specified graphics attributes) can be copied > > along with itself (making a media object). In the future this will be > > vital for algorithmic composition of graphics. > > You could test for clashing licenses! Hah. > > > Thoughts? > > I'd need to read a lot more about RDF itself. For example, how do we > reference a specific SVG group or shape within the doc? > XMP?

1 0

RE: [Inkscape-devel] joining development
by Bryce Harrington 07 Jul '04

07 Jul '04

On Tue, 6 Jul 2004, Gazal, Geraud (MED) wrote: > > > As I really appreciate the tool you're developping, I'd really like to > > > contribute, as soon as my home internet connection is up again. > > > Ah, cool, welcome aboard. :-) > > Yeah, will subscribe to inkscape devel/user as soon as possible (damned > internet provider) Note that there's also a news feed available via gmane.org, if mail is an issue. > OK, there we are. I really want to help this project as it really helps me. > Here are the tasks on which I can help : > > - writing test plan (it used to be my job a few years ago) I've been (slowly) working on exploring some different aspects for testing Inkscape, and would love to work with you on this. So far our testing has been organic as opposed to systematic; planned testing likely could help identify issues more intently. > - translation : my English is not perfect (and my accent is terrible/fic), > but I'got some good dictionaries. I'm native French speaker (this can > explain the accent), correct in Spanish and German, poor in Slovak and Czech > (but my girlfriend is native :) ). Translators are always welcome. :-) I think we've got people involved in all those languages, but the translations may benefit from additional sets of eyes. > - doing some tests This is definitely needed; I can give lots of tips and ideas on testing. We don't have much in the way of unit tests, but I've been finding a number of other effective approaches to doing it. > - working on specifications (my current job : project coordination) An immediate area we need help here is with the extensions system. It's been on our roadmap to write a spec for this, and some work has been done and many of the ideas are out there, but it needs to be written up and pushed to completion. The reason why extensions would benefit from a spec whereas most other features haven't needed one, is because by definition the system needs to be used by a lot of different developers coming at it from a lot of different ways (different programming languages, operating systems, etc.) So specifically detailing the API, capabilities and limitations, etc. etc. will be vital for making it successful. > - providing some example svg (mostly technical/mapmaking oriented, not > artiscal value) / screenshots Also definitely check out www.openclipart.org, one of Inkscape's sister projects; technical symbols and examples are quite welcome there. > - work on some small tutorials > - test test test > > I fact, here is my proposal : > > - begin working on a list of specifications in order to get a traceability > matrix for test/user manual/tutorial/screenshots. (see example below > attached as rtf doc). Maybe to be posted on your wiki someday > - will try to do the same for RFEs in order to sort/orgize them (sounds > huge) By the way, note that I did this too, back when we were all part of Sodipodi. What I came up with is here: http://www.sodipodi.com/index.php3?section=development/tasks I believe rejon ported these writeups into the RFE tracker, so you hopefully should find some good order in the older RFE's. For what it's worth, I think for the RFE what we need is not so much organizing them, but more about identifying ones that are completed or duplicates, or that need further elaboration. Also, to date we've focused more intently on the bug list than the rfe list, although hopefully this will shift towards rfes a little more in the future. Note that one area of testing that can be directly beneficial is to try to replicate some of the reported bugs (esp. the ones with comments "I can't recreate it"), and provide additional info like back traces, error messages, etc. > - begin working on some test documents > - start a 'Need for contribution' wiki page listing points where > coders/artists/dummies_like_me can help Looking forward to seeing this. :-) > Wainting for your feedback and if this souds good to you, please forward to > the devel-mail-list Definitely sounds good, and am forwarding. Thanks, Bryce

5 4

RE: [Inkscape-devel] joining development
by Gazal, Geraud (MED) 07 Jul '04

07 Jul '04

OK, then. Here are my priorities then : 1 provide a test framework, based on the following notions : feature testing non regression testing unit testing -> thus providing - a kind of test matrix - some test cases/documents - a test report template (maybe script/interface) in order to automatically generate test reports I insist on the fact that having Inkscape being scriptable would be a huge plus for automated tests, especially for : - SVG compliance, rendering, printing (automaticaly loads svg files, compare to 'reference', and provide a status). - editing features (automatically generates svg files according to scenario and compare to reference. 2 Test (of course). 3 Work on a 'help/work needed' page. And a the same time get a look on extensions specifications. 4 work on French translation. Regards, Matiphas

3 2

EPS import
by Ted Gould 07 Jul '04

07 Jul '04

Using an idea from Artis Rozentals in this enhancement request: https://sourceforge.net/tracker/?func=detail&atid=604309&aid=957916&group_i… I've implemented all the of the .inkmod files to do this. Basically it goes like this: EPS -> PS -> Sketch -> SVG Kind of convoluted, but most users won't have to see that. To see this work you'll need to have pstoedit, ghostscript, and Sketch installed. If other people could look at this and comment that would be great. If you have those installed, all you need to do is open a bunch of EPS files. --Ted

3 3

Inkscape 0.39pre3
by Ted Gould 07 Jul '04

07 Jul '04

Has been put on to Sourceforge (actually it happened last night, but I forgot to write the e-mail :) This signals the feature freeze for 0.39, and the start of bug fixing. Hopefully they'll all be easy and we should have a pre4 here shortly ;) http://prdownloads.sourceforge.net/inkscape/inkscape-0.39pre3.tar.gz?downlo… Testing of this release is strongly encouraged (along with bug reporting) so that we can find all the bugs and release a very stable 0.39. http://sourceforge.net/tracker/?group_id=93438&atid=604306 --Ted

1 0

export problems
by bulia byak 06 Jul '04

06 Jul '04

Ted, Thanks for implementing the export hints. There are a number of problems that I found in testing them today: 1 Why "Custom" is the default? As before, when I open Export, it must switch to Selection if there's selection, otherwise to Drawing if there's a drawing, otherwise to page. Switching to Custom must be possible either manually, or automatically when you change any of the x, y, w, h parameters (i.e. when they no longer correspond to selection, drawing, or page). 2 The dialog does not track selection change. It did before. Now it must not only change x/y/w/h when selection is changed or modified (as before) but also reread the filename and resolution hints when the selection is changed. 3 When I do export and the hints are remembered, the document is not considered changed. So I cannot save it (unless I change something else) and the hints are lost on close. 4. When there's no filename hint and the export filename is constructed from the document filename, it does not remove .svg which results e.g. in "wa.svg.png". This did not happen before. Please fix these problems and we'll have another killer feature for this release! I'm very excited about it.

1 0

export problems
by bulia byak 06 Jul '04

06 Jul '04

Ted, Thanks for implementing the export hints. There are a number of problems that I found in testing them today: 1 Why "Custom" is the default? As before, when I open Export, it must switch to Selection if there's selection, otherwise to Drawing if there's a drawing, otherwise to page. Switching to Custom must be possible either manually, or automatically when you change any of the x, y, w, h parameters (i.e. when they no longer correspond to selection, drawing, or page). 2 The dialog does not track selection change. It did before. Now it must not only change x/y/w/h when selection is changed or modified (as before) but also reread the filename and resolution hints when the selection is changed. 3 When I do export and the hints are remembered, the document is not considered changed. So I cannot save it (unless I change something else) and the hints are lost on close. 4. When there's no filename hint and the export filename is constructed from the document filename, it does not remove .svg which results e.g. in "wa.svg.png". This did not happen before. Please fix these problems and we'll have another killer feature for this release! I'm very excited about it.

1 0

Updated 0.39 spanish translation
by Lucas Vieites 06 Jul '04

06 Jul '04

Attached it goes -- Lucas 'Basurero' Vieites Dept. Desarrollo <lucas@...212...> Asix Informática <http://www.asixinformatica.com/> Tel/Fax: +34 986 54 26 98

2 1

inkscape-0.39pre3 delayed
by Ted Gould 06 Jul '04

06 Jul '04

Because it isn't passing distcheck. Here is the error that I'm getting. It's correct that there is no libtool in that directory... I've compared pre2 and pre3 pretty extensively and can't find any differences related to libtool. Hmmm... I'll keep looking, but anyone has ideas I'd love to hear them. /bin/sh ../libtool --mode=link ccache g++ -Wall -W -Wpointer-arith -Wcast-align -Wsign-compare -Woverloaded-virtual -Wswitch -Wno-unused-parameter -g -O2 -o inkscape --export-dynamic main.o libinkpre.a dialogs/libspdialogs.a xml/libspxml.a svg/libspsvg.a widgets/libspwidgets.a display/libspdisplay.a helper/libspchelp.a libnrtype/libnrtype.a libnr/libnr.a livarot/libvarot.a extension/libextension.a extension/implementation/libimplementation.a extension/internal/libinternal.a inkjar/libinkjar.a libinkpost.a -Wl,--export-dynamic -lxml2 -lpthread -lz -lgtkmm-2.0 -lgdkmm-2.0 -latkmm-1.0 -lgtk-x11-2.0 -lpangomm-1.0 -lglibmm-2.0 -lsigc-1.2 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangoxft-1.0 -lpangox-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -lpng -lz -lpopt -L/usr/X11R6/lib -lXft -lfreetype -lz -lXrender -lX11 -lfontconfig -Wl,--export-dynamic -lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -lfreetype -lz ../libtool: ../libtool: No such file or directory make[3]: *** [inkscape] Error 127 make[3]: Leaving directory `/home/ted/Development/inkscape.release/inkscape-0.39pre3/_build/src' --Ted

1 0

crazy idea: map ourselves
by Kees Cook 06 Jul '04

06 Jul '04

After working on this locale stuff, I got curious about where everyone else lived who working on inkscape. I found a nice (but large) SVG of the world (http://www.wherearewe.co.nz/svg/world.svgz), and I wanted to map everyone's names onto it. Can everyone who's interested in appearing on such a thing send me their long/lat (or an address I can go convert). I think it would be cool to see an "about" screen (or even a "users of inkscape" map) that shows what a diverse set of places we come from. -- Kees Cook @outflux.net

11 18

ill2svg.pl image support. Anyone?
by Tuukka Pasanen 05 Jul '04

05 Jul '04

hi, Have anyone tested ill2svg.pl image export support? Is it just me who needs it?? I like to get feed back so I could improve it.. Tuukka

2 1

Header Include Report
by Bryce Harrington 05 Jul '04

05 Jul '04

Header Include Report for Inkscape-0.35 to Inkscape-CVS (2004-07-05) -------------------------------------------------------------------- The following report measures Inkscape's current include file hierarchy, using inkscape-0.35 as a baseline. IDC (Include Dependency Count) - the number of source files that need to be recompiled if this file changes. IC (Include Count) - the number of files that could trigger a rebuild of any files that include this file. IDP (Include Dependency Product) = IDC x IC - an indicator of how much impact the file has on the include hierarchy of the project. Inkscape-0.35 Inkscape-CVS Filename IDC IC IDP IDC IC IDP ------------------------------------------------------------------------- sp-item.h 72 16 576 111 22 2442 sp-marker.h 3 12 36 86 28 2408 style.h 25 12 150 79 30 2370 sp-item-group.h 24 18 216 97 23 2231 desktop.h 44 22 484 53 38 2014 libnr/nr-rect.h 76 10 380 150 11 1650 libnr/nr-matrix.h 83 10 415 152 10 1520 libnr/nr-rect-l.h 97 13 1261 selection.h 33 10 165 46 24 1104 libnr/nr-rotate.h 153 7 1071 sp-shape.h 25 20 250 34 31 1054 libnr/nr-point-fns.h 162 6 972 libnr/nr-matrix-fns.h 88 11 968 display/sp-canvas.h 45 20 900 libnr/nr-pixblock.h 55 8 220 61 14 854 sp-root.h 17 30 255 30 26 780 libnr/nr-scale.h 153 5 765 display/nr-arena-item.h 20 14 140 32 22 704 libnr/nr-point-ops.h 172 4 688 view.h 51 4 102 73 9 657 libnr/nr-translate.h 152 4 608 libnr/nr-matrix-ops.h 46 12 552 libnr/nr-point.h 183 3 549 sp-object.h 94 6 282 123 4 492 libnr/nr-point-l.h 98 5 490 document-private.h 6 38 114 16 30 480 sp-path.h 10 22 110 15 32 480 sp-text.h 7 38 133 17 28 476 sp-chars.h 8 34 136 18 26 468 sp-paint-server.h 19 16 152 24 19 456 verbs.h 4 4 16 27 14 378 document.h 77 10 385 93 4 372 display/nr-arena-group.h 10 8 80 16 23 368 extension/extension.h 35 10 350 helper/action.h 9 6 27 29 12 348 interface.h 6 6 18 22 15 330 sp-gradient.h 10 22 110 13 24 312 desktop-events.h 7 12 84 8 39 312 libnr/nr-values.h 103 6 309 153 2 306 libnr/nr-path.h 40 6 120 101 3 303 libnr/nr-maybe.h 150 2 300 display/canvas-bpath.h 13 23 299 uri-references.h 4 2 8 96 3 288 sp-pattern.h 2 10 20 10 28 280 svg/svg.h 43 8 172 55 5 275 sp-use.h 2 10 20 11 24 264 sp-polygon.h 6 11 66 8 32 256 sp-rect.h 5 12 60 8 32 256 display/sp-canvas-util.h 12 21 252 sp-star.h 5 12 60 7 33 231 message-stack.h 76 3 228 sp-spiral.h 5 11 55 7 32 224 xml/repr.h 112 2 112 108 2 216 sp-namedview.h 14 12 84 18 12 216 nodepath.h 5 30 75 6 36 216 display/curve.h 52 4 208 libnr/nr-coord.h 194 1 194 config.h 71 2 71 192 1 192 sp-ellipse.h 4 12 48 6 32 192 color.h 36 8 144 95 2 190 display/sodipodi-ctrl.h 9 21 189 livarot/Shape.h 21 9 189 desktop-handles.h 48 6 144 62 3 186 inkscape.h 45 6 135 62 3 186 xml/repr-private.h 22 6 66 46 4 184 libnr/nr-dim2.h 183 1 183 helper/sp-intl.h 58 4 116 90 2 180 libnr/nr-forward.h 55 2 55 179 1 179 libnr/nr-macros.h 106 6 318 177 1 177 seltrans.h 6 7 42 8 22 176 libnrtype/font-instance.h 10 17 170 select-context.h 5 10 50 6 28 168 file.h 9 20 90 15 11 165 node-context.h 4 18 72 4 40 160 forward.h 114 2 114 150 1 150 message-context.h 75 2 150 libnr/nr-i-coord.h 150 1 150 livarot/ShapeUtils.h 21 7 147 xml/xml-forward.h 146 1 146 print.h 10 5 50 13 11 143 snap.h 27 5 135 libnr/nr-blit.h 7 5 35 9 15 135 extension/system.h 11 12 132 extension/db.h 12 11 132 libnrtype/font-style.h 10 13 130 sp-typeset-utils.h 3 43 129 sp-offset.h 4 32 128 display/sodipodi-ctrlrect.h 6 21 126 sp-typeset.h 5 25 125 display/nr-arena-forward.h 82 2 82 125 1 125 gradient-chemistry.h 5 24 60 5 25 125 display/canvas-arena.h 3 13 39 5 25 125 version.h 124 1 124 libnr/nr-object.h 49 4 98 60 2 120 sp-anchor.h 5 20 50 5 24 120 sp-defs.h 11 8 44 24 5 120 sp-image.h 4 10 40 5 24 120 shortcuts.h 7 2 7 8 15 120 knot.h 13 10 65 19 6 114 livarot/Path.h 19 6 114 sp-object-group.h 18 8 72 22 5 110 svg/svg-types.h 64 2 64 107 1 107 display/sp-ctrlline.h 5 21 105 toolbox.c[pp] 1 45 45 1 105 105 libnr/nr-gradient.h 4 12 24 5 21 105 xml/repr-action.h 25 2 25 52 2 104 uri.h 101 1 101 require-config.h 101 1 101 helper/helper-forward.h 70 2 70 100 1 100 sp-guide.h 7 5 35 11 9 99 verbs.c[pp] 1 65 65 1 98 98 enums.h 29 2 29 98 1 98 display/nr-arena-glyphs.h 2 18 36 3 32 96 sp-line.h 2 12 24 3 32 96 sp-polyline.h 2 11 22 3 32 96 desktop.c[pp] 1 56 56 1 95 95 libnr/nr-pixblock-pattern.h 5 10 25 6 15 90 display/nr-gradient-gpl.h 4 22 88 event-context.h 21 6 63 22 4 88 knotholder.h 6 6 36 11 8 88 dialogs/stroke-style.c[pp] 1 84 84 file.c[pp] 1 45 45 1 82 82 refcounted.h 81 1 81 seltrans-handles.h 3 13 39 3 27 81 tools-switch.c[pp] 1 80 80 display/nr-arena-shape.h 1 21 21 2 40 80 sp-shape.c[pp] 1 45 45 1 78 78 selection-chemistry.c[pp] 1 32 32 1 78 78 widgets/button.h 4 8 16 6 13 78 interface.c[pp] 1 50 50 1 77 77 select-toolbar.c[pp] 1 77 77 message.h 76 1 76 dialogs/find.c[pp] 1 76 76 sp-text.c[pp] 1 42 42 1 75 75 libnr/nr-render.h 4 10 20 5 15 75 widgets/paint-selector.h 2 2 4 3 25 75 toolbox.h 3 1 3 5 15 75 select-context.c[pp] 1 45 45 1 74 74 event-context.c[pp] 1 37 37 1 74 74 sp-typeset.c[pp] 1 74 74 seltrans.c[pp] 1 35 35 1 74 74 sp-object-repr.c[pp] 1 54 54 1 72 72 splivarot.c[pp] 1 72 72 inkscape-private.h 13 8 52 18 4 72 nodepath.c[pp] 1 34 34 1 71 71 widgets/gradient-vector.c[pp] 1 71 71 node-context.c[pp] 1 39 39 1 70 70 widgets/sp-widget.h 4 6 24 10 7 70 sp-typeset-kplayout.c[pp] 1 70 70 star-context.c[pp] 1 35 35 1 70 70 sp-typeset-layout.c[pp] 1 70 70 dialogs/desktop-properties.c[pp] 1 70 70 display/nr-arena.h 7 10 35 14 5 70 dialogs/text-edit.c[pp] 1 70 70 dialogs/xml-tree.c[pp] 1 69 69 spiral-context.c[pp] 1 35 35 1 69 69 rect-context.c[pp] 1 34 34 1 69 69 arc-context.c[pp] 1 32 32 1 69 69 dialogs/export.c[pp] 1 68 68 main.c[pp] 1 38 38 1 68 68 dropper-context.c[pp] 1 27 27 1 68 68 draw-context.c[pp] 1 41 41 1 66 66 widgets/gradient-position.h 2 33 66 desktop-events.c[pp] 1 33 33 1 66 66 document.c[pp] 1 32 32 1 66 66 svg-view.h 5 4 20 6 11 66 text-context.c[pp] 1 41 41 1 65 65 dialogs/fill-style.c[pp] 1 65 65 sp-item.c[pp] 1 37 37 1 65 65 inkscape.c[pp] 1 27 27 1 65 65 libnrtype/RasterFont.h 4 16 64 dyna-draw-context.c[pp] 1 32 32 1 64 64 extension/implementation/script.c[pp] 1 63 63 object-edit.h 2 7 14 7 9 63 display/guideline.h 3 21 63 display/nr-arena-glyphs.c[pp] 1 62 62 sp-use.c[pp] 1 30 30 1 61 61 desktop-affine.h 20 4 80 20 3 60 sp-metrics.h 10 10 50 10 6 60 sp-symbol.c[pp] 1 33 33 1 60 60 libnr/nr-pixblock-pixel.h 1 5 5 4 15 60 object-ui.c[pp] 1 35 35 1 59 59 widgets/paint-selector.c[pp] 1 59 59 sp-marker.c[pp] 1 34 34 1 58 58 dialogs/item-properties.c[pp] 1 58 58 display/nr-arena-shape.c[pp] 1 58 58 sp-root.c[pp] 1 31 31 1 58 58 dialogs/transformation.c[pp] 1 58 58 path-chemistry.c[pp] 1 37 37 1 57 57 sp-typeset-utils.c[pp] 1 56 56 sp-namedview.c[pp] 1 28 28 1 56 56 widgets/gradient-position.c[pp] 1 56 56 sp-offset.c[pp] 1 56 56 sp-chars.c[pp] 1 29 29 1 56 56 object-edit.c[pp] 1 22 22 1 56 56 knot.c[pp] 1 23 23 1 55 55 extension/internal/ps.c[pp] 1 54 54 sp-gradient.c[pp] 1 33 33 1 53 53 sp-image.c[pp] 1 30 30 1 53 53 sp-star.c[pp] 1 27 27 1 52 52 zoom-context.c[pp] 1 25 25 1 52 52 sp-symbol.h 2 12 24 2 26 52 sp-pattern.c[pp] 1 29 29 1 51 51 dialogs/object-properties.c[pp] 1 50 50 sp-item-group.c[pp] 1 30 30 1 50 50 selection.c[pp] 1 23 23 1 50 50 widgets/gradient-selector.h 2 25 50 dialogs/stroke-style.h 2 25 50 dialogs/dialog-events.h 25 2 50 widgets/gradient-image.h 1 12 12 2 25 50 prefs-utils.h 49 1 49 widgets/gradient-selector.c[pp] 1 49 49 dialogs/dialog-events.c[pp] 1 49 49 dialogs/align.c[pp] 1 48 48 print.c[pp] 1 30 30 1 48 48 widgets/sp-widget.c[pp] 1 48 48 help.c[pp] 1 27 27 1 48 48 libnr/nr-scale-ops.h 8 6 48 selcue.h 24 2 48 style.c[pp] 1 24 24 1 48 48 selcue.c[pp] 1 48 48 satisfied-guide-cns.c[pp] 1 47 47 knotholder.c[pp] 1 21 21 1 46 46 rubberband.c[pp] 1 16 16 1 46 46 display/nr-arena-image.h 1 8 8 2 23 46 helper/stock-items.c[pp] 1 46 46 macros.h 31 2 31 45 1 45 sp-rect.c[pp] 1 27 27 1 45 45 sp-ellipse.c[pp] 1 24 24 1 45 45 star-context.h 3 4 12 4 11 44 livarot/AVL.h 22 2 44 gradient-chemistry.c[pp] 1 28 28 1 44 44 dialogs/display-settings.c[pp] 1 44 44 spiral-context.h 3 8 24 4 11 44 desktop-affine.c[pp] 1 22 22 1 43 43 desktop-handles.c[pp] 1 14 14 1 43 43 sp-path.c[pp] 1 24 24 1 42 42 sp-line.c[pp] 1 19 19 1 42 42 display/gnome-canvas-acetate.h 2 21 42 display/canvas-grid.h 2 21 42 svg/stringstream.h 21 2 42 extension/internal/gdkpixbuf-input.c[pp] 1 41 41 widgets/spw-utilities.c[pp] 1 41 41 sp-anchor.c[pp] 1 22 22 1 40 40 sp-spiral.c[pp] 1 19 19 1 40 40 extension/implementation/implementation.h 10 4 40 libnr/nr-rotate-ops.h 5 8 40 sp-guide.c[pp] 1 16 16 1 40 40 sp-object-repr.h 11 6 33 13 3 39 slideshow.c[pp] 1 26 26 1 39 39 sp-polygon.c[pp] 1 15 15 1 39 39 sp-object.c[pp] 1 14 14 1 39 39 display/canvas-bpath.c[pp] 1 39 39 widgets/sp-xmlview-content.c[pp] 1 38 38 sp-clippath.c[pp] 1 23 23 1 38 38 widgets/dash-selector.c[pp] 1 38 38 sp-mask.c[pp] 1 23 23 1 38 38 svg-view.c[pp] 1 22 22 1 38 38 sp-polyline.c[pp] 1 15 15 1 37 37 libnrtype/RasterFont.c[pp] 1 37 37 display/sp-ctrlline.c[pp] 1 37 37 widgets/menu.h 16 2 16 37 1 37 widgets/font-selector.c[pp] 1 36 36 widgets/icon.c[pp] 1 36 36 dyna-draw-context.h 3 5 15 3 12 36 widgets/button.c[pp] 1 36 36 selection-chemistry.h 8 8 32 12 3 36 dropper-context.h 3 7 21 4 9 36 draw-context.h 3 5 15 3 12 36 libnrtype/FontFactory.h 7 5 35 extension/extension-forward.h 35 1 35 document-undo.c[pp] 1 21 21 1 35 35 livarot/LivarotDefs.h 35 1 35 extension/system.c[pp] 1 33 33 rect-context.h 3 4 12 3 11 33 libnrtype/font-style-to-pos.c[pp] 1 33 33 libnrtype/FontInstance.c[pp] 1 33 33 livarot/livarot-forward.h 33 1 33 attributes.h 27 1 27 33 1 33 arc-context.h 3 4 12 3 11 33 display/canvas-arena.c[pp] 1 32 32 selection-describer.c[pp] 1 31 31 sp-item-update-cns.c[pp] 1 31 31 dialogs/object-attributes.c[pp] 1 31 31 sp-item-notify-moveto.c[pp] 1 30 30 sp-clippath.h 3 6 18 3 10 30 widgets/gradient-image.c[pp] 1 30 30 sp-mask.h 3 6 18 3 10 30 sp-item-rm-unsatisfied-cns.c[pp] 1 30 30 livarot/Ligne.h 10 3 30 extension/internal/ps.h 2 15 30 sp-item-transform.c[pp] 1 15 15 1 29 29 livarot/PathCutting.c[pp] 1 29 29 dialogs/filedialog.c[pp] 1 29 29 dialogs/in-dt-coordsys.c[pp] 1 28 28 seltrans-handles.c[pp] 1 14 14 1 28 28 display/nr-arena-image.c[pp] 1 28 28 display/nr-arena-item.c[pp] 1 27 27 widgets/sp-color-selector.h 2 6 12 9 3 27 text-context.h 3 4 12 3 9 27 display/nr-gradient-gpl.c[pp] 1 26 26 libnrtype/TextWrapper.c[pp] 1 26 26 display/sp-canvas.c[pp] 1 26 26 libnr/nr-svp.h 3 8 12 2 13 26 extension/init.c[pp] 1 26 26 display/nr-arena-group.c[pp] 1 25 25 display/canvas-grid.c[pp] 1 25 25 zoom-context.h 5 4 20 5 5 25 display/guideline.c[pp] 1 25 25 libnr/nr-gradient.c[pp] 1 25 25 dialogs/rdf.h 3 8 24 display/sp-canvas-util.c[pp] 1 24 24 display/nr-arena.c[pp] 1 24 24 libnrtype/nrtype-forward.h 24 1 24 extension/extension.c[pp] 1 24 24 rubberband.h 4 4 16 4 6 24 dialogs/filedialog.h 2 12 24 display/sodipodi-ctrlrect.c[pp] 1 23 23 display/sodipodi-ctrl.c[pp] 1 23 23 livarot/DblLinked.h 23 1 23 display/gnome-canvas-acetate.c[pp] 1 22 22 svg/ftos.h 22 1 22 inkview.c[pp] 1 22 22 libnrtype/FontFactory.c[pp] 1 22 22 extension/internal/eps-out.c[pp] 1 21 21 selection-describer.h 7 3 21 sp-paint-server.c[pp] 1 10 10 1 21 21 snap.c[pp] 1 21 21 extension/internal/svg.c[pp] 1 21 21 libnr/nr-types.c[pp] 1 20 20 livarot/PathConversion.c[pp] 1 20 20 helper/unit-menu.h 8 4 16 10 2 20 libnr/nr-path.c[pp] 1 20 20 widgets/sp-color-scales.h 4 5 20 path-chemistry.h 6 2 12 10 2 20 libnr/nr-svp.c[pp] 1 20 20 libnr/nr-svp-render.c[pp] 1 19 19 libnr/nr-pixops.h 10 2 10 19 1 19 helper/window.c[pp] 1 19 19 helper/window.h 18 2 18 19 1 19 libnr/nr-rect.c[pp] 1 19 19 livarot/PathStroke.c[pp] 1 19 19 libnr/nr-types.h 141 4 282 1 19 19 libnr/nr-values.c[pp] 1 19 19 extension/implementation/script.h 3 6 18 libnr/nr-blit.c[pp] 1 18 18 libnr/nr-pixblock-line.c[pp] 1 18 18 display/nr-plain-stuff-gdk.c[pp] 1 18 18 extension/internal/ps-out.c[pp] 1 18 18 libnr/nr-pixblock-pattern.c[pp] 1 17 17 libnr/nr-svp-render.h 2 7 14 1 17 17 livarot/ShapeSweep.c[pp] 1 17 17 libnr/nr-pixblock-pixel.c[pp] 1 17 17 svg/svg-affine.c[pp] 1 17 17 livarot/PathSimplify.c[pp] 1 16 16 dialogs/object-attributes.h 6 2 12 8 2 16 view.c[pp] 1 9 9 1 16 16 widgets/spw-utilities.h 1 1 1 16 1 16 livarot/ShapeRaster.c[pp] 1 16 16 widgets/sp-color-notebook.c[pp] 1 16 16 widgets/sp-color-notebook.h 4 4 16 livarot/Path.c[pp] 1 16 16 shortcuts.c[pp] 1 6 6 1 16 16 libnr/nr-rotate-fns.h 2 8 16 libnr/nr-pixblock.c[pp] 1 15 15 libnr/nr-compose-transform.c[pp] 1 15 15 libnr/nr-pixblock-line.h 1 15 15 extension/db.c[pp] 1 15 15 extension/implementation/implementation.c[pp] 1 15 15 widgets/sp-color-wheel.c[pp] 1 15 15 libnr/nr-svp-private.h 2 5 10 1 14 14 libnr/nr-rect-l.c[pp] 1 14 14 livarot/ShapeMisc.c[pp] 1 14 14 helper/action.c[pp] 1 14 14 widgets/ruler.h 1 6 6 2 7 14 livarot/Shape.c[pp] 1 13 13 livarot/ShapeSweepUtils.c[pp] 1 13 13 libnr/nr-matrix.c[pp] 1 13 13 widgets/sp-color-wheel-selector.c[pp] 1 13 13 helper/sp-marshal.h 14 2 14 13 1 13 libnr/nr-matrix-fns.c[pp] 1 12 12 livarot/BitLigne.h 6 2 12 libnr/nr-convex-hull.h 1 12 12 libnrtype/TextWrapper.h 6 2 12 libnrtype/raster-glyph.h 3 4 12 widgets/sp-color-wheel-selector.h 2 6 12 sp-use-reference.h 3 4 12 widgets/spinbutton-events.c[pp] 1 11 11 inkscape-stock.h 11 1 11 widgets/sp-color-scales.c[pp] 1 11 11 dialogs/rdf.c[pp] 1 11 11 helper/units.h 86 2 86 11 1 11 livarot/ShapeDraw.c[pp] 1 10 10 extension/internal/eps-out.h 2 5 10 livarot/PathOutline.c[pp] 1 10 10 sp-animation.h 2 4 8 2 5 10 extension/internal/gdkpixbuf-input.h 2 5 10 display/bezier-utils.h 5 2 10 geom.c[pp] 1 10 10 sp-defs.c[pp] 1 8 8 1 10 10 widgets/icon.h 5 2 5 10 1 10 livarot/AlphaLigne.h 5 2 10 libnr/nr-rotate-fns.c[pp] 1 10 10 extension/internal/ps-out.h 2 5 10 display/bezier-utils.c[pp] 1 10 10 sp-object-group.c[pp] 1 8 8 1 10 10 dialogs/sp-attribute-widget.c[pp] 1 10 10 extension/internal/svg.h 2 5 10 prefs-utils.c[pp] 1 9 9 svg/svg-path.c[pp] 1 9 9 xml/repr-util.c[pp] 1 9 9 libnrtype/font-style-to-pos.h 3 3 9 svg/svg-length.c[pp] 1 9 9 uri-references.c[pp] 1 7 7 1 9 9 widgets/sp-xmlview-attr-list.c[pp] 1 9 9 streams-zlib.h 3 3 9 libnrtype/nr-type-pos-def.h 9 1 9 widgets/sp-color-gtkselector.c[pp] 1 9 9 widgets/ruler.c[pp] 1 9 9 widgets/sp-color-wheel.h 3 3 9 sp-metrics.c[pp] 1 6 6 1 9 9 widgets/sp-color-selector.c[pp] 1 8 8 xml/sp-repr-attr.h 4 2 8 widgets/sp-color-gtkselector.h 2 4 8 sp-guide-constraint.h 4 2 8 helper/unit-menu.c[pp] 1 8 8 dir-util.h 5 2 5 8 1 8 sp-use-reference.c[pp] 1 8 8 display/curve.c[pp] 1 8 8 tools-switch.h 4 2 8 widgets/widget-sizes.h 8 1 8 sp-item-transform.h 5 18 45 4 2 8 widgets/sp-xmlview-content.h 1 3 3 2 4 8 streams-handles.h 4 2 8 libnrtype/nr-type-primitives.h 6 2 6 8 1 8 sp-guide-attachment.h 4 2 8 svg/gnome-canvas-bpath-util.h 2 4 8 svg/svg-color.c[pp] 1 7 7 xml/repr-io.c[pp] 1 7 7 sp-animation.c[pp] 1 6 6 1 7 7 widgets/sp-color-preview.h 1 1 1 7 1 7 xml/repr.c[pp] 1 7 7 libnr/nr-point-fns.c[pp] 1 7 7 dialogs/fill-style.h 1 2 2 3 2 6 widgets/sp-xmlview-tree.h 1 2 2 2 3 6 widgets/sp-color-slider.c[pp] 1 6 6 widgets/sp-xmlview-tree.c[pp] 1 6 6 widgets/dash-selector.h 1 2 2 2 3 6 libnr/nr-translate-ops.h 1 6 6 xml/repr-get-children.h 3 2 6 object-hierarchy.c[pp] 1 6 6 dialogs/sp-attribute-widget.h 2 3 6 xml/repr-get-children.c[pp] 1 6 6 xml/repr-css.c[pp] 1 6 6 sp-item-rm-unsatisfied-cns.h 3 2 6 dialogs/item-properties.h 2 2 4 3 2 6 widgets/sp-xmlview-attr-list.h 1 2 2 2 3 6 prefix.h 6 1 6 svg/gnome-canvas-bpath-util.c[pp] 1 5 5 message-context.c[pp] 1 5 5 streams-jar.c[pp] 1 5 5 dialogs/object-properties.h 3 1 3 5 1 5 livarot/Ligne.c[pp] 1 5 5 display/nr-plain-stuff-gdk.h 5 1 5 streams-gzip.c[pp] 1 5 5 xml/repr-action.c[pp] 1 5 5 libnr/nr-compose.h 1 1 1 5 1 5 helper/units.c[pp] 1 5 5 marker-status.h 4 1 4 widgets/spinbutton-events.h 4 1 4 libnr/nr-object.c[pp] 1 4 4 object-ui.h 2 2 4 2 2 4 libnr/nr-compose-transform.h 1 3 3 2 2 4 dialogs/export.h 3 1 3 4 1 4 widgets/sp-color-slider.h 2 1 2 4 1 4 streams-gzip.h 1 4 4 dialogs/in-dt-coordsys.h 2 2 4 inkscape_version.h 4 1 4 satisfied-guide-cns.h 2 2 4 select-toolbar.h 2 2 4 splivarot.h 2 2 4 sp-item-notify-moveto.h 2 2 4 sp-item-update-cns.h 2 2 4 widgets/font-selector.h 1 10 10 2 2 4 sp-cursor.h 4 1 4 4 1 4 display/nr-plain-stuff.h 4 1 4 inkscape-stock.c[pp] 1 4 4 libnrtype/raster-position.h 1 4 4 display/nr-plain-stuff.c[pp] 1 4 4 approx-equal.h 4 1 4 libnr/nr-compose.c[pp] 1 4 4 streams-zlib.c[pp] 1 4 4 streams-jar.h 1 4 4 widgets/gradient-vector.h 2 2 4 geom.h 2 2 4 message-stack.c[pp] 1 4 4 livarot/AVL.c[pp] 1 4 4 helper/gnome-utils.h 2 1 2 4 1 4 livarot/MySeg.c[pp] 1 3 3 help.h 2 1 2 3 1 3 mod360.h 3 1 3 dialogs/text-edit.h 2 1 2 3 1 3 widgets/menu.c[pp] 1 3 3 livarot/BitLigne.c[pp] 1 3 3 widgets/sp-color-preview.c[pp] 1 3 3 dialogs/desktop-properties.h 2 1 2 3 1 3 libnrtype/font-glyph.h 1 3 3 livarot/AlphaLigne.c[pp] 1 3 3 inkjar/jar.c[pp] 1 3 3 remove-last.h 3 1 3 color.c[pp] 1 5 5 1 3 3 streams-handles.c[pp] 1 3 3 dialogs/align.h 2 1 2 3 1 3 libnrtype/nr-type-primitives.c[pp] 1 3 3 attributes.c[pp] 1 2 2 1 3 3 helper/png-write.c[pp] 1 3 3 helper/sp-marshal.c[pp] 1 2 2 marker-status.c[pp] 1 2 2 livarot/DblLinked.c[pp] 1 2 2 extension/init.h 2 1 2 fixes.c[pp] 1 2 2 sp-cursor.c[pp] 1 2 2 1 2 2 livarot/MySeg.h 1 2 2 helper/gnome-utils.c[pp] 1 2 2 dialogs/transformation.h 2 1 2 2 1 2 extract-uri.h 2 1 2 uri.c[pp] 1 2 2 preferences-skeleton.h 1 1 1 1 2 2 dialogs/display-settings.h 1 1 1 2 1 2 object-hierarchy.h 2 1 2 libnrtype/nr-type-pos-def.c[pp] 1 2 2 version.c[pp] 1 2 2 mod360.c[pp] 1 2 2 inkjar/jar.h 2 1 2 helper/stock-items.h 1 2 2 dir-util.c[pp] 1 2 2 1 2 2 svg/ftos.c[pp] 1 2 2 helper/png-write.h 1 1 1 2 1 2 extract-uri.c[pp] 1 2 2 prefix.c[pp] 1 2 2 svg/round.c[pp] 1 1 1 pixmaps/cursor-node-m.xpm 1 1 1 1 1 1 pixmaps/cursor-spiral.xpm 1 1 1 1 1 1 pixmaps/cursor-zoom.xpm 1 1 1 1 1 1 pixmaps/cursor-text-insert.xpm 1 1 1 pixmaps/cursor-select-d.xpm 1 1 1 1 1 1 pixmaps/cursor-text.xpm 1 1 1 1 1 1 pixmaps/cursor-select-m.xpm 1 1 1 1 1 1 dialogs/find.h 1 1 1 dialogs/xml-tree.h 1 1 1 1 1 1 pixmaps/handles.xpm 1 1 1 1 1 1 pixmaps/cursor-node-d.xpm 1 1 1 1 1 1 pixmaps/cursor-node.xpm 1 1 1 1 1 1 livarot/MyMath.h 1 1 1 svg/itos.c[pp] 1 1 1 pixmaps/cursor-star.xpm 1 1 1 1 1 1 brokenimage.xpm 1 1 1 1 1 1 pixmaps/cursor-rect.xpm 1 1 1 1 1 1 pixmaps/cursor-arc.xpm 1 1 1 1 1 1 pixmaps/cursor-zoom-out.xpm 1 1 1 slideshow.h 1 1 1 1 1 1 pixmaps/cursor-dropper.xpm 1 1 1 helper/sp-canvas.h 30 14 210 libnrtype/nr-font.h 16 18 144 libnrtype/nr-typeface.h 16 18 144 libnrtype/nr-rasterfont.h 16 18 144 libnr/nr_config.h 143 2 143 module.h 16 16 128 desktop-snap.h 10 12 120 modules/sp-module.h 10 18 90 helper/canvas-bpath.h 9 18 81 sp-canvas.h 9 7 63 sp-canvas-util.h 7 8 56 sp-module-doc.h 5 11 55 nr-arena-item.h 7 7 49 helper/sodipodi-ctrl.h 6 8 48 sp-module-exec.h 4 12 48 modules/sp-module-sys.h 4 12 48 sp-module.h 5 9 45 modules/sp-module-doc.h 4 11 44 event-broker.c[pp] 1 40 40 helper/sp-canvas-util.h 5 16 40 helper/curve.h 39 2 39 stroke-style.c[pp] 1 38 38 sp-module-exec-ext.c[pp] 1 35 35 text-edit.c[pp] 1 35 35 gradient-vector.c[pp] 1 34 34 gradient-selector.c[pp] 1 34 34 nr-type-directory.h 3 11 33 libnrtype/nr-type-directory.h 3 22 33 nr-arena-shape.c[pp] 1 32 32 desktop-properties.c[pp] 1 32 32 helper/sp-ctrlline.h 4 8 32 nr-type-ft2.h 3 10 30 fill-style.c[pp] 1 30 30 gradient-position.h 2 15 30 ps.c[pp] 1 28 28 object-properties.c[pp] 1 28 28 nr-arena-glyphs.c[pp] 1 27 27 sp-module-exec-ext.h 2 13 26 nr-type-xft.h 2 13 26 document-properties.c[pp] 1 25 25 gradient-position.c[pp] 1 25 25 nr-arena.h 5 5 25 paint-selector.c[pp] 1 25 25 icon.c[pp] 1 25 25 export.c[pp] 1 24 24 nr-arena-group.h 3 8 24 helper/sodipodi-ctrlrect.h 3 8 24 item-properties.c[pp] 1 24 24 spw-utilities.c[pp] 1 24 24 transformation.c[pp] 1 24 24 sp-module-sys.h 2 12 24 xml-tree.c[pp] 1 23 23 align.c[pp] 1 23 23 stroke-style.h 2 11 22 sp-widget.c[pp] 1 21 21 helper/nr-gradient-gpl.h 3 14 21 nr-arena-shape.h 1 21 21 sp-module-sys.c[pp] 1 20 20 font-selector.c[pp] 1 20 20 canvas-arena.c[pp] 1 19 19 nr-rasterfont.c[pp] 1 19 19 nr-type-directory.c[pp] 1 19 19 desktop-snap.c[pp] 1 18 18 module.c[pp] 1 18 18 nr-arena-glyphs.h 1 18 18 button.c[pp] 1 17 17 gradient-image.c[pp] 1 17 17 node-edit.c[pp] 1 17 17 object-attributes.c[pp] 1 17 17 svg.h 4 4 16 helper/guideline.h 2 8 16 nr-type-xft.c[pp] 1 16 16 nr-typeface.c[pp] 1 16 16 nr-arena-item.c[pp] 1 15 15 repr-private.h 5 3 15 nr-font.c[pp] 1 15 15 nr-gradient-gpl.c[pp] 1 14 14 nr-arena-image.c[pp] 1 14 14 nr-arena-group.c[pp] 1 14 14 sp-module-exec.c[pp] 1 14 14 nr-type-ft2.c[pp] 1 14 14 sp-module.c[pp] 1 13 13 canvas-arena.h 1 13 13 gradient-image.h 1 12 12 guideline.c[pp] 1 12 12 sp-color-selector.h 2 6 12 dash-selector.c[pp] 1 12 12 sp-canvas.c[pp] 1 12 12 tool-options.c[pp] 1 12 12 nr-arena.c[pp] 1 12 12 sp-module-doc.c[pp] 1 12 12 tool-attributes.c[pp] 1 12 12 canvas-bpath.c[pp] 1 11 11 sp-toolbox.c[pp] 1 11 11 font-selector.h 1 10 10 ps.h 1 10 10 nr-font.h 1 10 10 modules/ps.h 1 10 10 sodipodi-ctrl.c[pp] 1 10 10 sp-color-selector.c[pp] 1 10 10 nr-rasterfont.h 1 10 10 sp-ctrlline.c[pp] 1 10 10 canvas-grid.c[pp] 1 10 10 sodipodi-ctrlrect.c[pp] 1 10 10 nr-typeface.h 1 10 10 sp-attribute-widget.c[pp] 1 9 9 gnome-canvas-acetate.c[pp] 1 9 9 sp-canvas-util.c[pp] 1 9 9 helper-forward.h 9 1 9 helper/bezier-utils.h 3 3 9 canvas-bpath.h 1 9 9 display-settings.c[pp] 1 8 8 guideline.h 1 8 8 sp-ctrlline.h 1 8 8 sodipodi-ctrl.h 1 8 8 helper/canvas-grid.h 1 8 8 canvas-grid.h 1 8 8 gnome-canvas-acetate.h 1 8 8 nr-plain-stuff-gdk.c[pp] 1 8 8 helper/gnome-canvas-acetate.h 1 8 8 button.h 2 4 8 nr-arena-image.h 1 8 8 sodipodi-ctrlrect.h 1 8 8 gradient-selector.h 2 4 8 svg-affine.c[pp] 1 8 8 nr-arena-forward.h 7 1 7 ruler.c[pp] 1 7 7 sp-xmlview-attr-list.c[pp] 1 7 7 nr-gradient-gpl.h 1 7 7 sp-xmlview-content.c[pp] 1 7 7 svg-length.c[pp] 1 6 6 sp-attribute-widget.h 3 2 6 action.c[pp] 1 6 6 svg-path.c[pp] 1 6 6 ruler.h 1 6 6 sp-widget.h 1 6 6 repr.h 5 1 5 sp-xmlview-tree.c[pp] 1 5 5 nr-type-primitives.c[pp] 1 5 5 unit-menu.c[pp] 1 5 5 repr-action.h 5 1 5 svg-color.c[pp] 1 5 5 libnr/nr-stroke.h 1 5 5 repr-util.c[pp] 1 4 4 fill-style.h 2 2 4 nr-plain-stuff.c[pp] 1 4 4 repr-action.c[pp] 1 4 4 repr-css.c[pp] 1 4 4 repr-io.c[pp] 1 4 4 units.c[pp] 1 4 4 gradient-vector.h 2 2 4 repr.c[pp] 1 4 4 bezier-utils.c[pp] 1 4 4 helper/nr-plain-stuff-gdk.h 4 1 4 sp-xmlview-content.h 1 3 3 sp-color-slider.h 3 1 3 menu.c[pp] 1 3 3 window.c[pp] 1 3 3 nr-type-primitives.h 3 1 3 event-broker.h 3 1 3 bezier-utils.h 1 3 3 sp-color-preview.c[pp] 1 3 3 icon.h 3 1 3 action.h 1 3 3 gnome-canvas-bpath-util.h 2 1 2 menu.h 2 1 2 paint-selector.h 1 2 2 png-write.c[pp] 1 2 2 arikkei-token.c[pp] 1 2 2 dialogs/node-edit.h 2 1 2 helper/nr-plain-stuff.h 2 1 2 sp-xmlview-tree.h 1 2 2 curve.h 2 1 2 sp-color-slider.c[pp] 1 2 2 object-attributes.h 1 2 2 gnome-utils.c[pp] 1 2 2 curve.c[pp] 1 2 2 sp-color-preview.h 2 1 2 item-properties.h 1 2 2 gen_nr_config.c[pp] 1 2 2 arikkei-dict.c[pp] 1 2 2 nr-plain-stuff.h 2 1 2 sp-marshal.c[pp] 1 2 2 dash-selector.h 1 2 2 units.h 2 1 2 sp-intl.h 1 2 2 unit-menu.h 1 2 2 sp-xmlview-attr-list.h 1 2 2 gnome-canvas-bpath-util.c[pp] 1 2 2 tool-attributes.h 1 1 1 nr-plain-stuff-gdk.h 1 1 1 tool-options.h 1 1 1 object-properties.h 1 1 1 libarikkei/arikkei-token.h 1 1 1 dialogs/tool-options.h 1 1 1 gnome-utils.h 1 1 1 node-edit.h 1 1 1 extension.h 1 1 1 png-write.h 1 1 1 export.h 1 1 1 text-edit.h 1 1 1 widgets/sp-toolbox.h 1 1 1 spw-utilities.h 1 1 1 window.h 1 1 1 arikkei-token.h 1 1 1 sp-toolbox.h 1 1 1 display-settings.h 1 1 1 extensions-skeleton.h 1 1 1 arikkei-dict.h 1 1 1 desktop-properties.h 1 1 1 dialogs/tool-attributes.h 1 1 1 document-properties.h 1 1 1 dialogs/document-properties.h 1 1 1 align.h 1 1 1 ------------------------------------------------------------------------- File Count 464 562 Total 3486 5415 16178 8290 10960 59277 Average 7 11 34 14 19 105 Notes ----- * This analysis was performed with the 'Cumulative Include Dependency Checker' (CIDC) on 2004-07-05 by B. Harrington. * CIDC sometimes loses track of which subdirectories a file comes from, so there may be multiple entries for a given file. * IDP should be expected to increase due to a natural increase in codefiles in the project, so an increase in IDP is to be expected. * Inkscape 0.35 preceded our conversion to C++, so its code files are .c, rather than .cpp; this has been compensated by treating the same-named .c and .cpp files as the same file. * The file count in the above report does not match the count obtained from a wc -l of the cidcSummary.csv; this appears to be due to duplicate entries due to path confusion on cidc's part, and has been corrected for in the parsing scripts. The number shown above is expected to be more accurate than the linecount of the .csv. * If you suspect any discrepencies, please flag it so it can be corrected for future runs.

1 0

Re: [Inkscape-devel] new tutorial started on Wiki
by Bryce Harrington 05 Jul '04

05 Jul '04

Okay, I've activated the upload feature. Click on the Upload link to use it. I tested it out with a couple files here: http://inkscape.org/cgi-bin/wiki.pl?SandBox Regarding abuse, just keep an eye on it for now and let me know if you spot problems, and we'll figure out how to handle it accordingly. Enjoy! Bryce On Sat, 3 Jul 2004, John Griessen wrote: > I do, I do, > > Yes, I found this link that suggests it has a really good use for > collaborating on a visual program like Inkscape, where the benefit is to > put .png files to the webserver to be linked to in the Wiki. Only > thing to consider is probably only let it work while logged in as some > confirmed user so stopping XXX image promoters from uploading naked > human photos without being traceable. > > http://www.nzoss.org.nz/wiki/index.php?pagename=UploadFiles > > JG > > PS Thankyou Arpad > > > don't know what that function does (I guess you're referring to > > > the Upload link which is in the header of every Wiki page). I'm > > > CCing the development list, probably someone can enlighten us. > > > > Yeah, it's supposed to enable the ability to upload files to the server, > > for use within the wiki pages. The feature was added to enable > > Wikipedians to upload images for use within Wikipedia. > > > > I probably don't have it configured right though. I can work on getting > > it functional if people want to use it. Lemme know. > > > > Bryce > >

1 0

Report for 2004-07-03 18:00 GMT-0500
by unknown＠example.com 05 Jul '04

05 Jul '04

Hi. I have some bad news. Unfortunately, the last build attempt at compiling Inkscape CVS was very unsuccesful. I'm sorry, I really tried hard. Really. Here is the LOG file, and I hope that helps.

5 5

General and Specific Meta-Data
by Jon Phillips 04 Jul '04

04 Jul '04

Right now in Inkscape and OCAL graphics files meta-data is file wide, yet how can we maintain meta-data for discrete objects and groups of objects? How can we have both the General/Abstract meta-data and then have specific meta-data for discrete items and groups? I wonder how we can have it so that when an object or collection of objects is copied and pasted, imported and transformed, that its specific meta-data (beyond specified graphics attributes) can be copied along with itself (making a media object). In the future this will be vital for algorithmic composition of graphics. Thoughts? Jon -- Jon Phillips Graduate Researcher Visual Arts Department PO BOX 948667 LA JOLLA, CA 92037 USA cell.858.361.2811 jon@...235... http://www.rejon.org

4 4

L10n questions
by Arpad Biro 04 Jul '04

04 Jul '04

Hi, I have a few questions concerning new strings: #: src/dialogs/rdf.cpp:227 "Coverage" #: src/dialogs/rdf.cpp:228 "Extent or scope of this document." Do these mean "the things this document talks about"? #: src/dialogs/rdf.cpp:238 "URI to the License namespace definition." Is "License" the name of a namespace? #: src/interface.cpp:936 "Make Current Layer" Does this mean: "make it the current layer"? #: src/dialogs/rdf.cpp:225 "classication" Does this mean the same as "classification"? Arpad Biro __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail

3 2

Re: [Inkscape-devel] Clone command
by bulia byak 04 Jul '04

04 Jul '04

>Bulia...this is an awesome feature. I wish the keyboard shortcut was >easier to do with one hand. Most keys are already taken. Feel free to propose another shortcut. >Also, I think there should be another feature that should be added >called EXPAND, which allows for selected cloned objects to be made into >complete copies of the referenced image. Better "Unlink clone". Also a command to look up a clone's original. >Also, markers applied to the original do not apply to the clones. Yes. Please file a bug. _________________________________________________________________ http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

6 5

away for a while
by MenTaLguY 04 Jul '04

04 Jul '04

I'll be without phone or internet access for the next few days (hopefully not longer), so I probably won't be getting much Inkscape work done in that time. CVS isn't really very friendly for disconnected operation. In my absence, there are a few important things I wanted to make sure were nailed down before the 0.39 release: A. Clipping Paths Clipping paths are an extremely important feature for me personally, so I want to make sure they're in order before the release. 1. I think the clipping-paths-not-activating-on-load bug is related to a cut+paste mistake in sp_item_set -- if you compare the SP_ATTR_CLIP_PATH and SP_ATTR_MASK branches, one ->clip_ref has not been changed to ->mask_ref in the SP_ATTR_MASK branch. (hopefully that's right; this is from memory) Could someone please check, fix and commit that? 2. 'clip-path' specifications are currently only supported as XML attributes, not style= properties. Changing that now will require non-trival architectural work (I think), so just be aware of that when testing. 3. In case Bulia or anyone is interested, clipping paths currently require recursive updates. Not fatal, but if it bothers you you might want to have a look. B. Layers I kind of snuck in some layers stuff over the weekend. You can pick "enter group" from the context menu to start using a group as the current layer (i.e. the drawing tools will draw within it). "leave group" will "back out a level" (until you hit the root <svg> element again). I'd been hoping to get it a little more polished, but I probably won't have a chance before the release at this point... 1. The implementation is pretty crude and doesn't add any UI feedback; we should probably disable those menu entries for the final release 2. If you do decide to add feedback, I'd recommend adding a SigC++ signal to Inkscape::ObjectHierarchy that fires whenever the top or bottom object in the hierarchy changes. Also add a signal to SPDesktop that indicates when the current layer changes. The SPDesktop layer change should be driven by the signal belonging to SPDesktop::_layer_hierarchy (an Inkscape::ObjectHierarchy). SPDesktop would also end up needing to keep a SigC::Connection around to track its connection to the hierarchy signal -- so please remember to: a. explicitly call the constructor and destructors for any SPDesktop members of types in the SigC:: namespace b. disconnect the SigC::Connection before destroying it 3. The tools currently set the newly created item's transform by directly assigning to SPItem::transform. That's incredibly bad, and I had not intended to leave it in. It'd be nice if someone could make a public SPItem::setTransform() method (which would more or less just call the private sp_item_(mumble?)_set_transform() .. sorry, this is from memory) and use that instead. SPItem::transform should really be treated as read-only by outsiders. 4. "enter group" and "leave group" should really both go next to each other in the menu and in interface.cpp 5. There are also some issues of "transparency" (in the sense of event delivery) for layers currently, which is another reason I think we're probably best off shipping with the feature disabled. C. 0.40 release planning Also some entries I want to make sure we have on the 0.40 roadmap in the wiki: 1. add a dependency on libgc (the Boehm conservative collector), which will be required for the AST code 2. add a dependency on libcroco (which will be needed for the CSS portion of AST) 3. switch to sigc++ 2.0/newer gtkmm early in 0.40, before we start doing gtkmm-intensive stuff like the layers dialog etc. See y'all in a few days I hope... -mental

3 7

Perf improvement to IntLigne::Copy(FloatLigne)
by Bryce Harrington 04 Jul '04

04 Jul '04

I've checked in a patch to IntLigne::Copy(FloatLigne*) that improves performance on my box. Previously, it had been taking 0.10 sec (4.74%), but now has been reduced to 0.03 sec (1.47%). I don't think I made any algorithmic changes, and booleans seems to still be working right, but I'd appreciate it if someone could keep an eye on it in case a goof got introduced. Bryce Before: % cumulative self time seconds seconds name 11.85 0.25 0.25 Shape::SwapEdges(int, int) 7.11 0.40 0.15 Shape::ConvertToShape(Shape*, fill_typ, bool) 4.74 0.50 0.10 IntLigne::Copy(FloatLigne*) <---- 3.79 0.58 0.08 Shape::SwapPoints(int, int) 3.32 0.65 0.07 Shape::CmpToVert(NR::Point, NR::Point, bool, bool) ... After: % cumulative self time seconds seconds name 13.73 0.28 0.28 Shape::SwapEdges(int, int) 7.35 0.43 0.15 Shape::ConvertToShape(Shape*, fill_typ, bool) 5.39 0.54 0.11 Shape::SwapPoints(int, int) 3.43 0.61 0.07 FloatLigne::InsertBord(int, float, int) 3.43 0.68 0.07 FloatLigne::Flatten() 3.43 0.75 0.07 Shape::TesteIntersection(SweepTree*, SweepTree*, NR::Point&, double&, double&, bool) 2.94 0.81 0.06 Shape::AddEdge(int, int) 2.45 0.86 0.05 Shape::TesteAdjacency(Shape*, int, NR::Point, int, bool) 2.45 0.91 0.05 Shape::CheckAdjacencies(int, int, Shape*, int) 1.96 0.95 0.04 Shape::CheckEdges(int, int, Shape*, Shape*, bool_op) 1.96 0.99 0.04 Shape::SortEdges() 1.47 1.02 0.03 sp_repr_attr(SPRepr const*, char const*) 1.47 1.05 0.03 IntLigne::Copy(FloatLigne*) <---- 1.47 1.08 0.03 nr_path_matrix_bbox_union(NRBPath const*, NR::Matrix const&, NRRect*) 1.47 1.11 0.03 nr_object_check_instance_type(void*, unsigned) ...

2 3

layercake layercake baker's man...
by MenTaLguY 04 Jul '04

04 Jul '04

Just a quick note that I've been polishing the layers feature and even without the layers dialog it's becoming rather usable. So basic layers (of a sort) might actually make it in for this release. Here are some of the relevent changes: * I've retired the inkscape:groupmode attribute as it has served its purpose * You get Sodipodi-style "enter group"/"leave group" commands on the context (right click) menu which can be used to switch to using a group as a layer, or switch back to that group's parent * when a group is in this "layer" mode, the drawing tools create shapes within it and you can drag and select its objects directly Here are the items that are still needed: * The "group mode" setting needs to be per-NRArena key, and persist across hide/show cycles (currently, the change in event handling behavior is global, even though layer activation is per-SPDesktop) * Some sort of visual indicator of the current layer would be nice. I have provided an SPDesktop (SigC++) signal for this purpose, which can be connected to via SPDesktop::connectCurrentLayerChanged() * should e.g. "Select All" etc be influenced by the current group? -mental

4 9

layers credit
by MenTaLguY 04 Jul '04

04 Jul '04

I should also note that this was part of my inspiration as well: http://inkscape.org/cgi-bin/wiki.pl?ObjectManager -mental

1 0

Re: [Inkscape-user] Inkscape Text Rendering Strangeness...
by bulia byak 03 Jul '04

03 Jul '04

> One interesting bug that has cropped up occurs when I use the library to output some text and tspan elements. As an example I have included the original file, the output of svggrayscale.py, Inkscape's saved version of the output, and a fixed version of Inkscape's output. It seems to be adding extra text XML elements (tabs, newlines, spaces) when loaded in Inkscape, so the text displays with an offset to the right. At first I thought it was a problem with SVG-Utils, but librsvg 2.7.2 renders the output from svggrayscale correctly, so now I'm not sure. I hope you could look into this issue and help me to understand why it is happening. Use Batik and/or Adobe SVG plugin as reference renderers. In this case they both display the same as Inkscape, so the problem is not with Inkscape. Your script adds newlines between <text> and <tspan>. Within <text>, whitespace is meaningful and is displayed as text. Note that Inkscape, when creating <text>, does not leave any extra whitespace inside.

2 1

Inkscape Startup Times
by Bryce Harrington 03 Jul '04

03 Jul '04

--------------------- Real Time (s) ---- Inkscape Run 1 Run 2 Run 3 Run 4 Run 5 Average ============================================================== 0.35 0.125 0.119 0.118 0.119 0.120 0.120 0.36 0.142 0.140 0.142 0.144 0.151 0.144 0.37 0.200 0.195 0.193 0.196 0.195 0.196 0.38.1 2.289 2.317 2.297 2.303 2.309 2.303 CVS 0.720 0.725 0.727 0.732 0.720 0.725 --------------------- User Time (s) ---- Inkscape Run 1 Run 2 Run 3 Run 4 Run 5 Average ============================================================== 0.35 0.096 0.092 0.091 0.094 0.098 0.094 0.36 0.117 0.111 0.119 0.114 0.113 0.115 0.37 0.166 0.166 0.170 0.172 0.162 0.167 0.38.1 2.216 2.228 2.223 2.233 2.244 2.229 CVS 0.645 0.652 0.665 0.654 0.645 0.652 --------------------- System Time (s) ---- Inkscape Run 1 Run 2 Run 3 Run 4 Run 5 Average ============================================================== 0.35 0.014 0.013 0.016 0.014 0.010 0.013 0.36 0.011 0.016 0.011 0.013 0.016 0.013 0.37 0.026 0.022 0.021 0.016 0.025 0.022 0.38.1 0.040 0.036 0.034 0.036 0.031 0.035 CVS 0.046 0.035 0.034 0.046 0.044 0.041 I got curious about startup times, from bug reports that we've gotten from 0.38.1 users. I downloaded all the past Inkscape releases and replaced their gtk_main() call with exit(), and timed how long each took to get to that point. These tests were run on a 3GHz P4 with 512K cache and 1G RAM. Sure enough, 0.38.1's startup was significantly slower than previous releases. Good news it looks like CVS is much improved, although it's still slow compared with 0.37 and before. Bryce

2 3

share/tutorials/making_markers.svg
by Arpad Biro 03 Jul '04

03 Jul '04

Hi, Don't know if it's intentional or not, but currently making_markers.svg is not in share/tutorials/Makefile.am. Arpad Biro __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail

1 0

Incomplete translations because of "fuzzy" tags
by Arpad Biro 03 Jul '04

03 Jul '04

Dear Inkscape Translators, Recently I noticed (in de.po and pt_BR.po) that a lot of translated strings still carry the "fuzzy" tag. Please keep in mind that after translating a string that carried the "fuzzy" tag, YOU HAVE TO REMOVE THE FUZZY TAG - otherwise this translation will be discarded when creating the machine-readable translation file (*mo), which means that your work of translating those strings will be lost. Examples of how to remove the "fuzzy" tag: #: src/dialogs/desktop-properties.cpp:758 #, fuzzy msgid "Custom" msgstr "Personalizado" becomes #: src/dialogs/desktop-properties.cpp:758 msgid "Custom" msgstr "Personalizado" after translating, and #: src/dialogs/object-attributes.cpp:130 #, fuzzy, c-format msgid "%s attributes" msgstr "%s atributos" becomes #: src/dialogs/object-attributes.cpp:130 #, c-format msgid "%s attributes" msgstr "%s atributos" Alternatively, you can use KBabel for translating, so that the fuzzy tags are automatically removed after modifying a fuzzy string. KBabel also does a lot of other things for you (like updating the PO-Revision-Date field). I recommend using that software to everyone. Thanks for your hard work and let me know if you have questions. Arpad Biro __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail

3 3

Re: [Inkscape-devel] new tutorial started on Wiki
by Arpad Biro 03 Jul '04

03 Jul '04

Hi, > Yes, and I am still wanting to find out if the upload button does > anything useful, like putting a file on the > http://www.inkscape.org/cgi-bin/wiki.pl? webserver somewhere... I don't know what that function does (I guess you're referring to the Upload link which is in the header of every Wiki page). I'm CCing the development list, probably someone can enlighten us. Arpad Biro __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

Polyline and polygon point specification patch submitted
by Mark Nyrup Mortensen 03 Jul '04

03 Jul '04

Hi, I have submitted the patch for the polyline and polygon point specification and a simple self-explaining test-file to the tracker. And then another question somewhat related to the patch (and probably other places in Inkscape?): Does anyone know whether the "g_ascii_strtod" function actually is capable of reading and returning numbers sufficiently large to allow for the numbers available in SVG? From what I have seen so far i would say no, but again my knowledge of C/C++ and GTK+ is fairly limited. Mark Nyrup Mortensen

1 0

Report for 2004-07-02 18:00 GMT-0500
by unknown＠example.com 03 Jul '04

03 Jul '04

Hi. I have some bad news. Unfortunately, the last build attempt at compiling Inkscape CVS was very unsuccesful. I'm sorry, I really tried hard. Really. Here is the LOG file, and I hope that helps.

2 1

Polyline and polygon point specification
by Mark Nyrup Mortensen 03 Jul '04

03 Jul '04

Hi, i received a svg-file converted from wmf (by the Batik Graphics2D SVG Generator) a little more than a month ago. The file consisted of several thousands of polygons (i looked in the XML Editor :-), yet Inkscape displayed nothing but a blank canvas. I looked into the problem and found that Inkscape (and a pre-inkscape cvs-version of Sodipodi) only considered points in polygons (and polylines) written the same way as Inkscape does, and not in every way the SVG spec indicates (requires?). Well, to the point :-) I made a small patch (and a small test-file), which I have used for the last month with a CVS-update almost every day (no crashes), and I would like to know if anyone is interested in them? And then a small questions, sorry ;-) I would like to look into a blend tool (and some other more or less useful tools), but since I'm new to the internals of Inkscape, I would like to know if it's sane in it's current state (with the structural changes going on). I could still try to make an abstract outline of the blend function, which then could be implemented later (when the Extension API has been implemented around version 0.42?). (I make no promises though:-) I have been using Java almost exclusively since version 1.0.1 came out, with some perl and python tossed in, and have had only a brief look at C/C++ in the same period (that's the reason i don't promise anything :-). Mark Nyrup Mortensen

2 1

Re: [Inkscape-user] SVG that doesn't display in Inkscape.
by MenTaLguY 02 Jul '04

02 Jul '04

On Wed, 2004-06-30 at 22:36, Trent Buck wrote: > Removing the <switch> </switch> tags from around the body seems to work. > > About 80% of the data is some binary formatted junk in an <i:pgf> tag. > I guess it's a thumbnail or something. > > Maybe as a kluge inkscape should ignore <switch> tags to make such > exported images work? <switch> its intended use is to enclose a bunch of children, only one of which is supposed to be rendered (based on conditions specified in their requiredFeatures, requiredExtensions, and systemLanguage attributes); I'm not sure whether displaying everything would be an improvement over displaying nothing for typical documents that use it. It shouldn't be hard to support properly, though. We're a little too close to the pre-release freeze to squeak it into this release, but I'll put in an RFE and stick it on the roadmap for 0.40. -mental

1 0

Brasilian Portuguese Translation
by Juarez Rudsatz 02 Jul '04

02 Jul '04

Attached there is a pt_BR translation. Somebody could review ? Mit Freundichen Grüßen Juarez Rudsatz

2 1

new tutorial started on Wiki
by John Griessen 02 Jul '04

02 Jul '04

Hi, I've started putting up a tutorial, and would like a little help putting an image on the wiki... I read about links thinking they would apply to a upload file that is an image in .png format, but no luck... http://www.inkscape.org/cgi-bin/wiki.pl?action=edit&id=TutorialIdeas is where to look to help out. I have not seen any other image content on the Wiki, is it possible? JG -- John Griessen Cibolo Design Austin Texas EE good at IR systems, power supplies, logic design, A2D D2A, digital amps, mechatronics, SiGe and CMOS layout, MEMS/mech/electronic/photonic modeling, charge pump PV/battery/fuel cell power converters, linux counter #249315

2 1

Report for 2004-07-02 10:00 GMT-0500
by unknown＠example.com 02 Jul '04

02 Jul '04

Hi. I have some bad news. Unfortunately, the last build attempt at compiling Inkscape CVS was very unsuccesful. I'm sorry, I really tried hard. Really. Here is the LOG file, and I hope that helps.

1 0

mergining SPObject and SPRepr
by MenTaLguY 02 Jul '04

02 Jul '04

(yay, I'm back, sorta) Since it's been brought up I don't think the suggestion of merging SPObject and SPRepr to solve our update problems is necessarily a good idea. The main reason is just that with a unified representation we have to make a tradeoff between: * an efficient representation for editing or * a representation that preserves the XML syntax tree during every transformation (i.e. we don't want Inkscape to chew up or discard arbitrary XML fragments which have no semantic meaning to us, but are important for other uses..) Both of these are important goals for us, so I think dividing our representation into separate classes to address each of these needs is necessary. We could still wrap SPObject/SPRepr pairs in another object, which would encapsulate our updating strategies for them. That _might_ be helpful, but I'd need to think about that some more. FWIW, here are some of the updating problems I see: 1. the id binding problem Currently, the SPObject <-> SPRepr binding is maintained by using XML fragment ids. This is IMO, more problematic than it's worth and forces us to impose ids on all XML nodes (including text nodes). My existing plan is to do the mapping directly rather than relying on ids (I've done some of the preliminary work on this already; new code should use SPDocument::getObjectByRepr rather than SPDocument::getObjectById). 2. the authority problem Are SPObjects or SPReprs authoritative? Not all our code is consistent in this regard, especially as it's often more convenient/efficient to update the SPObject directly. I believe the answer should be that SPReprs are authoritative, though SPObjects can temporarily be out of sync ("dirty") with new changes, provided those changes are flushed to the SPRepr layer at key points, e.g. before committing an undo log. (i.e. SPObject is essentially a cache for SPRepr, which functions as a backing store) 3. the manual update problem Many times it's more efficient to make changes at the SPObject level rather than to the SPRepr. Under the present system, this requires explicit calls to SPObject::updateRepr() to synchronize the state; if updateRepr() is called for every SPObject change, it becomes grossly inefficient. On the other hand, it's very tricky to defer these update calls until later, because mistakes are easy and they often get missed. I think the solution is to automate the "lazy" updating of SPReprs, so we get the performance benefits of lazy updates without having to debug manual updating code in a bajillion places. This is one thing that could (conceivably) be addressed in a wrapper class. -mental

1 0

Re: Report for 2004-07-01 18:00
by bulia byak 02 Jul '04

02 Jul '04

> Unfortunately, the last build attempt at compiling Inkscape CVS was > very unsuccesful. Maybe it's better to just forward error logs to the devel list because it's hard to predict whose changes may be the cause of the problem. In this case, hierarchy_* is Mental's stuff and rdf_* is Kees'.

2 1

Unable to set an object ID
by Bob Jamison 01 Jul '04

01 Jul '04

Does anyone have any ideas about this one? I don't think that this is a new bug, but another symptom of our ongoing problem with SPRepr and SPObject synchronization. Now it seems that any attempt to set the ID of an object via the GUI, either via Item Properties, or the XML editor, fails with messages like this: ** (inkscape:7718): CRITICAL **: Attempt to set id of bound SPRepr (0x8f98b34) without having registered the SPObject in the document's id table I know that some code could set the ID of the SPObject, too, but I fear that might break things further. Bob

2 2