-
1999.06.04 03:45 "Re: Large File Support", by Frank Warmerdam
-
1999.06.07 13:00 "Re: Large File Support", by Rainer Wiesenfarth
- 1999.06.07 13:03 "Re: Large File Support", by Frank Warmerdam
- 1999.06.08 21:14 "Re: Large File Support", by Peter Smith
-
1999.06.07 13:00 "Re: Large File Support", by Rainer Wiesenfarth
- 1999.06.04 07:32 "Re: Large File Support", by Rob Tillaart
- 1999.06.04 18:35 "RE: Large File Support", by Bruce Forsberg
- 1999.06.10 09:48 "Re: Large File Support", by Klaus Bartz
- 1999.06.10 15:10 "Re: Large File Support", by Peter Smith
- 1999.06.14 11:16 "Re: Large File Support", by Martin Bailey
1999.06.10 16:56 "Re: Large File Support", by Chris Barker
1. An "standard api" won't prevent you from being compatible with the file using a non-standard api. But it would be a godsend to the folks who find their current implementation deficient and need to plug in another library. I was merely suggesting that a "standard api" be defined alongside the format, and a reference implementaion made. You could then conform to one of "TIFF64" and "T64API", both, or neither.
But this is a big opportunity. With a cleverly designed API (I happen to have one here...) it would be possible to plug other formats in at the back end, leaving the api unchanged. We could then get a little order out of all the chaos.
Of course, a binding for each supported language would be required, but I don't think its as big a deal as you make it out to be. With nearly all OSes supporting shared libraries, these have to be (by their nature) somewhat language independent.
As for being a "TIFF64" (or whatever) producer, you can be *that* with any libraries you care to write. I am suggesting the api bit for those who care to supply libraries (especially public domain ones).
I negelected to mention the important matter of a test suite (*very* important) which you have brought up. It should include a verifier.
--
========================================================================
Barker's law: For every inaction, there is an equal and opposite excuse.
Check out Interlinear's web page at http://www.ilt.com
========================================================================