Alan Horkan

I decided to give gimp-sharp a try.
I used Ubun also because it is what is used by Travis CI (Continuous Integration) testing service offered at GitHub. It was not easy.

To summarize the final incantation needed is:
sudo apt-get install gimp mono-complete libgimp2.0-dev gtk-sharp2
git clone https://github.com/mrijk/gimp-sharp.git
autoreconf -i
./configure
make
sudo make install

I set up Travis CI to automate the process of installing gimp-sharp. Now that I've got it to install I need to see if it runs, and explore what it can do.

SK1 Print Design is an interesting project. They found the vector graphics program Sketch was useful to their business, and maintained their own customized version, eventually becoming a project all of their own. I'm not involved with SK1 Print Design myself but I do follow their newsfeed on Facebook, where they regularly post information about their work.

They have added import and export support for a variety of Colour Palettes, including SOC (StarOffice Colours, i.e. the OpenDocument standard used by OpenOffice.org and LibreOffice) and CorelDraw XML Palettes and more. For users who already have CorelDraw this should allow them to reuse their existing Pantone palettes.

They are also continuing their work to merge their SK1 and PrintDesign branches. The next release seems very promising.

Paint.net is a graphics program that uses its own binary file format .pdn that almost no other program can open. Paint.net has a large community and many plugins are available including a third part plugin that adds support for OpenRaster. Paint.net is written in C# and requires the Microsoft .Net runtime, meaning current versions work only on Windows Vista or later.

If you need to open PDN files without using Paint.net there is an answer! Lazpaint can open .pdn files and also natively supports OpenRaster. Laz paint is available on Windows, Linux and MacOS X.

In hindsight using Lazpaint would have been easier than taking a flat image and editing it to recreate the layer information I wanted. Although I respect the work done by Paint.net it is yet another example of time wasted and hassle caused by proprietary file formats and vendor lock-in.

I could be programming but instead today I am playing games and watching television and films. I have always been a fan of Tetris which is a classic, but I am continuing to play an annoyingly difficult game, that to be honest, I am not sure I even enjoy all that much, but it is strangely compelling. My interest in usability coincides with my interest in playability. Each area has their own jargon but are very similar, the biggest difference is that games will intentionally make things difficult. Better games go to great lengths to make the difficulties challenging without being frustrating, gradually increasing the difficulty as they progress, and engaging the user without punishing them for mistakes. (Providing save points in a game game is similar to providing an undo system in an application, both make the system more forgiving and the users allow users to recover from mistakes, rather than punishing and them and forcing them to do things all over again.)

There is a great presentation about making games more juicy (short article including video) which I think most developers will find interesting. Essentially the presentation explains that a game can be improved significantly without adding any core features. The game functionality remains simple but the usability and playability is improved, providing a fuller more immersive experience. The animation added to the game is not merely about showing off, but provides a great level of feedback and interactivity. Theme music and sound effects also add to the experience, and again provide greater feedback to the user. The difference between the game at the start and at the end of the presentation is striking, stunning even.

I am not suggesting that flashy animation or theme music is a good idea for every application but (if the toolkit and infrastructure already provided is good enough) it is worth reconsidering that a small bit of "juice" like animations or sounds effect could be useful, not just in games, in any program. There are annoying bad examples too but when done correctly it is all about providing more feedback for users, and helping make applications feel more interactive and responsive.
For a very simple example I have seen a many users accidentally switch from Insert to Overwrite mode and not know how not get out of it, and unfortunately many things must be learned by trial and error. Abiword changes the shape and colour of the cursor (from a vertical line to a red block) and it could potentially also provide a sound effect when switching modes. Food for thought (alternative video link at Youtube).

OpenRaster is a file format for layered images, essentially each layer is a PNG file, there is some XML glue and it is all contained in a Zip file.

In addition to PNG some programs allow layers in other formats. MyPaint is able to import JPG and SVG layers. Drawpile has also added SVG import.

