[CREATE] OpenRaster minimal implementation

[Jon Phillips]

Martin, I don't think anyone jumped on this email, but I'm all for
locking down the minimal core of OpenRaster. We could do some press
around this too to help with uptake. What do you think?

More below...

On Wed, 2008-12-24 at 18:12 +0100, Martin Renold wrote:
> hello,
> 
> I would like to finalize a minimal core of the OpenRaster
> specification
> around January.
> 
> The reason is that I have implemented layers in MyPaint, and since
> there is
> no plan to add all the heavy "image manipulation" features that other
> programs do better anyway, the users would greatly benefit if they
> could
> just open their images in GIMP/Krita/etc for postprocessing.
> 
> My requirements are much lower than where OpenRaster aims. I think it
> covers
> what Cyrille has called "OpenRaster / Long-term Archiving".

Yes.

> I see OpenRaster mostly as an export file format; I have no ambition
> to
> implement many new features just to be able to import all possible
> OpenRaster documents. The other way around, I think the consensus is
> that
> any MyPaint-only extensions (like per-stroke tablet event logs) should
> not
> be stored redundantly inside those documents?

Sounds like the long-term archiving should be implemented first, then
you should propose any extensions you want in th spec on this list IMO.

All, I'm curious how the multiple types of OpenRaster documents should
be handled. I think the file format should stay the same. Having
multiple formats puts burden upon user unduly in this case. Its not like
the use of this file format is that much different like presentation vs
spreadsheet as is the case with OpenOffice.org.

I think all apps should implement support for this (long-term archiving,
which we should call Core) spec, then have bitmap renders of any layer
or any feature requiring one of the other file formats or extensions.
Generally, anything on top of Core should appear the same, just without
the functionality. Also, the app that implements OpenRaster should
really have some warning in the app interface which states that certain
functionality is not present in opening or saving an OpenRaster file
that an application doesn't support.

Since we are using this Oo.o zipfile package, we need to define what
makes core, printing, etc. If we have default need for core
functionality and redundancy, then it should be easy for apps to make
this user notification about lack of support, right?

> Either way, for most MyPaint users this minimal OpenRaster should be
> good
> enough as their primary file format.
> 
> The OpenRaster specification draft in the wiki did cover all my needs
> (one
> PNG for each layer) except for the file layout. I have specified this
> in the
> wiki now, with a sample .ora file and a link to my (fully working)
> save/load
> implementation:
> 
> http://create.freedesktop.org/wiki/index.php/OpenRaster

This is great!

Also, looks like there are a bunch of comments on the wiki which need
attention as well:

http://create.freedesktop.org/wiki/index.php/OpenRaster/File_Layout_Specification

http://create.freedesktop.org/wiki/index.php/OpenRaster/Open_for_comments

> So - is this something that GIMP and Krita and other projects would be
> happy
> to load and stay compatible with as it is, when OpenRaster is
> implemented?

Pippin? Others?

> What is missing/wrong/incomplete?
> What should the mime type be?

Looks pretty good to me. Power to the implementor/committer!

> Should it have a different filename extension to distinguish itself
> from
> other OpenRaster formats?

I don't like this idea. I outlined above a solution which will allow us
to keep one format and support multiple features with redundancy.

Others?

Jon

> bye,
> Martin
> _______________________________________________
> CREATE mailing list
> CREATE at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/create
-- 
Jon Phillips 
http://rejon.org/
San Francisco + Beijing
GLOBAL +1.415.830.3884 - CHINA +86.1.360.282.8624
IM/skype: kidproto - Jabber: rejon at gristle.org
BIO http://rejon.org/bio - CV http://rejon.org/bio/cv