For Arabic characters, the Unicode character codes are mapped to Unicode
character types using the character codes for indexing. However, the
character code 0x061D is undefined (and therefore invalid) in the
Unicode standard. The imported list does not contain this entry, but not
having it in the list breaks indexing for items after it. Therefore, put
an empty string on its position to make indexing work properly and issue
a warning in the unlikely event that we encounter this character.
This patch moves the user agent checks to the top of the file to reduce
duplication and to provide a clear overview of which user agent we are
detecting.
Moreover, we extract inline user agent checks as well and use existing
checks in more places. Finally, we fix the indenting in one place for
consistency.
*This patch fixes something that I noticed while debugging https://bugzilla.mozilla.org/show_bug.cgi?id=1308536.*
The PDF file contains a font called "NuptialScript", which unfortunately is not embedded. Since that is a non-standard font we will not be able to render it entirely correct. However, by adding "NuptialScript" to the `getNonStdFontMap`, we can at least improve the rendering slightly by using an italic (serif) fallback font.
This patch adds support for non-embedded Arial Black fonts, that use a `Arial-Black...` format for the font names.
Also, this patch changes `canvas.js` such that we always render Arial Black fonts with the maximum weight, which actually improves a number of existing test-cases. This should thus explain the test "failures", which are clear improvements compared with e.g. Adobe Reader.
Fixes 7835.
For consistency, I also renamed the `FIREFOX/MOZCENTRAL` sessionStorage key, but given that sessionStorage is a lot less permanent than localStorage it didn't seem necessary to migrate any existing values.
Fixes 7760.
Currently if you try to enable SVG rendering in the addons, a `TypeError` is thrown by the browser since we have code that depends on what `paintOnCanvas`/`paintOnSvg` (should) return.
For commands with with too few arguments, clear out `args` if it's an Array instead of replacing it with `null` in `EvaluatorPreprocessor_read` (issue 7804)
For `PartialEvaluator_getTextContent`, the same `args` Array should be re-used for every `EvaluatorPreprocessor_read` call. Hence we want to ensure that it's not accidentally replaced with `null` in `EvaluatorPreprocessor_read`, since otherwise corrupt PDF files (with too few arguments for certain commands) will cause errors in `PartialEvaluator_getTextContent`.
Perhaps a micro-optimization, but this patch also changes two `!args` comparisons to `args === null`, since that should be a tiny bit more efficient.
According to e.g. issue 7754, it appears that the current `isSafari` check is failing in newer version of the browser. Despite the fact that checking the userAgent is an anti-pattern, which should be avoided, it's currently the simplest solution.
By only allowing very specific type of `JavaScript` actions, and also utilizing the existing `URL` validation, this patch shouldn't pose too much risk.
Fixes one of the points in issue 3897 (with the PDF file taken from issue 3438).
Fixes https://bugzilla.mozilla.org/show_bug.cgi?id=843699 (probably, since that bug doesn't contain a test-case).
Given that the `customScaleOption` should already be hidden, provided that the browser supports that, this patch also prevents it from being accessible via the keyboard.
As far as my testing goes in various browsers, this doesn't seem to have any ill effects, and note that we're already explicitly ignoring the `custom` value in the `select` event handler.
Fixes https://bugzilla.mozilla.org/show_bug.cgi?id=1315608.
This patch resolves the responsiveness issues for the toolbar in the
viewer. Depending on the language (for example the Dutch language),
elements could overlap when the viewport size is reduced.
The main issue here is that the CSS rules are unnecessarily complex and
handle lots of different cases (LTR/RTL, displacements for specific
viewport widths, et cetera). By removing this complexity and letting the
browser handle the responsiveness, we not only get simpler CSS rules and
HTML mark-up, but the responsiveness issues are mostly fixed at the same
time. We no longer have to position the elements manually (by setting
their `left` attribute value) anymore.
It seems that certain bad PDF generators can create badly encoded "Prefix" entries for Page Labels, one example being http://ukjewishfilm.org/wp-content/uploads/2015/09/Jewish-Film-Festival-Programme-ONLINE.pdf.
Unfortunately I didn't come across such a PDF file while adding the API support for Page Labels, but with them now being used in the viewer I just found this issue. With this patch, we now display the Page Labels in the same way as Adobe Reader.