After a small change to the OpenRaster plugin for The GNU Image Manipulation Program, it will also allow non-PNG layers. The code had to be changed in any case, it needed to at least give a warning that non-PNG layers were not being loaded, instead of quietly dropping them. Allowing other layer types was more useful and easier too.
(This change only means that other file types with be imported, they will not be passed through and will be stored as PNG when the file is exported.)

Summary: plugin updated to allow round-trip of paths.

The MyPaint team are doing great work, making progress towards MyPaint 1.2, I encourage you to give it a try, build it from source or check out the nightly builds. (Recent windows build Note: the filename mypaint-1.1.1a.7z may stay the same but the date of build does change.)
The Vector Layers feature in MyPaint is particularly interesting. One downside though is that the resulting OpenRaster files with vector layers are incompatible with most existing programs. MyPaint 1.0 was one of the few programs that managed to open the file at all, presenting an error message only for the layer it was not able to import. The other programs I tested, failed to import the file at all. It would be great if OpenRaster could be extended to include vector layers and more features but it will take some careful thought and planning.

It can be challenging enough to create a new and useful feature, planning ahead or trying to keep backwards compatibility makes matters even more complicated. With that in mind I wanted to add some support for vectors to the OpenRaster plugin. Similar to my previous work to round-trip metadata in OpenRaster I found a way to round-trip Paths/Vectors that is "good enough" and that I hope will benefit users. The GNU Image Manipulation Program already allows paths to be exported in Scalable Vector Graphics (SVG) format. All paths are exported to a single file, paths.svg and are imported back from that same file. It is not ideal, but it is simple and it works.

Users can get the updated plugin immediately from the OpenRaster plugin gitorious project page. There is lots more that could be done behind the scenes, but for ordinary users I do not expect any changes as noticeable as these for a while.


Back to the code. I considered (and implemented) a more complicated approach that included changes to stack.xml, where raster layers were stored as one group, and
paths (vectors layers) as another group. This approach was better for exporting information that was compatible with MyPaint but as previously mentioned, the files were not compatible with any other existing programs.

To ensure OpenRaster files that are back compatibility it might be better to always include a PNG file as the source for every layer, and to find another way to link to other types of content, such as text or vectors, or at some distant point in the future even video. A more complicated fallback system might be useful in the long run. For example the EPUB format reuses the Open Packaging Framework (OPF) standard, any pages can be stored in multiple formats, so long as it includes a fallback to another format, ending with a fallback to a few standard baseline formats (i.e. XHTML). The OpenRaster standard has an elegant simplicity, but there is so much more it could do.

Summary: plugin updated to allow round-trip of metadata.

OpenRaster does not yet make any suggestions on how to store metadata. My preference is for OpenRaster to continue to borrow from OpenDocument and use the same format meta.xml file, but that can be complicated. Rather than taking the time to write a whole lot of code and waiting do metadata the best way, I found another way that is good enough, and expedient. I think ordinary users will find it useful -- which is the most important thing -- to be able to round-trip metadata in the OpenRaster format, so despite my reservations about creating code that might discourage developers (myself included) from doing things a better way in future I am choosing the easy option. (In my previous post I mentioned my concern about maintainability, this is what I was alluding to.)

A lot of work has been done over the years to make the The GNU Image Manupilation Program (GIMP) work with existing standards. One of those standards is XMP, the eXtensible Metadata Platform originally created by Adobe Systems, which used the existing Dublin Core metadata standard to create XML packets that can be inserted inside (or alongside) an image file. The existing code creates an XMP packet, let's call it packet.xmp and include it in the OpenRaster file. There's a little more code to the load the information back in and users should be able to go to menu File, Properties and in Properties dialog go to the tab labelled Advanced to view (or set) metadata.

