Drawing applications live and die by being able to share files with one another. In Open Source, different applications have different feature sets, and sometimes it's quite handy to be able to shift from app to app in order to perform all of the needed work. Additionally, for people converting over from legacy proprietary tools, the ability to import from proprietary formats is crucial.
As an example, in Inkscape we have a functionality that allows us to automatically pipe a file through a filter program. We found a script called ill2svg.pl that is able to take an Adobe Illustrator file on STDIN, and emits the corresponding SVG to STDOUT. This AI import feature was a very frequent request by users before we added it, and being able to reuse an existing Open Source tool saved us a *lot* of effort. Similarly, we've been able to leverage Sketch, dia, and other programs by running them from the command-line to convert their native file formats into SVG.
The other way Inkscape handles file formats is through libraries such as libpng. Formal libraries are generally better than command-line tools, and so are preferred, but they're more work to create so are not as common.
More file format converters (either command-line or libraries) and improvements to the existing converters, would be an extremely valuable way to improve interoperability between Open Source drawing applications. There is a dire need for maintainers of the command-line converters; many of the scripts out there are essentially unmaintained, and really need developers to improve them. The ill2svg.pl program mentioned above, for example, needs a number of improvements in order to read in a wider variety of AI files. A Visio(VDX)-to-SVG converter could also be extremely beneficial. Reimplementing the more popular converters as C libraries would give us even more flexibility and power as we move forward.
In addition, we need to encourage more drawing applications to support both input and output of SVG and other standard file formats. OODraw is a commonly used drawing tool, and it has an SVG output capability, but cannot import SVG. This tends to close off the benefits of SVG to a huge segment of the Open Source community's overall userbase.
Programs with unique primary file formats should also be encouraged to provide the converter code packaged as libraries and/or command-line tools where-ever possible. Thankfully, many Open Source applications are already doing this; users can help a lot here by keeping an eye out for apps that don't, and voicing their desire for this feature.
Achievement of document format compatibility could be instrumental in enabling wide numbers of users to convert to Linux. Corporate users with large numbers of existing drawing files will be loath to convert to Linux if it means they will not be able to re-use them. We have already seen with office documents how big of an enabler that OpenOffice.org's compatibility has been; doing the same with drawing formats could really solidify Linux's value as a desktop platform.
Code (and Widget) Libraries
Sharing of code seems like a no-brainer for achieving integration between the various projects. However, while this is certainly worth doing, the benefits are not always a trivial matter to obtain.
Between GIMP, Scribus, and Inkscape, we have one Gtk+ app, one Qt app, and one (soon-to-be) Gtkmm app. It would certainly not take much time to find a fourth, fifth, and sixth Open Source drawing application coded with completely incompatible interface languages. ;-)
I don't think it's realistic or productive in the near term to expect these projects to stop and recode themselves to a different widget set. It's a heck of a lot of work! Also keep in mind that Gtk and Qt each imply a lot more than just a widget set; they each have low level routines (such as glib in Gtk) that are used throughout the program codebase.
On the other hand, there's nothing to stop the projects from each creating shareable widgets, that are packaged and distributed independently of the program itself. Even if not all graphics applications could use those, at least some could, and maybe in the long term we could see some porting activity.
Drawing applications have needs for widgets such as rulers, canvases, palette editorss, gradient editors, and so forth. These are often too application-specific to be included and maintained in the core widget library, though. In addition, oftentimes applications wish to customize and go beyond the core default widgets.
An idea that's been voiced for this could be for the individual drawing application projects to try to organize and package their more general-purpose widgets into discrete libraries, that they would offer for other projects to reuse.
We also have numerous examples of efforts others have done to achieve code sharing both at low levels (such as some of the work KDE developers have done to reuse lower level GTK libs) and high level (such as metatheme, etc.) There are big shoulders we can stand on. ;-)
In addition, there are a number of non-widget things that may be worth sharing. For instance, a really good PDF printing library could help us all out; Scribus has the reputation for the best PDF export in the community, so this is something they could provide that we could all benefit from.
In addition to the above technical issues, it sounds like there is also a desire from users to see the applications united in spirit, if not in body. This is often mentioned as establishing a "suite", however I think what is desired is more about establishing ourselves as a "team".
To me, a "suite" conjures up the notion of corporate software giants bundling applications together to try to kill off the competition. But we're not trying to kill off or replace anyone. Unlike proprietary software, success with Open Source software is not measured by market-share dominance. GIMP, Scribus, and Inkscape can be quite successful even if they never have more than a fraction of the total userbase, so long as they continue to improve the value of the tools to the users and have fun in doing so.
Adobe and Macromedia provide excellent products that are essentially de facto standards in the computerized art world, and due to their resources and depth of experience will almost certainly remain the best solutions for most users. However, there are still sizeable numbers of users that will appreciate having an alternative, for a variety of reasons: Price, availability, openness, freedom, participation... Open Source operates from a fundamentally different philosophy than commercial-ware, which gives us a small but distinct edge.
I think one thing we could really use is additional liaisons between our groups. Peter Linnell has been an excellent example of this between Scribus and Inkscape, and has helped us build a strong relationship. Despite being in two completely different widget sets, the relationship has enabled us to achieve a notable amount of interoperability. Because Peter contributes to both projects, he provides information and keeps an eye out for things we can each do to improve integration. On several situations he's arranged IRC meet-ups between the groups to discuss long term plans and to share ideas. One or two people serving in such a role between GIMP and Inkscape (and perhaps other projects) could do a great deal of good for all of us.
The big picture here is to build something that enables designers to do a wide range of work on Open Source. Regardless of whether they're using a GNOME, KDE, OpenOffice, or Mozilla application, the goal is to make it straightforward for them to do better work than can be done with non-Open Source products.
This is completely achievable, and can be done without having to limit choice or impose large amounts of work on the projects in question. We achieve this by agreeing on standards and guidelines, building up collections of reusable drawing components, creating and maintaining powerful file format converters, sharing code and widget libraries, and establishing a shared "team identity".
I think it can definitely be done, especially if we can get more people involved in the various projects and efforts required to make it succeed. With this success in place, the success of the Linux Desktop will be certain.About the Author:
Bryce Harrington is one of the Inkscape project founders and a senior performance engineer at the Open Source Development Labs.
If you would like to see your thoughts or experiences with technology published, please consider writing an article for OSNews.
- "OSS consistency, Page 1/2"
- "OSS consistency, Page 2/2"