`__pdfjsdev_webpack__` was used to skip evaluating part of an AST,
in order to not mangle some `require` symbols.
This commit removes `__pdfjsdev_webpack__`, and:
- Uses `__non_webpack_require__` when one wants the output to
contain `require` instead of `__webpack_require__`.
- Adds options to the webpack config to prevent "polyfills" for
some Node.js-specific APIs to be added.
- Use `// eslint-disable-next-line no-undef` instead of `/* globals ... */`
for variables that are not meant to be used globally.
Don't allow setting various properties, such as `currentPageNumber`/`currentScale`/`currentScaleValue`/`pagesRotation`, before `{PDFViewer, PDFThumbnailViewer}.setDocument` has been called
This is a trivial follow-up to PR 5383, and it's a bit strange that this has been wrong since late 2014 without anyone noticing (maybe because inline images aren't too common).
So, apparently code works better if you actually spell correctly, who knew ;-)
Fixes 8613.
Note that these files were among the first to be converted to ES6 classes, so it probably makes sense to do another pass to bring them inline with the most recent ES6 conversions.
All other code-paths already checks that the `MessageHandler` isn't terminated, but apparently `onFailure` was missing that check (compare e.g. with the `onSuccess` function).
From what I can tell, this is only an issue if workers are *disabled*, hence why I didn't bother adding a unit-test.
Fixes 8584.
These changes consists mainly of replacing `var` with `let`/`const`, adding a couple of default parameters to function signatures, and finally converting `EventBus`/`ProgressBar` to proper classes.
After PR 8510, we now always lookup the localized `page_scale_percent` string to prevent any possible ordering issues. Since the scaleSelect dropdown is updated asynchronous, there's really no point in having a helper function any more, hence this code can rather be placed inline in `Toolbar._updateUIState`.
In general, we may not know the stroke properties when path construction
happens. Since we must know the properties when we apply the stroke, we
should set the properties at that point. Note that we already do that
for the color and opacity, but not yet for the other properties.
The https://github.com/mozilla/pdf.js/wiki/Contributing article has been updated to explicitly mention that an ES6 browser is now a minimum requirement for development.
Since we recently have seen a couple of issues filed which seemed to indicate that people tried to use PDF.js in browsers without full ES6 support, it's probably a good idea to mention this more prominently in the README as well.
*This is an existing issue that I noticed while testing PR 8552.*
When zooming or rotation occurs, we'll try to use the current canvas as a (CSS transformed) preview until the page has been completely re-drawn.
If you manage to change the scale (or rotation) *very* quickly, it's possible that `PDFPageView.update` can be called *before* a previous `render` operation has progressed far enough to remove the `hidden` property from the canvas.
The result is thus that a page may be *entirely* black during zooming or rotation, which doesn't look very good. This effect can be a bit difficult to spot, but it does manifest even in the default viewer.
In the PDF from issue 8527, the clip operator (W) shows up before a path
is defined. The current SVG backend however expects a path to exist
before generating a `<svg:clipPath>` element.
In the example, the path was defined after the clip, followed by a
endPath operator (n).
So this commit fixes the bug by moving the path generation logic from
clip to endPath.
Our canvas backend appears to use similar logic:
`CanvasGraphics_endPath` calls `consumePath`, which in turn draws the
clip and resets the `pendingClip` state. The canvas backend calls
`consumePath` from multiple other places, so we probably need to check
whether doing so is also necessary for the SVG backend.
I scanned our corpus of PDF files in test/pdfs, and found that in every
instance (except for one), the "W" PDF operator (clip) is immediately
followed by "n" (endPath). The new test from this commit (clippath.pdf)
starts with "W", followed by a path definition and then "n".
# Commands used to find some of the clipping commands:
grep -ra '^W$' -C7 | less -S
grep -ra '^W ' -C7 | less -S
grep -ra ' W$' -C7 | less -S
test/pdfs/issue6413.pdf is the only file where "W" (a tline 55) is not
followed by "n". In fact, the "W" is the last operation of a series of
XObject painting operations, and removing it does not have any effect
on the rendered PDF (confirmed by looking at the output of PDF.js's
canvas backend, and ImageMagick's convert command).
Nimesh Solanki
Yury Delendik
Jonas Jenwald
Rob Wu
Brendan Dahl
Mukul Mishra
Tim van der Meij
ghetolay