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