[CREATE] OpenRaster minimal implementation

[Martin Renold]

I'm not completely lacking response; there was some IRC discussion with
Øyvind and Cyrille in #create on Freenode.

My conclusion is that the the very minimal OpenRaster that MyPaint saves now
has no major flaws (opacity=255 has been removed) and should be loadable by
all future implementations.

The current loading code is unlikely to conform to the expected minimal
standard, but this can be fixed later (when another project starts saving
OpenRaster).

On Fri, Jan 02, 2009 at 03:29:54AM +0800, Jon Phillips wrote: 
> We could do some press around this too to help with uptake. What do you
> think?

I would wait a bit with that until discussions have died down again.

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

Yes.
Ideas for simple extensions exist, but that's for later.

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

I think so too. The question where the Core ends, and whether a second "High
Core" will be agreed upon that allows to drop pixbufs that would be required
for the normal "Core". Will applications be forced to implement nested
layers, layer modes, effect layers, text rendering, floating point pixel
formats, or will they be forced to save extra pixmaps for those features?

And if an advanced application has some nonstandard destructive effect on
top of everything (eg. heavy motion blur variant) there is no possibility to
save this as "Core" image without either reducing it to a single layer or
accepting different rendering in other apps. Giving the user a choice would
be nice, preferably at load time.

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

That's one open point: should an application keep the whole "not understood"
OpenRaster tree around and save it back as it is? That sounds difficult to
me; there would have to be a precise specification how to do manipulations
on rendered compatibility layers.

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

Yes. But (at the risk that I did not get your point) users will not trust
OpenRaster it if they can load some .ora files in every application and
others not. And they will not want to be educated about compatibility levels
when saving their work. IMO different compatibility levels must have
different file extensions.

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

Looks like always requiring "Core" compatibility would be the simplest
solution. More space-efficient file formats would have to be application
specific.

bye,
Martin