Subject: RE: draft-ietf-fax-implementers-guide-06.txt

From: "McIntyre, Lloyd" <[email-masked]>
Date: Tue, 13 Mar 2001 09:28:59 -0800

Tamura-san,
Sorry for the lack of clarity.
I am saying that this is  not an important request.

The proposal is to create two subsections within Section 5.2.3:
5.2.3.1 Considerations for greater reader flexibility
        a,b,c,d,e and f (formerly b,c,e,g,h and i)

5.2.3.2 Error considerations 
        g,h,i,j,k,l,m,n,o,p,q,r and s   (formerly
a,f,j,k,l,m,n,o,p,q,r,s,and t) 

Regards,
Lloyd

> -----Original Message-----
> From: Hiroshi Tamura [mailto:[email-masked]]
> Sent: Monday, March 12, 2001 7:18 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]
> Subject: RE: draft-ietf-fax-implementers-guide-06.txt
> 
> 
> I am a little confused.
> 
> > > Are you proposing section 5.2 as the followings, except 
> for item d?
> > > Could you reply to me?
> > This is effectively correct. 
> 
> OK. But, you are saying:
> 
> > This is only a cosmetic comment -> The items in Section 5.2 could be
> > organized so as to create two groups - items for which the 
> reader is being
> > advised to be more flexible and those which an error 
> response may be more
> > appropriate. Example current b,c,e,g,h and i encourage 
> greater flexibility
> > while a,f,j,k,l,m,n,o,p,q,r,s,and t tend to encourage an 
> error.  One could
> > reorganize so that b,c,e,g,h and i are not a,b,c,d,e and f 
> and listed under
> > recommended increased flexibility while 
> a,f,j,k,l,m,n,o,p,q,r,s,and t would
> > g,h,i, -----
> 
> I do not see the above.
> 
> Are you proposing the following two new section ?
> one section that includes b,c,e,g,h and i
> the other section that includes a,f,j,k,l,m,n,o,p,q,r,s,and t
> If so, what are the new section's title?
> 
> If "Cosmetic" is not so important, I would like the following,
> except for item d for that we need Mike confirmation.
> 
> Could you please clarify for my *editing* ?
> 
> Regards,
> 
> > > 
> > > > 5.2 Precautions for implementers of RFC 2301 [4]
> > > > 
> > > > 5.2.1 Errors encountered during interoperability testing
> > > > 
> > > >    The TIFF/RFC 2301 [4] errors listed below were 
> encountered during
> > > >    interoperability testing and are provided so that 
> implementers of
> > > >    TIFF readers and writers can take precautionary measures.
> > > > 
> > > >    a) Although Profile S of TIFF-FX [4] specifies that 
> files should
> > > >       be in little-endian order, during testing it was 
> found that
> > > >       some common TIFF writers create big-endian files.  If 
> > > possible,
> > > >       the TIFF reader should be coded to handle 
> big-endian files.
> > > >       TIFF writers should always create little-endian 
> files to be
> > > >       compliant with the standard and to allow 
> interoperation with
> > > >       memory-constrained devices.
> > > > 
> > > >    b) Bytes 0-1 of the Image File Header are supposed to be 
> > > set to "II"
> > > >       (4949h) or "MM" (4d4dh) to indicate the byte order. During
> > > >       testing, other values were encountered.  Readers 
> should handle
> > > >       cases where the byte order field contain values other 
> > > than "II"
> > > >       or "MM", and writers should ensure the correct 
> value is used.
> > > > 
> > > > 5.2.2 Color Gamut Considerations
> > > >  
> > > >    The ITULAB encoding (PhotometricInterpretation = 10) 
> > > allows choosing
> > > >    a gamut range for L*a*b* (see the TIFF field Decode), 
> > > which in turn
> > > >    provides a way to place finer granularity on the 
> integer values
> > > >    represented in this colorspace.  But consequently, 
> an inadequate
> > > >    gamut choice may cause a loss in the preservation of 
> colors that
> > > >    don't fall within the space of colors bounded by the 
> > > gamut.  As such,
> > > >    it is worth commenting on this.
> > > >  
> > > >    The ITULAB default gamut, L [0,100] a [-85,85] b 
> > > [-75,125], was chosen
> > > >    to accommodate most scan devices, which typically 
> acquire from a
> > > >    hardcopy source. It wasn't chosen to deal with the 
> range of color
> > > >    from camera input or sRGB monitor data.  In fact, when 
> > > dealing with
> > > >    images from the web and other display oriented 
> sources, the color
> > > >    range for scanned hardcopy may likely be inadequate. It 
> > > is important
> > > >    to use a gamut that matches the source of the image data.
> > > >  
> > > >    The following guidelines are recommended:
> > > >    1. When acquiring input from a printed hardcopy 
> source, without
> > > >       modification, the ITU-T Recommendation T.42 default 
> > > ITULAB gamut
> > > >       should be appropriate. 
> > > >    2. For an sRGB source the ITU-T Recommendation T.42 
> > > default ITULAB
> > > >       gamut is not appropriate. A more appropriate gamut to 
> > > consider is:
> > > >       L [0,100], a [-88,99] and b [-108.8,95.2]. These may be
> > > >       realized by using the following Decode values for 
> 8-bit data:
> > > >       (0/1, 100/1, -22440/255, 25245/255, -27744/255, 
> 24276/255). 
> > > >    3. If the range of L*a*b* value can be precomputed 
> > > efficiently before
> > > >       converting to ITULAB, then you may get the best 
> > > result by picking
> > > >       a gamut that is custom to this range.
> > > > 
> > > > 
> > > > 5.2.3 Fileformat Considerations
> > > > 
> > > >    TIFF-FX implementers should make sure that:
> > > > 
> > > >    a) Readers only accept files with bytes 2-3 of the Image 
> > > File Header
> > > >       equal to 42 (2Ah), the "magic number", as being 
> valid TIFF-FX
> > > >       files, while writers only generate files with the 
> appropriate
> > > >       magic number.
> > > > 
> > > >    b) Readers are able to handle cases where IFD offsets 
> > > point beyond
> > > >       the end of the TIFF-FX file, while writers ensure the 
> > > IFD offset
> > > >       does not point beyond the end of the file.
> > > > 
> > > >    c) Readers are able to handle the first IFD offset being on a
> > > >       non-word boundary, while writers ensure that the 
> > > first IFD offset
> > > >       is on a word boundary.
> > > > 
> > > >    d) Readers and writers should be careful to 
> correctly handle IFDs
> > > >       with other TIFF profile data such as strip image data and
> > > >       header data.
> > > > 
> > > > --> I am not clear as to what is being said by this item, 
> > > please clarify.
> > > > 
> > > >    e) Readers are flexible and able to accommodate: IFDs 
> > > that are not
> > > >       presented in ascending page order; IFDs that are not 
> > > placed at a
> > > >       location that precedes the image which the IFD 
> > > describes; nextIFD
> > > >       offsets that precede the current IFD, the current 
> IFDs' field
> > > >       data, or the current IFDs' image data. Writers on the 
> > > other hand
> > > >       should generate files with IFDs presented in 
> > > ascending page order;
> > > >       IFDs placed at a location that precedes the image 
> > > which the IFD
> > > >       describes; the next IFD should always follow the 
> > > current IFD and
> > > >       all of its data.
> > > > 
> > > >    f) Files are not generated with missing field entries, 
> > > and readers reject
> > > >       any such files.
> > > > 
> > > >    g) Writers generate tags with the appropriate type 
> of data (for
> > > >       example RATIONAL instead of SRATIONAL). Readers 
> are flexible
> > > >       with those types of misrepresentations that may be readily
> > > >       accommodated (for example SHORT instead of LONG) 
> and lead to
> > > >       enhanced robustness.
> > > > 
> > > >    h) The appropriate count is associated with the tags 
> (it is not 0
> > > >       and matches the tag requirement) while readers are 
> > > flexible with these
> > > >       types of misrepresentations, which may be readily 
> > > accommodated and
> > > >       lead to enhanced robustness.
> > > > 
> > > >    i) Tags appear in the correct order in the IFD and 
> readers are
> > > >       flexible with these types of misrepresentations.
> > > > 
> > > >    j) The PageNumber value is based on the order within the 
> > > Primary IFD
> > > >       chain. The ImageLayer values are based on the 
> layer order and
> > > >       the image order within the layer respectively. 
> > > Readers may reject
> > > >       the pages where the PageNumber or ImageLayer values 
> > > are not consistent
> > > >       with the number of Primary IFDs, number of layers 
> or number of
> > > >       images within the layers.
> > > > 
> > > >    k) Tags are unique within an IFD and readers may reject 
> > > pages where this
> > > >       is not the case.
> > > > 
> > > >    l) Strip data does not overlap other file data and 
> the reader may
> > > >       error appropriately.
> > > > 
> > > >    m) The strip offset does not point outside the file, 
> under these
> > > >       conditions readers may reject the page where this 
> is the case.
> > > > 
> > > >    n) The strip offset + StripByteCounts does not point 
> outside the
> > > >       file, under these conditions the reader may error 
> > > appropriately.
> > > > 
> > > >    o) Only one endian order is used within the file 
> otherwise the
> > > >       rendered file will be corrupted.
> > > > 
> > > >    p) Tag values are consistent with the data contained 
> within the
> > > >       image strip. For example, a bi-level black mark on white
> > > >       background image strip with PhotometricInterpretation 
> > > tag value
> > > >       of "1" (bit value of "0" means black) will result in 
> > > rendering of
> > > >       the image as white marks on a black  background 
> > > (reverse video).
> > > > 
> > > >    q) For the special color spaces (ITULAB, YCBCR, CMYK), 
> > > the parameters
> > > >       used for transformations are correct and 
> compliant with the
> > > >       specification.
> > > > 
> > > >    r) The XPosition and YPosition values are consistent with the
> > > >       horizontal and vertical offsets of the top-left of 
> > > the IFD from
> > > >       the top-left of the Primary IFD, in units of the 
> > > resolution. To do
> > > >       otherwise results in misplacement of the rendered image.
> > > > 
> > > >    s) All combinations of tag values are correct, with 
> > > special attention
> > > >       being given to the sets: XResolution, YResolution and
> > > >       ImageWidth; PhotometricInterpretation, 
> SamplesPerPixel, and
> > > >       BitsPerSample. Any appropriate combinations will 
> > > likely result in
> > > >       image distortion or an inability to render the image.
> > > > 
> > > >    t) The appropriate Compression types are used for the 
> > > image layers
> > > >       within a Profile M file, such as a bi-level coder 
> for the mask
> > > >       layers (i.e. odd numbered layers) and multi-level 
> > > (color) coders
> > > >       for the background and foreground layers. Readers 
> > > should reject
> > > >       files where this is not true.
> > > > 
> > > > 
> > > > ***********************************************
> > > > Lloyd McIntyre        [email-masked]
> > > > Xerox Corp., Xerox Architecture Center
> > > > 3400 Hillview Ave. Bldg. 1
> > > > Palo Alto, CA 94304
> > > > Tel: +1 650 813 6762   fax: +1 650 813 6860
> > > > ***********************************************
> > > 
> > > Regards,
> > > --
> > > Hiroshi Tamura, Ricoh Company, LTD.
> > > E-mail: [email-masked]
> > > 
> 
> --
> Hiroshi Tamura, Ricoh Company, LTD.
> E-mail: [email-masked]
>