Different fonts can point to the same font descriptor
(see https://github.com/mozilla/pdf.js/issues/4339 for details). With this
commit such fonts are treated as aliases if they have also the same encoding
and the same toUnicode map. The according info is stored on the font descriptor.
This change must also ensure that aliases use always the same font name
because translated fonts can get cleared depending on the CLEANUP_TIMEOUT setting.
The following changes make putBinaryImageData 2.2x faster.
* Use a Uint32Array to draw whole pixels instead component by component
* Unroll the inner most loop
* Added lazy PDFJS.hasCanvasTypedArrays, PDFJS.isLittleEndian and compatibility
Uint32ArrayView for browsers using the old CanvasPixelArray
This makes the code much simpler, and the extra memory use is tiny -- a vanilla
1000 element array is only 4000 bytes larger than a Uint32Array of the same
size.
This is achieved by adding getBytes2() and getBytes4() to streams, and by
changing int16() and int32() to take multiple scalar args instead of an array
arg.
This reduces memory consumption for text heavy documents. I tested five
documents and saw hit rates ranging from 97.4% to 99.8% (most of the misses are
due to |width| varying even when |fontChar| matches). On two of those documents
I saw improvements of 40 and 50 MiB.
The patch also introduces the Glyph constructor, and renames the |unicodeChars|
local variable as |unicode| for consistency with the corresponding Glyph
property.
There is no need to slow down the inner loop with a test for ltp as it can only
change if prediction is true in which case it only changes in the outer loop.
Christian Krebs
Jonas Jenwald
fkaelberer
Yury Delendik
p01
Manas (prometheansacrifice)
Tim van der Meij
Thorben Bochenek
Nicholas Nethercote
Juraj Sukop