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)
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
In the PDF file in question, some of the 'name' table entries have `record.length === 0`. This becomes problematic in the non-unicode case, since `font.getBytes(0)` will fetch the *entire* stream.
Given that OTS rejects 'name' entries larger than `2^16`, this thus explain the sanitizer errors.
Fixes 7020.
Functionality wise, `ensureThumbnailVisible` is essentially just a shorthand for `scrollThumbnailIntoView`. (And note that `PDFViewer` doesn't implement a `ensurePageVisible` method.)
The only remaining usage of `PDFThumbnailViewer_ensureThumbnailVisible` is inside `PDFPresentationMode`, which introduces an otherwise unnecessary `PDFThumbnailViewer` dependency there.
We're already relying on the `presentationmodechanged` event, in various files, to track the state of Presentation Mode. Thus we can simply listen for that event in `PDFSidebar` too, and update the thumbnails if necessary.
*This is a follow-up to PRs 6299 and 6441.*
The patch also adds an option to `PDFThumbnailView`, that disables the canvas-to-image conversion entirely, which might be useful in the context of issue 7026.
The sidebar code has, except for minor fixes/additions (such as attachments), been largely untouch for years.
To avoid having a bunch of sidebar code sprinkled throughout viewer.js, this patch moves the sidebar code into a separate file (pdf_sidebar.js), similar to how most other functionality has been moved in the last few years.
Besides simply moving code around, this patch also has the added benefit that we now keep track of the sidebar state (not just opened/closed).
This now makes it possible to handle both `Preferences` *and* `ViewHistory` settings for the sidebar state in a cleaner way, preventing strange and confusing interactions between the two.
Changes `PDFOutlineView`/`PDFAttachmentView` to be initialized once, since we're always creating them, and refactor their `render` methods to instead pass in the `outline`/`attachments`.
For consistency with other "classes", the `PDFOutlineView`/`PDFAttachmentView` are renamed to `PDFOutlineViewer`/`PDFAttachmentViewer`.
Also, make sure that the outline/attachments are reset when the document is closed. Currently we keep the old ones around until the `getOutline`/`getAttachments` API calls are resolved for a new document.
Re: issue 7017.
This should prevent the error, but does not fix the broken rendering.
The rendering issues are caused by `svg.js` not supporting the various text rendering modes, in this case specifically "invisible" (as indicated in the console `Warning: Unimplemented method setTextRenderingMode`).
Compared to the canvas case, where we just ignore invisible text, a smarter solution is probably required for the SVG case. Since just ignoring invisible text in `svg.js` would mean that text-selection isn't possible.
To reduce code duplication, the initialization code now uses the `reset` method.
Also, this patch moves `charactersToNormalize` out of `PDFFindController`, since it seemed better suited to be a "constant".
Open http://www.puolustusvoimat.fi/wcm/61ba4180411e702ea19ee9e364705c96/luonnonmuonaohjelmalumo1985.pdf?MOD=AJPERES#pagemode=bookmarks.
Note how the outline looks entirely empty, but hovering over it you'll see that there are entries present. There's two separate issues here, first of all the fact that you cannot visually make out the outline items, and secondly that the lack of text means that the clickable area becomes too small.
In Adobe Reader this issue is somewhat mitigated, since they use an icon for every item. For PDF.js, the easist way to address this seems to be making use of a default title.
This issue should be *very* rare in practice, but given the simplicity of the solution I think that we should fix this.
