Scribus actually didn't work on the example I tried. It didn't render the gradients correctly, and it also munged the fonts I was using (made Vera into a monospaced font).

I heard that Scribus (1) can't handle gradients whose nodes are outside the object and (2) has problems with fonts. The (2) is fixed by converting text to path before export, not sure about (1). Try to bug the Scribus guys about that.

Is anybody working actively on direct PDF output?

Not that I know of. It's an awful amount of work, and so far our plan was to lift, one day, the PDF code from Scribus and reuse it in Inkscape. Scribus' PDF is quite good.

output gradients to PS or PDF is a serious limitation that will probably be enough to prevent an awful lot of users from using Inkscape. Maybe my perceptions and priorities are different from other people's but it surprises me that people would be working on, e.g., Perl and Python extensions when a really basic feature like this is not yet implemented.

Personally, I would much prefer to have standard system-wide high-quality SVG->PDF and PS->SVG converters that we could use, without having to code them into Inkscape. Such a modular approach would be the best for everyone. The idea that every single design app must import and export all common formats is, IMHO, a harmful misconception originated on proprietary platforms where each app has to be self-sustaining and cannot count on cooperation from other programs. We can save a lot of resources by not following this model. I see no problem in having to run Inkscape files through Scribus or some other converter [1] when I need PDF, provided it is as cross-platform as we are and produces good output. And yes, I admit that myself I'm much more interested in developing innovative vector graphic abstractions and UI for them than in writing support for some foreign format.

[1] There was a talk of an SVG driver for Ghostscript - too bad it seems to have stalled, this would be the best solution for everything PS/PDF-related.

On Sun, 19 Dec 2004, Ben Crowell wrote:

Is anybody working actively on direct PDF output? The inability to output gradients to PS or PDF is a serious limitation that will probably be enough to prevent an awful lot of users from using Inkscape.

Yes there's very strong interest in this feature and you're right that it's lack is probably hindering some people.

Maybe my perceptions and priorities are different from other people's but it surprises me that people would be working on, e.g., Perl and Python extensions when a really basic feature like this is not yet implemented. Maybe it's just the nature of OSS: developers want to work on stuff that interests them personally, so that determines which features get added.

*Grin* Good observations.

A few points on this...

First, yes, that's correct that in OSS developers work on stuff that interests them. For many developers, they do the work because it's fun; the more fun they have, the more they want to work on it, and the more that gets implemented, so this is a good thing. Unfortunately, the price of this means that sometimes "cool" features get implemented before the "necessary" ones.

I personally feel very strongly that a project based on this approach will be much more prolific and successful. We actually _encourage_ people to work on what interests them personally; we don't assign features to implement - we will go as far as redoing the roadmap to accomodate people's interests. Based on the amount of work that got done over the past year, I think the value of this approach has demonstrated itself. People are very motivated when they're working on implementing something that is near and dear to their heart. :-)

Now, you'd think that with this approach we'd have pure anarchy, but it seems to have worked very well. Looking back over the last year, there have been a whole _string_ of things that were felt to be "top priorities", that didn't seem to be getting any implementation attention. Yet time and again, in each case they *did* get implemented, not because it became a crisis, but just because someone took it as a challenge. Booleans, arrowheads, text-on-path, layers, patterns, etc. I've always been amazed at how many times there's been some critically missing feature, with no work apparently being done on it, and then suddenly poof, it's in the codebase and we're off on the next "critically missing feature". ;-)

I liken it to layers of an onion. Each release solves "the critical need", peels off the layer, and lo and behold there's more "critical needs". When we started, we didn't have gradients; we added that and then needed radial gradients; we've added that and today we need path-based gradients; tomorrow we'll probably need programmatic gradients or something. Each set of new features opens the program to larger audiences and new use cases. We didn't used to have export PNG, so you had to take screenshots with Gimp; export png was added, then the need was for postscript output; then import/export from other formats; now we need even more compatibility... So this is natural progression, and I think we'll continue to see things getting better and better as we go.

Now, the ironic thing is that the example you mentioned - Perl and Python scripting - actually *is* one of those critical needs that folks have been wanting for a *very* long time (in fact, it's one of the few features identified in Inkscape's mission). The reason it's important is not so much about artistic functionality as much as for project growth. There are a lot of people who could contribute features for Inkscape if they don't feel like they have to spend weeks learning the core codebase. So, indirectly, this investment of time will probably pay off a lot.

Also, you hit it on the nose that people work on what matters most to them, and that different people have different priorities. Scripting is one of the reasons that Ishmal got involved in the first place. He needed it for a project he was doing at work, and the lack of it in Inkscape meant he had to use other applications to do it. Plus, we got him distracted off implementing a bunch of other critical needs. ;-) So for this reason alone I think it's great to see him making progress in this area (and in ECMA). I think he's taken it as a personal challenge. :-)

Right now, I'd say there's at least a dozen different items that someone feels are critical top priorities. The UI improvement work was identified as needing attention by a lot of the commenters on the 0.40 release. Postscript/PDF is another area in need of work, like you and others note. Printing needs attention badly. Snapping and object-to-object linking is a critically needed feature for diagrammers out there. Gradient editing needs an overhaul. CSS/Style functionality is a continual issue with SVG compatibility and needs a complete rewrite. And on and on. I'm sure we'll get all these things done eventually, but right now I think we have more features needed than we have developers, so we'll have to take them a few at a time. The fastest way to get them all done is to have people work on the one(s) they're most interested in; they'll be more dedicated, and will get more out of the project personally.

I suppose as a general rule of thumb, if a feature you're interested in doesn't seem to get enough development attention, the best thing to do is to put time into it - coding is the best way, of course, but also just doing testing, writing recommendations, or documenting how it does/should work. Generating some movement in the area of that feature can sometimes be enough to attract people to work on it. If not, at least you'll have pushed the ball forward a bit for someone else with similar interests.

Anyway, I guess this is a really long winded way of saying, yes, you're right, but it's not so bad - this way actually seems to work out well in the end. :-)

Bryce