On Monday 16 June 2008, Øyvind Kolås wrote: > > After all it might appear like a feature, to check for strict or > > lazy following the OpenRaster specification. > > There already has been discussions about various levels of confrmance > or strictness. This is more about which core functionality is used,
The way I see OpenRaster is more like a toolkit to build raster file format. But as far as, Open Raster (long-term) Archiving is concerned, only the core functionnality are allowed, and for extension (like filters not available in the core), then providing a rendered version of the filter will be *mandatory*. That said, I have started a list of filters I would like to see in version "1.0" of core filters : http://create.freedesktop.org/wiki/index.php/OpenRaster/Effects_Specification (it's mostly the list of SVG filters plus a few addition). > the representation of the buffers (additional files stored along the > .xml) etc. It is for instance very likely that GEGL will not use > OpenRaster files with .png's .jpg's or .exr's when saving natively but > use some of the same technologies using it's internal GeglBuffer > on-disk representation. But I would love to see those buffer standardized as well (even if they are not part of ORA). I am pretty sure users would want to import GEGL-variant OpenRaster files in Krita as well (and possibelly the other way arround too), even if it's not the preferred way for interoperability. -- Cyrille Berger _______________________________________________ CREATE mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/create
