Q. Does Dosadi support 'Wang TIFF' Files?
A. To a limited extent: We can read many such files. We don't write them.
These are aberrant TIFF files written by a module which was originally created by Wang Laboratories Inc (Wang Labs). Kodak acquired the library from Wang and distributed it under the name Kodak Imaging for Windows, later eiStream and today Global360 Imaging for Windows.
The code was licensed by Microsoft first from Wang and then from Kodak, and freely distributed as (Microsoft) Imaging for Windows with most (all?) versions of Windows prior to XP, apparently without any effort to either document or correct its defects. See background below.
These files do not conform to any version of the TIFF specification, not even the repudiated/superceded TIFF 6.0. Dosadi engineering has devoted hundreds of hours to trying to read these files, with partial success - many such files can be read, there always seem to be some that cannot.
As a matter of policy, we decline to create files in this format.
If you have examples of TIFF files that Dosadi software cannot read, please contact Dosadi Support with a sample and we will be happy to evaluate them.
Why This Problem Exists: Thank You Microsoft.
Date: Wed, 11 Sep 1996 01:52:58 -0400
From: Tom Lane <tgl@sss.pgh.pa.us>
To: tiff@sgi.com
Subject: Microsoft is pushing old-style TIFF/JPEG
Microsoft is pushing some "Imaging Software for Windows 95" developed by
Wang. In fact, they're giving it away free: see
http://www.microsoft.com/windows/software/img_us.htm
and the associated press release contains some big talk about setting
the standards for the document imaging industry.
I don't use W95, but examination of the sample image available from that
page told a sad tale. It's TIFF/JPEG, compression tag 6 --- that is, JPEG
per TIFF 6.0, not per TIFF Tech Note #2. Actually, it's not even
compliant with the unambiguous parts of the TIFF 6.0 spec (details below).
Just to add insult to injury, Microsoft is apparently pushing TIFF/JPEG as
a suitable format for black and white fax-type images ... at least, that's
what this sample file is, and that's what the press release mostly talks
about. As best I can tell, this file would've been about a factor of 5
smaller as TIFF G3, and lossless to boot.
If they actually push this software seriously, and achieve any kind of
market penetration, we can pretty much kiss goodbye any hope that TIFF
Tech Note #2 will become the standard way of storing TIFF/JPEG.
I think I'll go cry in my beer now.
regards, tom lane
organizer, Independent JPEG Group
PS: The sample file violates TIFF 6.0 Section 22 in at least three ways:
1. It contains JPEGInterchangeFormat and JPEGInterchangeFormatLength tags,
but the file does *not* contain a valid JPEG datastream. In fact these
two tags are set to point to an area, just in front of the first strip,
that includes only the JPEG header markers (SOI, a COM marker, DQT, SOF0,
DHT ... but not SOS for some reason).
2. Even if one ignores the given length and tries to read the rest of the
file as JPEG interchange data, one will fail. It appears that at the
inter-strip boundaries, the data is padded to byte boundaries without
inserting any restart markers. This is a plausible interpretation of
6.0's rather vague description of strip boundary handling, but the result
is certainly not a pure JPEG-compatible datastream, so
JPEGInterchangeFormat should've been omitted.
3. The first StripOffset pointer points to the SOS marker, not to the
start of encoded data, in direct contradiction to p. 103 of the spec.
So, totally aside from any hope of TIFF Tech Note #2 compatibility,
this file would not even be readable by any arguably correct
implementation of the TIFF 6.0 spec. *Sigh*. This is a black day
for standards.