Sakurai/pdf.js
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
master
pdf.js/web/viewer-geckoview.html

124 lines
4.5 KiB
HTML
Raw Permalink Normal View History

[GV] Add a viewer for GeckoView
2022-12-15 00:40:25 +09:00
<!DOCTYPE html>
<!--
Copyright 2012 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.
Adobe CMap resources are covered by their own copyright but the same license:
Copyright 1990-2015 Adobe Systems Incorporated.
See https://github.com/adobe-type-tools/cmap-resources
-->
<html dir="ltr" mozdisallowselectionprint>
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1">
<title>PDF.js viewer</title>
<!--#if MOZCENTRAL-->
<!--#include viewer-snippet-firefox-extension.html-->
<!--#endif-->
<!--#if MOZCENTRAL-->
Remove <base> tag from the Firefox built-in viewer (bug 1821408) The tag <base> is used to resolve relative URIs within the document. Newly added SVG filters use a relative URI which then use the URI in base but this one mismatches with the document URI and consequently filters are not found in the Firefox viewer. So this patch just removes <base> and replace few relative URLs by absolute ones.
2023-03-14 00:56:42 +09:00
<!--<link rel="stylesheet" href="resource://pdf.js/web/viewer.css">-->
[api-minor] Move to Fluent for the localization (bug 1858715) - For the generic viewer we use @fluent/dom and @fluent/bundle - For the builtin pdf viewer in Firefox, we set a localization url and then we rely on document.l10n which is a DOMLocalization object.
2023-10-13 23:23:17 +09:00
<!--<link rel="localization" href="toolkit/pdfviewer/viewer.ftl"/>-->
[GV] Add a viewer for GeckoView
2022-12-15 00:40:25 +09:00
<!--#else-->
<link rel="stylesheet" href="viewer-geckoview.css">
<!--#endif-->
<!--#if !MOZCENTRAL-->
[api-minor] Move to Fluent for the localization (bug 1858715) - For the generic viewer we use @fluent/dom and @fluent/bundle - For the builtin pdf viewer in Firefox, we set a localization url and then we rely on document.l10n which is a DOMLocalization object.
2023-10-13 23:23:17 +09:00
<link rel="resource" type="application/l10n" href="locale/locale.json">
[GV] Add a viewer for GeckoView
2022-12-15 00:40:25 +09:00
<!--#endif-->
<!--#if !MOZCENTRAL-->
Use native `import maps` in development mode This patch seem to work fine locally now, and `mozregression` points to it being fixed in bug https://bugzilla.mozilla.org/show_bug.cgi?id=1803984 which landed in Firefox 116. By using the native `import maps` functionality, we can remove a development dependency. Please find the specification at https://wicg.github.io/import-maps/
2022-04-02 20:00:25 +09:00
<script type="importmap">
[GV] Add a viewer for GeckoView
2022-12-15 00:40:25 +09:00
{
"imports": {
"pdfjs/": "../src/",
"pdfjs-lib": "../src/pdf.js",
"pdfjs-web/": "./",
[GeckoView] Reduce the size of the *built* viewer Given that the GV-viewer isn't using most of the UI-related components of the default-viewer, we can avoid including them in the *built* viewer to save space.[1] The least "invasive" way of implementing this, at least that I could come up with, is to leverage import maps with suitable stubs for the GV-viewer. The one slightly annoying thing is that we now have larger import maps across multiple html-files, and you'll need to remember to update all of them when making future changes. --- [1] With this patch, the built `viewer.js` size is 391 kB and `viewer-geckoview.js` is 285 kB.
2023-02-04 21:55:12 +09:00
[api-minor] Move to Fluent for the localization (bug 1858715) - For the generic viewer we use @fluent/dom and @fluent/bundle - For the builtin pdf viewer in Firefox, we set a localization url and then we rely on document.l10n which is a DOMLocalization object.
2023-10-13 23:23:17 +09:00
"fluent-bundle": "../node_modules/@fluent/bundle/esm/index.js",
"fluent-dom": "../node_modules/@fluent/dom/esm/index.js",
"cached-iterable": "../node_modules/cached-iterable/src/index.mjs",
Remove most build-time `require`-calls from the `src/display/`-folder By leveraging import maps we can get rid of *most* of the remaining `require`-calls in the `src/display/`-folder, since we should strive to use modern `import`-statements wherever possible. The only remaining cases are Node.js-specific dependencies, since those seem very difficult to convert unless we start producing a bundle *specifically* for Node.js environments.
2023-07-13 18:58:16 +09:00
"display-fetch_stream": "../src/display/fetch_stream.js",
"display-network": "../src/display/network.js",
"display-node_stream": "../src/display/stubs.js",
"display-node_utils": "../src/display/stubs.js",
[GeckoView] Avoid bundling the `AltTextManager` class, since it's unused
2023-09-21 19:51:34 +09:00
"web-alt_text_manager": "./stubs-geckoview.js",
[GeckoView] Reduce the size of the *built* viewer Given that the GV-viewer isn't using most of the UI-related components of the default-viewer, we can avoid including them in the *built* viewer to save space.[1] The least "invasive" way of implementing this, at least that I could come up with, is to leverage import maps with suitable stubs for the GV-viewer. The one slightly annoying thing is that we now have larger import maps across multiple html-files, and you'll need to remember to update all of them when making future changes. --- [1] With this patch, the built `viewer.js` size is 391 kB and `viewer-geckoview.js` is 285 kB.
2023-02-04 21:55:12 +09:00
"web-annotation_editor_params": "./stubs-geckoview.js",
Remove the `createDownloadManager` method from `DefaultExternalServices` Given the simplicity of the `createDownloadManager` method, we can leverage import maps to directly initialize the correct `DownloadManager`-instance depending on the build.
2024-01-26 19:50:25 +09:00
"web-download_manager": "./download_manager.js",
Re-factor `DefaultExternalServices` into a regular class, without static methods The `DefaultExternalServices` code, which is used to provide build-specific functionality, is very old. This results in a pattern where we first initialize `PDFViewerApplication.externalServices` and then *override* it for the different builds. By converting `DefaultExternalServices` into a "regular" class, and leveraging import maps, we can directly initialize the correct instance depending on the build.
2024-01-26 22:31:42 +09:00
"web-external_services": "./genericcom.js",
Ensure that `GenericL10n` works if the locale files cannot be loaded - Ensure that localization works in the GENERIC viewer, even if the necessary locale files cannot be loaded. This was the behaviour prior to the introduction of Fluent, and it seems worthwhile to keep that (especially since we already bundle the en-US strings anyway). - Let the `GenericL10n`-implementation use the *bundled* en-US strings directly when no language is provided. - Remove the `NullL10n`-implementation, and simply fallback to `GenericL10n`, to reduce the maintenance burden of viewer-components localization. - Indirectly, given the previous point, stop exporting `NullL10n` in the viewer-components since it's now removed. Note that it was never really intended to be used directly and only existed as a fallback. *Please note:* This doesn't affect the Firefox PDF Viewer, thanks to the use of import maps.
2024-01-31 02:32:35 +09:00
"web-null_l10n": "./genericl10n.js",
[GeckoView] Reduce the size of the *built* viewer Given that the GV-viewer isn't using most of the UI-related components of the default-viewer, we can avoid including them in the *built* viewer to save space.[1] The least "invasive" way of implementing this, at least that I could come up with, is to leverage import maps with suitable stubs for the GV-viewer. The one slightly annoying thing is that we now have larger import maps across multiple html-files, and you'll need to remember to update all of them when making future changes. --- [1] With this patch, the built `viewer.js` size is 391 kB and `viewer-geckoview.js` is 285 kB.
2023-02-04 21:55:12 +09:00
"web-pdf_attachment_viewer": "./stubs-geckoview.js",
"web-pdf_cursor_tools": "./stubs-geckoview.js",
"web-pdf_document_properties": "./stubs-geckoview.js",
"web-pdf_find_bar": "./stubs-geckoview.js",
"web-pdf_layer_viewer": "./stubs-geckoview.js",
"web-pdf_outline_viewer": "./stubs-geckoview.js",
"web-pdf_presentation_mode": "./stubs-geckoview.js",
"web-pdf_sidebar": "./stubs-geckoview.js",
"web-pdf_thumbnail_viewer": "./stubs-geckoview.js",
Remove the `createPreferences` method from `DefaultExternalServices` Given the simplicity of the `createPreferences` method, we can leverage import maps to directly initialize the correct `Preferences`-instance depending on the build.
2024-01-26 20:04:54 +09:00
"web-preferences": "./genericcom.js",
[GeckoView] Bundle the Firefox printing code in the viewer (bug 1810111) This may not be enough, on its own, to completely fix [bug 1810111](https://bugzilla.mozilla.org/show_bug.cgi?id=1810111) however it's impossible for printing to work in GeckoView without this patch.
2023-03-16 22:22:14 +09:00
"web-print_service": "./pdf_print_service.js",
[GeckoView] Reduce the size of the *built* viewer Given that the GV-viewer isn't using most of the UI-related components of the default-viewer, we can avoid including them in the *built* viewer to save space.[1] The least "invasive" way of implementing this, at least that I could come up with, is to leverage import maps with suitable stubs for the GV-viewer. The one slightly annoying thing is that we now have larger import maps across multiple html-files, and you'll need to remember to update all of them when making future changes. --- [1] With this patch, the built `viewer.js` size is 391 kB and `viewer-geckoview.js` is 285 kB.
2023-02-04 21:55:12 +09:00
"web-secondary_toolbar": "./stubs-geckoview.js",
[GeckoView] Add a basic toolbar with a download button for GV (bug 1823164)
2023-04-07 17:28:53 +09:00
"web-toolbar": "./toolbar-geckoview.js"
[GV] Add a viewer for GeckoView
2022-12-15 00:40:25 +09:00
}
}
</script>
Use native `import maps` in development mode This patch seem to work fine locally now, and `mozregression` points to it being fixed in bug https://bugzilla.mozilla.org/show_bug.cgi?id=1803984 which landed in Firefox 116. By using the native `import maps` functionality, we can remove a development dependency. Please find the specification at https://wicg.github.io/import-maps/
2022-04-02 20:00:25 +09:00
<script src="viewer-geckoview.js" type="module"></script>
[GV] Add a viewer for GeckoView
2022-12-15 00:40:25 +09:00
<!--#else-->
[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 20:00:10 +09:00
<!--<script src="resource://pdf.js/web/viewer.mjs" type="module"></script>-->
[GV] Add a viewer for GeckoView
2022-12-15 00:40:25 +09:00
<!--#endif-->
</head>
<body tabindex="1">
<div id="outerContainer">
<div id="mainContainer">
[GeckoView] Add a Nimbus experiment for the toolbar (bug 1833093)
2023-05-15 23:13:41 +09:00
<div id="floatingToolbar">
[api-minor] Move to Fluent for the localization (bug 1858715) - For the generic viewer we use @fluent/dom and @fluent/bundle - For the builtin pdf viewer in Firefox, we set a localization url and then we rely on document.l10n which is a DOMLocalization object.
2023-10-13 23:23:17 +09:00
<button id="download" class="toolbarButton" title="Download" tabindex="31" data-l10n-id="pdfjs-download-button">
<span data-l10n-id="pdfjs-download-button-label">Download</span>
[GeckoView] Change the toolbar for a static one on the top of the viewer (bug 1829366)
2023-04-24 18:44:43 +09:00
</button>
</div>
[GV] Add a viewer for GeckoView
2022-12-15 00:40:25 +09:00
<div id="viewerContainer" tabindex="0">
<div id="viewer" class="pdfViewer"></div>
</div>
</div> <!-- mainContainer -->
<div id="dialogContainer">
<dialog id="passwordDialog">
<div class="row">
[api-minor] Move to Fluent for the localization (bug 1858715) - For the generic viewer we use @fluent/dom and @fluent/bundle - For the builtin pdf viewer in Firefox, we set a localization url and then we rely on document.l10n which is a DOMLocalization object.
2023-10-13 23:23:17 +09:00
<label for="password" id="passwordText" data-l10n-id="pdfjs-password-label">Enter the password to open this PDF file:</label>
[GV] Add a viewer for GeckoView
2022-12-15 00:40:25 +09:00
</div>
<div class="row">
<input type="password" id="password" class="toolbarField">
</div>
<div class="buttonRow">
[api-minor] Move to Fluent for the localization (bug 1858715) - For the generic viewer we use @fluent/dom and @fluent/bundle - For the builtin pdf viewer in Firefox, we set a localization url and then we rely on document.l10n which is a DOMLocalization object.
2023-10-13 23:23:17 +09:00
<button id="passwordCancel" class="dialogButton"><span data-l10n-id="pdfjs-password-cancel-button">Cancel</span></button>
<button id="passwordSubmit" class="dialogButton"><span data-l10n-id="pdfjs-password-ok-button">OK</span></button>
[GV] Add a viewer for GeckoView
2022-12-15 00:40:25 +09:00
</div>
</dialog>
</div> <!-- dialogContainer -->
</div> <!-- outerContainer -->
[GeckoView] Bundle the Firefox printing code in the viewer (bug 1810111) This may not be enough, on its own, to completely fix [bug 1810111](https://bugzilla.mozilla.org/show_bug.cgi?id=1810111) however it's impossible for printing to work in GeckoView without this patch.
2023-03-16 22:22:14 +09:00
<div id="printContainer"></div>
[GV] Add a viewer for GeckoView
2022-12-15 00:40:25 +09:00
</body>
</html>
Reference in New Issue Copy Permalink