2020-06-29 13:18:51 +02:00
|
|
|
/* Copyright 2020 Mozilla Foundation
|
|
|
|
*
|
|
|
|
* Licensed under the Apache License, Version 2.0 (the "License");
|
|
|
|
* you may not use this file except in compliance with the License.
|
|
|
|
* You may obtain a copy of the License at
|
|
|
|
*
|
|
|
|
* http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
*
|
|
|
|
* Unless required by applicable law or agreed to in writing, software
|
|
|
|
* distributed under the License is distributed on an "AS IS" BASIS,
|
|
|
|
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
|
|
* See the License for the specific language governing permissions and
|
|
|
|
* limitations under the License.
|
|
|
|
*/
|
|
|
|
|
2020-12-10 17:32:18 -08:00
|
|
|
import {
|
|
|
|
BaseCanvasFactory,
|
|
|
|
BaseCMapReaderFactory,
|
[api-minor] Extend general transfer function support to browsers without `OffscreenCanvas`
This patch extends PR 16115 to work in all browsers, regardless of their `OffscreenCanvas` support, such that transfer functions will be applied to general rendering (and not just image data).
In order to do this we introduce the `BaseFilterFactory` that is then extended in browsers/Node.js environments, similar to all the other factories used in the API, such that we always have the necessary factory available in `src/display/canvas.js`.
These changes help simplify the existing `putBinaryImageData` function, and the new method can easily be stubbed-out in the Firefox PDF Viewer.
*Please note:* This patch removes the old *partial* transfer function support, which only applied to image data, from Node.js environments since the `node-canvas` package currently doesn't support filters. However, this should hopefully be fine given that:
- Transfer functions are not very commonly used in PDF documents.
- Browsers in general, and Firefox in particular, are the *primary* development target for the PDF.js library.
- The FAQ only lists Node.js as *mostly* supported, see https://github.com/mozilla/pdf.js/wiki/Frequently-Asked-Questions#faq-support
2023-03-12 15:47:01 +01:00
|
|
|
BaseFilterFactory,
|
2020-12-10 17:32:18 -08:00
|
|
|
BaseStandardFontDataFactory,
|
2021-06-07 11:45:16 +02:00
|
|
|
} from "./base_factory.js";
|
2023-07-24 12:21:58 +02:00
|
|
|
import { isNodeJS, warn } from "../shared/util.js";
|
2020-06-29 13:18:51 +02:00
|
|
|
|
2022-05-03 11:13:34 +02:00
|
|
|
if (typeof PDFJSDev !== "undefined" && PDFJSDev.test("MOZCENTRAL")) {
|
|
|
|
throw new Error(
|
|
|
|
'Module "./node_utils.js" shall not be used with MOZCENTRAL builds.'
|
|
|
|
);
|
|
|
|
}
|
2020-06-29 13:18:51 +02:00
|
|
|
|
2023-10-13 12:11:29 +02:00
|
|
|
let fs, canvas, path2d_polyfill;
|
|
|
|
if (isNodeJS) {
|
|
|
|
// Native packages.
|
|
|
|
fs = await __non_webpack_import__("fs");
|
|
|
|
// Optional, third-party, packages.
|
|
|
|
try {
|
|
|
|
canvas = await __non_webpack_import__("canvas");
|
|
|
|
} catch {}
|
|
|
|
try {
|
|
|
|
path2d_polyfill = await __non_webpack_import__("path2d-polyfill");
|
|
|
|
} catch {}
|
[api-major] Output JavaScript modules in the builds (issue 10317)
At this point in time all browsers, and also Node.js, support standard `import`/`export` statements and we can now finally consider outputting modern JavaScript modules in the builds.[1]
In order for this to work we can *only* use proper `import`/`export` statements throughout the main code-base, and (as expected) our Node.js support made this much more complicated since both the official builds and the GitHub Actions-based tests must keep working.[2]
One remaining issue is that the `pdf.scripting.js` file cannot be built as a JavaScript module, since doing so breaks PDF scripting.
Note that my initial goal was to try and split these changes into a couple of commits, however that unfortunately didn't really work since it turned out to be difficult for smaller patches to work correctly and pass (all) tests that way.[3]
This is a classic case of every change requiring a couple of other changes, with each of those changes requiring further changes in turn and the size/scope quickly increasing as a result.
One possible "issue" with these changes is that we'll now only output JavaScript modules in the builds, which could perhaps be a problem with older tools. However it unfortunately seems far too complicated/time-consuming for us to attempt to support both the old and modern module formats, hence the alternative would be to do "nothing" here and just keep our "old" builds.[4]
---
[1] The final blocker was module support in workers in Firefox, which was implemented in Firefox 114; please see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#browser_compatibility
[2] It's probably possible to further improve/simplify especially the Node.js-specific code, but it does appear to work as-is.
[3] Having partially "broken" patches, that fail tests, as part of the commit history is *really not* a good idea in general.
[4] Outputting JavaScript modules was first requested almost five years ago, see issue 10317, and nowadays there *should* be much better support for JavaScript modules in various tools.
2023-09-28 13:00:10 +02:00
|
|
|
}
|
|
|
|
|
2023-07-17 15:44:30 +02:00
|
|
|
if (typeof PDFJSDev !== "undefined" && !PDFJSDev.test("SKIP_BABEL")) {
|
|
|
|
(function checkDOMMatrix() {
|
|
|
|
if (globalThis.DOMMatrix || !isNodeJS) {
|
|
|
|
return;
|
|
|
|
}
|
2023-10-13 12:11:29 +02:00
|
|
|
const DOMMatrix = canvas?.DOMMatrix;
|
[api-major] Output JavaScript modules in the builds (issue 10317)
At this point in time all browsers, and also Node.js, support standard `import`/`export` statements and we can now finally consider outputting modern JavaScript modules in the builds.[1]
In order for this to work we can *only* use proper `import`/`export` statements throughout the main code-base, and (as expected) our Node.js support made this much more complicated since both the official builds and the GitHub Actions-based tests must keep working.[2]
One remaining issue is that the `pdf.scripting.js` file cannot be built as a JavaScript module, since doing so breaks PDF scripting.
Note that my initial goal was to try and split these changes into a couple of commits, however that unfortunately didn't really work since it turned out to be difficult for smaller patches to work correctly and pass (all) tests that way.[3]
This is a classic case of every change requiring a couple of other changes, with each of those changes requiring further changes in turn and the size/scope quickly increasing as a result.
One possible "issue" with these changes is that we'll now only output JavaScript modules in the builds, which could perhaps be a problem with older tools. However it unfortunately seems far too complicated/time-consuming for us to attempt to support both the old and modern module formats, hence the alternative would be to do "nothing" here and just keep our "old" builds.[4]
---
[1] The final blocker was module support in workers in Firefox, which was implemented in Firefox 114; please see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#browser_compatibility
[2] It's probably possible to further improve/simplify especially the Node.js-specific code, but it does appear to work as-is.
[3] Having partially "broken" patches, that fail tests, as part of the commit history is *really not* a good idea in general.
[4] Outputting JavaScript modules was first requested almost five years ago, see issue 10317, and nowadays there *should* be much better support for JavaScript modules in various tools.
2023-09-28 13:00:10 +02:00
|
|
|
|
|
|
|
if (DOMMatrix) {
|
|
|
|
globalThis.DOMMatrix = DOMMatrix;
|
|
|
|
} else {
|
|
|
|
warn("Cannot polyfill `DOMMatrix`, rendering may be broken.");
|
2023-07-24 12:21:58 +02:00
|
|
|
}
|
2023-07-17 15:44:30 +02:00
|
|
|
})();
|
|
|
|
|
|
|
|
(function checkPath2D() {
|
|
|
|
if (globalThis.Path2D || !isNodeJS) {
|
|
|
|
return;
|
|
|
|
}
|
2023-10-13 12:11:29 +02:00
|
|
|
const CanvasRenderingContext2D = canvas?.CanvasRenderingContext2D;
|
|
|
|
const polyfillPath2D = path2d_polyfill?.polyfillPath2D;
|
2023-07-17 15:44:30 +02:00
|
|
|
|
[api-major] Output JavaScript modules in the builds (issue 10317)
At this point in time all browsers, and also Node.js, support standard `import`/`export` statements and we can now finally consider outputting modern JavaScript modules in the builds.[1]
In order for this to work we can *only* use proper `import`/`export` statements throughout the main code-base, and (as expected) our Node.js support made this much more complicated since both the official builds and the GitHub Actions-based tests must keep working.[2]
One remaining issue is that the `pdf.scripting.js` file cannot be built as a JavaScript module, since doing so breaks PDF scripting.
Note that my initial goal was to try and split these changes into a couple of commits, however that unfortunately didn't really work since it turned out to be difficult for smaller patches to work correctly and pass (all) tests that way.[3]
This is a classic case of every change requiring a couple of other changes, with each of those changes requiring further changes in turn and the size/scope quickly increasing as a result.
One possible "issue" with these changes is that we'll now only output JavaScript modules in the builds, which could perhaps be a problem with older tools. However it unfortunately seems far too complicated/time-consuming for us to attempt to support both the old and modern module formats, hence the alternative would be to do "nothing" here and just keep our "old" builds.[4]
---
[1] The final blocker was module support in workers in Firefox, which was implemented in Firefox 114; please see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#browser_compatibility
[2] It's probably possible to further improve/simplify especially the Node.js-specific code, but it does appear to work as-is.
[3] Having partially "broken" patches, that fail tests, as part of the commit history is *really not* a good idea in general.
[4] Outputting JavaScript modules was first requested almost five years ago, see issue 10317, and nowadays there *should* be much better support for JavaScript modules in various tools.
2023-09-28 13:00:10 +02:00
|
|
|
if (CanvasRenderingContext2D && polyfillPath2D) {
|
2023-07-24 12:21:58 +02:00
|
|
|
globalThis.CanvasRenderingContext2D = CanvasRenderingContext2D;
|
|
|
|
polyfillPath2D(globalThis);
|
[api-major] Output JavaScript modules in the builds (issue 10317)
At this point in time all browsers, and also Node.js, support standard `import`/`export` statements and we can now finally consider outputting modern JavaScript modules in the builds.[1]
In order for this to work we can *only* use proper `import`/`export` statements throughout the main code-base, and (as expected) our Node.js support made this much more complicated since both the official builds and the GitHub Actions-based tests must keep working.[2]
One remaining issue is that the `pdf.scripting.js` file cannot be built as a JavaScript module, since doing so breaks PDF scripting.
Note that my initial goal was to try and split these changes into a couple of commits, however that unfortunately didn't really work since it turned out to be difficult for smaller patches to work correctly and pass (all) tests that way.[3]
This is a classic case of every change requiring a couple of other changes, with each of those changes requiring further changes in turn and the size/scope quickly increasing as a result.
One possible "issue" with these changes is that we'll now only output JavaScript modules in the builds, which could perhaps be a problem with older tools. However it unfortunately seems far too complicated/time-consuming for us to attempt to support both the old and modern module formats, hence the alternative would be to do "nothing" here and just keep our "old" builds.[4]
---
[1] The final blocker was module support in workers in Firefox, which was implemented in Firefox 114; please see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#browser_compatibility
[2] It's probably possible to further improve/simplify especially the Node.js-specific code, but it does appear to work as-is.
[3] Having partially "broken" patches, that fail tests, as part of the commit history is *really not* a good idea in general.
[4] Outputting JavaScript modules was first requested almost five years ago, see issue 10317, and nowadays there *should* be much better support for JavaScript modules in various tools.
2023-09-28 13:00:10 +02:00
|
|
|
} else {
|
|
|
|
warn("Cannot polyfill `Path2D`, rendering may be broken.");
|
2023-07-24 12:21:58 +02:00
|
|
|
}
|
2023-07-17 15:44:30 +02:00
|
|
|
})();
|
|
|
|
}
|
|
|
|
|
2022-05-03 11:13:34 +02:00
|
|
|
const fetchData = function (url) {
|
|
|
|
return new Promise((resolve, reject) => {
|
|
|
|
fs.readFile(url, (error, data) => {
|
|
|
|
if (error || !data) {
|
|
|
|
reject(new Error(error));
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
resolve(new Uint8Array(data));
|
|
|
|
});
|
|
|
|
});
|
2020-06-29 13:18:51 +02:00
|
|
|
};
|
|
|
|
|
[api-minor] Extend general transfer function support to browsers without `OffscreenCanvas`
This patch extends PR 16115 to work in all browsers, regardless of their `OffscreenCanvas` support, such that transfer functions will be applied to general rendering (and not just image data).
In order to do this we introduce the `BaseFilterFactory` that is then extended in browsers/Node.js environments, similar to all the other factories used in the API, such that we always have the necessary factory available in `src/display/canvas.js`.
These changes help simplify the existing `putBinaryImageData` function, and the new method can easily be stubbed-out in the Firefox PDF Viewer.
*Please note:* This patch removes the old *partial* transfer function support, which only applied to image data, from Node.js environments since the `node-canvas` package currently doesn't support filters. However, this should hopefully be fine given that:
- Transfer functions are not very commonly used in PDF documents.
- Browsers in general, and Firefox in particular, are the *primary* development target for the PDF.js library.
- The FAQ only lists Node.js as *mostly* supported, see https://github.com/mozilla/pdf.js/wiki/Frequently-Asked-Questions#faq-support
2023-03-12 15:47:01 +01:00
|
|
|
class NodeFilterFactory extends BaseFilterFactory {}
|
|
|
|
|
2022-05-03 11:13:34 +02:00
|
|
|
class NodeCanvasFactory extends BaseCanvasFactory {
|
|
|
|
/**
|
|
|
|
* @ignore
|
|
|
|
*/
|
|
|
|
_createCanvas(width, height) {
|
2023-10-13 12:11:29 +02:00
|
|
|
return canvas.createCanvas(width, height);
|
2020-12-10 17:32:18 -08:00
|
|
|
}
|
2022-05-03 11:13:34 +02:00
|
|
|
}
|
2020-12-10 17:32:18 -08:00
|
|
|
|
2022-05-03 11:13:34 +02:00
|
|
|
class NodeCMapReaderFactory extends BaseCMapReaderFactory {
|
|
|
|
/**
|
|
|
|
* @ignore
|
|
|
|
*/
|
|
|
|
_fetchData(url, compressionType) {
|
|
|
|
return fetchData(url).then(data => {
|
|
|
|
return { cMapData: data, compressionType };
|
2021-06-07 11:45:16 +02:00
|
|
|
});
|
2022-05-03 11:13:34 +02:00
|
|
|
}
|
|
|
|
}
|
2020-12-10 17:32:18 -08:00
|
|
|
|
2022-05-03 11:13:34 +02:00
|
|
|
class NodeStandardFontDataFactory extends BaseStandardFontDataFactory {
|
|
|
|
/**
|
|
|
|
* @ignore
|
|
|
|
*/
|
|
|
|
_fetchData(url) {
|
|
|
|
return fetchData(url);
|
|
|
|
}
|
2020-06-29 13:18:51 +02:00
|
|
|
}
|
|
|
|
|
2020-12-10 17:32:18 -08:00
|
|
|
export {
|
|
|
|
NodeCanvasFactory,
|
|
|
|
NodeCMapReaderFactory,
|
[api-minor] Extend general transfer function support to browsers without `OffscreenCanvas`
This patch extends PR 16115 to work in all browsers, regardless of their `OffscreenCanvas` support, such that transfer functions will be applied to general rendering (and not just image data).
In order to do this we introduce the `BaseFilterFactory` that is then extended in browsers/Node.js environments, similar to all the other factories used in the API, such that we always have the necessary factory available in `src/display/canvas.js`.
These changes help simplify the existing `putBinaryImageData` function, and the new method can easily be stubbed-out in the Firefox PDF Viewer.
*Please note:* This patch removes the old *partial* transfer function support, which only applied to image data, from Node.js environments since the `node-canvas` package currently doesn't support filters. However, this should hopefully be fine given that:
- Transfer functions are not very commonly used in PDF documents.
- Browsers in general, and Firefox in particular, are the *primary* development target for the PDF.js library.
- The FAQ only lists Node.js as *mostly* supported, see https://github.com/mozilla/pdf.js/wiki/Frequently-Asked-Questions#faq-support
2023-03-12 15:47:01 +01:00
|
|
|
NodeFilterFactory,
|
2020-12-10 17:32:18 -08:00
|
|
|
NodeStandardFontDataFactory,
|
|
|
|
};
|