| AWARE [SYSTEMS] | Imaging expertise for the Delphi developer | |||||||
![]() |
TIFF and LibTiff Mailing List Archive | |||||||
LibTiff Mailing List
TIFF and LibTiff Mailing List Archive Contact
The TIFF Mailing List Homepage |
Thread2007.07.04 18:51 "Re: BigTIFF extension", by Toby ThainOn 4-Jul-07, at 3:13 PM, John Aldridge wrote: > Andrew Brooks wrote: >> On Wed, 04 Jul 2007 17:56:38 +0100, Kemp Watson >> <kemp@extelligence.net> wrote: >>> Besides, if a user tries to open a BigTIFF file with a regular >>> TIFF tool, they will need to get a BigTIFF tool no matter >>> what the file extension is. >> The real question here is what error message is presented? >> Obviously it will never be the best message: "This is a BigTIFF >> file, please upgrade to a version which supports BigTIFF". >> I would hope that the design of BigTIFF means that the messages >> are not simply "Cannot open. File is corrupt", but rather >> something like "file uses an unsupported compression algorithm". > > I think there's more to it than that... it's about arranging that > file-open dialogs offer an appropriate list of files. The advantage > of a changed suffix is that non-BigTIFF compliant applications can > offer > > TIFF files (*.tif,*.tiff) > > whereas ones which do support BigTIFF can offer > > TIFF files (*.tif,*.tiff,*.btf) > > and in each case the user is only offered those files which the > application can process. But only if BigTIFF is *never* named *.TIF. --Toby > _______________________________________________ > Tiff mailing list: Tiff@lists.maptools.org > http://lists.maptools.org/mailman/listinfo/tiff > http://www.remotesensing.org/libtiff/ |
|||||||