- Inkscape Devel - Inkscape Mailman

assertion `bpd->moveto_idx >= 0' failed
by unknown＠example.com 10 Apr '05

10 Apr '05

I was playing around with an effect script I wrote yesterday. <http://www.ekips.org/comp/inkscape/koch.php> And I found that if I add a path to the document with the following pathdata: M208.57143 703.79075L174.516731473 751.46188866L239.616096737 756.673375098L208.57143 703.79075ZM414.28571 715.21933L354.791910976 765.893698391L462.153883759 809.766643481L414.28571 715.21933ZL435.919819746 753.935147186L460.519786772 711.050828191L414.28571 715.21933ZM488.57143 578.07647L504.042810705 635.178562182L568.765082358 575.851235234L488.57143 578.07647Z I see this message on the console: ** (inkscape:5371): CRITICAL **: void gnome_canvas_bpath_def_closepath(GnomeCanvasBpathDef*): assertion `bpd->moveto_idx >= 0' failed I'm guessing that the sticky part is "ZL435.919819746 753.935147186" because there is a closepath directive that is not followed immediately by a moveto. But I think this is within the bounds of the spec: 'If a "closepath" is followed immediately by a "moveto", then the "moveto" identifies the start point of the next subpath. If a "closepath" is followed immediately by any other command, then the next subpath starts at the same initial point as the current subpath.' <http://www.w3.org/TR/SVG/paths.html#PathDataClosePathCommand> So it would seem to me that "g_return_if_fail (bpd->moveto_idx >= 0)" in "src/svg/gnome-canvas-bpath-util.cpp" says "fail if the current subpath doesn't begin with a moveto" when it means to say "fail if the current path doesn't begin with a moveto." Aaron Spike

1 0

Re: [Inkscape-devel] DXF import
by Bryce Harrington 10 Apr '05

10 Apr '05

On Sat, Apr 09, 2005 at 06:40:15AM -0500, aaron@...749... wrote: > Jon A. Cruz wrote: > >One thing I was thinking, when I saw the first messages on this thread, > >was that even if there are some other DXF converters we might want to do > >our own anyway, since there might be higher-level semantics we could > >preserve differently, or might map into Inkscape-specific extensions. > >Thinking of some of the things wanted like diagramming, connectors, etc. > > Two links that I saw a while back that might be of interest: > http://www.ribbonsoft.com/dxflib.html Mmm, good find. That's exactly the type of thing needed. I downloaded the code and browsed through it. It looks like to create a dxf2svg converter one would need to do this: Create a sub-class of DL_CreationInterface called something like SvgCreator. SvgCreator's job would be to build up a tree of SVG elements from the DXF data as parsed by this library. To do this, in SvgCreator implement all of the virtual methods in DL_CreationInterface - addCircle(), addLine(), addKnot(), etc. Each of these routines would need to create the corresponding SVG element. I.e., in addCircle(DL_CircleData), you'd convert the contents of the DL_CircleData structure into SVG data and add it to your SVG tree. The next question is, how do you build the SVG tree? This is basically just a data structure to contain XML data, so you could probably use some existing XML library to do it. There is also some SVG-specific code out there you could look at reusing, such as Cairo, librsvg, or even Inkscape itself, in the src/xml directory. (Anyone have a suggestion for which lib would be best to use?) Finally, given the built-up tree, you need code to write it out to an SVG file. Presumably, whatever code you've selected for building the XML tree will include some sort of writer function, so in theory you can just call that, and you're done. :-) So to recap, this looks pretty straightforward. To code it you'll need to be moderately comfortable with C++. You'll need to create one class, and hook two libraries together. You'll need to create a makefile for it, and set up the usual packaging stuff too, but this is all pretty straightforward. I think this'd be a 2-weekend project for someone with good C++ skills, and perhaps thrice that (but an excellent learning project) for a C++ newbie. Anyway, wish I had time to do more than just give advice, but I hope this helps. This looks totally do-able, it just needs a bit of coding time. It'd sure be handy, and I bet it'd get used pretty widely. Bryce

2 1

Gtkmmification status
by Bryce Harrington 10 Apr '05

10 Apr '05

