Fix bug where too many content stream operands cause eternal loop

Once enough operands were push on top of the operand stack an
exception would be thrown. The exception handling ignored the
exception, printed a warning and continued processing the content
stream. Unfortunately the token was never consumed, so once the
interpreter retried parsing the stream it encountered the same token
again, causing the loop and thus a stack overflow. Now, make sure each
token is consumed before throwing a new exception thereby breaking the
eternal loop and letting pdfs with excessive operands be rendered,
albeit with both errors and a warning.

0 files changed, 0 insertions, 0 deletions