In the `legacy`-builds we (obviously) support the currently maintained Firefox ESR version, and looking at the [release history](https://wiki.mozilla.org/Release_Management/Calendar) those are officially supported (by Mozilla) for about 1-1.5 years.
However, for non-Firefox browsers the `legacy`-builds currently attempt to "support" browsers that are approximately *three* years old.[1] Historically, in the PDF.js project, trying to support old browsers have caused some maintenance problems and even delayed adoption of new web-platform features/functionality.
To lessen the support burden, given that the primary purpose of the PDF.js library is still to develop the *built-in* Firefox PDF Viewer, this patch proposes that the upcoming *major* release changes the minimum supported browsers/environments as follows:
- Chrome 85, which was released on 2020-08-25; see https://en.wikipedia.org/wiki/Google_Chrome_version_history
- Firefox ESR (as before); see https://wiki.mozilla.org/Release_Management/Calendar
- Safari 14, which was released on 2020-09-16; see https://en.wikipedia.org/wiki/Safari_version_history#Safari_14
- Node.js 14 (as before), which is now explicitly listed to prevent it from accidentally breaking; see https://en.wikipedia.org/wiki/Node.js#Releases
---
[1] In older browsers some functionality may not be available and generally we'll ask users to update to a modern browser when bugs, specific to old browsers, are being reported.
The [official Chrome extension](https://chrome.google.com/webstore/detail/pdf-viewer/oemmndcbldboiebfnladdacbdfmadadm) has unfortunately not been updated for *three years*, which means that it's currently missing out on years worth of bug fixes, performance improvements, and new features.
In particular, the Chrome extension suffers from a known bug with non-embedded standard fonts; see issue 13669 for details.
For the time being, this patch proposes that we *temporary* make the following changes:
- Remove the mention of the official Chrome extension from the main README, since it seems unfortunate to somewhat prominently recommend users an old and partially non-working extension.
- Don't run the `gulp lint-chromium` task as part of the CI, since in addition to the official extension not having been updated its code is also not being actively maintained.[1]
Once the official Chrome extension has been updated, and it's being actively maintained again, this patch should be simple enough to revert.
---
[1] The last commits, which aren't e.g. linting or general code-maintenance related, happened a year ago now.
There's no point in having this variable defined (implicitly) as `undefined` in e.g. the Firefox PDF Viewer.
By defining it with `var` and using an ESLint ignore, rather than `let`, we can move it into the relevant pre-processor block instead. Note that since the entire viewer-code is placed, by Webpack, in a top-level closure this variable will thus not become globally accessible.
After the changes in PR 15391 one separator may now become visible too soon when the viewer is narrow, applies e.g. to the MOZCENTRAL viewer, since the wrong CSS class is being used.
The reason that this happens is that only the GENERIC viewer includes the "openFile"-buttons, and we thus need the separator to also be conditionally defined.
This is a slightly speculative change, based on something that I happened to notice while browsing MDN, to hopefully prevent PDF.js from outright breaking in older browsers.
According to the following information on MDN, Safari didn't implement support for the necessary features until version 14:
- https://developer.mozilla.org/en-US/docs/Web/API/MediaQueryList#browser_compatibility
- https://developer.mozilla.org/en-US/docs/Web/API/MediaQueryList/change_event#browser_compatibility
Given the browsers that we currently support only older versions of Safari should be affected, hence it seems reasonable to simply disable the functionality rather than trying to polyfill it.
(It's interesting how it's very often Safari which is *much* slower than the other browsers at implementing new features.)
After the changes in PR 14112 the `PDFViewer`-class is now "identical" to the `BaseViewer`-class and the `PDFSinglePageViewer`-class is just a very thin wrapper around the `BaseViewer`-class.
Hence we can rename these files, and also remove the abstract `BaseViewer`-class, which helps reduce some unnecessary "closures" in the *built* viewer.
*Please note:* These changes are made in two separate commits, to allow GitHub to preserve `blame` for the affected files.
After the changes in PR 14112 the `PDFViewer`-class is now "identical" to the `BaseViewer`-class and the `PDFSinglePageViewer`-class is just a very thin wrapper around the `BaseViewer`-class.
Hence we can rename these files, and also remove the abstract `BaseViewer`-class, which helps reduce some unnecessary "closures" in the *built* viewer.
*Please note:* These changes are made in two separate commits, to allow GitHub to preserve `blame` for the affected files.
This patch updates a bunch of older code, that makes conditional function calls, to use optional chaining rather than `if`-blocks.
These mostly mechanical changes reduce the size of the `gulp mozcentral` build by a little over 1 kB.
*Please note:* This is only a, hopefully generally helpful, work-around rather than a proper solution to issue 15292.
There's something that's "special" about the Type1 fonts in the referenced PDF document, since we don't manage to find any actual font programs and thus cannot render anything.
Given that it shouldn't make sense for a Type1 font program to ever be empty, since that means that there's no glyph-data to render, we simply fallback to a standard font to at least try and render *something* in these rare cases.
Given that the change in PR 13393 was slightly speculative, given the lack of test-cases, let's just revert part of that to fix the referenced issue.
Based on a quick look at old issues and existing test-cases, it seems that most (if not all) PDF documents that benefit from using the font-data in this way lack any /ToUnicode maps which should mean that they're unaffected by these changes.
Given that the official Bower website, since almost five years, has been advising users to utilize other tools it doesn't seem entirely necessary to keep including the `bower.json` file in the `pdfjs-dist` repository; see e.g. https://bower.io/blog/2017/how-to-migrate-away-from-bower/