Several people have taken interest in how the Gtkmm work is coming along, particularly in where they could help move it forward. The Gtkmm conversion is required for the 0.42 release, so it's got the high priority currently. We've got a ton of cool features besides gtkmm already in the can, so we have strong incentives to getting gtkmm done. We really don't want to bump the gtkmm work to next release; we've already bumped it for the past three releases, plus we have a bunch of other highly requested features (like the layer dialog) that are dependent on the gtkmm work being in place. Good progress has been made so far, but as you can imagine, reimplementing the Inkscape interface is not a trivial task! We've got most of the bones in place, but there's a lot of flesh to be hung. We had started from the point of Gtkmmifying dialogs. We've made good progress in this area, and have converted most of the simpler dialogs. There's a few challenges still left, such as figuring out how to do TreeView-based dialogs like the XML Editor and the much-anticipated Layer Dialog, however for the most part I think we've got a good framework in place so it'll just be the effort needed to do the conversions. There's still a lot of TODO's in the code for doing things like hooking up preferences, gaining some better abstractions, etc. Jon Philips has been plugging away at some of these items. Converting dialogs to Gtkmm is pretty straightforward. You choose the dialog you want to convert, create a new class derived from Inkscape::UI::Dialog, and go through the old dialog code, migrating function calls over. You look at the manual on gtkmm.org to learn what the C++ versions of the gtk calls are. Usually you can eliminate a lot of unnecessary code in the process (gtkmm is more concise, and the Dialog class takes care of a lot of the basics for you). Meanwhile, Jon Cruz has been experimenting with a cool new idea that abstracts the contents of dialogs into "Panels" that could either be presented in dialogs or embedded in the GUI frame itself. I think this adds flexibility that many users may find quite helpful; it should be possible for someone to adapt the Gtkmm dialog architecture to this without too much trouble. Jizzbug has done a bang-up job of Gtkmmifying all the toolbar and menu stuff. The Gtkmm interface now at least *looks* like the current interface. There's still some optimizations and tweaks needed - button sizes aren't quite right, for example, and we probably need to update the toolbars and menus with recent changes to the main codebase, but these are bite-sized tasks that seem very appropriate for new Gtkmm developers so I'm not worrying about them for now. There's still a lot of chunks of the UI that haven't even been started yet, such as the statusbar and rt-click context menu. They're of medium priority, so I'm not worried about them yet, but they'll definitely have to be tackled before we can make the new UI the default. The highest priority right now is getting the Canvas hooked up. This will be a major milestone to achieve since it'll finally let us *see* SVG documents inside the new interface. With that in place, the work of hooking up toolbars, menu items, dialogs, etc. can finally get under way in full earnest. It looks to me like the path to achieving this is to C++-ify SPView and SPSVGView more, then reimplement SPDesktop and SPDesktopWidget in Gtkmm. This is what I'm focusing on myself right now. Last night I created some C++ member function wrappers for the sp_view* routines, and intend to continue this work through the weekend. Converting SPDesktop will be a sizeable project, but I'm hopeful within a week or so I'll have it in working order, if not completely done. I'm really looking forward to having the Gtkmm work available for us to use in the main interface. Beyond just making the ui code a lot easier to work with, it's bringing in some rather cool innovations we will be able to take advantage of. It will eliminate a ton of quirks in the current UI. It will give users much more flexibility in how the UI is laid out. It will enable us to do some much more sophisticated UI designs, and give Inkscape the advanced UI capabilities that other leading edge GNOME applications have today. :-) As you can see, there's a lot of areas where work can be done in parallel. There's still a lot of blank-page type areas for pure creativity, other areas that mostly work now but need good problem solvers to perfect, and plenty of bulk-work places where C++/gtkmm novices can have a big impact while they learn. I would strongly urge anyone that has some time in the coming months, a little C++ skill, and an interest in pushing Inkscape forward, to think about joining in on the Gtkmm effort. Contact me and let me know what you're interested in, and I'll help you get going. :-) Bryce

1 0

Re: [Inkscape-devel] DXF import
by Bryce Harrington 10 Apr '05

10 Apr '05

On Sat, Apr 09, 2005 at 10:50:36AM +0200, Tobias Jakobs wrote: > Am Freitag, den 08.04.2005, 17:34 -0700 schrieb Bryce Harrington: > > > Anyway, I would imagine that for the DXF module in OO, the situation > > would be similar, however it may be well worth doublechecking. > > Basically, what you'd need to do is dig into the OpenOffice codebase and > > locate the chunk of code that handles DXF, and figure out how much work > > it'd be to extract it. Then, of course, you'd need to find some way to > > turn that into SVG; since OO doesn't yet have SVG export, that'd > > probably be a show-stopper, but who knows. > > > My OO.o has SVG export, or did you mean import? Sorry, I meant "a stand-alone SVG export functionality". Bryce

