Leonard Rosenthol wrote:
At 8:47 AM -0700 8/12/03, Nathan Carl Summers wrote:
This is what I mean by a standard that people can have confidence in --
people should trust that if their program writes good XCF's that a good
program will be able to read it.
Right!
If a program writes GOOD XCF...
As long as a program follows the rules, TIFF is compatible. If you
break the rules, all bets are off...
The difference is that TIFF is read and written by dozens of ad'hoc software
packages. Some use 'libtiff' - but most do not.
If you look at a format like PNG, hardly anyone reads and writes it using
their own code - almost everyone uses libpng - so there are no problems
with PNG compatibility.
So, I think what is needed to make a reliable file format is to provide
a well written library for reading and writing the files that's freely
available and properly maintained on every modern platform FROM DAY ONE.
If you then write in the specification document something like:
"You are strongly encouraged to use the standard file reading/writing
library rather than writing your own"
...then better still.
I don't think it matters very much how the format is specified. The
reliability and transportability of the resulting files depends mostly
on the quality of the support library.
Another problem with TIFF is that it's easy to extend. That sounds like
a good idea - there are ways to simply ignore tags that your program
doesn't understand - so how bad could that be?
Well, if you have programs that invent tags that say things like "What
follows is a block of pixels in MacPaint format", or "If this tag is
set, the pixels are stored bottom-to-top instead of top-to-bottom" - then
ignoring a tag you don't recognise results in a very screwed up image.
----
Steve Baker (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: sjbaker@xxxxxxxx http://www.link.com
Home: sjbaker1@xxxxxxxxxxx http://www.sjbaker.org
