Fixes two issues:
- #4456 : The first 100 bytes are often not unique as they can be
filled with standard PDF headers - so we use the first 200 KB instead.
(This may be overkill)
- Some documents we encountered have invalid xref ids, which were
always coming out as ‘0000000000000000’ - so we detect that and use the
MD5 instead.
When submitting PR 5276 there wasn't a good PDF file to include in the test suite. However, with https://bugzilla.mozilla.org/show_bug.cgi?id=1108753, we now have a better source for a test file, hence this patch.
This is a tentative patch that adds *very* basic support for non-embedded Wingdings fonts (a Windows version of Dingbats), by falling back to the ZapfDingbats encoding. Obviously this approach will not work perfectly, but in my opinion it seems to work reasonably well in pratice.
Instead of this very simple patch, another option would be to try and include more complete glyph data for Wingdings, e.g. a Unicode map and glyph widths, similar to what was done for ZapfDingbats.
However there is, in my opinion, one important difference between Wingdings and ZapfDingbats: ZapfDingbats is part of the 14 standard fonts, which in previous versions of the PDF specification was assumed to be available in PDF readers. To improve compatibility with older files, it thus makes sense for us to include data for ZapfDingbats.
However Wingdings has never been a standard font in PDF files, hence PDF files using it *should* thus contain all the necessary font data.
Given the above, I thus believe that it should be OK to fall back to ZapfDingbats for now. If non-embedded Wingdings fonts turns out to be *a lot* more common, then we can revisit this later.
Fixes 4301 completely.
Fixes 4837 almost completely. With this patch the bullets are displayed correctly, but the arrows are not of the correct type.
Fixes `artofwar.pdf`, pages 14 and 15.
maskData comes out of maskCtx.getImageData, so is 0..255 clamped, and
the used multiplications will not create fractions needing rounding,
neither would addition.
This checks for both prefs on the understanding that we need to work on older versions of Firefox. If that isn't the case, the first part of the if isn't necessary. This should only land if bug 639134 is resolved - I'd make the patch part of that bug, but AIUI pdfjs's canonical repo is on github, so...
Currently if you manage to e.g. open the console (with <kbd>Ctrl</kbd>+<kbd>Shift</kbd>+<kbd>K</kbd>) before the viewer is initialized, the following will be printed in the console: `TypeError: pdfViewer is null`.
This doesn't cause any actual errors, but nevertheless it seems like something we should avoid.
Followup to PR 5413.