This approach may not be particularly useful to users who want to get their information out into other applications such as MyPaint or Krita (or Drawpile or Lazpaint) but it at least allows them not to lose metadata information when they use OpenRaster. (In the long run other programs will probably want to implement code to read XMP anyway, so I think this is a reasonable compromise, even though I want OpenRaster to stay close to OpenDocument and benefit from being part of that very large community.)

You can get the updated plugin immediately from the OpenRaster plugin gitorious project page.

If you are a developer and want to modify or reuse the code, it is published under the ISC License.

Thanks to developers Martin Renold and Jon Nordby who generously agreed to relicense the OpenRaster plugin under the Internet Software Consortium (ISC) license (it is a permissive license, it is the license preferred by the OpenBSD project, and also the license used by brushlib from MyPaint). Hopefully other applications will be encouraged to take another look at implementing OpenRaster.

[Edit: The code might possibly also be useful to anyone interested in writing a plugin for other file formats that use ZIP containers or XML. For example XML Paper Specification (XPS) JavaFX (.fxz and the unzipped .fxd), or even OpenDocument]

The code has been tidied to conform to the PEP8 style guide, with only 4 warnings remaining, and they are all concerning long lines of more than 80 characters (E501).

The OpenRaster files are also far tidier. For some bizarre reason the Python developers choose to make things ugly by default, and neglected to include any line breaks in the XML. Thanks to Fredrik Lundh and Effbot.org for the very helpful pretty-printing code. The code has also been changed so that many optional tags are included if and only if they are needed, so if you ever do need to read the raw XML it should be a lot easier.

There isn't much for normal users unfortunately. The currently selected layer is marked in the OpenRaster file, and also if a layer is edit locked. If you are sending files to MyPaint it will correctly select the active layer, and recognize which layers were locked. (No import back yet though.) Unfortunately edit locking (or "Lock pixels") does require version 2.8 so if there is anyone out there stuck on version 2.6 or earlier I'd be interested to learn more, and I will try to adjust the code if I get any feedback. [Edit: No feedback but I fixed it anyway, to keep the plugin compatible with version 2.6.]
I've a few other changes that are almost ready but I'm concerned about compatibility and maintainability so I'm going to take a bit more time before releasing those changes.

The latest code is available from the OpenRaster plugin gitorious project page. [Edit: ... but only until May 2015.]

Congratulations to Krita on releasing version 2.9 and a very positive write-up for Krita by Bruce Byfield writing for Linux Pro Magazine.

I'm amused by his comment comparing Krita to "the cockpit of a fighter jet" and although there are some things I'd like to see done differently* I think Krita is remarkably clear for a program as complex as it is and does a good job of balancing depth and breadth. (* As just one example: I'm never going to use "File, Mail..." so it's just there waiting for me to hit it accidentally, but far as I know I cannot disable or hide it.)

Unfortunately Byfield writes about Krita "versus" other software. I do not accept that premise. Different software does different things, users can mix and match (and if they can't that is a different and bigger problem). Krita is another weapon in the arsenal. Enjoy Krita 2.9.

OpenRaster Python Plugin

Early in 2014, version 0.0.2 of the OpenRaster specification added a requirement that each file should include a full size pre-rendered image (mergedimage.png) so that other programs could more easily view OpenRaster files. [Developers: if your program can open a zip file and show a PNG you could add support for viewing OpenRaster files.*]

The GNU Image Manipulation Program includes a python plugin for OpenRaster support, but it did not yet include mergedimage.png so I made the changes myself. You do not need to wait for the next release, or for your distribution to eventually package that release you can benefit from this change immediately. If you are using the GNU Image Manipulation Program version 2.6 you will need to make sure you have support for python plugins included in your version (if you are using Windows you wont), and if you are using version 2.8 it should already be included.

It was only a small change but working with Python and not having to wait for code to compile make it so much easier.

* Although it would probably be best if viewer support was added at the toolkit level, so that many applications could benefit.
[Edit: Updated link]