1 0

Re: [Clipart] developing an xml schema standard for packaged multimedia
by Bryce Harrington 10 Apr '05

10 Apr '05

On Tue, Apr 05, 2005 at 01:48:18PM -0400, Nathan Eady wrote: > Mike Traum wrote: > >I think an xml schema should be developed for a bundle of multimedia > >files. There may be one already, but in my brief search I was not > >able to come up with anything. > > Maybe I'm just old-fashioned, but I would think that an archive format, > such as PKWare ZIP format, would make more sense than XML for a bundle > of files. Even OpenOffice, which uses XML extensively, uses ZIP for > packaging up groups of related files together. Seems to work very > well. Java and Mozilla also use the ZIP format for similar purposes > (jar and xpi, respectively). Johan Ceuppens created a jar-based format for contining multiple SVG files about a year ago for Inkscape. See inkscape/src/inkjar/ for details. It would be nice to build atop that effort. It did not include a metadata format IIRC but it does handle the storage/compression/CRC parts. It was originally created to enable packaging of SVG presentations. In fact, inkview includes support for browsing these files (inkview mypackage.jar). Bryce

1 0

Donation System Proposal
by Bryce Harrington 10 Apr '05

10 Apr '05

Hi all, The other day we received another donation to Inkscape ($10, less SourceForge and PayPal fees). :-) For about a year we've talked on and off about donations for Inkscape. The major question is not getting the money, but deciding how to apply the money appropriately. Of course, we've had no shortage of ideas... From bug bounties/contracts, to hardware, to developer support, to sponsoring attendance at conferences. I like all the ideas, although some would be more feasible than others. However, the one idea I think I like the best, to start with, is to fund contract work to enhance file import/export converters. I.e., accumulate enough funding to pay a developer to augment an existing xyz2svg tool for use with Inkscape. Here is my reasoning for this proposal: 1. These extensions are distinct from the main Inkscape codebase, thus eliminating a range of potential conflicts of interests, learning curve issues, and so forth. 2. Users *definitely* want to see the file converters improved. This is often a crucially important need for them, and they will see the benefits of the improvements immediately. 3. File converters haven't tended to attract attention from many developers. Maybe they're not considered 'sexy' enough? Using money as a motivator is worth a shot. 4. These converters will have definite value beyond Inkscape. A lot of programs out there are starting to gain SVG support. If we are able to gain good xyz2svg converters, this could benefit them as well, plus would help build the reputation of SVG as a good format for interoperability, which helps all of us out a lot. 5. I emphasize focus on enhancing _existing_ tools over creating new ones for several reasons. First, the work of creating a basic tool that does the first 80% of the conversion is usually not too hard and actually kind of fun; the hard part is getting that last 20%, and that's where I think funding development will be most effective. Also, it can be harder to track progress for development of a tool being written from scratch. 6. We can allow users to contribute to the specific converter they wish to support; i.e., we establish one pool for the AI extension, another for DXF, another for VSD, etc. and allow people to choose which one their donations will go to. Here are the challenges I see for this proposal, and how we'd be able to deal with them: a. Funds collection/distribution: If we get a large number of donations, there may be an administrative overhead to keep track of them. I'll set up an account that allows us to accumulate the funds via SourceForge, and for now I'll just handle the accounting manually. If it becomes burdensome, myself or someone can script it up better. b. Donation fees: Currently, SF and Paypal impose fees for donations. A $10 donation works out to be $8.48. It'd be nice to preserve a larger proportion, but beggers can't be choosers. If someone less lazy than me wants to set up something better, let me know. c. Deciding the contract terms. This is the point I'm not sure about, but clearly we need to have some way of establishing the minimum goals for the funding. I'm open to suggestions, but sure we can figure something out; contracting developers is nothing particularly new. d. Deciding who is allowed to bid on the work. I'm concerned about random people bidding on the work, and also think that the spirit of the donations is to also help further Inkscape development in general. Thus I would be tempted to limit participation to people who have a track record of doing development work for Inkscape. These people will be "known quantities", and will have a stake in doing a good job. e. Deciding when to close donations and open bidding. In other words, how do we decide how much money to raise? It's often difficult to determine how much time it'd take to implement a feature. My thought is to leave this open ended - we simply post what the expectations are and how much $$ has been collected, and when a developer feels enough has been raised, he submits a bid to do the work. This way, "the market" is left to decide what the rate should be. f. Deciding what file converter features to allow donating to. My feeling is that we should just leave this open to the donors. Any donation target that someone puts money against is worth adding to the list. g. Legal/contractual paperwork and such. I'm blissfully clueless here. Maybe this part is the achilles heel of the whole idea, or maybe it's no big deal, I have no idea. But people have paid other people to do work before, and I'm sure it can be sorted out somehow. Anyway, let me know what y'all think of this proposal. Worth doing? Bryce

