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

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

569 lines
33 KiB
HTML
Raw Normal View History

Add BOM to viewer.
2013-11-23 04:10:43 +09:00
<!DOCTYPE html>
Change to the Apache v2 license.
2012-09-01 07:48:21 +09: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-11 05:03:35 +09:00
Update Adobe CMaps URL and license They are now using Apache 2.0 as well.
2015-06-30 16:33:25 +09: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-09-01 07:48:21 +09:00
-->
Remove `moznomarginboxes`
2018-01-20 06:05:50 +09:00
<html dir="ltr" mozdisallowselectionprint>
first mockup, loads tracemonkey pages OK
2012-04-12 08:12:51 +09:00
<head>
Embed locale.properties in the viewer.html for extension
2012-05-01 11:55:21 +09:00
<meta charset="utf-8">
Add viewport metatag
2012-05-24 06:50:54 +09: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 07:13:05 +09: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-19 04:02:49 +09:00
<title>PDF.js viewer</title>
Add the new preprocessor.
2012-08-02 03:29:13 +09: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 21:57:31 +09:00
<!--#if MOZCENTRAL-->
Add the new preprocessor.
2012-08-02 03:29:13 +09: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-19 01:17:46 +09: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-16 05:47:30 +09: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-19 01:17:46 +09:00
<!--#else-->
<!--#include viewer-snippet.html-->
Add the new preprocessor.
2012-08-02 03:29:13 +09:00
<!--#endif-->
first mockup, loads tracemonkey pages OK
2012-04-12 08:12:51 +09: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-14 00:56:42 +09: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 23:23:17 +09: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-14 00:56:42 +09:00
<!--#else-->
Remove XHTML leftovers from the viewer HTML files
2016-02-14 21:23:34 +09: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-14 00:56:42 +09: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-19 01:17:46 +09: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 20:00:10 +09: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 17:07:26 +09: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 20:00:10 +09: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 20:42:22 +09: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 23:23:17 +09:00
<link rel="resource" type="application/l10n" href="locale/locale.json">
Add the new preprocessor.
2012-08-02 03:29:13 +09: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 20:00:25 +09: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-20 01:00:23 +09: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-07 06:02:53 +09: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 21:55:12 +09:00
[api-minor] Move to Fluent for the localization (bug 1858715) - For the generic viewer we use @fluent/dom and @fluent/bundle - For the builtin pdf viewer in Firefox, we set a localization url and then we rely on document.l10n which is a DOMLocalization object.
2023-10-13 23:23:17 +09:00
"fluent-bundle": "../node_modules/@fluent/bundle/esm/index.js",
"fluent-dom": "../node_modules/@fluent/dom/esm/index.js",
"cached-iterable": "../node_modules/cached-iterable/src/index.mjs",
Remove most build-time `require`-calls from the `src/display/`-folder By leveraging import maps we can get rid of *most* of the remaining `require`-calls in the `src/display/`-folder, since we should strive to use modern `import`-statements wherever possible. The only remaining cases are Node.js-specific dependencies, since those seem very difficult to convert unless we start producing a bundle *specifically* for Node.js environments.
2023-07-13 18:58:16 +09:00
"display-fetch_stream": "../src/display/fetch_stream.js",
"display-network": "../src/display/network.js",
"display-node_stream": "../src/display/stubs.js",
"display-node_utils": "../src/display/stubs.js",
[GeckoView] Avoid bundling the `AltTextManager` class, since it's unused
2023-09-21 19:51:34 +09:00
"web-alt_text_manager": "./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 21:55:12 +09: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 19:50:25 +09:00
"web-download_manager": "./download_manager.js",
Re-factor `DefaultExternalServices` into a regular class, without static methods The `DefaultExternalServices` code, which is used to provide build-specific functionality, is very old. This results in a pattern where we first initialize `PDFViewerApplication.externalServices` and then *override* it for the different builds. By converting `DefaultExternalServices` into a "regular" class, and leveraging import maps, we can directly initialize the correct instance depending on the build.
2024-01-26 22:31:42 +09:00
"web-external_services": "./genericcom.js",
Ensure that `GenericL10n` works if the locale files cannot be loaded - Ensure that localization works in the GENERIC viewer, even if the necessary locale files cannot be loaded. This was the behaviour prior to the introduction of Fluent, and it seems worthwhile to keep that (especially since we already bundle the en-US strings anyway). - Let the `GenericL10n`-implementation use the *bundled* en-US strings directly when no language is provided. - Remove the `NullL10n`-implementation, and simply fallback to `GenericL10n`, to reduce the maintenance burden of viewer-components localization. - Indirectly, given the previous point, stop exporting `NullL10n` in the viewer-components since it's now removed. Note that it was never really intended to be used directly and only existed as a fallback. *Please note:* This doesn't affect the Firefox PDF Viewer, thanks to the use of import maps.
2024-01-31 02:32:35 +09:00
"web-null_l10n": "./genericl10n.js",
[GeckoView] Reduce the size of the *built* viewer Given that the GV-viewer isn't using most of the UI-related components of the default-viewer, we can avoid including them in the *built* viewer to save space.[1] The least "invasive" way of implementing this, at least that I could come up with, is to leverage import maps with suitable stubs for the GV-viewer. The one slightly annoying thing is that we now have larger import maps across multiple html-files, and you'll need to remember to update all of them when making future changes. --- [1] With this patch, the built `viewer.js` size is 391 kB and `viewer-geckoview.js` is 285 kB.
2023-02-04 21:55:12 +09:00
"web-pdf_attachment_viewer": "./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 20:04:54 +09: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-06 00:13:18 +09:00
"web-print_service": "./pdf_print_service.js",
[GeckoView] Reduce the size of the *built* viewer Given that the GV-viewer isn't using most of the UI-related components of the default-viewer, we can avoid including them in the *built* viewer to save space.[1] The least "invasive" way of implementing this, at least that I could come up with, is to leverage import maps with suitable stubs for the GV-viewer. The one slightly annoying thing is that we now have larger import maps across multiple html-files, and you'll need to remember to update all of them when making future changes. --- [1] With this patch, the built `viewer.js` size is 391 kB and `viewer-geckoview.js` is 285 kB.
2023-02-04 21:55:12 +09:00
"web-secondary_toolbar": "./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-20 01:00:23 +09:00
}
}
</script>
Use native `import maps` in development mode This patch seem to work fine locally now, and `mozregression` points to it being fixed in bug https://bugzilla.mozilla.org/show_bug.cgi?id=1803984 which landed in Firefox 116. By using the native `import maps` functionality, we can remove a development dependency. Please find the specification at https://wicg.github.io/import-maps/
2022-04-02 20:00:25 +09:00
<script src="viewer.js" type="module"></script>
Add the new preprocessor.
2012-08-02 03:29:13 +09:00
<!--#endif-->
first mockup, loads tracemonkey pages OK
2012-04-12 08:12:51 +09:00
</head>
Separate js and css from the test.html file
2011-05-26 23:02:52 +09:00
Let the loadingBar have the same width as the viewerContainer For years the loadingBar and sidebarContainer has had a slightly annoying and unfortunate dependency, since the loadingBar width follows the main toolbar width[1]. To prevent the loadingBar from obscuring part of the sidebarContainer, especially the buttons, the sidebarContainer is thus moved down when the loadingBar is visible. This has always annoyed me[2], since it means that the buttons in the sidebar may thus move vertically which seems bad from a UX perspective. Now that CSS variables are available in all supported browsers[3] however, fixing the loadingBar/sidebarContainer overlap issues are finally easy. The solution is simply to let the sidebarContainer, when visible, control the loadingBar left position (right in RTL locales) in the same way that the viewerContainer is handled. Hence the sidebarContainer can now have a *consistent* vertical postition, without the loadingBar overlapping it. --- [1] Obviously the right position (left in RTL locales) of the loadingBar is, potentially, reduced to account for a scrollbar. [2] I've tried to fix this a few times, but it always seemed like more trouble than it's worth. [3] https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_custom_properties#Browser_compatibility
2020-09-08 21:13:10 +09:00
<body tabindex="1">
Small refactoring of the loadingBar hiding code
2014-08-17 07:22:05 +09:00
<div id="outerContainer">
Unify the multi_page_viewer and the basic viewer
2011-07-29 02:48:05 +09:00
Move sidebar open class.
2012-04-26 05:46:17 +09:00
<div id="sidebarContainer">
Minor css tweaks for small viewer and aligning borders.
2012-10-30 06:35:07 +09:00
<div id="toolbarSidebar">
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 20:57:43 +09:00
<div id="toolbarSidebarLeft">
Try to improve a11y for the "button groups" in the SecondaryToolbar/Sidebar (issue 14526) *Please note:* I don't really know anything about a11y, hence it's possible that this patch either doesn't work correctly or at least isn't a complete solution. In both the SecondaryToolbar and the Sidebar we have "button groups" that functionally acts essentially like radio-buttons. Based on skimming through [this MDN article](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/radio_role) it thus appears that we should tag them as such, using `role="radiogroup"` and `role="radio"`, and then utilize the `aria-checked` attribute to indicate to a11y software which button is currently active.
2022-02-11 22:04:47 +09:00
<div id="sidebarViewButtons" class="splitToolbarButton toggled" role="radiogroup">
[api-minor] Move to Fluent for the localization (bug 1858715) - For the generic viewer we use @fluent/dom and @fluent/bundle - For the builtin pdf viewer in Firefox, we set a localization url and then we rely on document.l10n which is a DOMLocalization object.
2023-10-13 23:23:17 +09:00
<button id="viewThumbnail" class="toolbarButton toggled" title="Show Thumbnails" tabindex="2" data-l10n-id="pdfjs-thumbs-button" role="radio" aria-checked="true" aria-controls="thumbnailView">
<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 20:57:43 +09:00
</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 23:23:17 +09:00
<button id="viewOutline" class="toolbarButton" title="Show Document Outline (double-click to expand/collapse all items)" tabindex="3" data-l10n-id="pdfjs-document-outline-button" role="radio" aria-checked="false" aria-controls="outlineView">
<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 20:57:43 +09:00
</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 23:23:17 +09:00
<button id="viewAttachments" class="toolbarButton" title="Show Attachments" tabindex="4" data-l10n-id="pdfjs-attachments-button" role="radio" aria-checked="false" aria-controls="attachmentsView">
<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 20:57:43 +09:00
</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 23:23:17 +09:00
<button id="viewLayers" class="toolbarButton" title="Show Layers (double-click to reset all layers to the default state)" tabindex="5" data-l10n-id="pdfjs-layers-button" role="radio" aria-checked="false" aria-controls="layersView">
<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 20:57:43 +09:00
</button>
</div>
</div>
<div id="toolbarSidebarRight">
Toggle the visibility of the `outlineOptionsContainer`, in the sidebar, using only CSS Now that `:has()` is available we no longer need to use JavaScript to toggle the visibility of this DOM element.
2023-12-19 18:01:16 +09:00
<div id="outlineOptionsContainer">
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 20:57:43 +09:00
<div class="verticalToolbarSeparator"></div>
[api-minor] Move to Fluent for the localization (bug 1858715) - For the generic viewer we use @fluent/dom and @fluent/bundle - For the builtin pdf viewer in Firefox, we set a localization url and then we rely on document.l10n which is a DOMLocalization object.
2023-10-13 23:23:17 +09:00
<button id="currentOutlineItem" class="toolbarButton" disabled="disabled" title="Find Current Outline Item" tabindex="6" data-l10n-id="pdfjs-current-outline-item-button">
<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 20:57:43 +09:00
</button>
</div>
Minor css tweaks for small viewer and aligning borders.
2012-10-30 06:35:07 +09:00
</div>
Unify the multi_page_viewer and the basic viewer
2011-07-29 02:48:05 +09:00
</div>
Remove flex box. Add side animation. Add dashed line around unload thumbnails.
2012-04-26 03:34:28 +09:00
<div id="sidebarContent">
<div id="thumbnailView">
first mockup, loads tracemonkey pages OK
2012-04-12 08:12:51 +09:00
</div>
Remove flex box. Add side animation. Add dashed line around unload thumbnails.
2012-04-26 03:34:28 +09:00
<div id="outlineView" class="hidden">
first mockup, loads tracemonkey pages OK
2012-04-12 08:12:51 +09: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-19 05:32:47 +09: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-07 04:01:03 +09:00
<div id="layersView" class="hidden">
</div>
Switching to the document outline view if the document structure is present
2011-08-22 11:05:10 +09: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 20:29:44 +09:00
<div id="sidebarResizer"></div>
Remove flex box. Add side animation. Add dashed line around unload thumbnails.
2012-04-26 03:34:28 +09:00
</div> <!-- sidebarContainer -->
<div id="mainContainer">
Viewer: enable find functionality for small devices The find functionality is currently not available for small devices because the find dialog is not responsive. This patch fixes that. To achieve this goal, the HTML is changed to always show the find button. To prevent issues because of the addition of an extra button for small views, the previous/next page buttons are hidden if the view becomes small. These buttons are not useful anyway because on small devices navigation is usually done via scrolling. The find functionality is much more useful to have in this case. Moreover, we wrap the existing elements into separate `div`s so that the browser can position the elements itself when the view becomes smaller and logically connected elements stay together when this happens. In the CSS, extra rules for the find bar have been added to ensure that the dialog's doorhanger is always below the find button. All findbar `div`s are forced to be 32 pixels high to prevent the find message text being aligned under the checkboxes. Finally, the find message is only visible when there is actually text to display. This prevents wrapping issues because, by default, the label has padding and margin even if there is no text.
2017-03-09 07:54:28 +09:00
<div class="findbar hidden doorHanger" id="findbar">
<div id="findbarInputContainer">
Re-factor the loading-icons used in the viewer toolbars Currently the SVG images for the loading-icons exist in two versions, for the light- respectively dark-theme, which nowadays are the only "duplicated" icons left. The reason for this is that these icons are being used in `input`-elements, where the regular `mask-image` approach used for all buttons don't work. To address this we add containers for the `input`-elements, such that we have a "regular" DOM-element where we can use `mask-image`.
2023-11-16 22:24:16 +09:00
<span class="loadingInput end">
<input id="findInput" class="toolbarField" title="Find" placeholder="Find in document…" tabindex="91" data-l10n-id="pdfjs-find-input" aria-invalid="false">
</span>
Viewer: enable find functionality for small devices The find functionality is currently not available for small devices because the find dialog is not responsive. This patch fixes that. To achieve this goal, the HTML is changed to always show the find button. To prevent issues because of the addition of an extra button for small views, the previous/next page buttons are hidden if the view becomes small. These buttons are not useful anyway because on small devices navigation is usually done via scrolling. The find functionality is much more useful to have in this case. Moreover, we wrap the existing elements into separate `div`s so that the browser can position the elements itself when the view becomes smaller and logically connected elements stay together when this happens. In the CSS, extra rules for the find bar have been added to ensure that the dialog's doorhanger is always below the find button. All findbar `div`s are forced to be 32 pixels high to prevent the find message text being aligned under the checkboxes. Finally, the find message is only visible when there is actually text to display. This prevents wrapping issues because, by default, the label has padding and margin even if there is no text.
2017-03-09 07:54:28 +09:00
<div class="splitToolbarButton">
[api-minor] Move to Fluent for the localization (bug 1858715) - For the generic viewer we use @fluent/dom and @fluent/bundle - For the builtin pdf viewer in Firefox, we set a localization url and then we rely on document.l10n which is a DOMLocalization object.
2023-10-13 23:23:17 +09:00
<button id="findPrevious" class="toolbarButton" title="Find the previous occurrence of the phrase" tabindex="92" data-l10n-id="pdfjs-find-previous-button">
<span data-l10n-id="pdfjs-find-previous-button-label">Previous</span>
Viewer: enable find functionality for small devices The find functionality is currently not available for small devices because the find dialog is not responsive. This patch fixes that. To achieve this goal, the HTML is changed to always show the find button. To prevent issues because of the addition of an extra button for small views, the previous/next page buttons are hidden if the view becomes small. These buttons are not useful anyway because on small devices navigation is usually done via scrolling. The find functionality is much more useful to have in this case. Moreover, we wrap the existing elements into separate `div`s so that the browser can position the elements itself when the view becomes smaller and logically connected elements stay together when this happens. In the CSS, extra rules for the find bar have been added to ensure that the dialog's doorhanger is always below the find button. All findbar `div`s are forced to be 32 pixels high to prevent the find message text being aligned under the checkboxes. Finally, the find message is only visible when there is actually text to display. This prevents wrapping issues because, by default, the label has padding and margin even if there is no text.
2017-03-09 07:54:28 +09:00
</button>
<div class="splitToolbarButtonSeparator"></div>
[api-minor] Move to Fluent for the localization (bug 1858715) - For the generic viewer we use @fluent/dom and @fluent/bundle - For the builtin pdf viewer in Firefox, we set a localization url and then we rely on document.l10n which is a DOMLocalization object.
2023-10-13 23:23:17 +09:00
<button id="findNext" class="toolbarButton" title="Find the next occurrence of the phrase" tabindex="93" data-l10n-id="pdfjs-find-next-button">
<span data-l10n-id="pdfjs-find-next-button-label">Next</span>
Viewer: enable find functionality for small devices The find functionality is currently not available for small devices because the find dialog is not responsive. This patch fixes that. To achieve this goal, the HTML is changed to always show the find button. To prevent issues because of the addition of an extra button for small views, the previous/next page buttons are hidden if the view becomes small. These buttons are not useful anyway because on small devices navigation is usually done via scrolling. The find functionality is much more useful to have in this case. Moreover, we wrap the existing elements into separate `div`s so that the browser can position the elements itself when the view becomes smaller and logically connected elements stay together when this happens. In the CSS, extra rules for the find bar have been added to ensure that the dialog's doorhanger is always below the find button. All findbar `div`s are forced to be 32 pixels high to prevent the find message text being aligned under the checkboxes. Finally, the find message is only visible when there is actually text to display. This prevents wrapping issues because, by default, the label has padding and margin even if there is no text.
2017-03-09 07:54:28 +09:00
</button>
</div>
</div>
Add initial support for "Whole words" searching in the viewer As outlined in https://bugzilla.mozilla.org/show_bug.cgi?id=1282759 the internal Firefox name for the feature is `entireWord`, hence that name is used here as well for consistency (with "Whole words" being limited to the UI). Given existing limitations of the PDF.js search functionality, e.g. the existing problems of searching across "new lines", there's some edge-cases where "Whole words" searching will ignore (valid) results. However, considering that this is a pre-existing issue related to the way that the find controller joins text-content together, that shouldn't have to block this new feature in my opionion. *Please note:* In order to enable this feature in the `MOZCENTRAL` version, a small follow-up patch for [PdfjsChromeUtils.jsm](https://hg.mozilla.org/mozilla-central/file/tip/browser/extensions/pdfjs/content/PdfjsChromeUtils.jsm) will be required once this has landed in `mozilla-central`.
2018-09-01 08:28:19 +09:00
<div id="findbarOptionsOneContainer">
Viewer: enable find functionality for small devices The find functionality is currently not available for small devices because the find dialog is not responsive. This patch fixes that. To achieve this goal, the HTML is changed to always show the find button. To prevent issues because of the addition of an extra button for small views, the previous/next page buttons are hidden if the view becomes small. These buttons are not useful anyway because on small devices navigation is usually done via scrolling. The find functionality is much more useful to have in this case. Moreover, we wrap the existing elements into separate `div`s so that the browser can position the elements itself when the view becomes smaller and logically connected elements stay together when this happens. In the CSS, extra rules for the find bar have been added to ensure that the dialog's doorhanger is always below the find button. All findbar `div`s are forced to be 32 pixels high to prevent the find message text being aligned under the checkboxes. Finally, the find message is only visible when there is actually text to display. This prevents wrapping issues because, by default, the label has padding and margin even if there is no text.
2017-03-09 07:54:28 +09:00
<input type="checkbox" id="findHighlightAll" class="toolbarField" tabindex="94">
[api-minor] Move to Fluent for the localization (bug 1858715) - For the generic viewer we use @fluent/dom and @fluent/bundle - For the builtin pdf viewer in Firefox, we set a localization url and then we rely on document.l10n which is a DOMLocalization object.
2023-10-13 23:23:17 +09:00
<label for="findHighlightAll" class="toolbarLabel" data-l10n-id="pdfjs-find-highlight-checkbox">Highlight All</label>
Viewer: enable find functionality for small devices The find functionality is currently not available for small devices because the find dialog is not responsive. This patch fixes that. To achieve this goal, the HTML is changed to always show the find button. To prevent issues because of the addition of an extra button for small views, the previous/next page buttons are hidden if the view becomes small. These buttons are not useful anyway because on small devices navigation is usually done via scrolling. The find functionality is much more useful to have in this case. Moreover, we wrap the existing elements into separate `div`s so that the browser can position the elements itself when the view becomes smaller and logically connected elements stay together when this happens. In the CSS, extra rules for the find bar have been added to ensure that the dialog's doorhanger is always below the find button. All findbar `div`s are forced to be 32 pixels high to prevent the find message text being aligned under the checkboxes. Finally, the find message is only visible when there is actually text to display. This prevents wrapping issues because, by default, the label has padding and margin even if there is no text.
2017-03-09 07:54:28 +09:00
<input type="checkbox" id="findMatchCase" class="toolbarField" tabindex="95">
[api-minor] Move to Fluent for the localization (bug 1858715) - For the generic viewer we use @fluent/dom and @fluent/bundle - For the builtin pdf viewer in Firefox, we set a localization url and then we rely on document.l10n which is a DOMLocalization object.
2023-10-13 23:23:17 +09:00
<label for="findMatchCase" class="toolbarLabel" data-l10n-id="pdfjs-find-match-case-checkbox-label">Match Case</label>
Viewer: enable find functionality for small devices The find functionality is currently not available for small devices because the find dialog is not responsive. This patch fixes that. To achieve this goal, the HTML is changed to always show the find button. To prevent issues because of the addition of an extra button for small views, the previous/next page buttons are hidden if the view becomes small. These buttons are not useful anyway because on small devices navigation is usually done via scrolling. The find functionality is much more useful to have in this case. Moreover, we wrap the existing elements into separate `div`s so that the browser can position the elements itself when the view becomes smaller and logically connected elements stay together when this happens. In the CSS, extra rules for the find bar have been added to ensure that the dialog's doorhanger is always below the find button. All findbar `div`s are forced to be 32 pixels high to prevent the find message text being aligned under the checkboxes. Finally, the find message is only visible when there is actually text to display. This prevents wrapping issues because, by default, the label has padding and margin even if there is no text.
2017-03-09 07:54:28 +09:00
</div>
Add initial support for "Whole words" searching in the viewer As outlined in https://bugzilla.mozilla.org/show_bug.cgi?id=1282759 the internal Firefox name for the feature is `entireWord`, hence that name is used here as well for consistency (with "Whole words" being limited to the UI). Given existing limitations of the PDF.js search functionality, e.g. the existing problems of searching across "new lines", there's some edge-cases where "Whole words" searching will ignore (valid) results. However, considering that this is a pre-existing issue related to the way that the find controller joins text-content together, that shouldn't have to block this new feature in my opionion. *Please note:* In order to enable this feature in the `MOZCENTRAL` version, a small follow-up patch for [PdfjsChromeUtils.jsm](https://hg.mozilla.org/mozilla-central/file/tip/browser/extensions/pdfjs/content/PdfjsChromeUtils.jsm) will be required once this has landed in `mozilla-central`.
2018-09-01 08:28:19 +09:00
<div id="findbarOptionsTwoContainer">
Support search with or without diacritics (bug 1508345, bug 916883, bug 1651113) - get original index in using a dichotomic seach instead of a linear one; - normalize the text in using NFD; - convert the query string into a RegExp; - replace whitespaces in the query with \s+; - handle hyphens at eol use to break a word; - add some \s* around punctuation signs
2021-04-19 06:37:22 +09:00
<input type="checkbox" id="findMatchDiacritics" class="toolbarField" tabindex="96">
[api-minor] Move to Fluent for the localization (bug 1858715) - For the generic viewer we use @fluent/dom and @fluent/bundle - For the builtin pdf viewer in Firefox, we set a localization url and then we rely on document.l10n which is a DOMLocalization object.
2023-10-13 23:23:17 +09:00
<label for="findMatchDiacritics" class="toolbarLabel" data-l10n-id="pdfjs-find-match-diacritics-checkbox-label">Match Diacritics</label>
Support search with or without diacritics (bug 1508345, bug 916883, bug 1651113) - get original index in using a dichotomic seach instead of a linear one; - normalize the text in using NFD; - convert the query string into a RegExp; - replace whitespaces in the query with \s+; - handle hyphens at eol use to break a word; - add some \s* around punctuation signs
2021-04-19 06:37:22 +09:00
<input type="checkbox" id="findEntireWord" class="toolbarField" tabindex="97">
[api-minor] Move to Fluent for the localization (bug 1858715) - For the generic viewer we use @fluent/dom and @fluent/bundle - For the builtin pdf viewer in Firefox, we set a localization url and then we rely on document.l10n which is a DOMLocalization object.
2023-10-13 23:23:17 +09:00
<label for="findEntireWord" class="toolbarLabel" data-l10n-id="pdfjs-find-entire-word-checkbox-label">Whole Words</label>
Support search with or without diacritics (bug 1508345, bug 916883, bug 1651113) - get original index in using a dichotomic seach instead of a linear one; - normalize the text in using NFD; - convert the query string into a RegExp; - replace whitespaces in the query with \s+; - handle hyphens at eol use to break a word; - add some \s* around punctuation signs
2021-04-19 06:37:22 +09:00
</div>
[GENERIC viewer] Try to improve a11y, for search results, in the findbar (issue 14525) Note that it seemed necessary to re-factor the `findResultsCount` and `findMsg` element grouping, in the HTML/CSS code, in order those elements to be correctly announced by a11y software in Firefox. The following MDN articles may be helpful here: - https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-invalid - https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-live
2022-04-01 06:12:56 +09:00
<div id="findbarMessageContainer" aria-live="polite">
Simplify the `findResultsCount` span toggling, by using the same approach as with the `findMsg` span
2022-02-04 06:16:56 +09:00
<span id="findResultsCount" class="toolbarLabel"></span>
Viewer: enable find functionality for small devices The find functionality is currently not available for small devices because the find dialog is not responsive. This patch fixes that. To achieve this goal, the HTML is changed to always show the find button. To prevent issues because of the addition of an extra button for small views, the previous/next page buttons are hidden if the view becomes small. These buttons are not useful anyway because on small devices navigation is usually done via scrolling. The find functionality is much more useful to have in this case. Moreover, we wrap the existing elements into separate `div`s so that the browser can position the elements itself when the view becomes smaller and logically connected elements stay together when this happens. In the CSS, extra rules for the find bar have been added to ensure that the dialog's doorhanger is always below the find button. All findbar `div`s are forced to be 32 pixels high to prevent the find message text being aligned under the checkboxes. Finally, the find message is only visible when there is actually text to display. This prevents wrapping issues because, by default, the label has padding and margin even if there is no text.
2017-03-09 07:54:28 +09:00
<span id="findMsg" class="toolbarLabel"></span>
Add pilot find next/prev icons; localization
2012-10-06 09:15:06 +09:00
</div>
Secondary toolbar
2013-09-05 06:48:31 +09:00
</div> <!-- findbar -->
[Editor] Add a new editor to highlight some text in a pdf (bug 1866119) This patch is first big step for the new highlight feature. Few patches will follow in order to conform to the specs UX/UI gave us.
2023-11-23 03:02:42 +09:00
<div class="editorParamsToolbar hidden doorHangerRight" id="editorHighlightParamsToolbar">
[Editor] Add a color picker with predefined colors for highlighting text (bug 1866434) The doorhanger for highlighting has a basic color picker composed of 5 predefined colors to set the default color to use. These colors can be changed thanks to a preference for now but it's something which could be changed in the Firefox settings in the future. Each highlight has in its own toolbar a color picker to just change its color. The different color pickers are so similar (modulo few differences in their styles) that this patch introduces a new class ColorPicker which provides a color picker component which could be reused in future editors. All in all, a large part of this patch is dedicated to color picker itself and its style and the rest is almost a matter of wiring the component.
2023-12-01 00:21:13 +09:00
<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>
[Editor] Add a new editor to highlight some text in a pdf (bug 1866119) This patch is first big step for the new highlight feature. Few patches will follow in order to conform to the specs UX/UI gave us.
2023-11-23 03:02:42 +09:00
</div>
[Editor] Add the possibility to change the thickness of a free highlight (bug 1876096)
2024-01-23 05:27:45 +09:00
<div id="editorHighlightThickness">
<label for="editorFreeHighlightThickness" class="editorParamsLabel" data-l10n-id="pdfjs-editor-free-highlight-thickness-input">Thickness</label>
<div class="thicknessPicker">
[Editor] Add a tooltip to the slider to set the thickness of free highlights
2024-01-26 03:50:18 +09:00
<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="101">
[Editor] Add the possibility to change the thickness of a free highlight (bug 1876096)
2024-01-23 05:27:45 +09:00
</div>
</div>
[Editor] Add a new editor to highlight some text in a pdf (bug 1866119) This patch is first big step for the new highlight feature. Few patches will follow in order to conform to the specs UX/UI gave us.
2023-11-23 03:02:42 +09:00
</div>
</div>
[editor] Add some UI elements in order to set font size & color, and ink thickness & color
2022-06-14 01:23:10 +09:00
<div class="editorParamsToolbar hidden doorHangerRight" id="editorFreeTextParamsToolbar">
<div class="editorParamsToolbarContainer">
<div class="editorParamsSetter">
[api-minor] Move to Fluent for the localization (bug 1858715) - For the generic viewer we use @fluent/dom and @fluent/bundle - For the builtin pdf viewer in Firefox, we set a localization url and then we rely on document.l10n which is a DOMLocalization object.
2023-10-13 23:23:17 +09:00
<label for="editorFreeTextColor" class="editorParamsLabel" data-l10n-id="pdfjs-editor-free-text-color-input">Color</label>
[Editor] Add a new editor to highlight some text in a pdf (bug 1866119) This patch is first big step for the new highlight feature. Few patches will follow in order to conform to the specs UX/UI gave us.
2023-11-23 03:02:42 +09:00
<input type="color" id="editorFreeTextColor" class="editorParamsColor" tabindex="102">
[editor] Add some UI elements in order to set font size & color, and ink thickness & color
2022-06-14 01:23:10 +09:00
</div>
<div class="editorParamsSetter">
[api-minor] Move to Fluent for the localization (bug 1858715) - For the generic viewer we use @fluent/dom and @fluent/bundle - For the builtin pdf viewer in Firefox, we set a localization url and then we rely on document.l10n which is a DOMLocalization object.
2023-10-13 23:23:17 +09:00
<label for="editorFreeTextFontSize" class="editorParamsLabel" data-l10n-id="pdfjs-editor-free-text-size-input">Size</label>
[Editor] Add a new editor to highlight some text in a pdf (bug 1866119) This patch is first big step for the new highlight feature. Few patches will follow in order to conform to the specs UX/UI gave us.
2023-11-23 03:02:42 +09:00
<input type="range" id="editorFreeTextFontSize" class="editorParamsSlider" value="10" min="5" max="100" step="1" tabindex="103">
[editor] Add some UI elements in order to set font size & color, and ink thickness & color
2022-06-14 01:23:10 +09:00
</div>
</div>
</div>
<div class="editorParamsToolbar hidden doorHangerRight" id="editorInkParamsToolbar">
<div class="editorParamsToolbarContainer">
<div class="editorParamsSetter">
[api-minor] Move to Fluent for the localization (bug 1858715) - For the generic viewer we use @fluent/dom and @fluent/bundle - For the builtin pdf viewer in Firefox, we set a localization url and then we rely on document.l10n which is a DOMLocalization object.
2023-10-13 23:23:17 +09:00
<label for="editorInkColor" class="editorParamsLabel" data-l10n-id="pdfjs-editor-ink-color-input">Color</label>
[Editor] Add a new editor to highlight some text in a pdf (bug 1866119) This patch is first big step for the new highlight feature. Few patches will follow in order to conform to the specs UX/UI gave us.
2023-11-23 03:02:42 +09:00
<input type="color" id="editorInkColor" class="editorParamsColor" tabindex="104">
[editor] Add some UI elements in order to set font size & color, and ink thickness & color
2022-06-14 01:23:10 +09:00
</div>
<div class="editorParamsSetter">
[api-minor] Move to Fluent for the localization (bug 1858715) - For the generic viewer we use @fluent/dom and @fluent/bundle - For the builtin pdf viewer in Firefox, we set a localization url and then we rely on document.l10n which is a DOMLocalization object.
2023-10-13 23:23:17 +09:00
<label for="editorInkThickness" class="editorParamsLabel" data-l10n-id="pdfjs-editor-ink-thickness-input">Thickness</label>
[Editor] Add a new editor to highlight some text in a pdf (bug 1866119) This patch is first big step for the new highlight feature. Few patches will follow in order to conform to the specs UX/UI gave us.
2023-11-23 03:02:42 +09:00
<input type="range" id="editorInkThickness" class="editorParamsSlider" value="1" min="1" max="20" step="1" tabindex="105">
[editor] Add some UI elements in order to set font size & color, and ink thickness & color
2022-06-14 01:23:10 +09:00
</div>
[Editor] Add the possibility to change line opacity in Ink editor
2022-07-25 05:19:09 +09:00
<div class="editorParamsSetter">
[api-minor] Move to Fluent for the localization (bug 1858715) - For the generic viewer we use @fluent/dom and @fluent/bundle - For the builtin pdf viewer in Firefox, we set a localization url and then we rely on document.l10n which is a DOMLocalization object.
2023-10-13 23:23:17 +09:00
<label for="editorInkOpacity" class="editorParamsLabel" data-l10n-id="pdfjs-editor-ink-opacity-input">Opacity</label>
[Editor] Add a new editor to highlight some text in a pdf (bug 1866119) This patch is first big step for the new highlight feature. Few patches will follow in order to conform to the specs UX/UI gave us.
2023-11-23 03:02:42 +09:00
<input type="range" id="editorInkOpacity" class="editorParamsSlider" value="100" min="1" max="100" step="1" tabindex="106">
[Editor] Add the possibility to change line opacity in Ink editor
2022-07-25 05:19:09 +09:00
</div>
[editor] Add some UI elements in order to set font size & color, and ink thickness & color
2022-06-14 01:23:10 +09:00
</div>
</div>
[Editor] Add a button to explicitly add an image (bug 1848108) The main stamp button will be used to just enter in a add/edit image mode: - the user can add a new image in using the new button. - the user can edit an image in resizing, moving it. In image mode, when the user clicks outside on the page but not on an editor, then all the selected editors will be unselected.
2023-08-09 21:07:15 +09:00
<div class="editorParamsToolbar hidden doorHangerRight" id="editorStampParamsToolbar">
<div class="editorParamsToolbarContainer">
[Editor] Add a new editor to highlight some text in a pdf (bug 1866119) This patch is first big step for the new highlight feature. Few patches will follow in order to conform to the specs UX/UI gave us.
2023-11-23 03:02:42 +09:00
<button id="editorStampAddImage" class="secondaryToolbarButton" title="Add image" tabindex="107" data-l10n-id="pdfjs-editor-stamp-add-image-button">
[Editor] Add a color picker with predefined colors for highlighting text (bug 1866434) The doorhanger for highlighting has a basic color picker composed of 5 predefined colors to set the default color to use. These colors can be changed thanks to a preference for now but it's something which could be changed in the Firefox settings in the future. Each highlight has in its own toolbar a color picker to just change its color. The different color pickers are so similar (modulo few differences in their styles) that this patch introduces a new class ColorPicker which provides a color picker component which could be reused in future editors. All in all, a large part of this patch is dedicated to color picker itself and its style and the rest is almost a matter of wiring the component.
2023-12-01 00:21:13 +09:00
<span class="editorParamsLabel" data-l10n-id="pdfjs-editor-stamp-add-image-button-label">Add image</span>
[Editor] Add a button to explicitly add an image (bug 1848108) The main stamp button will be used to just enter in a add/edit image mode: - the user can add a new image in using the new button. - the user can edit an image in resizing, moving it. In image mode, when the user clicks outside on the page but not on an editor, then all the selected editors will be unselected.
2023-08-09 21:07:15 +09:00
</button>
</div>
</div>
Secondary toolbar
2013-09-05 06:48:31 +09:00
<div id="secondaryToolbar" class="secondaryToolbar hidden doorHangerRight">
<div id="secondaryToolbarButtonContainer">
Stop bundling the openFile-buttons in the CHROME build This is, for all intents and purposes, equivalent to PR 14833 and slightly reduces the size of the `gulp chromium` output.
2022-05-08 05:05:39 +09:00
<!--#if GENERIC-->
Remove the "Open file"-button from the main toolbar This button is *only* used in the GENERIC viewer, and will currently be visible either in the main or secondary toolbars (depending on the viewer width). To simplify upcoming changes, and to avoid then having to complicate the relevant CSS rules unnecessarily, let's place the "Open file"-button permanently in the secondary toolbar instead. (Note that the GENERIC viewer also, since five years, supports drag-and-drop in order to open local files.)
2023-11-09 15:55:48 +09:00
<button id="secondaryOpenFile" class="secondaryToolbarButton" title="Open File" tabindex="51" data-l10n-id="pdfjs-open-file-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 23:23:17 +09:00
<span data-l10n-id="pdfjs-open-file-button-label">Open</span>
Secondary toolbar
2013-09-05 06:48:31 +09:00
</button>
Stop bundling the openFile-buttons in the MOZCENTRAL build Note how both of the openFile-buttons are always hidden during viewer initialization in the MOZCENTRAL build, i.e. the *built-in* Firefox PDF Viewer. Despite that we still include HTML, CSS, and JavaScript code for these buttons in the build. This patch *reduces* the size of the `gulp mozcentral` output by `1679` bytes, which isn't a lot but still cannot hurt.
2022-04-25 17:06:47 +09:00
<!--#endif-->
Secondary toolbar
2013-09-05 06:48:31 +09:00
[api-minor] Move to Fluent for the localization (bug 1858715) - For the generic viewer we use @fluent/dom and @fluent/bundle - For the builtin pdf viewer in Firefox, we set a localization url and then we rely on document.l10n which is a DOMLocalization object.
2023-10-13 23:23:17 +09:00
<button id="secondaryPrint" class="secondaryToolbarButton visibleMediumView" title="Print" tabindex="52" data-l10n-id="pdfjs-print-button">
<span data-l10n-id="pdfjs-print-button-label">Print</span>
Secondary toolbar
2013-09-05 06:48:31 +09:00
</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 23:23:17 +09:00
<button id="secondaryDownload" class="secondaryToolbarButton visibleMediumView" title="Save" tabindex="53" data-l10n-id="pdfjs-save-button">
<span data-l10n-id="pdfjs-save-button-label">Save</span>
Secondary toolbar
2013-09-05 06:48:31 +09:00
</button>
Fix the visibility of a separator in the secondaryToolbar (PR 15391 follow-up) After the changes in PR 15391 one separator may now become visible too soon when the viewer is narrow, applies e.g. to the MOZCENTRAL viewer, since the wrong CSS class is being used. The reason that this happens is that only the GENERIC viewer includes the "openFile"-buttons, and we thus need the separator to also be conditionally defined.
2022-09-10 00:50:29 +09:00
<!--#if GENERIC-->
Remove the "Open file"-button from the main toolbar This button is *only* used in the GENERIC viewer, and will currently be visible either in the main or secondary toolbars (depending on the viewer width). To simplify upcoming changes, and to avoid then having to complicate the relevant CSS rules unnecessarily, let's place the "Open file"-button permanently in the secondary toolbar instead. (Note that the GENERIC viewer also, since five years, supports drag-and-drop in order to open local files.)
2023-11-09 15:55:48 +09:00
<div class="horizontalToolbarSeparator"></div>
Fix the visibility of a separator in the secondaryToolbar (PR 15391 follow-up) After the changes in PR 15391 one separator may now become visible too soon when the viewer is narrow, applies e.g. to the MOZCENTRAL viewer, since the wrong CSS class is being used. The reason that this happens is that only the GENERIC viewer includes the "openFile"-buttons, and we thus need the separator to also be conditionally defined.
2022-09-10 00:50:29 +09:00
<!--#else-->
<!-- <div class="horizontalToolbarSeparator visibleMediumView"></div>-->
<!--#endif-->
Move 'presentation mode' and 'bookmarks' buttons in the secondary toolbar (bug 1789082)
2022-09-03 23:17:22 +09:00
[api-minor] Move to Fluent for the localization (bug 1858715) - For the generic viewer we use @fluent/dom and @fluent/bundle - For the builtin pdf viewer in Firefox, we set a localization url and then we rely on document.l10n which is a DOMLocalization object.
2023-10-13 23:23:17 +09:00
<button id="presentationMode" class="secondaryToolbarButton" title="Switch to Presentation Mode" tabindex="54" data-l10n-id="pdfjs-presentation-mode-button">
<span data-l10n-id="pdfjs-presentation-mode-button-label">Presentation Mode</span>
Move 'presentation mode' and 'bookmarks' buttons in the secondary toolbar (bug 1789082)
2022-09-03 23:17:22 +09:00
</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 23:23:17 +09:00
<a href="#" id="viewBookmark" class="secondaryToolbarButton" title="Current Page (View URL from Current Page)" tabindex="55" data-l10n-id="pdfjs-bookmark-button">
<span data-l10n-id="pdfjs-bookmark-button-label">Current Page</span>
Add the viewBookmark button to the secondary toolbar
2013-09-27 18:44:45 +09:00
</a>
Ignore PDF documents opened from "data:"-URLs when handling internal links (bug 1803050) This patch has been successfully tested in a local, artifact, Firefox build. *Please note:* The only thing that'll no longer work for PDF documents opened using "data:"-URLs is middle-clicking on internal/outline links, in order to open the destination in a new tab. This is however an extremely small loss of functionality, and as can be seen in the bug the alternative (i.e. doing nothing) is surely much worse.
2022-11-29 21:51:40 +09:00
<div id="viewBookmarkSeparator" class="horizontalToolbarSeparator"></div>
Secondary toolbar
2013-09-05 06:48:31 +09:00
[api-minor] Move to Fluent for the localization (bug 1858715) - For the generic viewer we use @fluent/dom and @fluent/bundle - For the builtin pdf viewer in Firefox, we set a localization url and then we rely on document.l10n which is a DOMLocalization object.
2023-10-13 23:23:17 +09:00
<button id="firstPage" class="secondaryToolbarButton" title="Go to First Page" tabindex="56" data-l10n-id="pdfjs-first-page-button">
<span data-l10n-id="pdfjs-first-page-button-label">Go to First Page</span>
Secondary toolbar
2013-09-05 06:48:31 +09:00
</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 23:23:17 +09:00
<button id="lastPage" class="secondaryToolbarButton" title="Go to Last Page" tabindex="57" data-l10n-id="pdfjs-last-page-button">
<span data-l10n-id="pdfjs-last-page-button-label">Go to Last Page</span>
Secondary toolbar
2013-09-05 06:48:31 +09:00
</button>
<div class="horizontalToolbarSeparator"></div>
[api-minor] Move to Fluent for the localization (bug 1858715) - For the generic viewer we use @fluent/dom and @fluent/bundle - For the builtin pdf viewer in Firefox, we set a localization url and then we rely on document.l10n which is a DOMLocalization object.
2023-10-13 23:23:17 +09:00
<button id="pageRotateCw" class="secondaryToolbarButton" title="Rotate Clockwise" tabindex="58" data-l10n-id="pdfjs-page-rotate-cw-button">
<span data-l10n-id="pdfjs-page-rotate-cw-button-label">Rotate Clockwise</span>
Secondary toolbar
2013-09-05 06:48:31 +09:00
</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 23:23:17 +09:00
<button id="pageRotateCcw" class="secondaryToolbarButton" title="Rotate Counterclockwise" tabindex="59" data-l10n-id="pdfjs-page-rotate-ccw-button">
<span data-l10n-id="pdfjs-page-rotate-ccw-button-label">Rotate Counterclockwise</span>
Secondary toolbar
2013-09-05 06:48:31 +09:00
</button>
Implement hand tool The logic for the hand tool is implemented in a separate project, maintained at https://github.com/Rob--W/grab-to-pan.js Integration notes - Added toggle as an entry under the Secondary toolbar - Added shortcut "h" to toggle hand tool (to-do: document this in wiki after merge). This shortcut is also used in Adobe's Acrobat Reader. To-do: localizations for: hand_tool_enable.title= hand_tool_enable_label= hand_tool_disable.title= hand_tool_disable_label= To-do (wish): persistence of hand tool preference, preferably a global setting. secondaryToolbarButton-handTool.png created by Stephen Horlander <shorlander@mozilla.com>
2013-10-03 05:09:43 +09:00
<div class="horizontalToolbarSeparator"></div>
Try to improve a11y for the "button groups" in the SecondaryToolbar/Sidebar (issue 14526) *Please note:* I don't really know anything about a11y, hence it's possible that this patch either doesn't work correctly or at least isn't a complete solution. In both the SecondaryToolbar and the Sidebar we have "button groups" that functionally acts essentially like radio-buttons. Based on skimming through [this MDN article](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/radio_role) it thus appears that we should tag them as such, using `role="radiogroup"` and `role="radio"`, and then utilize the `aria-checked` attribute to indicate to a11y software which button is currently active.
2022-02-11 22:04:47 +09:00
<div id="cursorToolButtons" role="radiogroup">
[api-minor] Move to Fluent for the localization (bug 1858715) - For the generic viewer we use @fluent/dom and @fluent/bundle - For the builtin pdf viewer in Firefox, we set a localization url and then we rely on document.l10n which is a DOMLocalization object.
2023-10-13 23:23:17 +09:00
<button id="cursorSelectTool" class="secondaryToolbarButton toggled" title="Enable Text Selection Tool" tabindex="60" 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>
Try to improve a11y for the "button groups" in the SecondaryToolbar/Sidebar (issue 14526) *Please note:* I don't really know anything about a11y, hence it's possible that this patch either doesn't work correctly or at least isn't a complete solution. In both the SecondaryToolbar and the Sidebar we have "button groups" that functionally acts essentially like radio-buttons. Based on skimming through [this MDN article](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/radio_role) it thus appears that we should tag them as such, using `role="radiogroup"` and `role="radio"`, and then utilize the `aria-checked` attribute to indicate to a11y software which button is currently active.
2022-02-11 22:04:47 +09:00
</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 23:23:17 +09:00
<button id="cursorHandTool" class="secondaryToolbarButton" title="Enable Hand Tool" tabindex="61" 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>
Try to improve a11y for the "button groups" in the SecondaryToolbar/Sidebar (issue 14526) *Please note:* I don't really know anything about a11y, hence it's possible that this patch either doesn't work correctly or at least isn't a complete solution. In both the SecondaryToolbar and the Sidebar we have "button groups" that functionally acts essentially like radio-buttons. Based on skimming through [this MDN article](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/radio_role) it thus appears that we should tag them as such, using `role="radiogroup"` and `role="radio"`, and then utilize the `aria-checked` attribute to indicate to a11y software which button is currently active.
2022-02-11 22:04:47 +09:00
</button>
</div>
cleaned whitespace
2015-02-03 00:12:52 +09:00
Document properties
2014-01-22 08:07:07 +09:00
<div class="horizontalToolbarSeparator"></div>
Try to improve a11y for the "button groups" in the SecondaryToolbar/Sidebar (issue 14526) *Please note:* I don't really know anything about a11y, hence it's possible that this patch either doesn't work correctly or at least isn't a complete solution. In both the SecondaryToolbar and the Sidebar we have "button groups" that functionally acts essentially like radio-buttons. Based on skimming through [this MDN article](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/radio_role) it thus appears that we should tag them as such, using `role="radiogroup"` and `role="radio"`, and then utilize the `aria-checked` attribute to indicate to a11y software which button is currently active.
2022-02-11 22:04:47 +09:00
<div id="scrollModeButtons" role="radiogroup">
[api-minor] Move to Fluent for the localization (bug 1858715) - For the generic viewer we use @fluent/dom and @fluent/bundle - For the builtin pdf viewer in Firefox, we set a localization url and then we rely on document.l10n which is a DOMLocalization object.
2023-10-13 23:23:17 +09:00
<button id="scrollPage" class="secondaryToolbarButton" title="Use Page Scrolling" tabindex="62" data-l10n-id="pdfjs-scroll-page-button" role="radio" aria-checked="false">
<span data-l10n-id="pdfjs-scroll-page-button-label">Page Scrolling</span>
Try to improve a11y for the "button groups" in the SecondaryToolbar/Sidebar (issue 14526) *Please note:* I don't really know anything about a11y, hence it's possible that this patch either doesn't work correctly or at least isn't a complete solution. In both the SecondaryToolbar and the Sidebar we have "button groups" that functionally acts essentially like radio-buttons. Based on skimming through [this MDN article](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/radio_role) it thus appears that we should tag them as such, using `role="radiogroup"` and `role="radio"`, and then utilize the `aria-checked` attribute to indicate to a11y software which button is currently active.
2022-02-11 22:04:47 +09:00
</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 23:23:17 +09:00
<button id="scrollVertical" class="secondaryToolbarButton toggled" title="Use Vertical Scrolling" tabindex="63" data-l10n-id="pdfjs-scroll-vertical-button" role="radio" aria-checked="true">
<span data-l10n-id="pdfjs-scroll-vertical-button-label" >Vertical Scrolling</span>
Try to improve a11y for the "button groups" in the SecondaryToolbar/Sidebar (issue 14526) *Please note:* I don't really know anything about a11y, hence it's possible that this patch either doesn't work correctly or at least isn't a complete solution. In both the SecondaryToolbar and the Sidebar we have "button groups" that functionally acts essentially like radio-buttons. Based on skimming through [this MDN article](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/radio_role) it thus appears that we should tag them as such, using `role="radiogroup"` and `role="radio"`, and then utilize the `aria-checked` attribute to indicate to a11y software which button is currently active.
2022-02-11 22:04:47 +09:00
</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 23:23:17 +09:00
<button id="scrollHorizontal" class="secondaryToolbarButton" title="Use Horizontal Scrolling" tabindex="64" data-l10n-id="pdfjs-scroll-horizontal-button" role="radio" aria-checked="false">
<span data-l10n-id="pdfjs-scroll-horizontal-button-label">Horizontal Scrolling</span>
Try to improve a11y for the "button groups" in the SecondaryToolbar/Sidebar (issue 14526) *Please note:* I don't really know anything about a11y, hence it's possible that this patch either doesn't work correctly or at least isn't a complete solution. In both the SecondaryToolbar and the Sidebar we have "button groups" that functionally acts essentially like radio-buttons. Based on skimming through [this MDN article](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/radio_role) it thus appears that we should tag them as such, using `role="radiogroup"` and `role="radio"`, and then utilize the `aria-checked` attribute to indicate to a11y software which button is currently active.
2022-02-11 22:04:47 +09:00
</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 23:23:17 +09:00
<button id="scrollWrapped" class="secondaryToolbarButton" title="Use Wrapped Scrolling" tabindex="65" data-l10n-id="pdfjs-scroll-wrapped-button" role="radio" aria-checked="false">
<span data-l10n-id="pdfjs-scroll-wrapped-button-label">Wrapped Scrolling</span>
Try to improve a11y for the "button groups" in the SecondaryToolbar/Sidebar (issue 14526) *Please note:* I don't really know anything about a11y, hence it's possible that this patch either doesn't work correctly or at least isn't a complete solution. In both the SecondaryToolbar and the Sidebar we have "button groups" that functionally acts essentially like radio-buttons. Based on skimming through [this MDN article](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/radio_role) it thus appears that we should tag them as such, using `role="radiogroup"` and `role="radio"`, and then utilize the `aria-checked` attribute to indicate to a11y software which button is currently active.
2022-02-11 22:04:47 +09:00
</button>
</div>
Add scrolling modes to web viewer In addition to the default scrolling mode (vertical), this commit adds horizontal and wrapped scrolling, implemented primarily with CSS.
2018-05-15 12:10:32 +09:00
Remove the `PDFSinglePageViewer`-specific code from `web/secondary_toolbar.js` (PR 9877 follow-up) This was added on the assumption that the viewer would (eventually) start using the `PDFSinglePageViewer` for e.g. PAGE-scrolling mode and PresentationMode. However, having both a `PDFViewer` and a `PDFSinglePageViewer` side-by-side in the viewer would've been tricky to implement well, which is why PR 14112 implemented PAGE-scrolling for the general `BaseViewer` instead. Given that the default viewer is no longer (potentially) going to use `PDFSinglePageViewer`, there's code in the `SecondaryToolbar` (and related CSS rules) which is now unnecessary.
2021-11-29 02:36:25 +09:00
<div class="horizontalToolbarSeparator"></div>
Add scrolling modes to web viewer In addition to the default scrolling mode (vertical), this commit adds horizontal and wrapped scrolling, implemented primarily with CSS.
2018-05-15 12:10:32 +09:00
Try to improve a11y for the "button groups" in the SecondaryToolbar/Sidebar (issue 14526) *Please note:* I don't really know anything about a11y, hence it's possible that this patch either doesn't work correctly or at least isn't a complete solution. In both the SecondaryToolbar and the Sidebar we have "button groups" that functionally acts essentially like radio-buttons. Based on skimming through [this MDN article](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/radio_role) it thus appears that we should tag them as such, using `role="radiogroup"` and `role="radio"`, and then utilize the `aria-checked` attribute to indicate to a11y software which button is currently active.
2022-02-11 22:04:47 +09:00
<div id="spreadModeButtons" role="radiogroup">
[api-minor] Move to Fluent for the localization (bug 1858715) - For the generic viewer we use @fluent/dom and @fluent/bundle - For the builtin pdf viewer in Firefox, we set a localization url and then we rely on document.l10n which is a DOMLocalization object.
2023-10-13 23:23:17 +09:00
<button id="spreadNone" class="secondaryToolbarButton toggled" title="Do not join page spreads" tabindex="66" data-l10n-id="pdfjs-spread-none-button" role="radio" aria-checked="true">
<span data-l10n-id="pdfjs-spread-none-button-label">No Spreads</span>
Try to improve a11y for the "button groups" in the SecondaryToolbar/Sidebar (issue 14526) *Please note:* I don't really know anything about a11y, hence it's possible that this patch either doesn't work correctly or at least isn't a complete solution. In both the SecondaryToolbar and the Sidebar we have "button groups" that functionally acts essentially like radio-buttons. Based on skimming through [this MDN article](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/radio_role) it thus appears that we should tag them as such, using `role="radiogroup"` and `role="radio"`, and then utilize the `aria-checked` attribute to indicate to a11y software which button is currently active.
2022-02-11 22:04:47 +09:00
</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 23:23:17 +09:00
<button id="spreadOdd" class="secondaryToolbarButton" title="Join page spreads starting with odd-numbered pages" tabindex="67" data-l10n-id="pdfjs-spread-odd-button" role="radio" aria-checked="false">
<span data-l10n-id="pdfjs-spread-odd-button-label">Odd Spreads</span>
Try to improve a11y for the "button groups" in the SecondaryToolbar/Sidebar (issue 14526) *Please note:* I don't really know anything about a11y, hence it's possible that this patch either doesn't work correctly or at least isn't a complete solution. In both the SecondaryToolbar and the Sidebar we have "button groups" that functionally acts essentially like radio-buttons. Based on skimming through [this MDN article](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/radio_role) it thus appears that we should tag them as such, using `role="radiogroup"` and `role="radio"`, and then utilize the `aria-checked` attribute to indicate to a11y software which button is currently active.
2022-02-11 22:04:47 +09:00
</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 23:23:17 +09:00
<button id="spreadEven" class="secondaryToolbarButton" title="Join page spreads starting with even-numbered pages" tabindex="68" data-l10n-id="pdfjs-spread-even-button" role="radio" aria-checked="false">
<span data-l10n-id="pdfjs-spread-even-button-label">Even Spreads</span>
Try to improve a11y for the "button groups" in the SecondaryToolbar/Sidebar (issue 14526) *Please note:* I don't really know anything about a11y, hence it's possible that this patch either doesn't work correctly or at least isn't a complete solution. In both the SecondaryToolbar and the Sidebar we have "button groups" that functionally acts essentially like radio-buttons. Based on skimming through [this MDN article](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/radio_role) it thus appears that we should tag them as such, using `role="radiogroup"` and `role="radio"`, and then utilize the `aria-checked` attribute to indicate to a11y software which button is currently active.
2022-02-11 22:04:47 +09:00
</button>
</div>
Add spread modes to web viewer This builds on the scrolling mode work to add three buttons for joining page spreads together: one for the default view, with no page spreads, and two for spreads starting on odd-numbered or even-numbered pages.
2018-05-15 12:10:32 +09:00
Remove the `PDFSinglePageViewer`-specific code from `web/secondary_toolbar.js` (PR 9877 follow-up) This was added on the assumption that the viewer would (eventually) start using the `PDFSinglePageViewer` for e.g. PAGE-scrolling mode and PresentationMode. However, having both a `PDFViewer` and a `PDFSinglePageViewer` side-by-side in the viewer would've been tricky to implement well, which is why PR 14112 implemented PAGE-scrolling for the general `BaseViewer` instead. Given that the default viewer is no longer (potentially) going to use `PDFSinglePageViewer`, there's code in the `SecondaryToolbar` (and related CSS rules) which is now unnecessary.
2021-11-29 02:36:25 +09:00
<div class="horizontalToolbarSeparator"></div>
Add spread modes to web viewer This builds on the scrolling mode work to add three buttons for joining page spreads together: one for the default view, with no page spreads, and two for spreads starting on odd-numbered or even-numbered pages.
2018-05-15 12:10:32 +09:00
[api-minor] Move to Fluent for the localization (bug 1858715) - For the generic viewer we use @fluent/dom and @fluent/bundle - For the builtin pdf viewer in Firefox, we set a localization url and then we rely on document.l10n which is a DOMLocalization object.
2023-10-13 23:23:17 +09:00
<button id="documentProperties" class="secondaryToolbarButton" title="Document Properties…" tabindex="69" data-l10n-id="pdfjs-document-properties-button" aria-controls="documentPropertiesDialog">
<span data-l10n-id="pdfjs-document-properties-button-label">Document Properties…</span>
Document properties
2014-01-22 08:07:07 +09:00
</button>
Secondary toolbar
2013-09-05 06:48:31 +09:00
</div>
</div> <!-- secondaryToolbar -->
Remove flex box. Add side animation. Add dashed line around unload thumbnails.
2012-04-26 03:34:28 +09:00
<div class="toolbar">
<div id="toolbarContainer">
<div id="toolbarViewer">
<div id="toolbarViewerLeft">
[api-minor] Move to Fluent for the localization (bug 1858715) - For the generic viewer we use @fluent/dom and @fluent/bundle - For the builtin pdf viewer in Firefox, we set a localization url and then we rely on document.l10n which is a DOMLocalization object.
2023-10-13 23:23:17 +09:00
<button id="sidebarToggle" class="toolbarButton" title="Toggle Sidebar" tabindex="11" data-l10n-id="pdfjs-toggle-sidebar-button" aria-expanded="false" aria-controls="sidebarContainer">
<span data-l10n-id="pdfjs-toggle-sidebar-button-label">Toggle Sidebar</span>
Addressing accessebility aspects
2012-05-04 23:51:21 +09:00
</button>
Remove flex box. Add side animation. Add dashed line around unload thumbnails.
2012-04-26 03:34:28 +09:00
<div class="toolbarButtonSpacer"></div>
[api-minor] Move to Fluent for the localization (bug 1858715) - For the generic viewer we use @fluent/dom and @fluent/bundle - For the builtin pdf viewer in Firefox, we set a localization url and then we rely on document.l10n which is a DOMLocalization object.
2023-10-13 23:23:17 +09:00
<button id="viewFind" class="toolbarButton" title="Find in Document" tabindex="12" data-l10n-id="pdfjs-findbar-button" aria-expanded="false" aria-controls="findbar">
<span data-l10n-id="pdfjs-findbar-button-label">Find</span>
Add some door hanger styling for the find bar
2012-09-29 04:30:07 +09:00
</button>
Viewer: enable find functionality for small devices The find functionality is currently not available for small devices because the find dialog is not responsive. This patch fixes that. To achieve this goal, the HTML is changed to always show the find button. To prevent issues because of the addition of an extra button for small views, the previous/next page buttons are hidden if the view becomes small. These buttons are not useful anyway because on small devices navigation is usually done via scrolling. The find functionality is much more useful to have in this case. Moreover, we wrap the existing elements into separate `div`s so that the browser can position the elements itself when the view becomes smaller and logically connected elements stay together when this happens. In the CSS, extra rules for the find bar have been added to ensure that the dialog's doorhanger is always below the find button. All findbar `div`s are forced to be 32 pixels high to prevent the find message text being aligned under the checkboxes. Finally, the find message is only visible when there is actually text to display. This prevents wrapping issues because, by default, the label has padding and margin even if there is no text.
2017-03-09 07:54:28 +09:00
<div class="splitToolbarButton hiddenSmallView">
[api-minor] Move to Fluent for the localization (bug 1858715) - For the generic viewer we use @fluent/dom and @fluent/bundle - For the builtin pdf viewer in Firefox, we set a localization url and then we rely on document.l10n which is a DOMLocalization object.
2023-10-13 23:23:17 +09:00
<button class="toolbarButton" title="Previous Page" id="previous" tabindex="13" data-l10n-id="pdfjs-previous-button">
<span data-l10n-id="pdfjs-previous-button-label">Previous</span>
Addressing accessebility aspects
2012-05-04 23:51:21 +09:00
</button>
Remove flex box. Add side animation. Add dashed line around unload thumbnails.
2012-04-26 03:34:28 +09:00
<div class="splitToolbarButtonSeparator"></div>
[api-minor] Move to Fluent for the localization (bug 1858715) - For the generic viewer we use @fluent/dom and @fluent/bundle - For the builtin pdf viewer in Firefox, we set a localization url and then we rely on document.l10n which is a DOMLocalization object.
2023-10-13 23:23:17 +09:00
<button class="toolbarButton" title="Next Page" id="next" tabindex="14" data-l10n-id="pdfjs-next-button">
<span data-l10n-id="pdfjs-next-button-label">Next</span>
Addressing accessebility aspects
2012-05-04 23:51:21 +09:00
</button>
Remove flex box. Add side animation. Add dashed line around unload thumbnails.
2012-04-26 03:34:28 +09:00
</div>
Re-factor the loading-icons used in the viewer toolbars Currently the SVG images for the loading-icons exist in two versions, for the light- respectively dark-theme, which nowadays are the only "duplicated" icons left. The reason for this is that these icons are being used in `input`-elements, where the regular `mask-image` approach used for all buttons don't work. To address this we add containers for the `input`-elements, such that we have a "regular" DOM-element where we can use `mask-image`.
2023-11-16 22:24:16 +09:00
<span class="loadingInput start">
<input type="number" id="pageNumber" class="toolbarField" title="Page" value="1" min="1" tabindex="15" data-l10n-id="pdfjs-page-input" autocomplete="off">
</span>
Remove flex box. Add side animation. Add dashed line around unload thumbnails.
2012-04-26 03:34:28 +09:00
<span id="numPages" class="toolbarLabel"></span>
</div>
<div id="toolbarViewerRight">
[api-major] Enable editing by default Note that this patch *at least* shouldn't land until both [bug 1784272](https://bugzilla.mozilla.org/show_bug.cgi?id=1784272) and [bug 1785248](https://bugzilla.mozilla.org/show_bug.cgi?id=1785248) are fixed.
2022-08-21 20:48:48 +09:00
<div id="editorModeButtons" class="splitToolbarButton toggled" role="radiogroup">
[Editor] Add some missing strings to localize for highlighting
2023-12-12 01:20:56 +09:00
<button id="editorHighlight" class="toolbarButton" hidden="true" disabled="disabled" title="Highlight" role="radio" aria-checked="false" aria-controls="editorHighlightParamsToolbar" tabindex="31" data-l10n-id="pdfjs-editor-highlight-button">
<span data-l10n-id="pdfjs-editor-highlight-button-label">Highlight</span>
Adds missing button closing tag
2023-12-12 01:42:43 +09:00
</button>
[Editor] Add a new editor to highlight some text in a pdf (bug 1866119) This patch is first big step for the new highlight feature. Few patches will follow in order to conform to the specs UX/UI gave us.
2023-11-23 03:02:42 +09:00
<button id="editorFreeText" class="toolbarButton" disabled="disabled" title="Text" role="radio" aria-checked="false" aria-controls="editorFreeTextParamsToolbar" tabindex="32" data-l10n-id="pdfjs-editor-free-text-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 23:23:17 +09:00
<span data-l10n-id="pdfjs-editor-free-text-button-label">Text</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-21 01:08:41 +09:00
</button>
[Editor] Add a new editor to highlight some text in a pdf (bug 1866119) This patch is first big step for the new highlight feature. Few patches will follow in order to conform to the specs UX/UI gave us.
2023-11-23 03:02:42 +09:00
<button id="editorInk" class="toolbarButton" disabled="disabled" title="Draw" role="radio" aria-checked="false" aria-controls="editorInkParamsToolbar" tabindex="33" data-l10n-id="pdfjs-editor-ink-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 23:23:17 +09:00
<span data-l10n-id="pdfjs-editor-ink-button-label">Draw</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-21 01:08:41 +09:00
</button>
Revert "Remove the `enableStampEditor` preference" (bug 1879588) This reverts commit e820688510e2c1c24088e76a178a82ef8ebcaf4d.
2024-02-10 02:19:19 +09:00
<button id="editorStamp" class="toolbarButton hidden" disabled="disabled" title="Add or edit images" role="radio" aria-checked="false" aria-controls="editorStampParamsToolbar" tabindex="34" data-l10n-id="pdfjs-editor-stamp-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 23:23:17 +09:00
<span data-l10n-id="pdfjs-editor-stamp-button-label">Add or edit images</span>
[Editor] Move the stamp button on the right of the pen one (bug 1847707)
2023-08-08 18:35:51 +09:00
</button>
[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-21 01:08:41 +09:00
</div>
[api-major] Enable editing by default Note that this patch *at least* shouldn't land until both [bug 1784272](https://bugzilla.mozilla.org/show_bug.cgi?id=1784272) and [bug 1785248](https://bugzilla.mozilla.org/show_bug.cgi?id=1785248) are fixed.
2022-08-21 20:48:48 +09:00
<div id="editorModeSeparator" class="verticalToolbarSeparator"></div>
[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-21 01:08:41 +09:00
Move the editor-buttons in the main toolbar By introducing a CSS variable for the editor-toolbars we're able to handle resizing of the viewer without complicating the code too much.
2023-11-19 06:05:21 +09:00
<button id="print" class="toolbarButton hiddenMediumView" title="Print" tabindex="41" data-l10n-id="pdfjs-print-button">
<span data-l10n-id="pdfjs-print-button-label">Print</span>
</button>
<button id="download" class="toolbarButton hiddenMediumView" title="Save" tabindex="42" data-l10n-id="pdfjs-save-button">
<span data-l10n-id="pdfjs-save-button-label">Save</span>
</button>
<div class="verticalToolbarSeparator hiddenMediumView"></div>
<button id="secondaryToolbarToggle" class="toolbarButton" title="Tools" tabindex="43" data-l10n-id="pdfjs-tools-button" aria-expanded="false" aria-controls="secondaryToolbar">
[api-minor] Move to Fluent for the localization (bug 1858715) - For the generic viewer we use @fluent/dom and @fluent/bundle - For the builtin pdf viewer in Firefox, we set a localization url and then we rely on document.l10n which is a DOMLocalization object.
2023-10-13 23:23:17 +09:00
<span data-l10n-id="pdfjs-tools-button-label">Tools</span>
cleaned whitespace
2015-02-03 00:12:52 +09:00
</button>
Remove flex box. Add side animation. Add dashed line around unload thumbnails.
2012-04-26 03:34:28 +09: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-04 00:56:57 +09:00
<div id="toolbarViewerMiddle">
<div class="splitToolbarButton">
[api-minor] Move to Fluent for the localization (bug 1858715) - For the generic viewer we use @fluent/dom and @fluent/bundle - For the builtin pdf viewer in Firefox, we set a localization url and then we rely on document.l10n which is a DOMLocalization object.
2023-10-13 23:23:17 +09:00
<button id="zoomOut" class="toolbarButton" title="Zoom Out" tabindex="21" data-l10n-id="pdfjs-zoom-out-button">
<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-04 00:56:57 +09:00
</button>
<div class="splitToolbarButtonSeparator"></div>
[api-minor] Move to Fluent for the localization (bug 1858715) - For the generic viewer we use @fluent/dom and @fluent/bundle - For the builtin pdf viewer in Firefox, we set a localization url and then we rely on document.l10n which is a DOMLocalization object.
2023-10-13 23:23:17 +09:00
<button id="zoomIn" class="toolbarButton" title="Zoom In" tabindex="22" data-l10n-id="pdfjs-zoom-in-button">
<span data-l10n-id="pdfjs-zoom-in-button-label">Zoom In</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-04 00:56:57 +09:00
</button>
Remove flex box. Add side animation. Add dashed line around unload thumbnails.
2012-04-26 03:34:28 +09: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-04 00:56:57 +09:00
<span id="scaleSelectContainer" class="dropdownToolbarButton">
[api-minor] Move to Fluent for the localization (bug 1858715) - For the generic viewer we use @fluent/dom and @fluent/bundle - For the builtin pdf viewer in Firefox, we set a localization url and then we rely on document.l10n which is a DOMLocalization object.
2023-10-13 23:23:17 +09:00
<select id="scaleSelect" title="Zoom" tabindex="23" data-l10n-id="pdfjs-zoom-select">
<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 23:30:57 +09: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 23:23:17 +09: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-04 00:56:57 +09:00
</select>
</span>
Remove flex box. Add side animation. Add dashed line around unload thumbnails.
2012-04-26 03:34:28 +09:00
</div>
</div>
Implement progressive loading of PDFs
2013-02-07 08:19:29 +09:00
<div id="loadingBar">
<div class="progress">
<div class="glimmer">
</div>
</div>
</div>
Simple search results
2011-12-12 10:38:20 +09:00
</div>
</div>
Separate js and css from the test.html file
2011-05-26 23:02:52 +09: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 22:37:03 +09:00
<div id="viewerContainer" tabindex="0">
Move text_layer_builder and pdf_viewer styles out
2014-10-01 00:48:29 +09:00
<div id="viewer" class="pdfViewer"></div>
Unify the multi_page_viewer and the basic viewer
2011-07-29 02:48:05 +09:00
</div>
Remove flex box. Add side animation. Add dashed line around unload thumbnails.
2012-04-26 03:34:28 +09: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 21:32:36 +09: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 22:10:13 +09: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 23:23:17 +09:00
<label for="password" id="passwordText" data-l10n-id="pdfjs-password-label">Enter the password to open this PDF file:</label>
Document properties
2014-01-22 08:07:07 +09: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 22:10:13 +09:00
<div class="row">
<input type="password" id="password" class="toolbarField">
Improved password prompt
2013-09-25 00:46:54 +09: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 22:10:13 +09:00
<div class="buttonRow">
[api-minor] Move to Fluent for the localization (bug 1858715) - For the generic viewer we use @fluent/dom and @fluent/bundle - For the builtin pdf viewer in Firefox, we set a localization url and then we rely on document.l10n which is a DOMLocalization object.
2023-10-13 23:23:17 +09:00
<button id="passwordCancel" class="dialogButton"><span data-l10n-id="pdfjs-password-cancel-button">Cancel</span></button>
<button id="passwordSubmit" class="dialogButton"><span data-l10n-id="pdfjs-password-ok-button">OK</span></button>
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 22:10:13 +09: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 23:23:17 +09: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 22:10:28 +09: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 22:10:13 +09: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 23:23:17 +09: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 22:10:28 +09: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 22:10:13 +09: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 23:23:17 +09: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 22:10:28 +09: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 22:10:13 +09: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 23:23:17 +09: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 22:10:28 +09: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 22:10:13 +09: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 23:23:17 +09: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 22:10:28 +09: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 22:10:13 +09: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 23:23:17 +09: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 22:10:28 +09: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 22:10:13 +09: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 23:23:17 +09: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 22:10:28 +09: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 22:10:13 +09: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 23:23:17 +09: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 22:10:28 +09: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 22:10:13 +09: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 23:23:17 +09: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 22:10:28 +09: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 22:10:13 +09: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 23:23:17 +09: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 22:10:28 +09: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 22:10:13 +09: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 23:23:17 +09: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 22:10:28 +09: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 22:10:13 +09: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 23:23:17 +09: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 22:10:28 +09: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 22:10:13 +09: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 23:23:17 +09: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 22:10:28 +09: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 22:10:13 +09: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 23:23:17 +09: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 22:10:28 +09: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 22:10:13 +09:00
</div>
<div class="buttonRow">
[api-minor] Move to Fluent for the localization (bug 1858715) - For the generic viewer we use @fluent/dom and @fluent/bundle - For the builtin pdf viewer in Firefox, we set a localization url and then we rely on document.l10n which is a DOMLocalization object.
2023-10-13 23:23:17 +09:00
<button id="documentPropertiesClose" class="dialogButton"><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 22:10:13 +09:00
</div>
</dialog>
[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 21:06:50 +09:00
<dialog id="altTextDialog" aria-labelledby="dialogLabel" aria-describedby="dialogDescription">
<div id="altTextContainer">
<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 23:23:17 +09: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 16:27:43 +09: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 21:06:50 +09: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 17:45:26 +09: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 23:23:17 +09: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 21:06:50 +09: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 23:23:17 +09: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 21:06:50 +09: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 23:23:17 +09: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 21:06:50 +09: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 17:45:26 +09: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 23:23:17 +09: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 21:06:50 +09: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 23:23:17 +09: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 18:00:07 +09: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 21:06:50 +09:00
</span>
</div>
</div>
</div>
<div id="buttons">
[api-minor] Move to Fluent for the localization (bug 1858715) - For the generic viewer we use @fluent/dom and @fluent/bundle - For the builtin pdf viewer in Firefox, we set a localization url and then we rely on document.l10n which is a DOMLocalization object.
2023-10-13 23:23:17 +09:00
<button id="altTextCancel" tabindex="0"><span data-l10n-id="pdfjs-editor-alt-text-cancel-button">Cancel</span></button>
<button id="altTextSave" 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 21:06:50 +09:00
</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 21:57:31 +09: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 22:10:28 +09: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 22:10:13 +09: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 23:23:17 +09:00
<span data-l10n-id="pdfjs-print-progress-message">Preparing document for printing…</span>
Removes mozPrintCallback polyfill, converts canvas to PNG.
2016-10-08 21:36:55 +09: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 22:10:13 +09: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 23:23:17 +09: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 22:10:13 +09:00
</div>
<div class="buttonRow">
[api-minor] Move to Fluent for the localization (bug 1858715) - For the generic viewer we use @fluent/dom and @fluent/bundle - For the builtin pdf viewer in Firefox, we set a localization url and then we rely on document.l10n which is a DOMLocalization object.
2023-10-13 23:23:17 +09:00
<button id="printCancel" class="dialogButton"><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 22:10:13 +09:00
</div>
</dialog>
Removes mozPrintCallback polyfill, converts canvas to PNG.
2016-10-08 21:36:55 +09:00
<!--#endif-->
Teach users how to enable access to local files.
2015-07-19 00:11:33 +09: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 22:10:13 +09:00
</div> <!-- dialogContainer -->
Improved password prompt
2013-09-25 00:46:54 +09:00
text selection OK, switch outline OK
2012-04-13 08:29:15 +09:00
</div> <!-- outerContainer -->
Adds support for the new mozPrintCallback api.
2012-06-29 01:50:25 +09:00
<div id="printContainer"></div>
Separate js and css from the test.html file
2011-05-26 23:02:52 +09:00
</body>
Factor out mock tests, add browser test page, initial canvas backend
2011-05-05 09:32:59 +09:00
</html>
Reference in New Issue Copy Permalink