In the API unit-tests, we're currently loading the `basicapi.pdf` before every sub-test in `PDFDocument` and `Page`, which slows down the unit-tests quite a bit.
Locally this patch reduces the run time for `gulp unittest` by at least 40% for me.
Some browsers render certain special characters with width 0, others with strictly positive width. (For example, the Greek Delta, Δ, has width 0 in Google Chrome, and a positive width in Firefox.) The `if` clause in operation so far results in different text layer DOM trees for different browsers.
This commit fixes that by adding the elements independently of their width.
Note that in the PDF files provided by the reporter, this issue was limited to `Rect` arrays in AcroForm entries (which we currently don't support).
However, since a bad PDF generator could create this problem in *any* kind of annotation, the reduced test-case included here uses a simple LinkAnnotation instead.
Fixes 7115.
According to "The table directory" under https://developer.apple.com/fonts/TrueType-Reference-Manual/RM06/Chap6.html#Directory, TrueType font tables should have `uint32` checksums.
This is something that I noticed, and was initially confused about, while debugging a TrueType issue.
As far as I can tell, the current (`int32`) checksums we use doesn't cause any issues in practice. However, I do think that this should be addressed to agree with the specification, and to reduce possible confusion when reading the font code.
This is regression from PR 7063, causing `gulp importl10n` to fail:
```
$ gulp importl10n
[19:45:02] Using gulpfile c:\Users\Jonas\Git\pdfjs\gulpfile.js
[19:45:02] Starting 'importl10n'...
Downloading ach...
[19:45:02] 'importl10n' errored after 4.42 ms
[19:45:02] Error: EEXIST, file already exists 'c:\Users\Jonas\Git\pdfjs\l10n\ach
'
at Error (native)
at Object.fs.mkdirSync (fs.js:747:18)
at downloadLanguageFiles (c:\Users\Jonas\Git\pdfjs\external\importL10n\local
es.js:59:8)
at next (c:\Users\Jonas\Git\pdfjs\external\importL10n\locales.js:90:5)
at Object.downloadL10n (c:\Users\Jonas\Git\pdfjs\external\importL10n\locales
.js:91:5)
at Gulp.<anonymous> (c:\Users\Jonas\Git\pdfjs\gulpfile.js:92:11)
at module.exports (c:\Users\Jonas\Git\pdfjs\node_modules\gulp\node_modules\o
rchestrator\lib\runTask.js:34:7)
at Gulp.Orchestrator._runTask (c:\Users\Jonas\Git\pdfjs\node_modules\gulp\no
de_modules\orchestrator\index.js:273:3)
at Gulp.Orchestrator._runStep (c:\Users\Jonas\Git\pdfjs\node_modules\gulp\no
de_modules\orchestrator\index.js:214:10)
at Gulp.Orchestrator.start (c:\Users\Jonas\Git\pdfjs\node_modules\gulp\node_
modules\orchestrator\index.js:134:8)
```
Pass the `PDFJS.postMessageTransfer` parameter to the worker, so that the `MessageHandler` can be setup correctly in `createDocumentHandler` (issue 6957)
Currently there's a lot of duplicate code for non-embedded `toFontChar`, which this patch simplifies by extracting the code into a helper function instead.
This patch adds a `getUnicodeForGlyph` helper function, which is used to recover Unicode values for non-standard glyph names.
Some PDF generators, e.g. Scribus PDF, use improper `uniXXXX` glyph names which breaks the glyph mapping. We can avoid this by converting them to "standard" glyph names instead.
Fixes https://bugzilla.mozilla.org/show_bug.cgi?id=1132849.
Fixes 6893.
Fixes 6894.
[PDFThumbnailView] Re-factor the `canvas` to `image` conversion such that we always render to a `canvas`, and then replace it with an `image` once rendering is done