3 2

Re: [Inkscape-devel] DXF import
by John Taber 09 Apr '05

09 Apr '05

Are there any plans for a DXF import ? Right now I have to open a DXF in Open Office Draw, save as SVG, then import into Inkscape. Too bad OO is not GPL otherwise could just take that code module and stick into Inkscape, but maybe there are others.

6 9

Re: [Inkscape-devel] DXF import
by John Taber 09 Apr '05

09 Apr '05

Are there any plans for a DXF import ? Right now I have to open a DXF in Open Office Draw, save as SVG, then import into Inkscape. Too bad OO is not GPL otherwise could just take that code module and stick into Inkscape, but maybe there are others.

3 2

Allowed INX param types
by unknown＠example.com 09 Apr '05

09 Apr '05

I was wondering. What are all of the possible param types that can be passed to scripts? I'm wondering specifically if it is possible to specify quoted strings and one of a set of enumerated value. Aaron Spike http://www.ekips.org/comp/inkscape/wavy.php

1 0

NEW: Load from URL
by Bryce Harrington 08 Apr '05

08 Apr '05

As a configure-time option, Inkscape now supports loading SVG's from a remote URL via HTTP. This is implemented using the GNOME VFS library. This is a library that Inkscape has not had a dependency on previously, so it's implemented as an optional dependency that is controlled during configuration via the --with-gnome-vfs flag. In other words: $ ./configure --with-gnome-vfs $ make $ src/inkscape http://openclipart.org/clipart//animals/bugs/butterfly_jonathan_dietr_01.svg The file is loaded into memory and parsed directly, rather than saving to a temporary file, so it loads pretty fast. Enjoy, Bryce

4 5

Re: [Inkscape-devel] Scripting
by unknown＠example.com 08 Apr '05

08 Apr '05

aaron@...749... wrote: > ted@...11... wrote: > >> This is really nice. Aaron, one thing that we'd talked about in the >> past is starting to move twoards having a seperate package of scripts, >> to remove some dependencies from the base Inkscape package. So, you'd >> have "inkscape.rpm" and "inkscape-scripts-python.rpm" that you'd >> install (if you wanted). >> >> As someone who is starting to write more scripts, do you have thoughts >> on this? Would you perhaps want to start such a package? Do any of >> the packagers out there have any thoughts? > > I'd love to start a package, but I'm sure I wouldn't have a clue. I > thought I read somewhere that Inkscape was leaning toward a CPAN-like > setup perhaps an XML-RPC service. In some ways I think distributing a > package of extensions doesn't fit well with the cause. Thinking about how scripts should be distributed reminded me of a question I wanted to as a few days ago. Should there be or is there a search path for extensions? Could I for instance install my custom effect scripts and thier *.inx files into ~/.inkscape/extensions ? Aaron Spike

2 2

Effect errors
by unknown＠example.com 08 Apr '05

08 Apr '05

