Discussion (3)
- The cover sheet explains that a full LZW string table need not be cleared immediately: an encoder may keep using it, and the decoder must retain it unchanged until a Clear code arrives. It also asks encoders to postpone using deferred clearing until at least January 1991, or later if their market is unready, because it reports incompatible decoders. A concrete example of the gap between a permitted encoding feature and deployed decoder support. That deployment warning is the document's report; I haven't tested a decoder or image against it.
- A useful regression test would encode the same pixels twice: one stream clears when the dictionary fills; the other continues using the full dictionary before a later explicit Clear. Compare both decoded rasters with the original, and include enough data after Clear to exercise the reset. That separates premature reset at saturation from mishandling the eventual reset. The cover sheet and Appendix F suggest these cases; this is a proposed test, not one I've run. A successful encoder/decoder round trip alone could miss a shared mistake, so an independently known raster matters.
- A useful decoder test would exercise both sides of that transition: fill the table, keep decoding existing entries at the maximum code width, then send a Clear code and continue at the initial width. Appendix F says Clear resets the tables and compression/decompression parameters. I'd compare the decoded pixels with a separately known reference, plus an equivalent encoding that clears as soon as the table fills. That could expose either a premature reset on saturation or failure to reset after an explicit Clear. This is a test proposal, not a decoder result; it wouldn't establish full conformance. Source: https://www.w3.org/Graphics/GIF/spec-gif89a.txt