This file contains the differences between MNG-0.97 and MNG-0.97b, for the purposes of voting. There are four proposals: 1. To change "Repeat count" to "Iteration count" in the LOOP chunk specification, and "times to repeat" to "times to execute" in the description of the "Iteration max" field in the TERM chunk, to add a statement about representing infinity, and to add a definition of "iteration" in the terminology section. This is a minor proposal that can be handled by informal consensus. 2. To separates the "transparency" profile bit into "transparency", "semitransparency, and "background transparency", and adds discussion of "background transparency" to the BACK and FRAM chunk specifications. This is a proposal will require a formal vote. 3. To add a "stored objects" flag to promise that even of "complex MNG features" are present, it is not necessary to create object buffers. This proposal requires a formal vote. 4. To add JPEG-encoded alpha channels to JNG and Delta-PNG datastreams. Proposals 2 and 3 both add a "validity" flag to maintain backward compatibility of the simplicity profile. If it is zero, then the "background transparency" and "stored objects" flags do not make any promises if they are zero. This is not a separate proposal but is required for accomplishing either of the "background transparency" or "stored objects" proposals. Note: don't apply this diff to the *.txt file at Swrinde. It was made against a new *.txt file that I saved from Netscape 4.7 while viewing the mng-0.97-20000227-pdg-h20.html file. *** mng-0.97-20000228-pdg-h20.txt Tue Aug 22 21:26:06 2000 --- mng-0.97b-20000822-pdg-h20.txt Tue Aug 22 21:27:52 2000 *************** *** 390,396 **** abstract image or object An image whose pixels have a hidden representation, and which does not necessarily carry PNG or JNG chunk data. An image delta cannot be ! applied to an abstract image. All abstract objects are viewable. child, or child image An image produced by applying an image delta to a parent object. --- 396,403 ---- abstract image or object An image whose pixels have a hidden representation, and which does not necessarily carry PNG or JNG chunk data. An image delta cannot be ! applied to an abstract image. All abstract objects are viewable. Object ! 0 is always abstract, since it is never stored. child, or child image An image produced by applying an image delta to a parent object. *************** *** 459,464 **** --- 466,477 ---- frame. There is no interframe delay prior to the implicit background layer at the beginning of the animation nor after the final frame. + iteration + One cycle of a loop. In this document, as is customary among + mathematicians and computer programmers, the number of iterations of a + loop includes the first cycle. A loop can have zero iterations, which + means it is not executed at all. + layer A layer can be o A visible embedded image, located with respect to the frame *************** *** 496,506 **** loops can all be run once, JNG and Delta-PNG are not present, and certain MNG chunks are not present. Bit 0 of the MHDR simplicity profile must be 1, indicating that the profile is valid, and all other ! bits of the profile except possibly for bits 2 and 3 must be 0, ! indicating that "complex MNG features", JNG, and Delta-PNG are not ! present. Bits 2 and 3 can be 0 or 1, depending on whether "simple MNG ! features" and transparency are absent or present. MNG-LC is a proper ! subset of MNG. MNG-VLC A very-low-complexity version of MNG in which only image 0 is --- 509,519 ---- loops can all be run once, JNG and Delta-PNG are not present, and certain MNG chunks are not present. Bit 0 of the MHDR simplicity profile must be 1, indicating that the profile is valid, and all other ! bits of the profile except possibly for bits 2, 3, 6, 7, and 8 must be ! 0, indicating that "complex MNG features", JNG, and Delta-PNG are not ! present. Bits 2, 3, 6, 7, and 8 can be 0 or 1, depending on whether ! "simple MNG features" and transparency are absent or present. MNG-LC is ! a proper subset of MNG. MNG-VLC A very-low-complexity version of MNG in which only image 0 is *************** *** 507,516 **** permitted, loops can all be run once, JNG and Delta-PNG are not present, and certain MNG chunks are not present. Bit 0 of the MHDR simplicity profile must be 1, indicating that the profile is valid, and ! all other bits of the profile except possibly for bit 3 must be 0, ! indicating that "simple MNG features", "complex MNG features", JNG, and ! Delta-PNG are not present. Bit 3 can be 0 or 1, to indicate whether ! transparency is absent or present. MNG-VLC is a proper subset of MNG. object, object_id An image or a nonviewable basis object. The object_id is an unsigned --- 520,530 ---- permitted, loops can all be run once, JNG and Delta-PNG are not present, and certain MNG chunks are not present. Bit 0 of the MHDR simplicity profile must be 1, indicating that the profile is valid, and ! all other bits of the profile except possibly for bits 3, 6, 7, and 8 ! must be 0, indicating that "simple MNG features", "complex MNG ! features", JNG, and Delta-PNG are not present. Bits 3, 6, 7, and 8 can ! be 0 or 1, to indicate whether transparency is absent or present. ! MNG-VLC is a proper subset of MNG. object, object_id An image or a nonviewable basis object. The object_id is an unsigned *************** *** 677,682 **** --- 691,702 ---- The clipping boundaries of an object are determined by the DEFI chunk that introduced it, and can be changed by means of the CLIP chunk. + Additional information. + While not required by this specification, applications may wish to + store other information about the object, such as whether it is + eligible to be updated by block-alpha-addition, for error-checking + purposes. + 3.3. Object buffers An object buffer is created by the appearance of an embedded object in the *************** *** 693,698 **** --- 713,725 ---- be made available to the rest of the MNG datastream or be considered viewable after it has been processed. + When the "stored objects" flag (bit 9 of the simplicity profile) is 0 and + valid (i.e., bit 6 is 1 and bit 9 is 0), an object buffer need not be + created even when an embedded object with a nonzero object_id appears, since + the flag promises that the object buffer will never be used. There is no + requirement not to create an object buffer; no harm will be done except for + some unnecessary memory consumption. + Object buffer is viewable. Any object that points to a viewable object buffer can be displayed, but one that points to a nonviewable one cannot. Any attempt to do so *************** *** 839,847 **** (must be 0 in MNG-LC and MNG-VLC datastreams) bit 3: ! 0: transparency is absent or can be ! ignored. ! 1: transparency is present and is essential (critical) for proper display of the images. bit 4: --- 866,877 ---- (must be 0 in MNG-LC and MNG-VLC datastreams) bit 3: ! 0: Transparency is absent. No ! image in the datastream has ! transparency, or its transparency ! can be ignored and all images ! can be rendered as opaque. ! 1: Transparency is present and is essential (critical) for proper display of the images. bit 4: *************** *** 854,860 **** 1: Delta-PNG is present. (must be 0 in MNG-LC and MNG-VLC datastreams) ! bits 6-15: Reserved for public expansion. Must be zero in this version. bits 16-30: --- 884,924 ---- 1: Delta-PNG is present. (must be 0 in MNG-LC and MNG-VLC datastreams) ! bit 6: Validity flag for bits 7, 8, and 9 ! 0: The presence or absence of ! background transparency, stored ! objects, and semitransparency is ! unspecified. ! 1: Background transparency is ! expressed by bit 7, semitransparency ! by bit 8, and the presence of stored ! objects by bit 9. ! bit 7: ! 0: Background transparency is absent ! (i.e., the first layer fills the ! entire MNG frame with opaque pixels) ! or can be ignored. ! 1: Background transparency is present ! and is essential (critical) for ! proper display of the images. ! bit 8: ! 0: Semitransparency (i.e., an image ! with an alpha channel that has ! values that are neither 0 nor the ! maximum value) is present or can ! be dithered down to binary ! transparency. ! 1: Semitransparency is present and is ! essential (critical) for proper ! display of the images. Full alpha ! composition rather than dithering is ! required. ! bit 9: ! 0: Stored objects are not present. ! 1: Stored objects are present. ! (must be 0 in MNG-LC and MNG-VLC ! datastreams) ! bits 10-15: Reserved for public expansion. Must be zero in this version. bits 16-30: *************** *** 921,934 **** If the simplicity profile is nonzero, it can be regarded as a 32-bit profile, with bit 0 (the least significant bit) being a "profile-validity" ! flag, bit 1 being a "simple MNG" flag, bit 2 being a "complex MNG" flag, bit ! 3 being a "transparency" flag, bit 4 being a "JNG" flag, and bit 5 being a ! "Delta-PNG" flag. The upper 15 bits (except for the most significant bit, ! which must be zero) are available for private test or experimental versions, ! and the remaining bits are reserved for future MNG versions, and must be ! zero in this version. If a bit is zero, the corresponding feature is ! guaranteed to be absent, and if a bit is one, the corresponding feature may ! be present in the MNG datastream. When bit 1 is zero ("simple" MNG features are absent), the datastream does not contain the DEFI, FRAM, or global PLTE and tRNS chunks. --- 985,998 ---- If the simplicity profile is nonzero, it can be regarded as a 32-bit profile, with bit 0 (the least significant bit) being a "profile-validity" ! flag, bit 1 being a "simple MNG" flag, bit 2 being a "complex MNG" flag, ! bits 3, 7, and 8 being a "transparency" flags, bit 4 being a "JNG" flag, bit ! 5 being a "Delta-PNG" flag, and bit 9 being a "stored objects" flag. The ! upper 15 bits (except for the most significant bit, which must be zero) are ! available for private test or experimental versions, and the remaining bits ! are reserved for future MNG versions, and must be zero in this version. If a ! bit is zero, the corresponding feature is guaranteed to be absent, and if a ! bit is one, the corresponding feature may be present in the MNG datastream. When bit 1 is zero ("simple" MNG features are absent), the datastream does not contain the DEFI, FRAM, or global PLTE and tRNS chunks. *************** *** 948,965 **** if they are present they are not essential (or critical) for displaying the images. A MNG-LC (i.e., a "low-complexity MNG") datastream must have a simplicity ! profile with bit 0 equal to 1 and all other bits except possibly for bits 1 ! and 3 ("simple MNG" MNG features and transparency) equal to zero. If bit 4 ! (JNG) is 1, the datastream is a "MNG-LC with JNG" datastream. MNG-LC decoders are allowed to reject such datastreams unless they have been enhanced with JNG capability. A MNG-VLC (i.e., a "very low-complexity MNG") datastream must have a simplicity profile with bit 0 equal to 1 and all other bits except possibly ! for bit 3 (transparency) equal to 0. If bit 4 (JNG) is 1, the datastream is ! a "MNG-VLC with JNG" datastream. MNG-VLC decoders are allowed to reject such ! datastreams unless they have been enhanced with JNG capability. Encoders that write a nonzero simplicity profile should endeavor to be accurate, so that decoders that process it will not unnecessarily reject --- 1012,1059 ---- if they are present they are not essential (or critical) for displaying the images. + "Semitransparency is absent or can be dithered" means that if the MNG or PNG + tRNS chunk is present and any PNG or JNG image has an alpha channel, they + only contain the values 0 and the maximum (opaque) value, or that if other + values are present the decoding application is allowed to dither them down + to binary transparency. The "semitransparency" flag means nothing and must + be 0 if bit 6 is 0. + + "Background transparency is absent or can be ignored" means that the first + layer fills the entire frame with opaque pixels, or if any part of the first + layer is not filled with an opaque pixel, the application is free to fill it + with a color of its own choosing. Whatever is behind the first layer need + not show through, or it is not essential (or critical) that it do so. + + When "Background transparency" is present, the application is responsible + for supplying a background color or image against which the MNG background + layer is composited, and if the MNG is being displayed against a changing + scene, the application should refresh the entire MNG frame against a new + copy of the background layer whenever the application's background scene + changes. The "background transparency" flag means nothing and must be 0 if + bit 6 is 0. + + The "stored objects" flag is only useful when bit 2 is nonzero (i.e., + "complex MNG features" are present). This flag promises that even though + such features are present, it is never necessary to store an object buffer + for any object. An object attributes set is necessary for each object, + however. Therefore, the MOVE, CLIP, DISC, deterministic LOOP, partial CLON, + and immediately-displayed BASI chunk are permissible. The "stored objects" + flag means nothing and must be 0 if bit 6 is 0. + A MNG-LC (i.e., a "low-complexity MNG") datastream must have a simplicity ! profile with bit 0 equal to 1 and all other bits except possibly for bits 1, ! 3, 6, and 7 ("simple MNG" MNG features and transparency) equal to zero. If ! bit 4 (JNG) is 1, the datastream is a "MNG-LC with JNG" datastream. MNG-LC decoders are allowed to reject such datastreams unless they have been enhanced with JNG capability. A MNG-VLC (i.e., a "very low-complexity MNG") datastream must have a simplicity profile with bit 0 equal to 1 and all other bits except possibly ! for bits 3, 6, and 7 (transparency) equal to 0. If bit 4 (JNG) is 1, the ! datastream is a "MNG-VLC with JNG" datastream. MNG-VLC decoders are allowed ! to reject such datastreams unless they have been enhanced with JNG ! capability. Encoders that write a nonzero simplicity profile should endeavor to be accurate, so that decoders that process it will not unnecessarily reject *************** *** 983,989 **** contents are the first two or more of the following fields: Nest level: 1 byte (unsigned integer). ! Repeat count: 4 bytes (unsigned integer), range [0..2^31-1]. Termination condition: 1 byte (unsigned integer). --- 1077,1083 ---- contents are the first two or more of the following fields: Nest level: 1 byte (unsigned integer). ! Iteration count: 4 bytes (unsigned integer), range [0..2^31-1]. Termination condition: 1 byte (unsigned integer). *************** *** 2053,2058 **** --- 2147,2161 ---- each image appears. Otherwise, framing_mode=3 is identical to framing_mode=1. + When the background layer is transparent or does not fill the clipping + boundaries of the image layer, the application is responsible for + supplying a background color or image against which the image layer is + composited, and if the MNG is being displayed against a changing scene, + the application should refresh the entire MNG frame against a new copy + of the background layer whenever the application's background scene + changes (see the "background transparency" bit of the simplicity + profile). + Framing mode 4. When framing_mode=4, the background layer is displayed before each frame, i.e., after each FRAM chunk, with no interframe delay before *************** *** 2060,2065 **** --- 2163,2177 ---- elapsed before displaying the background layer. Otherwise, framing_mode=4 is identical to framing_mode=2. + When the background layer is transparent or does not fill the clipping + boundaries of the frame, the application is responsible for supplying a + background color or image against which the subframes are composited, + and if the MNG is being displayed against a changing scene, the + application should refresh the entire MNG frame against a new copy of + the background layer whenever the application's background scene + changes (see the "background transparency" bit of the simplicity + profile). + The subframe name must conform to the same formatting rules as those for a PNG tEXt keyword: It must consist only of printable Latin-1 characters and must not have leading or trailing blanks, but can have single embedded *************** *** 2470,2476 **** ticks, before repeating the animation. Iteration max: 4 bytes (unsigned integer). Maximum ! number of times to repeat the animation. The loop created by processing a TERM must always be treated by the decoder as if it were a cacheable loop, with iteration_min=1. --- 2582,2589 ---- ticks, before repeating the animation. Iteration max: 4 bytes (unsigned integer). Maximum ! number of times to execute the animation. ! Infinity is represented by 0x7fffffff. The loop created by processing a TERM must always be treated by the decoder as if it were a cacheable loop, with iteration_min=1. *************** *** 2996,3014 **** Alpha sample depth: 1 byte. ! 0, 1, 2, 4, 8, or 16. Alpha compression method: 1 byte. 0: PNG grayscale IDAT format. Alpha filter method: 1 byte. ! 0: Adaptive (see PNG spec). Alpha interlace method: 1 byte. ! 0: Not interlaced. The width, height, image_sample_depth, image_compression_method, and image_interlace_method fields are redundant because equivalent information --- 3109,3133 ---- Alpha sample depth: 1 byte. ! 0, 1, 2, 4, 8, or 16, if the Alpha ! compression method is 0 (PNG) ! 8, if the Alpha compression method ! is 8 (JNG). Alpha compression method: 1 byte. 0: PNG grayscale IDAT format. + 8: JNG 8-bit grayscale JDAA format. Alpha filter method: 1 byte. ! 0: Adaptive PNG (see PNG spec) or ! not applicable (JPEG). Alpha interlace method: 1 byte. ! 0: Noninterlaced PNG or sequential ! single-scan JPEG. The width, height, image_sample_depth, image_compression_method, and image_interlace_method fields are redundant because equivalent information *************** *** 3200,3206 **** either 8-bit or 16-bit quantization tables. All other JNG restrictions still apply. ! 5.1.3. IDAT JNG alpha data This chunk is exactly like the IDAT chunk in a PNG grayscale image, except that it is interpreted as an alpha mask to be applied to the image data from --- 3319,3325 ---- either 8-bit or 16-bit quantization tables. All other JNG restrictions still apply. ! 5.1.3. IDAT JNG PNG-encoded alpha data This chunk is exactly like the IDAT chunk in a PNG grayscale image, except that it is interpreted as an alpha mask to be applied to the image data from *************** *** 3222,3233 **** chunk and apply the alpha samples to the twelve-bit image that is contained in the JDAT chunks that follow the JSEP chunk. ! 5.1.4. IEND End of JNG datastream The JNG IEND chunk is identical to its counterpart in PNG. Its data length is zero, and it serves to mark the end of the JNG datastream. ! 5.1.5. JSEP 8-bit/12-bit image separator The JSEP chunk is empty. --- 3341,3364 ---- chunk and apply the alpha samples to the twelve-bit image that is contained in the JDAT chunks that follow the JSEP chunk. ! 5.1.4. JDAA JNG JPEG-encoded alpha data ! ! This chunk is exactly like the JDAT chunk in a non-progressive JNG 8-bit ! grayscale image, except that it is interpreted as an alpha mask to be ! applied to the image data from the JDAT chunks, when ! alpha_compression_method=8. The alpha channel, if present, can have only ! sample depth 8. The JDAA chunks can be interleaved with the JDAT chunks (see ! Recommendations for Encoders: JNG interleaving below). ! ! Like IDAT chunks, the JDAA chunks must precede the JSEP chunk, if the JSEP ! chunk is present, and are handled similarly. ! ! 5.1.5. IEND End of JNG datastream The JNG IEND chunk is identical to its counterpart in PNG. Its data length is zero, and it serves to mark the end of the JNG datastream. ! 5.1.6. JSEP 8-bit/12-bit image separator The JSEP chunk is empty. *************** *** 3257,3269 **** When cHRM, gAMA, iCCP, or sRGB are present, they provide information about the color space of the decoded JDAT image, and they have no effect on the ! decoded alpha samples from the IDAT chunks. Any viewer that processes the ! gAMA chunk must also recognize and process the sRGB chunk. It can treat it ! as if it were a gAMA chunk containing the value .45455 and it can ignore its ! "intent" field. The chunk copying and ordering rules for JNG are the same as those in PNG, ! except for the fact that JDAT and IDAT chunks can be interleaved. 6. The Delta-PNG Format --- 3388,3401 ---- When cHRM, gAMA, iCCP, or sRGB are present, they provide information about the color space of the decoded JDAT image, and they have no effect on the ! decoded alpha samples from the IDAT or JDAA chunks. Any viewer that ! processes the gAMA chunk must also recognize and process the sRGB chunk. It ! can treat it as if it were a gAMA chunk containing the value .45455 and it ! can ignore its "intent" field. The chunk copying and ordering rules for JNG are the same as those in PNG, ! except for the fact that the JDAT chunks and IDAT or JDAA chunks can be ! interleaved. 6. The Delta-PNG Format *************** *** 3485,3491 **** method, filter method, and interlace method need not be the same. If they are different, the child object inherits the new values, and the new values will be used in decoding the data in any subsequent IDAT ! chunks. The sample_depth value from the IHDR chunk is interpreted as a new value of alpha_sample_depth and is only used for decoding the IDAT data --- 3617,3624 ---- method, filter method, and interlace method need not be the same. If they are different, the child object inherits the new values, and the new values will be used in decoding the data in any subsequent IDAT ! chunks. Neither the parent object nor the delta object can have alpha ! samples that were carried in JPEG-encoded JDAA chunks. The sample_depth value from the IHDR chunk is interpreted as a new value of alpha_sample_depth and is only used for decoding the IDAT data *************** *** 3538,3543 **** --- 3671,3680 ---- compression method, filter method, and interlace method need not be the same. If they differ, the child object inherits the new values. + It is permitted to use JPEG-encoded JDAA chunks to convey the new alpha + data. If this is done, then the alpha channel of the object can no + longer be used as the parent for block-alpha-addition. + Block color replacement delta_type=6 is similar to delta_type=4 except that the alpha channel is not included in the IDAT pixels; the alpha channel is inherited from *************** *** 3652,3658 **** alpha channel is affected, if one is present. If the color_type has been promoted from indexed-color, the original bit depth is always considered to be 8. See the PNG specification [PNG] for further information on these ! filling methods. If the basis object contains data from the PNG bKGD chunk, this data must be promoted as well. If a grayscale object is being promoted to a truecolor --- 3789,3796 ---- alpha channel is affected, if one is present. If the color_type has been promoted from indexed-color, the original bit depth is always considered to be 8. See the PNG specification [PNG] for further information on these ! filling methods. Any alpha channel added in this manner is eligible to be ! updated by block-alpha-addition in this or a subsequent Delta-PNG. If the basis object contains data from the PNG bKGD chunk, this data must be promoted as well. If a grayscale object is being promoted to a truecolor *************** *** 3834,3845 **** location occupied by the IJNG chunk. The JHDR chunk can also be omitted when image_type=2 and the JNG datastream ! begins with a JDAT chunk. Note: Be sure that the first JDAT chunk precedes ! the first IDAT chunk. In this case, no IJNG chunk is required, either. The ! decoder must treat this datastream as though the JHDR chunk were present, ! immediately preceding the first JDAT chunk. If the first JNG chunk is not a ! JDAT chunk, then either the IJNG or JHDR must be present to introduce the ! JNG datastream. 6.1.10. DROP Drop chunks --- 3972,3983 ---- location occupied by the IJNG chunk. The JHDR chunk can also be omitted when image_type=2 and the JNG datastream ! begins with a JDAT or JDAA chunk. Note: Be sure that the first JDAT or JDAA ! chunk precedes the first IDAT chunk. In this case, no IJNG chunk is ! required, either. The decoder must treat this datastream as though the JHDR ! chunk were present, immediately preceding the first JDAT chunk. If the first ! JNG chunk is not a JDAT or JDAA chunk, then either the IJNG or JHDR must be ! present to introduce the JNG datastream. 6.1.10. DROP Drop chunks *************** *** 3884,3893 **** Chunk name: 4 bytes (ASCII text). Order type: 1 byte. 0: Anywhere. ! 1: After IDAT and/or JDAT. ! 2: Before IDAT and/or JDAT. 3: Before IDAT, but not before PLTE. 4: Before IDAT, but not after PLTE. etc. Critical chunk names must not appear in the ORDR chunk. The applier needs to --- 4022,4031 ---- Chunk name: 4 bytes (ASCII text). Order type: 1 byte. 0: Anywhere. ! 1: After IDAT and/or JDAT or JDAA. ! 2: Before IDAT and/or JDAT or JDAA. 3: Before IDAT, but not before PLTE. 4: Before IDAT, but not after PLTE. etc. Critical chunk names must not appear in the ORDR chunk. The applier needs to *************** *** 4065,4071 **** 2. MNG-LC with JNG, ! 3. MNG. On the other hand, a developer working on an application for storing multi-page fax documents might have no need for more than "MNG-VLC without --- 4203,4211 ---- 2. MNG-LC with JNG, ! 3. MNG with JNG, but without stored objects. ! ! 4. MNG. On the other hand, a developer working on an application for storing multi-page fax documents might have no need for more than "MNG-VLC without *************** *** 4174,4180 **** before deciding to proceed. MNG-compliant decoders must support JNG, but MNG-LC and MNG-VLC decoders are not required to support JNG. ! JHDR, JDAT, IDAT, JSEP, IEND All JNG critical chunks must be fully supported. All values of color_type, bit_depth, compression_method, filter_method and interlace_method must be supported (interlacing, as in PNG, need not --- 4314,4320 ---- before deciding to proceed. MNG-compliant decoders must support JNG, but MNG-LC and MNG-VLC decoders are not required to support JNG. ! JHDR, JDAT, IDAT, JDAA, JSEP, IEND All JNG critical chunks must be fully supported. All values of color_type, bit_depth, compression_method, filter_method and interlace_method must be supported (interlacing, as in PNG, need not *************** *** 4206,4212 **** MNG-compliant decoders are required to support Delta-PNG, but MNG-LC and MNG-VLC decoders are not. ! DHDR, PROM, IHDR, IDAT, IPNG, JHDR, JDAT, IJNG, JSEP, PLTE, tRNS, IEND, PPLT Must be fully supported. Bit 2 or bit 5 of the simplicity profile can be used to promise that none of these are present (because the DHDR chunk is absent). Bit 4 of the simplicity profile can be used to --- 4346,4353 ---- MNG-compliant decoders are required to support Delta-PNG, but MNG-LC and MNG-VLC decoders are not. ! DHDR, PROM, IHDR, IDAT, JDAA, IPNG, JHDR, JDAT, IJNG, JSEP, PLTE, tRNS, ! IEND, PPLT Must be fully supported. Bit 2 or bit 5 of the simplicity profile can be used to promise that none of these are present (because the DHDR chunk is absent). Bit 4 of the simplicity profile can be used to *************** *** 4282,4296 **** should replace the empty SAVE chunk with one containing the index. See above (Paragraph 4.4.1). ! 9.6. Interleaving JDAT and IDAT chunks When a JNG datastream contains an alpha channel, and the file is intended ! for transmission over a network, it is useful to interleave the IDAT and ! JDAT chunks. In the case of sequential JPEG, the interleaving should be ! arranged so that the alpha data arrives more or less in sync with the color ! data for the scanlines. In the case of progressive JPEG, the alpha data ! should be interleaved with the first JPEG pass, so that all of the alpha ! data has arrived before beginning the second JPEG pass. 10. Recommendations for Decoders --- 4423,4437 ---- should replace the empty SAVE chunk with one containing the index. See above (Paragraph 4.4.1). ! 9.6. Interleaving JDAT, JDAA, and IDAT chunks When a JNG datastream contains an alpha channel, and the file is intended ! for transmission over a network, it is useful to interleave the IDAT or JDAA ! and the JDAT chunks. In the case of sequential JPEG, the interleaving should ! be arranged so that the alpha data arrives more or less in sync with the ! color data for the scanlines. In the case of progressive JPEG, the alpha ! data should be interleaved with the first JPEG pass, so that all of the ! alpha data has arrived before beginning the second JPEG pass. 10. Recommendations for Decoders *************** *** 4651,4657 **** 13. Rationale ! This (incomplete as of version 0.96) section does not form a part of the specification. It provides the rationale behind some of the design decisions in MNG. --- 4792,4798 ---- 13. Rationale ! This (incomplete as of version 0.97) section does not form a part of the specification. It provides the rationale behind some of the design decisions in MNG. *************** *** 4686,4697 **** 14. Revision History ! 14.1. Version 0.97 Released 28 February 2000. Minor editorial changes only. A new example was added. ! 14.2. Version 0.96 Released 18 July 1999. The changes that are not simple editorial changes were approved by votes of the PNG Development group that closed 16 July 1999 --- 4827,4880 ---- 14. Revision History ! 14.1. Version 0.97b ! ! Proposed 22 August 2000 ! ! Added JPEG-encoded alpha channel in JNG and Delta-PNG datastreams, stored in ! a new JDAA chunk. This requires a formal vote. ! ! The meaning of the transparency flag (bit 2 of the simplicity profile) was ! restored to the meaning that it had in version 0.97. ! ! A "semitransparency" flag was added to the simplicity profile. This will be ! included in the vote on the "background transparency" flag. ! ! Revised the MNG-LC and MNG-VLC definitions to include the possibility of the ! two new transparency flags and the new validity flag being set. ! ! The discussion of handling a changing background scene was revised. ! ! References to "cdrom.com" were changed to "libpng.org". ! ! 14.2. Version 0.97a ! ! Proposed 21 August 2000 ! ! Changed "Repeat count" to "Iteration count" in the LOOP chunk specification, ! and "times to repeat" to "times to execute" in the description of the ! "Iteration max" field in the TERM chunk, and added a statement about ! representing infinity. This is a minor proposal that will be handled by ! informal consensus. ! ! Separates the "transparency" profile bit into "transparency" and "background ! transparency", and adds discussion of "background transparency" to the BACK ! and FRAM chunk specifications. This proposal requires a formal vote. ! ! Adds a "stored objects" flag to promise that even of "complex MNG features" ! are present, it is not necessary to create object buffers. This proposal ! requires a formal vote. ! ! Adds a "validity" flag to maintain backward compatibility of the simplicity ! profile. If it is zero, then the "background transparency" and "stored ! objects" flags do not make any promises. ! ! 14.3. Version 0.97 Released 28 February 2000. Minor editorial changes only. A new example was added. ! 14.4. Version 0.96 Released 18 July 1999. The changes that are not simple editorial changes were approved by votes of the PNG Development group that closed 16 July 1999 *************** *** 4744,4750 **** * Added the global bKGD and sBIT chunks. ! 14.3. Version 0.95 Initial public release, approved by the PNG Development Group on 11 May 1999. --- 4927,4933 ---- * Added the global bKGD and sBIT chunks. ! 14.5. Version 0.95 Initial public release, approved by the PNG Development Group on 11 May 1999. *************** *** 5542,5548 **** Document source ! This document was built from the file mng-master-20000228 on 22 August 2000. Copyright Notice --- 5725,5731 ---- Document source ! This document was built from the file mng-master-20000822 on 22 August 2000. Copyright Notice