I often write effects in Python that raise an exception, and therefore send no output to STDOUT. Inkscape responds with: Extension::Script: Unknown error for pclose : Success /tmp/ink_ext_qL04b1:1: parser error : Document is empty ^ /tmp/ink_ext_qL04b1:1: parser error : Start tag expected, '<' not found ^ ** (inkscape:6769): CRITICAL **: virtual void Inkscape::Extension::Implementation::Script::effect(Inkscape::Extension::Effect*, SPView*): assertion `mydoc != NULL' failed Is that just a healthy warning? I also notice on occasion (though I can not reproduce it on command yet) that I experience a crash soon afterward. So my question: Could stderr generated by scripts be captured into a gui window? This is of course unnecessary because, I can always run inkscape from the command line for debugging. But I thought the information might help users track down dependencies. Aaron Spike

1 2

Basepoint of objects
by Craig Bradney 07 Apr '05

07 Apr '05

Hi Just wondering if theres any plans to implement the ability to change the basepoint of an object. I just submitted 1178771 for this. It'd be really nice to be able to change the position or rotation based on all of the corners and centre, and perhaps midpoints of the sides of an object. Please refer to Scribus' Properties Palette for an example if its interesting to Inkscape. Craig Scribus Team

3 3

Re: [Inkscape-devel] Basepoint of objects
by Craig Bradney 07 Apr '05

07 Apr '05

On Thursday 07 April 2005 22:41, bulia byak wrote: > On Apr 7, 2005 4:48 PM, Craig Bradney <cbradney@...242...> wrote: > > Basepoint = Top left, bottom right, centre etc of what would be the > > bounding box of an object. > > So we just need to make the centerpoint snap to these points (and to > grid and guides too). I was always going to do that. > > > A) Its not convenient to move the rotation center for every single object > > you pick up > > Why would you need a uniform location for more than one object at > once? Can you give a usage scenario? > > > B) The rotation centre is not obvious in all modes > > It's visible in those modes which it affects. Yes, I see now that the rotation value doesnt seem to be shown anywhere after rotation is done, which is why it may not apply to Inkscape (/SVG) in this instance. Or have I missed where this is stored too? :) > > C) Is there a way to accurately set the rotation centre to the TL, TR, > > BL, BR and C of the bounding box? > > Yes, once snapping is done. > > > Perhaps I've missed an easy way to say, eg, set a frame 100 units from > > the right of a page, or from another object. > > Ah, you mean you want the X/Y values in the selector controls to be > switchable to different corners of bbox? That might make sense, with a > small grid of toggle buttons to choose one of the corners or mid-sides > or the center. Yes.. thats basically it. In Scribus it is also used for the rotation centre. Craig

1 0

Scripting
by unknown＠example.com 07 Apr '05

07 Apr '05

Sorry I don't know enough about the subject to formulate more proper questions. I'm interested in learning more about the python scripting support. I realize it is a ways down on the roadmap still, but occasionally I hear a bit about it. Is there anything in CVS that I can try or anything I can read to learn more and watch it develop? Aaron Spike

4 14

inx files
by unknown＠example.com 07 Apr '05

07 Apr '05

I have read through most of the inx files in the extensions directory and I have created a few myself. I would like to learn whatever else there is to know about inx files. Who should I ask? Where should I look (in which source files)? Today I am wondering specifically about the param elements as seen in grid.inx. When I see the param element I expect two things. That there will be a gui facility for a user to change those values. And that those values will be passed to my script. When I tried neither happened. I think I've heard some chatter about the gui not being finished. But I was surprised that the values weren't passed on the command line. Am I at least in the ballpark with how this will work? Aaron Spike

1 1

Re: [Inkscape-user] some pdf creation info
by Erik 07 Apr '05

07 Apr '05

Craig, I have used the pdf printer route with Inkscape numerous times but have always been a bit disappointed. I tried again this evening using a recent cvs with a test file containing a rectangle (+radial gradient) +star (+linear gradient) + spiral +some text. While this is hardly of mind shattering complexity there was an awful lot of huffing and puffing. Saved as svg the file size was 6KB. Saved as pdf the file size was 959KB. then I changed the gradients to uniform grey. Saved as pdf the file size was still 575KB. Some observations. I am using the PrimoPDF driver as downloaded, and saving in Screen mode. Win2000 and PentiumIII933. The saving takes ages - as in a couple of minutes. However, once it gets there the pdf contains the colour and the gradients. I remember trying transparency as well some time ago and that was ok too. The line quality onscreen is pretty bad but improves with magnification up until the jaggies come in. The slow speed and large file sizes are definitely a concern. I have not looked at what a "realistic" file would be like in terms of time. But if a svg file of say 60KB produced a pdf file of 10MB then I would doubt its use! Having said that, I must admit there are lots of issues with PDFs and even a very fast program such as Xarax. There the gradients/transparencies/other special effects are often changed into bitmaps and produce huge files. Interestingly, exchanging gradients for say 20% grey in Xarax brings the file size back down to sensible figures. We do not seem to have quite got there yet. Xarax also does not seem to suffer the time problems that Inkscape does. However, we know there are time problems and have done for some time. Maybe at this stage we should be thankful that we can get pdfs in this way at all. There are also many PDF printer solutions out there. It would be good for someone to look at a few of them and find out which is the most efficient at this stage. Certainly pdf capability is a limiting factor in my use of Inkscape at present. Erik ----- Original Message ----- From: "Craig Gotthardt" <craig2b@...782...> To: "'InkScape-Users'" <inkscape-user(a)lists.sourceforge.net> Sent: Thursday, April 07, 2005 8:54 PM Subject: [Inkscape-user] some pdf creation info > > I have found that on xp (0.41.win.exe) CutePDF works to create a basic pdf > directly from inkcsape. It installs as a printer. > NOTE: ("dependency") needs Ghostscript to convert. > I dont know about linux? But Im sure theres something out there to use. > http://www.cutepdf.com/products/CutePDF/writer.asp > > Craig

1 0

Re: [Inkscape-user] 0.41 autopackage - missing dependencies
by unknown＠example.com 07 Apr '05

07 Apr '05

Quoting Bryce Harrington <bryce@...260...>: > I think it would be invaluable for 0.42 that this whole > approach should be rethought and reimplemented in a clearer way. Not just invaluable but mandatory, IMO. It's been a usability disaster. -mental

5 4

Re: [Inkscape-user] icon theming
by MenTaLguY 07 Apr '05

07 Apr '05

> My 16x16px icon got scaled down to about 10px in the toolbar. What's the magic here? I would like to be able to tell you why the icons are the size they are, but the icon drawing code we inherited from Sodipodi is scary and nobody quite understands it... :P I'll CC the devel list in case perhaps the gtkmmification team has made any breakthroughs studying and/or rewriting that code. -mental

3 3

Re: [Inkscape-user] autosave ?
by MenTaLguY 07 Apr '05

07 Apr '05

On Sat, 2004-06-19 at 18:04, Florent wrote: > So I'm appealing to anyone who can create an autosave :-) We already have autosave-on-crash already, actually. The one catch is that for crashes due to failed assertions (like this one), it isn't triggered yet. (I'm CCing the development mailing list, if anyone's interested in attacking this right now: At least on Unix, this is relatively easy to fix -- just set up a SIGABRT handler similar to the SIGSEGV handler we have now. The one catch is that the handler will need to disable itself as soon as it is triggered, because the autosave code raises SIGABRT when it is done. Also we should make sure we've got SIGBUS covered if we don't already.) -mental

3 4

New dialog/panel junk
by Jon A. Cruz 07 Apr '05

07 Apr '05

I've started a bit of stuff on my "Panels" replacement for subclassing dialogs. It's on the Wiki, linked under "User Interface Discussion" http://www.inkscape.org/cgi-bin/wiki.pl?DialogReplacement Bulia, see? I have a plan. :-)

1 0

Gristle down?
by Bob Jamison 06 Apr '05

06 Apr '05

Is it just me, or is Gristle.org down? (Normally I wouldn't post something like this, but I can't get onto irc.freenode.net to check) Bob

2 2

Absurd stack bottom value\n inkscape v0.41
by jerry ondola 06 Apr '05

06 Apr '05

the subject line is what is recieved after attempting to run inkscape 0.41 from the command line. using the gui interface, it quitely dies, no error messages. this is on gentoo. i've filed bug report #1176668, this happens with the CVS version and the emerge version. there where no other errors reported with or during the emerge. any other troubleshooting that i can do before dumping this version and going back to 0.37, which works fine ? thanks for the suggestions jerry __________________________________ Do you Yahoo!? Yahoo! Personals - Better first dates. More second dates. http://personals.yahoo.com

5 9

New features in Illustrator
by Joshua A. Andler 05 Apr '05

05 Apr '05

Just thought I'd throw the link on the list so you can all see what they're up to... http://www.adobe.com/products/illustrator/newfeatures.html Boy does that "Control Palette" look awfully familiar. ; ) (yeah, I know Xara had it first, but still... goes to show how they're playing catch-up in some areas) The Live Painting and Enhanced Stroke options look interesting... I question how much better their new "live tracing" is, compared to their old tracing engine (as it is supposedly much better). The rest of the "new features" don't look too interesting to me (other than the custom workspaces, which might be handy... but it's something only a fringe crowd would benefit from). Just figured I'd see what others opinions were. -Josh

7 15

Palette loading
by Jon A. Cruz 04 Apr '05

04 Apr '05

I got palette loading in last night. It now looks in the /usr/local/share/inkscape/palettes and ~/.inkscape/palettes directories for any Gimp-style palette files and loads them all up. Of course... that was just loading. :-) I'll check in soon to add UI changes to allow switching the palette displayed in the swatches window.

6 11