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.
When a search term isn't found, the background color of the findInput is supposed to change (to red). This is currently not working as intended, because the CSS rule is not being applied correctly. (It seems that this broke in PR 2208.)
This patch also changes the background color to match the one used in the native Firefox findbar, since the old color seemed a bit too pink.
