Achieving higher consistency between OSS graphics applications

Jozef Mak recently made a noteworthy proposal for achieving better integration of Open Source graphic applications, which has been positively received by the three communities he targeted: GIMP (for photo and image editing), Scribus (for desktop publishing), and Inkscape (for vector graphics editing). This has sparked a bit of discussion in our communities and brought up several ideas for improvement.

The ideas can be broken down into several distinct categories:
Standards, drawing element collections, format converters, and code
libraries. Each of these needs can be handled independently of each
other, and I think even if only a few could be achieved, it would
enhance the current situation considerably.

In addition, there have been several ideas around the theme of “shared
identity”, by which I mean the discussions about suites, merging, etc.
While I think many of these ideas are a bit too optimistically ambitious
to be realized in the near future, I think they hint at a desire among
the community for a “teammanship” approach between these projects.
Perhaps we can achieve this desire without having to undertake radical
changes to how the projects work.

Standards and Guidelines

The Open Source community thrives on standards. In Inkscape, we’ve
found the SVG spec to excel at helping us figure out interoperability
problems with other applications; we simply compare behaviors of the two
apps against the spec, and file a bug on whichever app isn’t following
it. Similarly, the GNOME HIG has been instrumental in settling
arguments over how the interface should look. We may disagree with the
standard, but hey, those are the rules. Processes exist to change the
rules, but until that happens we abide by them.

One idea for improving the interoperability and integration between Open
Source graphics applications is to establish some new standards and
guidelines. For example, a “guideline for artistic application keyboard
accelerators” could help address a huge number of the discrepancies
between the applications that users are noticing today, especially if it
also details the rationale for each binding. Path, text, and gradient
editing may be other areas where new guidelines could help.

It would be wise for any such standardization efforts be kept at a
desktop-system-neutral level. I.e., they should not be appended to the
GNOME or KDE interface guidelines, but kept independent of either. This
way, the work will be applicable to a wider range of projects, and thus
will help all of the Open Source applications we use. has been
working on a wide number of guidelines and standards that are highly
applicable to our projects. Perhaps as a starting point, we can work on
attaining and/or validating compliance to these specs between the
three programs.

These are just a handful of examples of’s work, so this
could be a very rich vein to tap. In addition, if there are areas we
need standards that have not yet been covered, perhaps we can encourage
investigation into those areas as well.

Drawing Element Collections

Probably the most powerful and effective ways of instilling a sense of
interoperability between open source graphics applications would be to
establish some shared collections of the low level elements they all use
for creating drawings:

  • Colors
  • Fonts
  • Gradients
  • Patterns
  • Symbols
  • Clipart
  • Filters

Presently, each Open Source drawing application essentially does its own
thing with its palettes, and with the exception of fonts and clipart
there is little sharing between them.

The Open Clip Art Library project may be a good model for how things
could work. OCAL was started by several Inkscape developers, but was
kept independent of Inkscape so other applications could benefit from
its work. The clipart is installed into a general location so it is
clearly considered a system resource like fonts. This project has also
included gradients and symbols, and possibly could be a good forum for
maintaining additional collections of drawing elements. They are
associated with, put out routine monthly releases, and
are already included in several Linux distros. If a few more of us
volunteer to help them with the technical side of things, I think OCAL
could be expanded to cover the range of items needed.

The next step would be to improve installation of these items. I.e.,
gradients should probably be located in /usr/share/gradients, rather
than as a subdir of the clipart package. I imagine some file hierarchy
standards could be beneficial to scope out where these items should be
installed on a Linux system, and how applications should access them.
Indexing is probably worth thinking about, since conceivably these
collections could get rather large.

From there would follow the work of both incorporating the palettes from
existing programs into shared collections, and implementing support for
these collections into programs that currently lack palette support.

For colors, there is a challenge in the fact that Pantone colors (the
colors that everyone wants) have strict IP restrictions on them.
Inkscape and Scribus have discussed this, but without a good solution.
I’m sure the GIMP folks have likewise mulled it over. It would be
wonderful if someone could figure out a system that would allow users to
be able to incorporate Pantone, without incurring the IP challenges onto
the applications themselves.

Format Converters

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 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

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 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’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

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.

“Shared Identity”

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.

Blue Sky

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.


  1. 2005-02-09 12:07 pm
  2. 2005-02-09 12:23 pm
  3. 2005-02-09 12:25 pm
  4. 2005-02-09 12:31 pm
  5. 2005-02-09 12:39 pm
  6. 2005-02-09 12:47 pm
  7. 2005-02-09 1:04 pm
  8. 2005-02-09 1:18 pm
  9. 2005-02-09 3:44 pm
  10. 2005-02-09 4:35 pm
  11. 2005-02-09 6:10 pm
  12. 2005-02-09 6:42 pm
  13. 2005-02-09 6:54 pm
  14. 2005-02-09 6:56 pm
  15. 2005-02-09 7:03 pm
  16. 2005-02-09 7:11 pm
  17. 2005-02-09 7:56 pm
  18. 2005-02-09 8:26 pm
  19. 2005-02-09 8:33 pm
  20. 2005-02-09 8:35 pm
  21. 2005-02-09 8:50 pm
  22. 2005-02-09 8:56 pm
  23. 2005-02-09 10:31 pm
  24. 2005-02-10 1:00 am
  25. 2005-02-10 1:25 am
  26. 2005-02-10 2:02 am
  27. 2005-02-10 2:07 am
  28. 2005-02-10 4:09 am
  29. 2005-02-10 6:05 am
  30. 2005-02-10 12:18 pm
  31. 2005-02-10 12:52 pm
  32. 2005-02-10 6:21 pm
  33. 2005-02-11 9:33 am
  34. 2005-02-11 1:42 pm
  35. 2005-02-14 8:04 pm