On Wed, Aug 13, 2003 at 08:32:00PM -0300, Joao S. O. Bueno wrote:
| But on this new thread were proprietary formats batle along with mutant
| ideas, here I go:
| Why not settle for a Postscript subset?
PostScript is a proprietary format controlled by Adobe. Adobe has several
patents on various aspects of the PostScript format any implementation
would be affected by.
| The major one, of course, is that the file would be essentialy "auto
| renderable" - no need of GIMP, neither of any other program, to get it
This is a good idea, but it would also mean GIMP would have to read back
a PostScript file. PostScript is a huge standard outside the scope of an
application such as the GIMP.
Developers would have to put in kludges and special comments which'll help
them represent structures which cannot be natively represented using
PostScript. Isn't this just as expensive as implementing a new
What's more easier?
A> Have a native file format designed for the GIMP. Those who want to use it
with PostScript aware applications export the native format using a
plug-in. If XML is used for the underlying data representation, any
XML parser can be used to parse information, especially information
such as the author of an image, size and colour depth of the image, etc.
B> Use a subset PostScript as the native file format. Design
and implement representation of unrepresentable structures in
PostScript comments. Implement a PostScript parser (which is as good
as a stack based interpreter).
| Since PSD and TIFF are used by ADOBE, ADOBE also has a program that
| makes use of postscript subsets.. I just do not remember which file type
| it is.
| It can have color profiling support - it is on the specifications. It
| has support for multiple compression standards... (ok, maybe you have to
| encode the decompressor algorithm inside the file as well if you want
| something too different)
Support for multiple compression algorithms can be implemented in an XML
based format. One can also have data in other image formats such as TIFF,
PNG or even the same GIMP native format itself embedded as CDATA, or the
file format may be an archive of associated images, etc.
The features implemented depend on how far developers want to take the new
file format. The developers themselves are capable of doing what they
Gimp-developer mailing list