When decoding a stream, the decode buffer is often grown multiple times, its
byte size increasing like so: 512, 1024, 2048, etc. This patch estimates the
minimum size in advance (using the length of the encoded stream), often
allowing the smaller sizes to be skipped. It also renames numerous |length|
variables as |maybeLength| to make it clear that they can be |null|.
I measured this change on eight documents. This change reduces the cumulative
size of decode buffer allocations by 0--32%, with 10--20% being typical. This
reduces peak RSS by 10 or 20 MiB for several of them.
Now, it computes the numbers with only basic arithmetic operations, without first creating a string and then calling parseFloat.
The new function doesn't behave exactly the same as the old one.
In particular, the old behaviour was that when there was a number immediatly followed by an 'E', the 'E' was consumed. Now it's not. It allows for "glued" numbers and operators.
Also, the new function is faster and consumes less memory.
Do not throw exception when hex strings are in the wrong format
Currently pdf.js is throwing an exception for the following hex string:
`<7 0 2 15 5 2 2 2 4 3 2 4>`
The issue is that the 15 is not a valid hex character so pdf.js ends up
throwing an exception.
This diff changes the parser to process the above hex string as follow:
`70 21 55 2 24 32` (Note: the final 4 of the hex string is ignored)
replicating the behaviour of MuPDF, and doesn't throw an exception.
Tim van der Meij
Yury Delendik
Thorben Bochenek
Jonas Jenwald
Nicholas Nethercote
Mitar
Brendan Dahl
Ophir LOJKINE
Mack Duan
vyv03354
khodzha