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.
At the initialization of `Lexer_getObj` (in `parser.js`), there's a loop
that skips whitespace and breaks out whenever EOF is encountered.
(https://github.com/mozilla/pdf.js/blob/88ec2bd1a/src/core/parser.js#L586-L599)
Whenever the current character is not a whitespace character,
`ch = this.nextChar();` is used to find the next character
(using `return this.currentChar = this.stream.getByte())`).
The aforementioned `getByte` method retrieves the next byte using
(https://github.com/mozilla/pdf.js/blob/88ec2bd1a/src/core/stream.js#L122-L128)
var pos = this.pos;
while (this.bufferLength <= pos) {
if (this.eof)
return -1;
this.readBlock();
}
return this.buffer[this.pos++];
This piece of code relies on this.eof to detect whether the last character
has been read. When the stream is a `FlateStream`, and the end of the stream
has been reached, then **`this.eof` is not set to `true`**, because this check
is done inside a loop that does not occur when the read block size is zero:
(https://github.com/mozilla/pdf.js/blob/88ec2bd1ac/src/core/stream.js#L511-L517)
for (var n = bufferLength; n < end; ++n) {
if (typeof (b = bytes[bytesPos++]) == 'undefined') {
this.eof = true;
break;
}
buffer[n] = b;
}
This commit fixes the issue by setting this.eof to true whenever the loop is not
going to run (i.e. when bufferLength === end, i.e. blockLen === 0).