[CREATE] Re: Open File Format for Raster/Bitmaps Graphics

[Boudewijn Rempt]

>> * Layerdata in an extensible set of colorspaces (the list of colorspaces in 
>> e.g. /usr/include/icc34.h is not enough. Krita already goes beyond that.)
>> * Composition operations (maybe this list can be exhaustive)
>
> Be sure to be very explicit about the math used for each mode, and any
> mapping between these modes and modes from other formats.  

Yes, good point. We run into this at the moment already, of course, with psd
or xcf import.

> > * Layer states (locked, visible, etc)
> > * Paths (the gimp uses svg here, right? That should suffice for all 
purposes)
> 
> SVG is a huge spec (and references a huge number of other specs) and
> covers most of what this format you are describing can do itself.
> Including it as a path format is overkill and would make it trivial to
> write files that no two programs could render the same way.  Is there
> even a fully complaint SVG renderer in existence?

I'm not sure, but I would prefer to reuse what has already been proven. I'm 
not sure about the Gimp using svg for this -- but I am sure that at one point 
in time, Krita will be able to interleave Karbon (which saves as OpenDraw, 
which is some kind of weird svg, or so Rob Buis tells me) objects with its 
own layer data.

> If you want to use svg like constructs make a micro format that defines
> path elements the same way as a specific version of svg spec and give a
> trivial example how to convert it to svg, hopefully then you can avoid
> including all of CSS DOM ECMAScript etc. as part of your specification.

Something to keep in mind. Does anyone know what the Gimp's approach is?

> Making generic container formats quickly runs into a couple of problems.
> One is that parts of the file will quickly get out sync with other parts
> (especially metadata) try to be very explicit about what to do with
> metadata that the program doesn't understand.

This is handled by OpenDocument already. Krita at the moment can already embed 
KWord, KSpread etc. Now this is something that other application could safely
disregard and drop. My aim is interfachne to the capabilities of the receiving 
application. There will always be things that cannot be exchanged. As long as 
they, per OpenDocument standard, are not dropped on saving back, it's fine 
with me.

> Another is similar to the one above with svg.  You end up with files
> that nothing but the program that wrote the file can render and
> interchange becomes problematic.  This isn't easy to solve but it might
> be a good thing to have a very public way for applications to provide
> extension documents.  Both so that compliance with the main
> specification means something and so that people know where to look for
> information on what an application is doing.  Something as simple as
> requiring extended formats to include a URL to a public specification
> to be considered valid might go a long way.

> In my view is is better for a spec to be very strict well defined and
> easy to comply with than it is to try handle every imaginable case.  The
> bar you are setting for someone to implement this format from scratch is
> pretty high when you consider all the list above zip, xml, ICC etc.
> and here are already a lot of raster formats that act as containers out
> there.  Many of them aren't in wide use because they are too broad or
> poorly defined.  Don't compound the problem by trying to be too
> flexible.

 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/create/attachments/20060322/be79a3f3/attachment.pgp