mirrors/pdf.js
1
0
Fork 0
mirror of https://github.com/mozilla/pdf.js.git synced 2025-04-19 22:58:07 +02:00
Code Activity
pdf.js/web/viewer.html

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

695 lines
46 KiB
HTML
Raw Permalink Normal View History

Add BOM to viewer.
2013-11-22 11:10:43 -08:00
<!DOCTYPE html>
Change to the Apache v2 license.
2012-08-31 15:48:21 -07:00
<!--
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.
Add note about adobe license.
2014-03-10 13:03:35 -07:00
Update Adobe CMaps URL and license They are now using Apache 2.0 as well.
2015-06-30 00:33:25 -07:00
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
Change to the Apache v2 license.
2012-08-31 15:48:21 -07:00
-->
Remove `moznomarginboxes`
2018-01-19 22:05:50 +01:00
<html dir="ltr" mozdisallowselectionprint>
first mockup, loads tracemonkey pages OK
2012-04-11 16:12:51 -07:00
<head>
Embed locale.properties in the viewer.html for extension
2012-04-30 21:55:21 -05:00
<meta charset="utf-8">
Add viewport metatag
2012-05-23 16:50:54 -05:00
<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1">
Disable Google Translate on viewer in Chrome. test/pdfs/yo01.pdf triggered "This page is in Japanese. Would you like to translate it?" info bar in Chrome.
2013-07-16 00:13:05 +02:00
<!--#if GENERIC || CHROME-->
<meta name="google" content="notranslate">
<!--#endif-->
Merge branch 'master' into new-ui Conflicts: web/viewer.html web/viewer.js
2012-04-18 15:02:49 -04:00
<title>PDF.js viewer</title>
Add the new preprocessor.
2012-08-01 11:29:13 -07:00
Remove the `FIREFOX` build flag, since it's completely unused After PR 9566, which removed all of the old Firefox extension code, the `FIREFOX` build flag is no longer used for anything. It thus seems to me that it should be removed, for a couple of reasons: - It's simply dead code now, which only serves to add confusion when looking at the `PDFJSDev` calls. - It used to be that `MOZCENTRAL` and `FIREFOX` was *almost* always used together. However, ever since PR 9566 there's obviously been no effort put into keeping the `FIREFOX` build flags up to date. - In the event that a new, Webextension based, Firefox addon is created in the future you'd still need to audit all `MOZCENTRAL` (and possibly `CHROME`) build flags to see what'd make sense for the addon.
2020-01-08 13:57:31 +01:00
<!--#if MOZCENTRAL-->
Add the new preprocessor.
2012-08-01 11:29:13 -07:00
<!--#include viewer-snippet-firefox-extension.html-->
Clean-up the pre-processor statements in `web/viewer.html` Some of these pre-processor statements are *many* years old, and could thus do with some clean-up. Note that the pre-processor originally didn't support else-if statements, and by using those the code becomes a bit less verbose.
2023-03-18 17:17:46 +01:00
<!--#elif CHROME-->
[CRX] Show nicely formatted URL in omnibox Before commit: chrome-extension://EXTENSIONID/content/web/viewer.html?file=http%3A%2F%2Fexample.com%2Ffile.pdf After commit: chrome-extension://EXTENSIONID/http://example/file.pdf Technical details: - The extension's background page uses the webRequest API to intercept requests for <extension host>/<real path to pdf>, and redirect it to the viewer's URL. - viewer.js uses history.replaceState to rewrite the URL, so that it's easier for users to recognize and copy-paste URLs. - The fake paths /http:, /https:, /file:, etc. have been added to the web_accessible_resources section of the manifest file, in order to avoid seeing chrome-extension://invalid/ instead of the actual URL when using history back/forward to navigate from/to the PDF viewer. - Since the relative path resolving doesn't work because relative URLs are inaccurate, a <base> tag has been added. This method has already been proven to work in the Firefox add-on. Notes: - This commit has been cherry-picked from crx-using-streams-api. - Need to merge https://github.com/mozilla/pdf.js/pull/3582 to deal with a bug in Chrome <=30 - In Chrome, getting the contents of a FTP file is not possible, so there's no support for FTP files, even though the extension router recognizes the ftp: scheme.
2013-08-15 22:47:30 +02:00
<!--#include viewer-snippet-chrome-extension.html-->
Clean-up the pre-processor statements in `web/viewer.html` Some of these pre-processor statements are *many* years old, and could thus do with some clean-up. Note that the pre-processor originally didn't support else-if statements, and by using those the code becomes a bit less verbose.
2023-03-18 17:17:46 +01:00
<!--#else-->
<!--#include viewer-snippet.html-->
Add the new preprocessor.
2012-08-01 11:29:13 -07:00
<!--#endif-->
first mockup, loads tracemonkey pages OK
2012-04-11 16:12:51 -07:00
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-13 16:56:42 +01:00
<!--#if MOZCENTRAL-->
<!--<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 16:23:17 +02:00
<!--<link rel="localization" href="toolkit/pdfviewer/viewer.ftl"/>-->
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-13 16:56:42 +01:00
<!--#else-->
Remove XHTML leftovers from the viewer HTML files
2016-02-14 13:23:34 +01:00
<link rel="stylesheet" href="viewer.css">
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-13 16:56:42 +01:00
<!--#endif-->
Clean-up the pre-processor statements in `web/viewer.html` Some of these pre-processor statements are *many* years old, and could thus do with some clean-up. Note that the pre-processor originally didn't support else-if statements, and by using those the code becomes a bit less verbose.
2023-03-18 17:17:46 +01:00
<!--#if MOZCENTRAL-->
[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
<!--<script src="resource://pdf.js/web/viewer.mjs" type="module"></script>-->
[api-minor] Stop building a minified default viewer The minified default viewer has never been distributed in either official releases or through pdfjs-dist, which means that it's most likely unused, and it's has never been tested nor actively maintained.
2023-09-28 10:07:26 +02:00
<!--#elif !MOZCENTRAL-->
[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
<!--<script src="viewer.mjs" type="module"></script>-->
Remove the remaining `PRODUCTION` build-target usage After the previous patch we now have only *a single* `PRODUCTION` occurrence in the entire code-base, more specifically in the `web/viewer.html` file. This special build-target can be replaced with any condition that always evaluate to `false`, such as e.g. a comment. *Please note:* This patch might be considered too hacky, hence I completely understand if it's rejected.
2023-03-19 12:42:22 +01:00
<!--#elif /* Development mode. */-->
[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 16:23:17 +02:00
<link rel="resource" type="application/l10n" href="locale/locale.json">
Add the new preprocessor.
2012-08-01 11:29:13 -07:00
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 13:00:25 +02:00
<script type="importmap">
Reduce usage of SystemJS, in the development viewer, even further With these changes SystemJS is now only used, during development, on the worker-thread and in the unit/font-tests, since Firefox is currently missing support for worker modules; please see https://bugzilla.mozilla.org/show_bug.cgi?id=1247687 Hence all the JavaScript files in the `web/` and `src/display/` folders are now loaded *natively* by the browser (during development) using standard `import` statements/calls, thanks to a nice `import-maps` polyfill. *Please note:* As soon as https://bugzilla.mozilla.org/show_bug.cgi?id=1247687 is fixed in Firefox, we should be able to remove all traces of SystemJS and thus finally be able to use every possible modern JavaScript feature.
2020-05-19 18:00:23 +02:00
{
"imports": {
"pdfjs/": "../src/",
"pdfjs-lib": "../src/pdf.js",
[editor] Use the `fit-curve` package (issue 15004) Rather than including all of this external code in the PDF.js repository, we should be using the npm package instead. Unfortunately this is slightly more complicated than you'd hope, since the `fit-curve` package (which is older) isn't directly compatible with modern JavaScript modules. In particular, the following cases needed to be considered: - For the development viewer (i.e. `gulp server`) and the unit-tests, we thus need to build a fitCurve-bundle that can be directly `import`ed. - For the actual PDF.js build-targets, we can slightly reduce the sizes by depending on the "raw" `fit-curve` source-code. - For the Node.js unit-tests, the `fit-curve` package can be used as-is.
2022-07-06 23:02:53 +02:00
"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 13:55:12 +01: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 16:23:17 +02: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",
Move the various DOM-factories into their own files - Over time the number and size of these factories have increased, especially the `DOMFilterFactory` class, and this split should thus aid readability/maintainability of the code. - By introducing a couple of new import maps we can avoid bundling the `DOMCMapReaderFactory`/`DOMStandardFontDataFactory` classes in the Firefox PDF Viewer, since they are dead code there given that worker-thread fetching is always being used. - This patch has been successfully tested, by running `$ ./mach test toolkit/components/pdfjs/`, in a local Firefox artifact-build. *Note:* This patch reduces the size of the `gulp mozcentral` output by `1.3` kilo-bytes, which isn't a lot but still cannot hurt.
2024-11-01 12:34:39 +01:00
"display-cmap_reader_factory": "../src/display/cmap_reader_factory.js",
"display-standard_fontdata_factory": "../src/display/standard_fontdata_factory.js",
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 11:58:16 +02: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 12:51:34 +02:00
"web-alt_text_manager": "./alt_text_manager.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 13:55:12 +01:00
"web-annotation_editor_params": "./annotation_editor_params.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 11:50:25 +01: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 14:31:42 +01:00
"web-external_services": "./genericcom.js",
Implement the new alt text flow (bug 1909604) For the Firefox pdf viewer, we want to use AI to guess an alt-text when adding an image to a pdf. For now the telemtry stuff is not implemented and will come soon. In order to test it locally: - set enableAltText, enableFakeMLManager and enableUpdatedAddImage to true. or in Firefox: - set browser.ml.enable, pdfjs.enableAltText and pdfjs.enableUpdatedAddImage to true.
2024-07-24 09:34:32 +02:00
"web-new_alt_text_manager": "./new_alt_text_manager.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-30 18:32:35 +01: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 13:55:12 +01:00
"web-pdf_attachment_viewer": "./pdf_attachment_viewer.js",
"web-pdf_cursor_tools": "./pdf_cursor_tools.js",
"web-pdf_document_properties": "./pdf_document_properties.js",
"web-pdf_find_bar": "./pdf_find_bar.js",
"web-pdf_layer_viewer": "./pdf_layer_viewer.js",
"web-pdf_outline_viewer": "./pdf_outline_viewer.js",
"web-pdf_presentation_mode": "./pdf_presentation_mode.js",
"web-pdf_sidebar": "./pdf_sidebar.js",
"web-pdf_thumbnail_viewer": "./pdf_thumbnail_viewer.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 12:04:54 +01:00
"web-preferences": "./genericcom.js",
Remove most build-time `require` statements from the viewer (PR 16009 follow-up) This further extends the web-specific import maps introduced in PR 16009, to allow removing *most* of the build-time `require` statements from the viewer. The few remaining ones are fallbacks used for the COMPONENTS respectively the `legacy` GENERIC builds.
2023-02-05 16:13:18 +01: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 13:55:12 +01:00
"web-secondary_toolbar": "./secondary_toolbar.js",
"web-toolbar": "./toolbar.js"
Reduce usage of SystemJS, in the development viewer, even further With these changes SystemJS is now only used, during development, on the worker-thread and in the unit/font-tests, since Firefox is currently missing support for worker modules; please see https://bugzilla.mozilla.org/show_bug.cgi?id=1247687 Hence all the JavaScript files in the `web/` and `src/display/` folders are now loaded *natively* by the browser (during development) using standard `import` statements/calls, thanks to a nice `import-maps` polyfill. *Please note:* As soon as https://bugzilla.mozilla.org/show_bug.cgi?id=1247687 is fixed in Firefox, we should be able to remove all traces of SystemJS and thus finally be able to use every possible modern JavaScript feature.
2020-05-19 18:00:23 +02: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 13:00:25 +02:00
<script src="viewer.js" type="module"></script>
Add the new preprocessor.
2012-08-01 11:29:13 -07:00
<!--#endif-->
first mockup, loads tracemonkey pages OK
2012-04-11 16:12:51 -07:00
</head>
Separate js and css from the test.html file
2011-05-26 16:02:52 +02:00
Refactor the toolbar html & css to improve its overall accessibility (bug 1171799, bug 1855695) The first goal of this patch was to remove the tabindex because it helps to improve overall a11y. That led to move some html elements associated with the buttons which helped to position these elements relatively to their buttons. Consequently it was easy to change the toolbar height (configurable in Firefox with the pref browser.uidensity): it's the second goal of this patch. For a11y reasons we want to be able to change the height of the toolbar to make the buttons larger.
2024-07-01 22:37:48 +02:00
<body tabindex="0">
Small refactoring of the loadingBar hiding code
2014-08-17 00:22:05 +02:00
<div id="outerContainer">
Unify the multi_page_viewer and the basic viewer
2011-07-28 19:48:05 +02:00
Move sidebar open class.
2012-04-25 13:46:17 -07:00
<div id="sidebarContainer">
Refactor the toolbar html & css to improve its overall accessibility (bug 1171799, bug 1855695) The first goal of this patch was to remove the tabindex because it helps to improve overall a11y. That led to move some html elements associated with the buttons which helped to position these elements relatively to their buttons. Consequently it was easy to change the toolbar height (configurable in Firefox with the pref browser.uidensity): it's the second goal of this patch. For a11y reasons we want to be able to change the height of the toolbar to make the buttons larger.
2024-07-01 22:37:48 +02:00
<div id="toolbarSidebar" class="toolbarHorizontalGroup">
Add support for finding/highlighting the outlineItem, corresponding to the currently visible page, in the sidebar (issue 7557, bug 1253820, bug 1499050) This implementation is inspired by the behaviour in (recent versions of) Adobe Reader, since it leads to reasonably simple and straightforward code as far as I'm concerned. *Specifically:* We'll only consider *one* destination per page when finding/highlighting the current outline item, which is similar to e.g. Adobe Reader, and we choose the *first* outline item at the *lowest* level of the outline tree. Given that this functionality requires not only parsing of the `outline`, but looking up *all* of the destinations in the document, this feature can when initialized have a non-trivial performance overhead for larger PDF documents. In an attempt to reduce the performance impact, the following steps are taken here: - The "find current outline item"-functionality will only be enabled once *one* page has rendered and *all* the pages have been loaded[1], to prevent it interfering with data regular fetching/parsing early on during document loading and viewer initialization. - With the exception of a couple of small and simple `eventBus`-listeners, in `PDFOutlineViewer`, this new functionality is initialized *lazily* the first time that the user clicks on the `currentOutlineItem`-button. - The entire "find current outline item"-functionality is disabled when `disableAutoFetch = true` is set, since it can easily lead to the setting becoming essentially pointless[2] by triggering *a lot* of data fetching from a relatively minor viewer-feature. - Fetch the destinations *individually*, since that's generally more efficient than using `PDFDocumentProxy.getDestinations` to fetch them all at once. Despite making the overall parsing code *more* asynchronous, and leading to a lot more main/worker-thread message passing, in practice this seems faster for larger documents. Finally, we'll now always highlight an outline item that the user manually clicked on, since only highlighting when the new "find current outline item"-functionality is used seemed inconsistent. --- [1] Keep in mind that the `outline` itself already isn't fetched/parsed until at least *one* page has been rendered in the viewer. [2] And also quite slow, since it can take a fair amount of time to fetch all of the necessary `destinations` data when `disableAutoFetch = true` is set.
2020-12-25 12:57:43 +01:00
<div id="toolbarSidebarLeft">
Refactor the toolbar html & css to improve its overall accessibility (bug 1171799, bug 1855695) The first goal of this patch was to remove the tabindex because it helps to improve overall a11y. That led to move some html elements associated with the buttons which helped to position these elements relatively to their buttons. Consequently it was easy to change the toolbar height (configurable in Firefox with the pref browser.uidensity): it's the second goal of this patch. For a11y reasons we want to be able to change the height of the toolbar to make the buttons larger.
2024-07-01 22:37:48 +02:00
<div id="sidebarViewButtons" class="toolbarHorizontalGroup toggled" role="radiogroup">
<button id="viewThumbnail" class="toolbarButton toggled" type="button" title="Show Thumbnails" tabindex="0" data-l10n-id="pdfjs-thumbs-button" role="radio" aria-checked="true" aria-controls="thumbnailView">
[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 16:23:17 +02:00
<span data-l10n-id="pdfjs-thumbs-button-label">Thumbnails</span>
Add support for finding/highlighting the outlineItem, corresponding to the currently visible page, in the sidebar (issue 7557, bug 1253820, bug 1499050) This implementation is inspired by the behaviour in (recent versions of) Adobe Reader, since it leads to reasonably simple and straightforward code as far as I'm concerned. *Specifically:* We'll only consider *one* destination per page when finding/highlighting the current outline item, which is similar to e.g. Adobe Reader, and we choose the *first* outline item at the *lowest* level of the outline tree. Given that this functionality requires not only parsing of the `outline`, but looking up *all* of the destinations in the document, this feature can when initialized have a non-trivial performance overhead for larger PDF documents. In an attempt to reduce the performance impact, the following steps are taken here: - The "find current outline item"-functionality will only be enabled once *one* page has rendered and *all* the pages have been loaded[1], to prevent it interfering with data regular fetching/parsing early on during document loading and viewer initialization. - With the exception of a couple of small and simple `eventBus`-listeners, in `PDFOutlineViewer`, this new functionality is initialized *lazily* the first time that the user clicks on the `currentOutlineItem`-button. - The entire "find current outline item"-functionality is disabled when `disableAutoFetch = true` is set, since it can easily lead to the setting becoming essentially pointless[2] by triggering *a lot* of data fetching from a relatively minor viewer-feature. - Fetch the destinations *individually*, since that's generally more efficient than using `PDFDocumentProxy.getDestinations` to fetch them all at once. Despite making the overall parsing code *more* asynchronous, and leading to a lot more main/worker-thread message passing, in practice this seems faster for larger documents. Finally, we'll now always highlight an outline item that the user manually clicked on, since only highlighting when the new "find current outline item"-functionality is used seemed inconsistent. --- [1] Keep in mind that the `outline` itself already isn't fetched/parsed until at least *one* page has been rendered in the viewer. [2] And also quite slow, since it can take a fair amount of time to fetch all of the necessary `destinations` data when `disableAutoFetch = true` is set.
2020-12-25 12:57:43 +01:00
</button>
Refactor the toolbar html & css to improve its overall accessibility (bug 1171799, bug 1855695) The first goal of this patch was to remove the tabindex because it helps to improve overall a11y. That led to move some html elements associated with the buttons which helped to position these elements relatively to their buttons. Consequently it was easy to change the toolbar height (configurable in Firefox with the pref browser.uidensity): it's the second goal of this patch. For a11y reasons we want to be able to change the height of the toolbar to make the buttons larger.
2024-07-01 22:37:48 +02:00
<button id="viewOutline" class="toolbarButton" type="button" title="Show Document Outline (double-click to expand/collapse all items)" tabindex="0" data-l10n-id="pdfjs-document-outline-button" role="radio" aria-checked="false" aria-controls="outlineView">
[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 16:23:17 +02:00
<span data-l10n-id="pdfjs-document-outline-button-label">Document Outline</span>
Add support for finding/highlighting the outlineItem, corresponding to the currently visible page, in the sidebar (issue 7557, bug 1253820, bug 1499050) This implementation is inspired by the behaviour in (recent versions of) Adobe Reader, since it leads to reasonably simple and straightforward code as far as I'm concerned. *Specifically:* We'll only consider *one* destination per page when finding/highlighting the current outline item, which is similar to e.g. Adobe Reader, and we choose the *first* outline item at the *lowest* level of the outline tree. Given that this functionality requires not only parsing of the `outline`, but looking up *all* of the destinations in the document, this feature can when initialized have a non-trivial performance overhead for larger PDF documents. In an attempt to reduce the performance impact, the following steps are taken here: - The "find current outline item"-functionality will only be enabled once *one* page has rendered and *all* the pages have been loaded[1], to prevent it interfering with data regular fetching/parsing early on during document loading and viewer initialization. - With the exception of a couple of small and simple `eventBus`-listeners, in `PDFOutlineViewer`, this new functionality is initialized *lazily* the first time that the user clicks on the `currentOutlineItem`-button. - The entire "find current outline item"-functionality is disabled when `disableAutoFetch = true` is set, since it can easily lead to the setting becoming essentially pointless[2] by triggering *a lot* of data fetching from a relatively minor viewer-feature. - Fetch the destinations *individually*, since that's generally more efficient than using `PDFDocumentProxy.getDestinations` to fetch them all at once. Despite making the overall parsing code *more* asynchronous, and leading to a lot more main/worker-thread message passing, in practice this seems faster for larger documents. Finally, we'll now always highlight an outline item that the user manually clicked on, since only highlighting when the new "find current outline item"-functionality is used seemed inconsistent. --- [1] Keep in mind that the `outline` itself already isn't fetched/parsed until at least *one* page has been rendered in the viewer. [2] And also quite slow, since it can take a fair amount of time to fetch all of the necessary `destinations` data when `disableAutoFetch = true` is set.
2020-12-25 12:57:43 +01:00
</button>
Refactor the toolbar html & css to improve its overall accessibility (bug 1171799, bug 1855695) The first goal of this patch was to remove the tabindex because it helps to improve overall a11y. That led to move some html elements associated with the buttons which helped to position these elements relatively to their buttons. Consequently it was easy to change the toolbar height (configurable in Firefox with the pref browser.uidensity): it's the second goal of this patch. For a11y reasons we want to be able to change the height of the toolbar to make the buttons larger.
2024-07-01 22:37:48 +02:00
<button id="viewAttachments" class="toolbarButton" type="button" title="Show Attachments" tabindex="0" data-l10n-id="pdfjs-attachments-button" role="radio" aria-checked="false" aria-controls="attachmentsView">
[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 16:23:17 +02:00
<span data-l10n-id="pdfjs-attachments-button-label">Attachments</span>
Add support for finding/highlighting the outlineItem, corresponding to the currently visible page, in the sidebar (issue 7557, bug 1253820, bug 1499050) This implementation is inspired by the behaviour in (recent versions of) Adobe Reader, since it leads to reasonably simple and straightforward code as far as I'm concerned. *Specifically:* We'll only consider *one* destination per page when finding/highlighting the current outline item, which is similar to e.g. Adobe Reader, and we choose the *first* outline item at the *lowest* level of the outline tree. Given that this functionality requires not only parsing of the `outline`, but looking up *all* of the destinations in the document, this feature can when initialized have a non-trivial performance overhead for larger PDF documents. In an attempt to reduce the performance impact, the following steps are taken here: - The "find current outline item"-functionality will only be enabled once *one* page has rendered and *all* the pages have been loaded[1], to prevent it interfering with data regular fetching/parsing early on during document loading and viewer initialization. - With the exception of a couple of small and simple `eventBus`-listeners, in `PDFOutlineViewer`, this new functionality is initialized *lazily* the first time that the user clicks on the `currentOutlineItem`-button. - The entire "find current outline item"-functionality is disabled when `disableAutoFetch = true` is set, since it can easily lead to the setting becoming essentially pointless[2] by triggering *a lot* of data fetching from a relatively minor viewer-feature. - Fetch the destinations *individually*, since that's generally more efficient than using `PDFDocumentProxy.getDestinations` to fetch them all at once. Despite making the overall parsing code *more* asynchronous, and leading to a lot more main/worker-thread message passing, in practice this seems faster for larger documents. Finally, we'll now always highlight an outline item that the user manually clicked on, since only highlighting when the new "find current outline item"-functionality is used seemed inconsistent. --- [1] Keep in mind that the `outline` itself already isn't fetched/parsed until at least *one* page has been rendered in the viewer. [2] And also quite slow, since it can take a fair amount of time to fetch all of the necessary `destinations` data when `disableAutoFetch = true` is set.
2020-12-25 12:57:43 +01:00
</button>
Refactor the toolbar html & css to improve its overall accessibility (bug 1171799, bug 1855695) The first goal of this patch was to remove the tabindex because it helps to improve overall a11y. That led to move some html elements associated with the buttons which helped to position these elements relatively to their buttons. Consequently it was easy to change the toolbar height (configurable in Firefox with the pref browser.uidensity): it's the second goal of this patch. For a11y reasons we want to be able to change the height of the toolbar to make the buttons larger.
2024-07-01 22:37:48 +02:00
<button id="viewLayers" class="toolbarButton" type="button" title="Show Layers (double-click to reset all layers to the default state)" tabindex="0" data-l10n-id="pdfjs-layers-button" role="radio" aria-checked="false" aria-controls="layersView">
[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 16:23:17 +02:00
<span data-l10n-id="pdfjs-layers-button-label">Layers</span>
Add support for finding/highlighting the outlineItem, corresponding to the currently visible page, in the sidebar (issue 7557, bug 1253820, bug 1499050) This implementation is inspired by the behaviour in (recent versions of) Adobe Reader, since it leads to reasonably simple and straightforward code as far as I'm concerned. *Specifically:* We'll only consider *one* destination per page when finding/highlighting the current outline item, which is similar to e.g. Adobe Reader, and we choose the *first* outline item at the *lowest* level of the outline tree. Given that this functionality requires not only parsing of the `outline`, but looking up *all* of the destinations in the document, this feature can when initialized have a non-trivial performance overhead for larger PDF documents. In an attempt to reduce the performance impact, the following steps are taken here: - The "find current outline item"-functionality will only be enabled once *one* page has rendered and *all* the pages have been loaded[1], to prevent it interfering with data regular fetching/parsing early on during document loading and viewer initialization. - With the exception of a couple of small and simple `eventBus`-listeners, in `PDFOutlineViewer`, this new functionality is initialized *lazily* the first time that the user clicks on the `currentOutlineItem`-button. - The entire "find current outline item"-functionality is disabled when `disableAutoFetch = true` is set, since it can easily lead to the setting becoming essentially pointless[2] by triggering *a lot* of data fetching from a relatively minor viewer-feature. - Fetch the destinations *individually*, since that's generally more efficient than using `PDFDocumentProxy.getDestinations` to fetch them all at once. Despite making the overall parsing code *more* asynchronous, and leading to a lot more main/worker-thread message passing, in practice this seems faster for larger documents. Finally, we'll now always highlight an outline item that the user manually clicked on, since only highlighting when the new "find current outline item"-functionality is used seemed inconsistent. --- [1] Keep in mind that the `outline` itself already isn't fetched/parsed until at least *one* page has been rendered in the viewer. [2] And also quite slow, since it can take a fair amount of time to fetch all of the necessary `destinations` data when `disableAutoFetch = true` is set.
2020-12-25 12:57:43 +01:00
</button>
</div>
</div>
<div id="toolbarSidebarRight">
Refactor the toolbar html & css to improve its overall accessibility (bug 1171799, bug 1855695) The first goal of this patch was to remove the tabindex because it helps to improve overall a11y. That led to move some html elements associated with the buttons which helped to position these elements relatively to their buttons. Consequently it was easy to change the toolbar height (configurable in Firefox with the pref browser.uidensity): it's the second goal of this patch. For a11y reasons we want to be able to change the height of the toolbar to make the buttons larger.
2024-07-01 22:37:48 +02:00
<div id="outlineOptionsContainer" class="toolbarHorizontalGroup">
Add support for finding/highlighting the outlineItem, corresponding to the currently visible page, in the sidebar (issue 7557, bug 1253820, bug 1499050) This implementation is inspired by the behaviour in (recent versions of) Adobe Reader, since it leads to reasonably simple and straightforward code as far as I'm concerned. *Specifically:* We'll only consider *one* destination per page when finding/highlighting the current outline item, which is similar to e.g. Adobe Reader, and we choose the *first* outline item at the *lowest* level of the outline tree. Given that this functionality requires not only parsing of the `outline`, but looking up *all* of the destinations in the document, this feature can when initialized have a non-trivial performance overhead for larger PDF documents. In an attempt to reduce the performance impact, the following steps are taken here: - The "find current outline item"-functionality will only be enabled once *one* page has rendered and *all* the pages have been loaded[1], to prevent it interfering with data regular fetching/parsing early on during document loading and viewer initialization. - With the exception of a couple of small and simple `eventBus`-listeners, in `PDFOutlineViewer`, this new functionality is initialized *lazily* the first time that the user clicks on the `currentOutlineItem`-button. - The entire "find current outline item"-functionality is disabled when `disableAutoFetch = true` is set, since it can easily lead to the setting becoming essentially pointless[2] by triggering *a lot* of data fetching from a relatively minor viewer-feature. - Fetch the destinations *individually*, since that's generally more efficient than using `PDFDocumentProxy.getDestinations` to fetch them all at once. Despite making the overall parsing code *more* asynchronous, and leading to a lot more main/worker-thread message passing, in practice this seems faster for larger documents. Finally, we'll now always highlight an outline item that the user manually clicked on, since only highlighting when the new "find current outline item"-functionality is used seemed inconsistent. --- [1] Keep in mind that the `outline` itself already isn't fetched/parsed until at least *one* page has been rendered in the viewer. [2] And also quite slow, since it can take a fair amount of time to fetch all of the necessary `destinations` data when `disableAutoFetch = true` is set.
2020-12-25 12:57:43 +01:00
<div class="verticalToolbarSeparator"></div>
Refactor the toolbar html & css to improve its overall accessibility (bug 1171799, bug 1855695) The first goal of this patch was to remove the tabindex because it helps to improve overall a11y. That led to move some html elements associated with the buttons which helped to position these elements relatively to their buttons. Consequently it was easy to change the toolbar height (configurable in Firefox with the pref browser.uidensity): it's the second goal of this patch. For a11y reasons we want to be able to change the height of the toolbar to make the buttons larger.
2024-07-01 22:37:48 +02:00
<button id="currentOutlineItem" class="toolbarButton" type="button" disabled="disabled" title="Find Current Outline Item" tabindex="0" data-l10n-id="pdfjs-current-outline-item-button">
[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 16:23:17 +02:00
<span data-l10n-id="pdfjs-current-outline-item-button-label">Current Outline Item</span>
Add support for finding/highlighting the outlineItem, corresponding to the currently visible page, in the sidebar (issue 7557, bug 1253820, bug 1499050) This implementation is inspired by the behaviour in (recent versions of) Adobe Reader, since it leads to reasonably simple and straightforward code as far as I'm concerned. *Specifically:* We'll only consider *one* destination per page when finding/highlighting the current outline item, which is similar to e.g. Adobe Reader, and we choose the *first* outline item at the *lowest* level of the outline tree. Given that this functionality requires not only parsing of the `outline`, but looking up *all* of the destinations in the document, this feature can when initialized have a non-trivial performance overhead for larger PDF documents. In an attempt to reduce the performance impact, the following steps are taken here: - The "find current outline item"-functionality will only be enabled once *one* page has rendered and *all* the pages have been loaded[1], to prevent it interfering with data regular fetching/parsing early on during document loading and viewer initialization. - With the exception of a couple of small and simple `eventBus`-listeners, in `PDFOutlineViewer`, this new functionality is initialized *lazily* the first time that the user clicks on the `currentOutlineItem`-button. - The entire "find current outline item"-functionality is disabled when `disableAutoFetch = true` is set, since it can easily lead to the setting becoming essentially pointless[2] by triggering *a lot* of data fetching from a relatively minor viewer-feature. - Fetch the destinations *individually*, since that's generally more efficient than using `PDFDocumentProxy.getDestinations` to fetch them all at once. Despite making the overall parsing code *more* asynchronous, and leading to a lot more main/worker-thread message passing, in practice this seems faster for larger documents. Finally, we'll now always highlight an outline item that the user manually clicked on, since only highlighting when the new "find current outline item"-functionality is used seemed inconsistent. --- [1] Keep in mind that the `outline` itself already isn't fetched/parsed until at least *one* page has been rendered in the viewer. [2] And also quite slow, since it can take a fair amount of time to fetch all of the necessary `destinations` data when `disableAutoFetch = true` is set.
2020-12-25 12:57:43 +01:00
</button>
</div>
Minor css tweaks for small viewer and aligning borders.
2012-10-29 14:35:07 -07:00
</div>
Unify the multi_page_viewer and the basic viewer
2011-07-28 19:48:05 +02:00
</div>
Remove flex box. Add side animation. Add dashed line around unload thumbnails.
2012-04-25 11:34:28 -07:00
<div id="sidebarContent">
<div id="thumbnailView">
first mockup, loads tracemonkey pages OK
2012-04-11 16:12:51 -07:00
</div>
Remove flex box. Add side animation. Add dashed line around unload thumbnails.
2012-04-25 11:34:28 -07:00
<div id="outlineView" class="hidden">
first mockup, loads tracemonkey pages OK
2012-04-11 16:12:51 -07:00
</div>
Preliminary attachments support Added a partial Filespec support Added getAttachments in API Added a new attachments view in UI (with a new icon by @shorlander)
2014-03-18 16:32:47 -04:00
<div id="attachmentsView" class="hidden">
</div>
[api-minor] Add support for toggling of Optional Content in the viewer (issue 12096) *Besides, obviously, adding viewer support:* This patch attempts to improve the general API for Optional Content Groups slightly, by adding a couple of new methods for interacting with the (more complex) data structures of `OptionalContentConfig`-instances. (Thus allowing us to mark some of the data as "private", given that it probably shouldn't be manipulated directly.) By utilizing not just the "raw" Optional Content Groups, but the data from the `/Order` array when available, we can thus display the Layers in a proper tree-structure with collapsible headings for PDF documents that utilizes that feature. Note that it's possible to reset all Optional Content Groups to their default visibility state, simply by double-clicking on the Layers-button in the sidebar. (Currently that's indicated in the Layers-button tooltip, which is obviously easy to overlook, however it's probably the best we can do for now without adding more buttons, or even a dropdown-toolbar, to the sidebar.) Also, the current Layers-button icons are a little rough around the edges, quite literally, but given that the viewer will soon have its UI modernized anyway they hopefully suffice in the meantime. To give users *full* control of the visibility of the various Optional Content Groups, even those which according to the `/Order` array should not (by default) be toggleable in the UI, this patch will place those under a *custom* heading which: - Is collapsed by default, and placed at the bottom of the Layers-tree, to be a bit less obtrusive. - Uses a slightly different formatting, compared to the "regular" headings. - Is localizable. Finally, note that the thumbnails are *purposely* always rendered with all Optional Content Groups at their default visibility state, since that seems the most useful and it's also consistent with other viewers. To ensure that this works as intended, we'll thus disable the `PDFThumbnailView.setImage` functionality when the Optional Content Groups have been changed in the viewer. (This obviously means that we'll re-render thumbnails instead of using the rendered pages. However, this situation ought to be rare enough for this to not really be a problem.)
2020-08-06 21:01:03 +02:00
<div id="layersView" class="hidden">
</div>
Switching to the document outline view if the document structure is present
2011-08-21 21:05:10 -05:00
</div>
Remove CSS variables feature-testing from `PDFSidebarResizer` CSS variables are now supported in all reasonably modern browsers, according to: - https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_custom_properties#Browser_compatibility - https://caniuse.com/css-variables
2020-09-09 13:29:44 +02:00
<div id="sidebarResizer"></div>
Remove flex box. Add side animation. Add dashed line around unload thumbnails.
2012-04-25 11:34:28 -07:00
</div> <!-- sidebarContainer -->
<div id="mainContainer">
<div class="toolbar">
<div id="toolbarContainer">
Refactor the toolbar html & css to improve its overall accessibility (bug 1171799, bug 1855695) The first goal of this patch was to remove the tabindex because it helps to improve overall a11y. That led to move some html elements associated with the buttons which helped to position these elements relatively to their buttons. Consequently it was easy to change the toolbar height (configurable in Firefox with the pref browser.uidensity): it's the second goal of this patch. For a11y reasons we want to be able to change the height of the toolbar to make the buttons larger.
2024-07-01 22:37:48 +02:00
<div id="toolbarViewer" class="toolbarHorizontalGroup">
<div id="toolbarViewerLeft" class="toolbarHorizontalGroup">
<button id="sidebarToggleButton" class="toolbarButton" type="button" title="Toggle Sidebar" tabindex="0" data-l10n-id="pdfjs-toggle-sidebar-button" aria-expanded="false" aria-haspopup="true" aria-controls="sidebarContainer">
[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 16:23:17 +02:00
<span data-l10n-id="pdfjs-toggle-sidebar-button-label">Toggle Sidebar</span>
Addressing accessebility aspects
2012-05-04 09:51:21 -05:00
</button>
Remove flex box. Add side animation. Add dashed line around unload thumbnails.
2012-04-25 11:34:28 -07:00
<div class="toolbarButtonSpacer"></div>
Refactor the toolbar html & css to improve its overall accessibility (bug 1171799, bug 1855695) The first goal of this patch was to remove the tabindex because it helps to improve overall a11y. That led to move some html elements associated with the buttons which helped to position these elements relatively to their buttons. Consequently it was easy to change the toolbar height (configurable in Firefox with the pref browser.uidensity): it's the second goal of this patch. For a11y reasons we want to be able to change the height of the toolbar to make the buttons larger.
2024-07-01 22:37:48 +02:00
<div class="toolbarButtonWithContainer">
<button id="viewFindButton" class="toolbarButton" type="button" title="Find in Document" tabindex="0" data-l10n-id="pdfjs-findbar-button" aria-expanded="false" aria-controls="findbar">
<span data-l10n-id="pdfjs-findbar-button-label">Find</span>
</button>
<div class="hidden doorHanger toolbarHorizontalGroup" id="findbar">
<div id="findInputContainer" class="toolbarHorizontalGroup">
<span class="loadingInput end toolbarHorizontalGroup">
<input id="findInput" class="toolbarField" title="Find" placeholder="Find in document…" tabindex="0" data-l10n-id="pdfjs-find-input" aria-invalid="false">
</span>
<div class="toolbarHorizontalGroup">
<button id="findPreviousButton" class="toolbarButton" type="button" title="Find the previous occurrence of the phrase" tabindex="0" data-l10n-id="pdfjs-find-previous-button">
<span data-l10n-id="pdfjs-find-previous-button-label">Previous</span>
</button>
<div class="splitToolbarButtonSeparator"></div>
<button id="findNextButton" class="toolbarButton" type="button" title="Find the next occurrence of the phrase" tabindex="0" data-l10n-id="pdfjs-find-next-button">
<span data-l10n-id="pdfjs-find-next-button-label">Next</span>
</button>
</div>
</div>
<div id="findbarOptionsOneContainer" class="toolbarHorizontalGroup">
<div class="toggleButton toolbarLabel">
<input type="checkbox" id="findHighlightAll" tabindex="0" />
<label for="findHighlightAll" data-l10n-id="pdfjs-find-highlight-checkbox">Highlight All</label>
</div>
<div class="toggleButton toolbarLabel">
<input type="checkbox" id="findMatchCase" tabindex="0" />
<label for="findMatchCase" data-l10n-id="pdfjs-find-match-case-checkbox-label">Match Case</label>
</div>
</div>
<div id="findbarOptionsTwoContainer" class="toolbarHorizontalGroup">
<div class="toggleButton toolbarLabel">
<input type="checkbox" id="findMatchDiacritics" tabindex="0" />
<label for="findMatchDiacritics" data-l10n-id="pdfjs-find-match-diacritics-checkbox-label">Match Diacritics</label>
</div>
<div class="toggleButton toolbarLabel">
<input type="checkbox" id="findEntireWord" tabindex="0" />
<label for="findEntireWord" data-l10n-id="pdfjs-find-entire-word-checkbox-label">Whole Words</label>
</div>
</div>
<div id="findbarMessageContainer" class="toolbarHorizontalGroup" aria-live="polite">
<span id="findResultsCount" class="toolbarLabel"></span>
<span id="findMsg" class="toolbarLabel"></span>
</div>
</div> <!-- findbar -->
</div>
<div class="toolbarHorizontalGroup hiddenSmallView">
<button class="toolbarButton" title="Previous Page" type="button" id="previous" tabindex="0" data-l10n-id="pdfjs-previous-button">
[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 16:23:17 +02:00
<span data-l10n-id="pdfjs-previous-button-label">Previous</span>
Addressing accessebility aspects
2012-05-04 09:51:21 -05:00
</button>
Remove flex box. Add side animation. Add dashed line around unload thumbnails.
2012-04-25 11:34:28 -07:00
<div class="splitToolbarButtonSeparator"></div>
Refactor the toolbar html & css to improve its overall accessibility (bug 1171799, bug 1855695) The first goal of this patch was to remove the tabindex because it helps to improve overall a11y. That led to move some html elements associated with the buttons which helped to position these elements relatively to their buttons. Consequently it was easy to change the toolbar height (configurable in Firefox with the pref browser.uidensity): it's the second goal of this patch. For a11y reasons we want to be able to change the height of the toolbar to make the buttons larger.
2024-07-01 22:37:48 +02:00
<button class="toolbarButton" type="button" title="Next Page" id="next" tabindex="0" data-l10n-id="pdfjs-next-button">
[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 16:23:17 +02:00
<span data-l10n-id="pdfjs-next-button-label">Next</span>
Addressing accessebility aspects
2012-05-04 09:51:21 -05:00
</button>
Remove flex box. Add side animation. Add dashed line around unload thumbnails.
2012-04-25 11:34:28 -07:00
</div>
Refactor the toolbar html & css to improve its overall accessibility (bug 1171799, bug 1855695) The first goal of this patch was to remove the tabindex because it helps to improve overall a11y. That led to move some html elements associated with the buttons which helped to position these elements relatively to their buttons. Consequently it was easy to change the toolbar height (configurable in Firefox with the pref browser.uidensity): it's the second goal of this patch. For a11y reasons we want to be able to change the height of the toolbar to make the buttons larger.
2024-07-01 22:37:48 +02:00
<div class="toolbarHorizontalGroup">
<span class="loadingInput start toolbarHorizontalGroup">
<input type="number" id="pageNumber" class="toolbarField" title="Page" value="1" min="1" tabindex="0" data-l10n-id="pdfjs-page-input" autocomplete="off">
</span>
<span id="numPages" class="toolbarLabel"></span>
[editor] Support disabling of editing when `pdfjs.enablePermissions` is set (issue 15049) For encrypted PDF documents without the required permissions set, this patch adds support for disabling of Annotation-editing. However, please note that it also requires that the `pdfjs.enablePermissions` preference is set to `true` (since PDF document permissions could be seen as user hostile).[1] As I started looking at the issue, it soon became clear that *only* trying to fix the issue without slightly re-factor the surrounding code would be somewhat difficult. The following is an overview of the changes in this patch; sorry about the size/scope of this! - Use a new `AnnotationEditorUIManager`-instance *for each* PDF document opened in the GENERIC viewer, to prevent user-added Annotations from "leaking" from one document into the next. - Re-factor the `BaseViewer.#initializePermissions`-method, to simplify handling of temporarily disabled modes (e.g. for both Annotation-rendering and Annotation-editing). - When editing is enabled, let the Editor-buttons be `disabled` until the document has loaded. This way we avoid the buttons becoming clickable temporarily, for PDF documents that use permissions. - Slightly re-factor how the Editor-buttons are shown/hidden in the viewer, and reset the toolbar-state when a new PDF document is opened. - Flip the order of the Editor-buttons and the pre-exising toolbarButtons in the "toolbarViewerRight"-div. (To help reduce the size, a little bit, for the PR that adds new Editor-toolbars.) - Enable editing by default in the development viewer, i.e. `gulp server`, since having to (repeatedly) do that manually becomes annoying after a while. - Finally, support disabling of editing when `pdfjs.enablePermissions` is set; fixes issue 15049. --- [1] Either manually with `about:config`, or using e.g. a [Group Policy](https://github.com/mozilla/policy-templates).
2022-06-20 18:08:41 +02:00
</div>
Remove flex box. Add side animation. Add dashed line around unload thumbnails.
2012-04-25 11:34:28 -07:00
</div>
Refactor the toolbar html & css to improve its overall accessibility (bug 1171799, bug 1855695) The first goal of this patch was to remove the tabindex because it helps to improve overall a11y. That led to move some html elements associated with the buttons which helped to position these elements relatively to their buttons. Consequently it was easy to change the toolbar height (configurable in Firefox with the pref browser.uidensity): it's the second goal of this patch. For a11y reasons we want to be able to change the height of the toolbar to make the buttons larger.
2024-07-01 22:37:48 +02:00
<div id="toolbarViewerMiddle" class="toolbarHorizontalGroup">
<div class="toolbarHorizontalGroup">
<button id="zoomOutButton" class="toolbarButton" type="button" title="Zoom Out" tabindex="0" data-l10n-id="pdfjs-zoom-out-button">
[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 16:23:17 +02:00
<span data-l10n-id="pdfjs-zoom-out-button-label">Zoom Out</span>
Viewer: improve responsiveness and clean up CSS This patch resolves the responsiveness issues for the toolbar in the viewer. Depending on the language (for example the Dutch language), elements could overlap when the viewport size is reduced. The main issue here is that the CSS rules are unnecessarily complex and handle lots of different cases (LTR/RTL, displacements for specific viewport widths, et cetera). By removing this complexity and letting the browser handle the responsiveness, we not only get simpler CSS rules and HTML mark-up, but the responsiveness issues are mostly fixed at the same time. We no longer have to position the elements manually (by setting their `left` attribute value) anymore.
2016-11-03 16:56:57 +01:00
</button>
<div class="splitToolbarButtonSeparator"></div>
Refactor the toolbar html & css to improve its overall accessibility (bug 1171799, bug 1855695) The first goal of this patch was to remove the tabindex because it helps to improve overall a11y. That led to move some html elements associated with the buttons which helped to position these elements relatively to their buttons. Consequently it was easy to change the toolbar height (configurable in Firefox with the pref browser.uidensity): it's the second goal of this patch. For a11y reasons we want to be able to change the height of the toolbar to make the buttons larger.
2024-07-01 22:37:48 +02:00
<button id="zoomInButton" class="toolbarButton" type="button" title="Zoom In" tabindex="0" data-l10n-id="pdfjs-zoom-in-button">
[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 16:23:17 +02:00
<span data-l10n-id="pdfjs-zoom-in-button-label">Zoom In</span>
Refactor the toolbar html & css to improve its overall accessibility (bug 1171799, bug 1855695) The first goal of this patch was to remove the tabindex because it helps to improve overall a11y. That led to move some html elements associated with the buttons which helped to position these elements relatively to their buttons. Consequently it was easy to change the toolbar height (configurable in Firefox with the pref browser.uidensity): it's the second goal of this patch. For a11y reasons we want to be able to change the height of the toolbar to make the buttons larger.
2024-07-01 22:37:48 +02:00
</button>
Remove flex box. Add side animation. Add dashed line around unload thumbnails.
2012-04-25 11:34:28 -07:00
</div>
Viewer: improve responsiveness and clean up CSS This patch resolves the responsiveness issues for the toolbar in the viewer. Depending on the language (for example the Dutch language), elements could overlap when the viewport size is reduced. The main issue here is that the CSS rules are unnecessarily complex and handle lots of different cases (LTR/RTL, displacements for specific viewport widths, et cetera). By removing this complexity and letting the browser handle the responsiveness, we not only get simpler CSS rules and HTML mark-up, but the responsiveness issues are mostly fixed at the same time. We no longer have to position the elements manually (by setting their `left` attribute value) anymore.
2016-11-03 16:56:57 +01:00
<span id="scaleSelectContainer" class="dropdownToolbarButton">
Refactor the toolbar html & css to improve its overall accessibility (bug 1171799, bug 1855695) The first goal of this patch was to remove the tabindex because it helps to improve overall a11y. That led to move some html elements associated with the buttons which helped to position these elements relatively to their buttons. Consequently it was easy to change the toolbar height (configurable in Firefox with the pref browser.uidensity): it's the second goal of this patch. For a11y reasons we want to be able to change the height of the toolbar to make the buttons larger.
2024-07-01 22:37:48 +02:00
<select id="scaleSelect" title="Zoom" tabindex="0" data-l10n-id="pdfjs-zoom-select">
[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 16:23:17 +02:00
<option id="pageAutoOption" title="" value="auto" selected="selected" data-l10n-id="pdfjs-page-scale-auto">Automatic Zoom</option>
<option id="pageActualOption" title="" value="page-actual" data-l10n-id="pdfjs-page-scale-actual">Actual Size</option>
<option id="pageFitOption" title="" value="page-fit" data-l10n-id="pdfjs-page-scale-fit">Page Fit</option>
<option id="pageWidthOption" title="" value="page-width" data-l10n-id="pdfjs-page-scale-width">Page Width</option>
[api-minor] Use "data-l10n-id"/"data-l10n-args", rather than manually updating DOM-elements, to trigger translation (PR 17146 follow-up) This patch changes almost all viewer-components[1] to use "data-l10n-id"/"data-l10n-args" for localization, which means that in many cases we no longer need to pass around the `L10n`-instance any more. One part of the code-base where the `L10n`-instance is still being used "directly" is the AnnotationEditors, however while it might be possible to convert (most of) that code as well that's not attempted in this patch. --- [1] The one exception is the `PDFDocumentProperties` dialog, since the way it's currently implemented makes that less straightforward to fix without a lot of code changes.
2023-10-19 16:30:57 +02:00
<option id="customScaleOption" title="" value="custom" disabled="disabled" hidden="true" data-l10n-id="pdfjs-page-scale-percent" data-l10n-args='{ "scale": 0 }'>0%</option>
[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 16:23:17 +02:00
<option title="" value="0.5" data-l10n-id="pdfjs-page-scale-percent" data-l10n-args='{ "scale": 50 }'>50%</option>
<option title="" value="0.75" data-l10n-id="pdfjs-page-scale-percent" data-l10n-args='{ "scale": 75 }'>75%</option>
<option title="" value="1" data-l10n-id="pdfjs-page-scale-percent" data-l10n-args='{ "scale": 100 }'>100%</option>
<option title="" value="1.25" data-l10n-id="pdfjs-page-scale-percent" data-l10n-args='{ "scale": 125 }'>125%</option>
<option title="" value="1.5" data-l10n-id="pdfjs-page-scale-percent" data-l10n-args='{ "scale": 150 }'>150%</option>
<option title="" value="2" data-l10n-id="pdfjs-page-scale-percent" data-l10n-args='{ "scale": 200 }'>200%</option>
<option title="" value="3" data-l10n-id="pdfjs-page-scale-percent" data-l10n-args='{ "scale": 300 }'>300%</option>
<option title="" value="4" data-l10n-id="pdfjs-page-scale-percent" data-l10n-args='{ "scale": 400 }'>400%</option>
Viewer: improve responsiveness and clean up CSS This patch resolves the responsiveness issues for the toolbar in the viewer. Depending on the language (for example the Dutch language), elements could overlap when the viewport size is reduced. The main issue here is that the CSS rules are unnecessarily complex and handle lots of different cases (LTR/RTL, displacements for specific viewport widths, et cetera). By removing this complexity and letting the browser handle the responsiveness, we not only get simpler CSS rules and HTML mark-up, but the responsiveness issues are mostly fixed at the same time. We no longer have to position the elements manually (by setting their `left` attribute value) anymore.
2016-11-03 16:56:57 +01:00
</select>
</span>
Remove flex box. Add side animation. Add dashed line around unload thumbnails.
2012-04-25 11:34:28 -07:00
</div>
Refactor the toolbar html & css to improve its overall accessibility (bug 1171799, bug 1855695) The first goal of this patch was to remove the tabindex because it helps to improve overall a11y. That led to move some html elements associated with the buttons which helped to position these elements relatively to their buttons. Consequently it was easy to change the toolbar height (configurable in Firefox with the pref browser.uidensity): it's the second goal of this patch. For a11y reasons we want to be able to change the height of the toolbar to make the buttons larger.
2024-07-01 22:37:48 +02:00
<div id="toolbarViewerRight" class="toolbarHorizontalGroup">
<div id="editorModeButtons" class="toolbarHorizontalGroup" role="radiogroup">
<div id="editorHighlight" class="toolbarButtonWithContainer">
<button id="editorHighlightButton" class="toolbarButton" type="button" disabled="disabled" title="Highlight" role="radio" aria-expanded="false" aria-haspopup="true" aria-controls="editorHighlightParamsToolbar" tabindex="0" data-l10n-id="pdfjs-editor-highlight-button">
<span data-l10n-id="pdfjs-editor-highlight-button-label">Highlight</span>
</button>
<div class="editorParamsToolbar hidden doorHangerRight" id="editorHighlightParamsToolbar">
<div id="highlightParamsToolbarContainer" class="editorParamsToolbarContainer">
<div id="editorHighlightColorPicker" class="colorPicker">
<span id="highlightColorPickerLabel" class="editorParamsLabel" data-l10n-id="pdfjs-editor-highlight-colorpicker-label">Highlight color</span>
</div>
<div id="editorHighlightThickness">
<label for="editorFreeHighlightThickness" class="editorParamsLabel" data-l10n-id="pdfjs-editor-free-highlight-thickness-input">Thickness</label>
<div class="thicknessPicker">
<input type="range" id="editorFreeHighlightThickness" class="editorParamsSlider" data-l10n-id="pdfjs-editor-free-highlight-thickness-title" value="12" min="8" max="24" step="1" tabindex="0">
</div>
</div>
<div id="editorHighlightVisibility">
<div class="divider"></div>
<div class="toggler">
<label for="editorHighlightShowAll" class="editorParamsLabel" data-l10n-id="pdfjs-editor-highlight-show-all-button-label">Show all</label>
<button id="editorHighlightShowAll" class="toggle-button" type="button" data-l10n-id="pdfjs-editor-highlight-show-all-button" aria-pressed="true" tabindex="0"></button>
</div>
</div>
</div>
</div>
</div>
<div id="editorFreeText" class="toolbarButtonWithContainer">
<button id="editorFreeTextButton" class="toolbarButton" type="button" disabled="disabled" title="Text" role="radio" aria-expanded="false" aria-haspopup="true" aria-controls="editorFreeTextParamsToolbar" tabindex="0" data-l10n-id="pdfjs-editor-free-text-button">
<span data-l10n-id="pdfjs-editor-free-text-button-label">Text</span>
</button>
<div class="editorParamsToolbar hidden doorHangerRight" id="editorFreeTextParamsToolbar">
<div class="editorParamsToolbarContainer">
<div class="editorParamsSetter">
<label for="editorFreeTextColor" class="editorParamsLabel" data-l10n-id="pdfjs-editor-free-text-color-input">Color</label>
<input type="color" id="editorFreeTextColor" class="editorParamsColor" tabindex="0">
</div>
<div class="editorParamsSetter">
<label for="editorFreeTextFontSize" class="editorParamsLabel" data-l10n-id="pdfjs-editor-free-text-size-input">Size</label>
<input type="range" id="editorFreeTextFontSize" class="editorParamsSlider" value="10" min="5" max="100" step="1" tabindex="0">
</div>
</div>
</div>
</div>
<div id="editorInk" class="toolbarButtonWithContainer">
<button id="editorInkButton" class="toolbarButton" type="button" disabled="disabled" title="Draw" role="radio" aria-expanded="false" aria-haspopup="true" aria-controls="editorInkParamsToolbar" tabindex="0" data-l10n-id="pdfjs-editor-ink-button">
<span data-l10n-id="pdfjs-editor-ink-button-label">Draw</span>
</button>
<div class="editorParamsToolbar hidden doorHangerRight" id="editorInkParamsToolbar">
<div class="editorParamsToolbarContainer">
<div class="editorParamsSetter">
<label for="editorInkColor" class="editorParamsLabel" data-l10n-id="pdfjs-editor-ink-color-input">Color</label>
<input type="color" id="editorInkColor" class="editorParamsColor" tabindex="0">
</div>
<div class="editorParamsSetter">
<label for="editorInkThickness" class="editorParamsLabel" data-l10n-id="pdfjs-editor-ink-thickness-input">Thickness</label>
<input type="range" id="editorInkThickness" class="editorParamsSlider" value="1" min="1" max="20" step="1" tabindex="0">
</div>
<div class="editorParamsSetter">
<label for="editorInkOpacity" class="editorParamsLabel" data-l10n-id="pdfjs-editor-ink-opacity-input">Opacity</label>
<input type="range" id="editorInkOpacity" class="editorParamsSlider" value="100" min="1" max="100" step="1" tabindex="0">
</div>
</div>
</div>
</div>
<div id="editorStamp" class="toolbarButtonWithContainer">
<button id="editorStampButton" class="toolbarButton" type="button" disabled="disabled" title="Add or edit images" role="radio" aria-expanded="false" aria-haspopup="true" aria-controls="editorStampParamsToolbar" tabindex="0" data-l10n-id="pdfjs-editor-stamp-button">
<span data-l10n-id="pdfjs-editor-stamp-button-label">Add or edit images</span>
</button>
Increase the size of the toolbar depending on the uidensity (bug 1171799)
2024-09-24 15:37:42 +02:00
<div class="editorParamsToolbar hidden doorHangerRight menu" id="editorStampParamsToolbar">
Refactor the toolbar html & css to improve its overall accessibility (bug 1171799, bug 1855695) The first goal of this patch was to remove the tabindex because it helps to improve overall a11y. That led to move some html elements associated with the buttons which helped to position these elements relatively to their buttons. Consequently it was easy to change the toolbar height (configurable in Firefox with the pref browser.uidensity): it's the second goal of this patch. For a11y reasons we want to be able to change the height of the toolbar to make the buttons larger.
2024-07-01 22:37:48 +02:00
<div class="menuContainer">
<button id="editorStampAddImage" class="toolbarButton labeled" type="button" title="Add image" tabindex="0" data-l10n-id="pdfjs-editor-stamp-add-image-button">
<span class="editorParamsLabel" data-l10n-id="pdfjs-editor-stamp-add-image-button-label">Add image</span>
</button>
</div>
</div>
</div>
</div>
<div id="editorModeSeparator" class="verticalToolbarSeparator"></div>
<div class="toolbarHorizontalGroup hiddenMediumView">
<button id="printButton" class="toolbarButton" type="button" title="Print" tabindex="0" data-l10n-id="pdfjs-print-button">
<span data-l10n-id="pdfjs-print-button-label">Print</span>
</button>
<button id="downloadButton" class="toolbarButton" type="button" title="Save" tabindex="0" data-l10n-id="pdfjs-save-button">
<span data-l10n-id="pdfjs-save-button-label">Save</span>
</button>
</div>
<div class="verticalToolbarSeparator hiddenMediumView"></div>
<div id="secondaryToolbarToggle" class="toolbarButtonWithContainer">
<button id="secondaryToolbarToggleButton" class="toolbarButton" type="button" title="Tools" tabindex="0" data-l10n-id="pdfjs-tools-button" aria-expanded="false" aria-haspopup="true" aria-controls="secondaryToolbar">
<span data-l10n-id="pdfjs-tools-button-label">Tools</span>
</button>
Increase the size of the toolbar depending on the uidensity (bug 1171799)
2024-09-24 15:37:42 +02:00
<div id="secondaryToolbar" class="hidden doorHangerRight menu">
Refactor the toolbar html & css to improve its overall accessibility (bug 1171799, bug 1855695) The first goal of this patch was to remove the tabindex because it helps to improve overall a11y. That led to move some html elements associated with the buttons which helped to position these elements relatively to their buttons. Consequently it was easy to change the toolbar height (configurable in Firefox with the pref browser.uidensity): it's the second goal of this patch. For a11y reasons we want to be able to change the height of the toolbar to make the buttons larger.
2024-07-01 22:37:48 +02:00
<div id="secondaryToolbarButtonContainer" class="menuContainer">
<!--#if GENERIC-->
<button id="secondaryOpenFile" class="toolbarButton labeled" type="button" title="Open File" tabindex="0" data-l10n-id="pdfjs-open-file-button">
<span data-l10n-id="pdfjs-open-file-button-label">Open</span>
</button>
<!--#endif-->
<div class="visibleMediumView">
<button id="secondaryPrint" class="toolbarButton labeled" type="button" title="Print" tabindex="0" data-l10n-id="pdfjs-print-button">
<span data-l10n-id="pdfjs-print-button-label">Print</span>
</button>
<button id="secondaryDownload" class="toolbarButton labeled" type="button" title="Save" tabindex="0" data-l10n-id="pdfjs-save-button">
<span data-l10n-id="pdfjs-save-button-label">Save</span>
</button>
<!--#if !GENERIC-->
<!-- <div class="horizontalToolbarSeparator"></div>-->
<!--#endif-->
</div>
<!--#if GENERIC-->
<div class="horizontalToolbarSeparator"></div>
<!--#endif-->
<button id="presentationMode" class="toolbarButton labeled" type="button" title="Switch to Presentation Mode" tabindex="0" data-l10n-id="pdfjs-presentation-mode-button">
<span data-l10n-id="pdfjs-presentation-mode-button-label">Presentation Mode</span>
</button>
<a href="#" id="viewBookmark" class="toolbarButton labeled" title="Current Page (View URL from Current Page)" tabindex="0" data-l10n-id="pdfjs-bookmark-button">
<span data-l10n-id="pdfjs-bookmark-button-label">Current Page</span>
</a>
<div id="viewBookmarkSeparator" class="horizontalToolbarSeparator"></div>
<button id="firstPage" class="toolbarButton labeled" type="button" title="Go to First Page" tabindex="0" data-l10n-id="pdfjs-first-page-button">
<span data-l10n-id="pdfjs-first-page-button-label">Go to First Page</span>
</button>
<button id="lastPage" class="toolbarButton labeled" type="button" title="Go to Last Page" tabindex="0" data-l10n-id="pdfjs-last-page-button">
<span data-l10n-id="pdfjs-last-page-button-label">Go to Last Page</span>
</button>
<div class="horizontalToolbarSeparator"></div>
<button id="pageRotateCw" class="toolbarButton labeled" type="button" title="Rotate Clockwise" tabindex="0" data-l10n-id="pdfjs-page-rotate-cw-button">
<span data-l10n-id="pdfjs-page-rotate-cw-button-label">Rotate Clockwise</span>
</button>
<button id="pageRotateCcw" class="toolbarButton labeled" type="button" title="Rotate Counterclockwise" tabindex="0" data-l10n-id="pdfjs-page-rotate-ccw-button">
<span data-l10n-id="pdfjs-page-rotate-ccw-button-label">Rotate Counterclockwise</span>
</button>
<div class="horizontalToolbarSeparator"></div>
<div id="cursorToolButtons" role="radiogroup">
<button id="cursorSelectTool" class="toolbarButton labeled toggled" type="button" title="Enable Text Selection Tool" tabindex="0" data-l10n-id="pdfjs-cursor-text-select-tool-button" role="radio" aria-checked="true">
<span data-l10n-id="pdfjs-cursor-text-select-tool-button-label">Text Selection Tool</span>
</button>
<button id="cursorHandTool" class="toolbarButton labeled" type="button" title="Enable Hand Tool" tabindex="0" data-l10n-id="pdfjs-cursor-hand-tool-button" role="radio" aria-checked="false">
<span data-l10n-id="pdfjs-cursor-hand-tool-button-label">Hand Tool</span>
</button>
</div>
<div class="horizontalToolbarSeparator"></div>
<div id="scrollModeButtons" role="radiogroup">
<button id="scrollPage" class="toolbarButton labeled" type="button" title="Use Page Scrolling" tabindex="0" data-l10n-id="pdfjs-scroll-page-button" role="radio" aria-checked="false">
<span data-l10n-id="pdfjs-scroll-page-button-label">Page Scrolling</span>
</button>
<button id="scrollVertical" class="toolbarButton labeled toggled" type="button" title="Use Vertical Scrolling" tabindex="0" data-l10n-id="pdfjs-scroll-vertical-button" role="radio" aria-checked="true">
<span data-l10n-id="pdfjs-scroll-vertical-button-label">Vertical Scrolling</span>
</button>
<button id="scrollHorizontal" class="toolbarButton labeled" type="button" title="Use Horizontal Scrolling" tabindex="0" data-l10n-id="pdfjs-scroll-horizontal-button" role="radio" aria-checked="false">
<span data-l10n-id="pdfjs-scroll-horizontal-button-label">Horizontal Scrolling</span>
</button>
<button id="scrollWrapped" class="toolbarButton labeled" type="button" title="Use Wrapped Scrolling" tabindex="0" data-l10n-id="pdfjs-scroll-wrapped-button" role="radio" aria-checked="false">
<span data-l10n-id="pdfjs-scroll-wrapped-button-label">Wrapped Scrolling</span>
</button>
</div>
<div class="horizontalToolbarSeparator"></div>
<div id="spreadModeButtons" role="radiogroup">
<button id="spreadNone" class="toolbarButton labeled toggled" type="button" title="Do not join page spreads" tabindex="0" data-l10n-id="pdfjs-spread-none-button" role="radio" aria-checked="true">
<span data-l10n-id="pdfjs-spread-none-button-label">No Spreads</span>
</button>
<button id="spreadOdd" class="toolbarButton labeled" type="button" title="Join page spreads starting with odd-numbered pages" tabindex="0" data-l10n-id="pdfjs-spread-odd-button" role="radio" aria-checked="false">
<span data-l10n-id="pdfjs-spread-odd-button-label">Odd Spreads</span>
</button>
<button id="spreadEven" class="toolbarButton labeled" type="button" title="Join page spreads starting with even-numbered pages" tabindex="0" data-l10n-id="pdfjs-spread-even-button" role="radio" aria-checked="false">
<span data-l10n-id="pdfjs-spread-even-button-label">Even Spreads</span>
</button>
</div>
<div id="imageAltTextSettingsSeparator" class="horizontalToolbarSeparator hidden"></div>
<button id="imageAltTextSettings" type="button" class="toolbarButton labeled hidden" title="Image alt text settings" tabindex="0" data-l10n-id="pdfjs-image-alt-text-settings-button" aria-controls="altTextSettingsDialog">
<span data-l10n-id="pdfjs-image-alt-text-settings-button-label">Image alt text settings</span>
</button>
<div class="horizontalToolbarSeparator"></div>
<button id="documentProperties" class="toolbarButton labeled" type="button" title="Document Properties…" tabindex="0" data-l10n-id="pdfjs-document-properties-button" aria-controls="documentPropertiesDialog">
<span data-l10n-id="pdfjs-document-properties-button-label">Document Properties…</span>
</button>
</div>
</div> <!-- secondaryToolbar -->
</div>
</div>
Remove flex box. Add side animation. Add dashed line around unload thumbnails.
2012-04-25 11:34:28 -07:00
</div>
Implement progressive loading of PDFs
2013-02-06 15:19:29 -08:00
<div id="loadingBar">
<div class="progress">
<div class="glimmer">
</div>
</div>
</div>
Simple search results
2011-12-11 19:38:20 -06:00
</div>
</div>
Separate js and css from the test.html file
2011-05-26 16:02:52 +02:00
Allow scrolling by keyboard in Chrome/Opera Set "tabindex" attribute to allow focus; Added "outline: none" to prevent focus ring from appearing. Fixes #3443
2013-07-06 15:37:03 +02:00
<div id="viewerContainer" tabindex="0">
Move text_layer_builder and pdf_viewer styles out
2014-09-30 10:48:29 -05:00
<div id="viewer" class="pdfViewer"></div>
Unify the multi_page_viewer and the basic viewer
2011-07-28 19:48:05 +02:00
</div>
Remove flex box. Add side animation. Add dashed line around unload thumbnails.
2012-04-25 11:34:28 -07:00
</div> <!-- mainContainer -->
Make worker support work again after file split. Add PDFJS_WORKER_DIR/PDFJS_WORKER_FILE to specify where to load files if worker support is enabled
2011-10-28 14:32:36 +02:00
Convert the existing overlays to use `<dialog>` elements (issue 14698) This replaces our *custom* overlays with standard `<dialog>` DOM elements, see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog, thus simplifying the related CSS, HTML, and JavaScript code. With these changes, some of the functionality of the `OverlayManager` class is now handled natively (e.g. `Esc` to close the dialog). However, since we still need to be able to prevent dialogs from overlaying one another, it still makes sense to keep this functionality (as far as I'm concerned).
2022-03-25 14:10:13 +01:00
<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 16:23:17 +02:00
<label for="password" id="passwordText" data-l10n-id="pdfjs-password-label">Enter the password to open this PDF file:</label>
Document properties
2014-01-22 00:07:07 +01:00
</div>
Convert the existing overlays to use `<dialog>` elements (issue 14698) This replaces our *custom* overlays with standard `<dialog>` DOM elements, see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog, thus simplifying the related CSS, HTML, and JavaScript code. With these changes, some of the functionality of the `OverlayManager` class is now handled natively (e.g. `Esc` to close the dialog). However, since we still need to be able to prevent dialogs from overlaying one another, it still makes sense to keep this functionality (as far as I'm concerned).
2022-03-25 14:10:13 +01:00
<div class="row">
<input type="password" id="password" class="toolbarField">
Improved password prompt
2013-09-24 17:46:54 +02:00
</div>
Convert the existing overlays to use `<dialog>` elements (issue 14698) This replaces our *custom* overlays with standard `<dialog>` DOM elements, see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog, thus simplifying the related CSS, HTML, and JavaScript code. With these changes, some of the functionality of the `OverlayManager` class is now handled natively (e.g. `Esc` to close the dialog). However, since we still need to be able to prevent dialogs from overlaying one another, it still makes sense to keep this functionality (as far as I'm concerned).
2022-03-25 14:10:13 +01:00
<div class="buttonRow">
Give all HTML button elements a type The HTML button elements we use are all regular buttons that don't submit form data to a server. According to https://developer.mozilla.org/en-US/docs/Web/HTML/Element/button#notes those buttons should all have their type set to `button` explicitly, but we only do that a handful of them. This commit fixes the issue by consistently giving all our buttons the `button` type. Co-authored-by: Calixte Denizet <calixte.denizet@gmail.com>
2024-07-30 18:35:12 +02:00
<button id="passwordCancel" class="dialogButton" type="button"><span data-l10n-id="pdfjs-password-cancel-button">Cancel</span></button>
<button id="passwordSubmit" class="dialogButton" type="button"><span data-l10n-id="pdfjs-password-ok-button">OK</span></button>
Convert the existing overlays to use `<dialog>` elements (issue 14698) This replaces our *custom* overlays with standard `<dialog>` DOM elements, see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog, thus simplifying the related CSS, HTML, and JavaScript code. With these changes, some of the functionality of the `OverlayManager` class is now handled natively (e.g. `Esc` to close the dialog). However, since we still need to be able to prevent dialogs from overlaying one another, it still makes sense to keep this functionality (as far as I'm concerned).
2022-03-25 14:10:13 +01:00
</div>
</dialog>
<dialog id="documentPropertiesDialog">
<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 16:23:17 +02:00
<span id="fileNameLabel" data-l10n-id="pdfjs-document-properties-file-name">File name:</span>
Try to improve a11y for the `PasswordPrompt` and `PDFDocumentProperties` dialogs This will hopefully improve the a11y a little bit in these dialogs, however there's most definately more things that can be done here (by someone more knowledgeable about a11y).
2022-03-25 14:10:28 +01:00
<p id="fileNameField" aria-labelledby="fileNameLabel">-</p>
Convert the existing overlays to use `<dialog>` elements (issue 14698) This replaces our *custom* overlays with standard `<dialog>` DOM elements, see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog, thus simplifying the related CSS, HTML, and JavaScript code. With these changes, some of the functionality of the `OverlayManager` class is now handled natively (e.g. `Esc` to close the dialog). However, since we still need to be able to prevent dialogs from overlaying one another, it still makes sense to keep this functionality (as far as I'm concerned).
2022-03-25 14:10:13 +01:00
</div>
<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 16:23:17 +02:00
<span id="fileSizeLabel" data-l10n-id="pdfjs-document-properties-file-size">File size:</span>
Try to improve a11y for the `PasswordPrompt` and `PDFDocumentProperties` dialogs This will hopefully improve the a11y a little bit in these dialogs, however there's most definately more things that can be done here (by someone more knowledgeable about a11y).
2022-03-25 14:10:28 +01:00
<p id="fileSizeField" aria-labelledby="fileSizeLabel">-</p>
Convert the existing overlays to use `<dialog>` elements (issue 14698) This replaces our *custom* overlays with standard `<dialog>` DOM elements, see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog, thus simplifying the related CSS, HTML, and JavaScript code. With these changes, some of the functionality of the `OverlayManager` class is now handled natively (e.g. `Esc` to close the dialog). However, since we still need to be able to prevent dialogs from overlaying one another, it still makes sense to keep this functionality (as far as I'm concerned).
2022-03-25 14:10:13 +01:00
</div>
<div class="separator"></div>
<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 16:23:17 +02:00
<span id="titleLabel" data-l10n-id="pdfjs-document-properties-title">Title:</span>
Try to improve a11y for the `PasswordPrompt` and `PDFDocumentProperties` dialogs This will hopefully improve the a11y a little bit in these dialogs, however there's most definately more things that can be done here (by someone more knowledgeable about a11y).
2022-03-25 14:10:28 +01:00
<p id="titleField" aria-labelledby="titleLabel">-</p>
Convert the existing overlays to use `<dialog>` elements (issue 14698) This replaces our *custom* overlays with standard `<dialog>` DOM elements, see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog, thus simplifying the related CSS, HTML, and JavaScript code. With these changes, some of the functionality of the `OverlayManager` class is now handled natively (e.g. `Esc` to close the dialog). However, since we still need to be able to prevent dialogs from overlaying one another, it still makes sense to keep this functionality (as far as I'm concerned).
2022-03-25 14:10:13 +01:00
</div>
<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 16:23:17 +02:00
<span id="authorLabel" data-l10n-id="pdfjs-document-properties-author">Author:</span>
Try to improve a11y for the `PasswordPrompt` and `PDFDocumentProperties` dialogs This will hopefully improve the a11y a little bit in these dialogs, however there's most definately more things that can be done here (by someone more knowledgeable about a11y).
2022-03-25 14:10:28 +01:00
<p id="authorField" aria-labelledby="authorLabel">-</p>
Convert the existing overlays to use `<dialog>` elements (issue 14698) This replaces our *custom* overlays with standard `<dialog>` DOM elements, see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog, thus simplifying the related CSS, HTML, and JavaScript code. With these changes, some of the functionality of the `OverlayManager` class is now handled natively (e.g. `Esc` to close the dialog). However, since we still need to be able to prevent dialogs from overlaying one another, it still makes sense to keep this functionality (as far as I'm concerned).
2022-03-25 14:10:13 +01:00
</div>
<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 16:23:17 +02:00
<span id="subjectLabel" data-l10n-id="pdfjs-document-properties-subject">Subject:</span>
Try to improve a11y for the `PasswordPrompt` and `PDFDocumentProperties` dialogs This will hopefully improve the a11y a little bit in these dialogs, however there's most definately more things that can be done here (by someone more knowledgeable about a11y).
2022-03-25 14:10:28 +01:00
<p id="subjectField" aria-labelledby="subjectLabel">-</p>
Convert the existing overlays to use `<dialog>` elements (issue 14698) This replaces our *custom* overlays with standard `<dialog>` DOM elements, see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog, thus simplifying the related CSS, HTML, and JavaScript code. With these changes, some of the functionality of the `OverlayManager` class is now handled natively (e.g. `Esc` to close the dialog). However, since we still need to be able to prevent dialogs from overlaying one another, it still makes sense to keep this functionality (as far as I'm concerned).
2022-03-25 14:10:13 +01:00
</div>
<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 16:23:17 +02:00
<span id="keywordsLabel" data-l10n-id="pdfjs-document-properties-keywords">Keywords:</span>
Try to improve a11y for the `PasswordPrompt` and `PDFDocumentProperties` dialogs This will hopefully improve the a11y a little bit in these dialogs, however there's most definately more things that can be done here (by someone more knowledgeable about a11y).
2022-03-25 14:10:28 +01:00
<p id="keywordsField" aria-labelledby="keywordsLabel">-</p>
Convert the existing overlays to use `<dialog>` elements (issue 14698) This replaces our *custom* overlays with standard `<dialog>` DOM elements, see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog, thus simplifying the related CSS, HTML, and JavaScript code. With these changes, some of the functionality of the `OverlayManager` class is now handled natively (e.g. `Esc` to close the dialog). However, since we still need to be able to prevent dialogs from overlaying one another, it still makes sense to keep this functionality (as far as I'm concerned).
2022-03-25 14:10:13 +01:00
</div>
<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 16:23:17 +02:00
<span id="creationDateLabel" data-l10n-id="pdfjs-document-properties-creation-date">Creation Date:</span>
Try to improve a11y for the `PasswordPrompt` and `PDFDocumentProperties` dialogs This will hopefully improve the a11y a little bit in these dialogs, however there's most definately more things that can be done here (by someone more knowledgeable about a11y).
2022-03-25 14:10:28 +01:00
<p id="creationDateField" aria-labelledby="creationDateLabel">-</p>
Convert the existing overlays to use `<dialog>` elements (issue 14698) This replaces our *custom* overlays with standard `<dialog>` DOM elements, see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog, thus simplifying the related CSS, HTML, and JavaScript code. With these changes, some of the functionality of the `OverlayManager` class is now handled natively (e.g. `Esc` to close the dialog). However, since we still need to be able to prevent dialogs from overlaying one another, it still makes sense to keep this functionality (as far as I'm concerned).
2022-03-25 14:10:13 +01:00
</div>
<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 16:23:17 +02:00
<span id="modificationDateLabel" data-l10n-id="pdfjs-document-properties-modification-date">Modification Date:</span>
Try to improve a11y for the `PasswordPrompt` and `PDFDocumentProperties` dialogs This will hopefully improve the a11y a little bit in these dialogs, however there's most definately more things that can be done here (by someone more knowledgeable about a11y).
2022-03-25 14:10:28 +01:00
<p id="modificationDateField" aria-labelledby="modificationDateLabel">-</p>
Convert the existing overlays to use `<dialog>` elements (issue 14698) This replaces our *custom* overlays with standard `<dialog>` DOM elements, see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog, thus simplifying the related CSS, HTML, and JavaScript code. With these changes, some of the functionality of the `OverlayManager` class is now handled natively (e.g. `Esc` to close the dialog). However, since we still need to be able to prevent dialogs from overlaying one another, it still makes sense to keep this functionality (as far as I'm concerned).
2022-03-25 14:10:13 +01:00
</div>
<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 16:23:17 +02:00
<span id="creatorLabel" data-l10n-id="pdfjs-document-properties-creator">Creator:</span>
Try to improve a11y for the `PasswordPrompt` and `PDFDocumentProperties` dialogs This will hopefully improve the a11y a little bit in these dialogs, however there's most definately more things that can be done here (by someone more knowledgeable about a11y).
2022-03-25 14:10:28 +01:00
<p id="creatorField" aria-labelledby="creatorLabel">-</p>
Convert the existing overlays to use `<dialog>` elements (issue 14698) This replaces our *custom* overlays with standard `<dialog>` DOM elements, see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog, thus simplifying the related CSS, HTML, and JavaScript code. With these changes, some of the functionality of the `OverlayManager` class is now handled natively (e.g. `Esc` to close the dialog). However, since we still need to be able to prevent dialogs from overlaying one another, it still makes sense to keep this functionality (as far as I'm concerned).
2022-03-25 14:10:13 +01:00
</div>
<div class="separator"></div>
<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 16:23:17 +02:00
<span id="producerLabel" data-l10n-id="pdfjs-document-properties-producer">PDF Producer:</span>
Try to improve a11y for the `PasswordPrompt` and `PDFDocumentProperties` dialogs This will hopefully improve the a11y a little bit in these dialogs, however there's most definately more things that can be done here (by someone more knowledgeable about a11y).
2022-03-25 14:10:28 +01:00
<p id="producerField" aria-labelledby="producerLabel">-</p>
Convert the existing overlays to use `<dialog>` elements (issue 14698) This replaces our *custom* overlays with standard `<dialog>` DOM elements, see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog, thus simplifying the related CSS, HTML, and JavaScript code. With these changes, some of the functionality of the `OverlayManager` class is now handled natively (e.g. `Esc` to close the dialog). However, since we still need to be able to prevent dialogs from overlaying one another, it still makes sense to keep this functionality (as far as I'm concerned).
2022-03-25 14:10:13 +01:00
</div>
<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 16:23:17 +02:00
<span id="versionLabel" data-l10n-id="pdfjs-document-properties-version">PDF Version:</span>
Try to improve a11y for the `PasswordPrompt` and `PDFDocumentProperties` dialogs This will hopefully improve the a11y a little bit in these dialogs, however there's most definately more things that can be done here (by someone more knowledgeable about a11y).
2022-03-25 14:10:28 +01:00
<p id="versionField" aria-labelledby="versionLabel">-</p>
Convert the existing overlays to use `<dialog>` elements (issue 14698) This replaces our *custom* overlays with standard `<dialog>` DOM elements, see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog, thus simplifying the related CSS, HTML, and JavaScript code. With these changes, some of the functionality of the `OverlayManager` class is now handled natively (e.g. `Esc` to close the dialog). However, since we still need to be able to prevent dialogs from overlaying one another, it still makes sense to keep this functionality (as far as I'm concerned).
2022-03-25 14:10:13 +01:00
</div>
<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 16:23:17 +02:00
<span id="pageCountLabel" data-l10n-id="pdfjs-document-properties-page-count">Page Count:</span>
Try to improve a11y for the `PasswordPrompt` and `PDFDocumentProperties` dialogs This will hopefully improve the a11y a little bit in these dialogs, however there's most definately more things that can be done here (by someone more knowledgeable about a11y).
2022-03-25 14:10:28 +01:00
<p id="pageCountField" aria-labelledby="pageCountLabel">-</p>
Convert the existing overlays to use `<dialog>` elements (issue 14698) This replaces our *custom* overlays with standard `<dialog>` DOM elements, see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog, thus simplifying the related CSS, HTML, and JavaScript code. With these changes, some of the functionality of the `OverlayManager` class is now handled natively (e.g. `Esc` to close the dialog). However, since we still need to be able to prevent dialogs from overlaying one another, it still makes sense to keep this functionality (as far as I'm concerned).
2022-03-25 14:10:13 +01:00
</div>
<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 16:23:17 +02:00
<span id="pageSizeLabel" data-l10n-id="pdfjs-document-properties-page-size">Page Size:</span>
Try to improve a11y for the `PasswordPrompt` and `PDFDocumentProperties` dialogs This will hopefully improve the a11y a little bit in these dialogs, however there's most definately more things that can be done here (by someone more knowledgeable about a11y).
2022-03-25 14:10:28 +01:00
<p id="pageSizeField" aria-labelledby="pageSizeLabel">-</p>
Convert the existing overlays to use `<dialog>` elements (issue 14698) This replaces our *custom* overlays with standard `<dialog>` DOM elements, see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog, thus simplifying the related CSS, HTML, and JavaScript code. With these changes, some of the functionality of the `OverlayManager` class is now handled natively (e.g. `Esc` to close the dialog). However, since we still need to be able to prevent dialogs from overlaying one another, it still makes sense to keep this functionality (as far as I'm concerned).
2022-03-25 14:10:13 +01:00
</div>
<div class="separator"></div>
<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 16:23:17 +02:00
<span id="linearizedLabel" data-l10n-id="pdfjs-document-properties-linearized">Fast Web View:</span>
Try to improve a11y for the `PasswordPrompt` and `PDFDocumentProperties` dialogs This will hopefully improve the a11y a little bit in these dialogs, however there's most definately more things that can be done here (by someone more knowledgeable about a11y).
2022-03-25 14:10:28 +01:00
<p id="linearizedField" aria-labelledby="linearizedLabel">-</p>
Convert the existing overlays to use `<dialog>` elements (issue 14698) This replaces our *custom* overlays with standard `<dialog>` DOM elements, see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog, thus simplifying the related CSS, HTML, and JavaScript code. With these changes, some of the functionality of the `OverlayManager` class is now handled natively (e.g. `Esc` to close the dialog). However, since we still need to be able to prevent dialogs from overlaying one another, it still makes sense to keep this functionality (as far as I'm concerned).
2022-03-25 14:10:13 +01:00
</div>
<div class="buttonRow">
Give all HTML button elements a type The HTML button elements we use are all regular buttons that don't submit form data to a server. According to https://developer.mozilla.org/en-US/docs/Web/HTML/Element/button#notes those buttons should all have their type set to `button` explicitly, but we only do that a handful of them. This commit fixes the issue by consistently giving all our buttons the `button` type. Co-authored-by: Calixte Denizet <calixte.denizet@gmail.com>
2024-07-30 18:35:12 +02:00
<button id="documentPropertiesClose" class="dialogButton" type="button"><span data-l10n-id="pdfjs-document-properties-close-button">Close</span></button>
Convert the existing overlays to use `<dialog>` elements (issue 14698) This replaces our *custom* overlays with standard `<dialog>` DOM elements, see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog, thus simplifying the related CSS, HTML, and JavaScript code. With these changes, some of the functionality of the `OverlayManager` class is now handled natively (e.g. `Esc` to close the dialog). However, since we still need to be able to prevent dialogs from overlaying one another, it still makes sense to keep this functionality (as far as I'm concerned).
2022-03-25 14:10:13 +01:00
</div>
</dialog>
Move the dialog css stuff in its own file In order to share common parts between different dialogs, this patch aims to slightly refactor the css in making it more generic. This way it'll simplify adding a new dialog (we want to add a new one when leaving an unsaved document).
2024-05-27 12:38:31 +02:00
<dialog class="dialog altText" id="altTextDialog" aria-labelledby="dialogLabel" aria-describedby="dialogDescription">
<div id="altTextContainer" class="mainContainer">
[Editor] Add a dialog box in order to get alt-text data (bug 1844952) Implement the specifications provided by UX for light, dark and HCM modes.
2023-09-15 14:06:50 +02:00
<div id="overallDescription">
[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 16:23:17 +02:00
<span id="dialogLabel" data-l10n-id="pdfjs-editor-alt-text-dialog-label" class="title">Choose an option</span>
<span id="dialogDescription" data-l10n-id="pdfjs-editor-alt-text-dialog-description">
[Editor] Update alt text dialog description
2023-09-19 09:27:43 +02:00
Alt text (alternative text) helps when people can’t see the image or when it doesn’t load.
[Editor] Add a dialog box in order to get alt-text data (bug 1844952) Implement the specifications provided by UX for light, dark and HCM modes.
2023-09-15 14:06:50 +02:00
</span>
</div>
<div id="addDescription">
<div class="radio">
<div class="radioButton">
[Editor] Change the colors for the disabled Save button in alt text dialoag in HCM
2023-09-20 10:45:26 +02:00
<input type="radio" id="descriptionButton" name="altTextOption" tabindex="0" aria-describedby="descriptionAreaLabel" checked>
[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 16:23:17 +02:00
<label for="descriptionButton" data-l10n-id="pdfjs-editor-alt-text-add-description-label">Add a description</label>
[Editor] Add a dialog box in order to get alt-text data (bug 1844952) Implement the specifications provided by UX for light, dark and HCM modes.
2023-09-15 14:06:50 +02:00
</div>
<div class="radioLabel">
[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 16:23:17 +02:00
<span id="descriptionAreaLabel" data-l10n-id="pdfjs-editor-alt-text-add-description-description">
[Editor] Add a dialog box in order to get alt-text data (bug 1844952) Implement the specifications provided by UX for light, dark and HCM modes.
2023-09-15 14:06:50 +02:00
Aim for 1-2 sentences that describe the subject, setting, or actions.
</span>
</div>
</div>
<div class="descriptionArea">
[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 16:23:17 +02:00
<textarea id="descriptionTextarea" placeholder="For example, “A young man sits down at a table to eat a meal”" aria-labelledby="descriptionAreaLabel" data-l10n-id="pdfjs-editor-alt-text-textarea" tabindex="0"></textarea>
[Editor] Add a dialog box in order to get alt-text data (bug 1844952) Implement the specifications provided by UX for light, dark and HCM modes.
2023-09-15 14:06:50 +02:00
</div>
</div>
<div id="markAsDecorative">
<div class="radio">
<div class="radioButton">
[Editor] Change the colors for the disabled Save button in alt text dialoag in HCM
2023-09-20 10:45:26 +02:00
<input type="radio" id="decorativeButton" name="altTextOption" aria-describedby="decorativeLabel">
[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 16:23:17 +02:00
<label for="decorativeButton" data-l10n-id="pdfjs-editor-alt-text-mark-decorative-label">Mark as decorative</label>
[Editor] Add a dialog box in order to get alt-text data (bug 1844952) Implement the specifications provided by UX for light, dark and HCM modes.
2023-09-15 14:06:50 +02:00
</div>
<div class="radioLabel">
[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 16:23:17 +02:00
<span id="decorativeLabel" data-l10n-id="pdfjs-editor-alt-text-mark-decorative-description">
[Editor] Change some strings in the alt-text dialog
2023-09-20 11:00:07 +02:00
This is used for ornamental images, like borders or watermarks.
[Editor] Add a dialog box in order to get alt-text data (bug 1844952) Implement the specifications provided by UX for light, dark and HCM modes.
2023-09-15 14:06:50 +02:00
</span>
</div>
</div>
</div>
<div id="buttons">
Give all HTML button elements a type The HTML button elements we use are all regular buttons that don't submit form data to a server. According to https://developer.mozilla.org/en-US/docs/Web/HTML/Element/button#notes those buttons should all have their type set to `button` explicitly, but we only do that a handful of them. This commit fixes the issue by consistently giving all our buttons the `button` type. Co-authored-by: Calixte Denizet <calixte.denizet@gmail.com>
2024-07-30 18:35:12 +02:00
<button id="altTextCancel" class="secondaryButton" type="button" tabindex="0"><span data-l10n-id="pdfjs-editor-alt-text-cancel-button">Cancel</span></button>
<button id="altTextSave" class="primaryButton" type="button" tabindex="0"><span data-l10n-id="pdfjs-editor-alt-text-save-button">Save</span></button>
[Editor] Add a dialog box in order to get alt-text data (bug 1844952) Implement the specifications provided by UX for light, dark and HCM modes.
2023-09-15 14:06:50 +02:00
</div>
</div>
</dialog>
Implement the new alt text flow (bug 1909604) For the Firefox pdf viewer, we want to use AI to guess an alt-text when adding an image to a pdf. For now the telemtry stuff is not implemented and will come soon. In order to test it locally: - set enableAltText, enableFakeMLManager and enableUpdatedAddImage to true. or in Firefox: - set browser.ml.enable, pdfjs.enableAltText and pdfjs.enableUpdatedAddImage to true.
2024-07-24 09:34:32 +02:00
<dialog class="dialog newAltText" id="newAltTextDialog" aria-labelledby="newAltTextTitle" aria-describedby="newAltTextDescription" tabindex="0">
<div id="newAltTextContainer" class="mainContainer">
<div class="title">
<span id="newAltTextTitle" data-l10n-id="pdfjs-editor-new-alt-text-dialog-edit-label" role="sectionhead" tabindex="0">Edit alt text (image description)</span>
</div>
<div id="mainContent">
<div id="descriptionAndSettings">
<div id="descriptionInstruction">
<div id="newAltTextDescriptionContainer">
<div class="altTextSpinner" role="status" aria-live="polite"></div>
<textarea id="newAltTextDescriptionTextarea" placeholder="Write your description here…" aria-labelledby="descriptionAreaLabel" data-l10n-id="pdfjs-editor-new-alt-text-textarea" tabindex="0"></textarea>
</div>
<span id="newAltTextDescription" role="note" data-l10n-id="pdfjs-editor-new-alt-text-description">Short description for people who can’t see the image or when the image doesn’t load.</span>
[Editor] Update the disclaimer string in the new alt-text dialog (bug 1911738) And tweak the css in order to take into account that disclaimer can be on two (or more lines).
2024-08-06 10:17:15 +02:00
<div id="newAltTextDisclaimer" role="note"><div><span data-l10n-id="pdfjs-editor-new-alt-text-disclaimer1">This alt text was created automatically and may be inaccurate.</span> <a href="https://support.mozilla.org/en-US/kb/pdf-alt-text" target="_blank" rel="noopener noreferrer" id="newAltTextLearnMore" data-l10n-id="pdfjs-editor-new-alt-text-disclaimer-learn-more-url" tabindex="0">Learn more</a></div></div>
Implement the new alt text flow (bug 1909604) For the Firefox pdf viewer, we want to use AI to guess an alt-text when adding an image to a pdf. For now the telemtry stuff is not implemented and will come soon. In order to test it locally: - set enableAltText, enableFakeMLManager and enableUpdatedAddImage to true. or in Firefox: - set browser.ml.enable, pdfjs.enableAltText and pdfjs.enableUpdatedAddImage to true.
2024-07-24 09:34:32 +02:00
</div>
<div id="newAltTextCreateAutomatically" class="toggler">
Give all HTML button elements a type The HTML button elements we use are all regular buttons that don't submit form data to a server. According to https://developer.mozilla.org/en-US/docs/Web/HTML/Element/button#notes those buttons should all have their type set to `button` explicitly, but we only do that a handful of them. This commit fixes the issue by consistently giving all our buttons the `button` type. Co-authored-by: Calixte Denizet <calixte.denizet@gmail.com>
2024-07-30 18:35:12 +02:00
<button id="newAltTextCreateAutomaticallyButton" class="toggle-button" type="button" aria-pressed="true" tabindex="0"></button>
Implement the new alt text flow (bug 1909604) For the Firefox pdf viewer, we want to use AI to guess an alt-text when adding an image to a pdf. For now the telemtry stuff is not implemented and will come soon. In order to test it locally: - set enableAltText, enableFakeMLManager and enableUpdatedAddImage to true. or in Firefox: - set browser.ml.enable, pdfjs.enableAltText and pdfjs.enableUpdatedAddImage to true.
2024-07-24 09:34:32 +02:00
<label for="newAltTextCreateAutomaticallyButton" class="togglerLabel" data-l10n-id="pdfjs-editor-new-alt-text-create-automatically-button-label">Create alt text automatically</label>
</div>
<div id="newAltTextDownloadModel" class="hidden">
[Editor] Fix l10n issues Remove the strings containing only a variable.
2024-08-02 09:28:57 +02:00
<span id="newAltTextDownloadModelDescription" data-l10n-id="pdfjs-editor-new-alt-text-ai-model-downloading-progress" aria-valuemin="0" data-l10n-args='{ "totalSize": 0, "downloadedSize": 0 }'>Downloading alt text AI model (0 of 0 MB)</span>
Implement the new alt text flow (bug 1909604) For the Firefox pdf viewer, we want to use AI to guess an alt-text when adding an image to a pdf. For now the telemtry stuff is not implemented and will come soon. In order to test it locally: - set enableAltText, enableFakeMLManager and enableUpdatedAddImage to true. or in Firefox: - set browser.ml.enable, pdfjs.enableAltText and pdfjs.enableUpdatedAddImage to true.
2024-07-24 09:34:32 +02:00
</div>
</div>
<div id="newAltTextImagePreview"></div>
</div>
<div id="newAltTextError" class="messageBar">
<div>
<div>
<span class="title" data-l10n-id="pdfjs-editor-new-alt-text-error-title">Couldn’t create alt text automatically</span>
<span class="description" data-l10n-id="pdfjs-editor-new-alt-text-error-description">Please write your own alt text or try again later.</span>
</div>
Give all HTML button elements a type The HTML button elements we use are all regular buttons that don't submit form data to a server. According to https://developer.mozilla.org/en-US/docs/Web/HTML/Element/button#notes those buttons should all have their type set to `button` explicitly, but we only do that a handful of them. This commit fixes the issue by consistently giving all our buttons the `button` type. Co-authored-by: Calixte Denizet <calixte.denizet@gmail.com>
2024-07-30 18:35:12 +02:00
<button id="newAltTextCloseButton" class="closeButton" type="button" tabindex="0" title="Close"><span data-l10n-id="pdfjs-editor-new-alt-text-error-close-button">Close</span></button>
Implement the new alt text flow (bug 1909604) For the Firefox pdf viewer, we want to use AI to guess an alt-text when adding an image to a pdf. For now the telemtry stuff is not implemented and will come soon. In order to test it locally: - set enableAltText, enableFakeMLManager and enableUpdatedAddImage to true. or in Firefox: - set browser.ml.enable, pdfjs.enableAltText and pdfjs.enableUpdatedAddImage to true.
2024-07-24 09:34:32 +02:00
</div>
</div>
<div id="newAltTextButtons" class="dialogButtonsGroup">
<button id="newAltTextCancel" type="button" class="secondaryButton hidden" tabindex="0"><span data-l10n-id="pdfjs-editor-alt-text-cancel-button">Cancel</span></button>
<button id="newAltTextNotNow" type="button" class="secondaryButton" tabindex="0"><span data-l10n-id="pdfjs-editor-new-alt-text-not-now-button">Not now</span></button>
<button id="newAltTextSave" type="button" class="primaryButton" tabindex="0"><span data-l10n-id="pdfjs-editor-alt-text-save-button">Save</span></button>
</div>
</div>
</dialog>
[Editor] Add a new dialog for alt-text settings (bug 1909604) This patch adds a new entry in the secondary menu in order to open a dialog to let the user: - disables the alt-text generation thanks to a ML model; - deletes the alt-text model downloaded in Firefox; - disabled the new alt-text flow.
2024-08-01 15:29:01 +02:00
<dialog class="dialog" id="altTextSettingsDialog" aria-labelledby="altTextSettingsTitle">
<div id="altTextSettingsContainer" class="mainContainer">
<div class="title">
<span id="altTextSettingsTitle" data-l10n-id="pdfjs-editor-alt-text-settings-dialog-label" role="sectionhead" tabindex="0" class="title">Image alt text settings</span>
</div>
<div id="automaticAltText">
<span data-l10n-id="pdfjs-editor-alt-text-settings-automatic-title">Automatic alt text</span>
<div id="automaticSettings">
<div id="createModelSetting">
<div class="toggler">
<button id="createModelButton" type="button" class="toggle-button" aria-pressed="true" tabindex="0"></button>
<label for="createModelButton" class="togglerLabel" data-l10n-id="pdfjs-editor-alt-text-settings-create-model-button-label">Create alt text automatically</label>
</div>
<div id="createModelDescription" class="description">
<span data-l10n-id="pdfjs-editor-alt-text-settings-create-model-description">Suggests descriptions to help people who can’t see the image or when the image doesn’t load.</span> <a href="https://support.mozilla.org/en-US/kb/pdf-alt-text" target="_blank" rel="noopener noreferrer" id="altTextSettingsLearnMore" data-l10n-id="pdfjs-editor-new-alt-text-disclaimer-learn-more-url" tabindex="0">Learn more</a>
</div>
</div>
<div id="aiModelSettings">
<div>
<span data-l10n-id="pdfjs-editor-alt-text-settings-download-model-label" data-l10n-args='{ "totalSize": 180 }'>Alt text AI model (180MB)</span>
<div id="aiModelDescription" class="description">
<span data-l10n-id="pdfjs-editor-alt-text-settings-ai-model-description">Runs locally on your device so your data stays private. Required for automatic alt text.</span>
</div>
</div>
<button id="deleteModelButton" type="button" class="secondaryButton" tabindex="0"><span data-l10n-id="pdfjs-editor-alt-text-settings-delete-model-button">Delete</span></button>
[Editor] Remove event listeners with `AbortSignal.any()` There's a fair number of event listeners in the editor-code that we're currently removing "manually", by keeping references to their event handler functions. This was necessary since we have a "global" `AbortController` that applies to all event listeners used in the editor-code, however it's now possible to combine multiple `AbortSignal`s; please see https://developer.mozilla.org/en-US/docs/Web/API/AbortSignal/any_static Since this functionality is [fairly new](https://developer.mozilla.org/en-US/docs/Web/API/AbortSignal/any_static#browser_compatibility) the viewer will check that `AbortSignal.any()` is available before enabling the editing-functionality. (It should hopefully be fairly straightforward, famous last words, for users to implement a polyfill to allow editing in older browsers.) Finally, this patch also adds checks and test-only asserts to ensure that we don't add duplicate event listeners in various editor-code.
2024-08-08 13:09:16 +02:00
<button id="downloadModelButton" type="button" class="secondaryButton" tabindex="0"><span data-l10n-id="pdfjs-editor-alt-text-settings-download-model-button">Download</span></button>
[Editor] Add a new dialog for alt-text settings (bug 1909604) This patch adds a new entry in the secondary menu in order to open a dialog to let the user: - disables the alt-text generation thanks to a ML model; - deletes the alt-text model downloaded in Firefox; - disabled the new alt-text flow.
2024-08-01 15:29:01 +02:00
</div>
</div>
</div>
<div class="dialogSeparator"></div>
<div id="altTextEditor">
<span data-l10n-id="pdfjs-editor-alt-text-settings-editor-title">Alt text editor</span>
<div id="showAltTextEditor">
<div class="toggler">
<button id="showAltTextDialogButton" type="button" class="toggle-button" aria-pressed="true" tabindex="0"></button>
<label for="showAltTextDialogButton" class="togglerLabel" data-l10n-id="pdfjs-editor-alt-text-settings-show-dialog-button-label">Show alt text editor right away when adding an image</label>
</div>
<div id="showAltTextDialogDescription" class="description">
<span data-l10n-id="pdfjs-editor-alt-text-settings-show-dialog-description">Helps you make sure all your images have alt text.</span>
</div>
</div>
</div>
<div id="buttons" class="dialogButtonsGroup">
<button id="altTextSettingsCloseButton" type="button" class="primaryButton" tabindex="0"><span data-l10n-id="pdfjs-editor-alt-text-settings-close-button">Close</span></button>
</div>
</div>
</dialog>
Remove the `FIREFOX` build flag, since it's completely unused After PR 9566, which removed all of the old Firefox extension code, the `FIREFOX` build flag is no longer used for anything. It thus seems to me that it should be removed, for a couple of reasons: - It's simply dead code now, which only serves to add confusion when looking at the `PDFJSDev` calls. - It used to be that `MOZCENTRAL` and `FIREFOX` was *almost* always used together. However, ever since PR 9566 there's obviously been no effort put into keeping the `FIREFOX` build flags up to date. - In the event that a new, Webextension based, Firefox addon is created in the future you'd still need to audit all `MOZCENTRAL` (and possibly `CHROME`) build flags to see what'd make sense for the addon.
2020-01-08 13:57:31 +01:00
<!--#if !MOZCENTRAL-->
Try to improve a11y for the `PasswordPrompt` and `PDFDocumentProperties` dialogs This will hopefully improve the a11y a little bit in these dialogs, however there's most definately more things that can be done here (by someone more knowledgeable about a11y).
2022-03-25 14:10:28 +01:00
<dialog id="printServiceDialog" style="min-width: 200px;">
Convert the existing overlays to use `<dialog>` elements (issue 14698) This replaces our *custom* overlays with standard `<dialog>` DOM elements, see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog, thus simplifying the related CSS, HTML, and JavaScript code. With these changes, some of the functionality of the `OverlayManager` class is now handled natively (e.g. `Esc` to close the dialog). However, since we still need to be able to prevent dialogs from overlaying one another, it still makes sense to keep this functionality (as far as I'm concerned).
2022-03-25 14:10:13 +01:00
<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 16:23:17 +02:00
<span data-l10n-id="pdfjs-print-progress-message">Preparing document for printing…</span>
Removes mozPrintCallback polyfill, converts canvas to PNG.
2016-10-08 07:36:55 -05:00
</div>
Convert the existing overlays to use `<dialog>` elements (issue 14698) This replaces our *custom* overlays with standard `<dialog>` DOM elements, see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog, thus simplifying the related CSS, HTML, and JavaScript code. With these changes, some of the functionality of the `OverlayManager` class is now handled natively (e.g. `Esc` to close the dialog). However, since we still need to be able to prevent dialogs from overlaying one another, it still makes sense to keep this functionality (as far as I'm concerned).
2022-03-25 14:10:13 +01:00
<div class="row">
<progress value="0" max="100"></progress>
[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 16:23:17 +02:00
<span data-l10n-id="pdfjs-print-progress-percent" data-l10n-args='{ "progress": 0 }' class="relative-progress">0%</span>
Convert the existing overlays to use `<dialog>` elements (issue 14698) This replaces our *custom* overlays with standard `<dialog>` DOM elements, see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog, thus simplifying the related CSS, HTML, and JavaScript code. With these changes, some of the functionality of the `OverlayManager` class is now handled natively (e.g. `Esc` to close the dialog). However, since we still need to be able to prevent dialogs from overlaying one another, it still makes sense to keep this functionality (as far as I'm concerned).
2022-03-25 14:10:13 +01:00
</div>
<div class="buttonRow">
Give all HTML button elements a type The HTML button elements we use are all regular buttons that don't submit form data to a server. According to https://developer.mozilla.org/en-US/docs/Web/HTML/Element/button#notes those buttons should all have their type set to `button` explicitly, but we only do that a handful of them. This commit fixes the issue by consistently giving all our buttons the `button` type. Co-authored-by: Calixte Denizet <calixte.denizet@gmail.com>
2024-07-30 18:35:12 +02:00
<button id="printCancel" class="dialogButton" type="button"><span data-l10n-id="pdfjs-print-progress-close-button">Cancel</span></button>
Convert the existing overlays to use `<dialog>` elements (issue 14698) This replaces our *custom* overlays with standard `<dialog>` DOM elements, see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog, thus simplifying the related CSS, HTML, and JavaScript code. With these changes, some of the functionality of the `OverlayManager` class is now handled natively (e.g. `Esc` to close the dialog). However, since we still need to be able to prevent dialogs from overlaying one another, it still makes sense to keep this functionality (as far as I'm concerned).
2022-03-25 14:10:13 +01:00
</div>
</dialog>
Removes mozPrintCallback polyfill, converts canvas to PNG.
2016-10-08 07:36:55 -05:00
<!--#endif-->
Teach users how to enable access to local files.
2015-07-18 17:11:33 +02:00
<!--#if CHROME-->
<!--#include viewer-snippet-chrome-overlays.html-->
<!--#endif-->
Convert the existing overlays to use `<dialog>` elements (issue 14698) This replaces our *custom* overlays with standard `<dialog>` DOM elements, see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog, thus simplifying the related CSS, HTML, and JavaScript code. With these changes, some of the functionality of the `OverlayManager` class is now handled natively (e.g. `Esc` to close the dialog). However, since we still need to be able to prevent dialogs from overlaying one another, it still makes sense to keep this functionality (as far as I'm concerned).
2022-03-25 14:10:13 +01:00
</div> <!-- dialogContainer -->
Improved password prompt
2013-09-24 17:46:54 +02:00
text selection OK, switch outline OK
2012-04-12 16:29:15 -07:00
</div> <!-- outerContainer -->
Adds support for the new mozPrintCallback api.
2012-06-28 09:50:25 -07:00
<div id="printContainer"></div>
Separate js and css from the test.html file
2011-05-26 16:02:52 +02:00
</body>
Factor out mock tests, add browser test page, initial canvas backend
2011-05-04 19:32:59 -05:00
</html>
Copy permalink