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 _______________________________________________ CREATE mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/create
