This problem occurs in PostScript calculator functions in several PDFs we have encountered, changes include unit tests to cover both common LZW and this more uncommon scenario.

Description of the new Feature/Bugfix

The fix is really a simplification of the main decoding loop in LZWDecoder and detecting explicitly when there is no "oldCode", i.e. previous code. Hopefully the decode() method is slightly easier to follow now and supports this valid scenario where the LZW encoded data does not start with the Clear Table (256) special code.

Related Issue: #1298

Unit-Tests for the new Feature/Bugfix

Three unit tests were added:

• [LZWDecoderTest.shouldDecodeType4PSCalcFunction1 ] Highlights the problem with LZWDecoder producing garbled output before the fix
• [LZWDecoderTest.shouldDecodeType4PSCalcFunction2] Highlights another possible result of the same problem with LZWDecoder throwing a null exception before the fix
• [LZWDecoderTest.shouldDecodeCmapData] A standard LZW encoded data sample that worked before and needs to keep working! This is a CMap dictionary from a PDF stream that starts with the common Clear Table code.

Compatibilities Issues

No compatibility issues or changes to function signatures. Fix is internal to LZWDecoer.decode() method

Your real name

Scott More

Testing details

Nothing specific. All PDFs with LZW decode streams should work with no data corruption or exceptions now.