mirrors/pdf.js
1
0
Fork 0
mirror of https://github.com/mozilla/pdf.js.git synced 2025-04-25 01:28:06 +02:00
Code Activity
pdf.js/web/viewer.html

810 lines
51 KiB
HTML
Raw Permalink Normal View History

Add BOM to viewer.
2013-11-22 11:10:43 -08:00
<!DOCTYPE html>
Change to the Apache v2 license.
2012-08-31 15:48:21 -07:00
<!--
Copyright 2012 Mozilla Foundation
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
Add note about adobe license.
2014-03-10 13:03:35 -07:00
Update Adobe CMaps URL and license They are now using Apache 2.0 as well.
2015-06-30 00:33:25 -07:00
Adobe CMap resources are covered by their own copyright but the same license:
Copyright 1990-2015 Adobe Systems Incorporated.
See https://github.com/adobe-type-tools/cmap-resources
Change to the Apache v2 license.
2012-08-31 15:48:21 -07:00
-->
Remove `moznomarginboxes`
2018-01-19 22:05:50 +01:00
<html dir="ltr" mozdisallowselectionprint>
first mockup, loads tracemonkey pages OK
2012-04-11 16:12:51 -07:00
<head>
Embed locale.properties in the viewer.html for extension
2012-04-30 21:55:21 -05:00
<meta charset="utf-8">
Add viewport metatag
2012-05-23 16:50:54 -05:00
<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1">
Disable Google Translate on viewer in Chrome. test/pdfs/yo01.pdf triggered "This page is in Japanese. Would you like to translate it?" info bar in Chrome.
2013-07-16 00:13:05 +02:00
<!--#if GENERIC || CHROME-->
<meta name="google" content="notranslate">
<!--#endif-->
Merge branch 'master' into new-ui Conflicts: web/viewer.html web/viewer.js
2012-04-18 15:02:49 -04:00
<title>PDF.js viewer</title>
Add the new preprocessor.
2012-08-01 11:29:13 -07:00
Remove the `FIREFOX` build flag, since it's completely unused After PR 9566, which removed all of the old Firefox extension code, the `FIREFOX` build flag is no longer used for anything. It thus seems to me that it should be removed, for a couple of reasons: - It's simply dead code now, which only serves to add confusion when looking at the `PDFJSDev` calls. - It used to be that `MOZCENTRAL` and `FIREFOX` was *almost* always used together. However, ever since PR 9566 there's obviously been no effort put into keeping the `FIREFOX` build flags up to date. - In the event that a new, Webextension based, Firefox addon is created in the future you'd still need to audit all `MOZCENTRAL` (and possibly `CHROME`) build flags to see what'd make sense for the addon.
2020-01-08 13:57:31 +01:00
<!--#if MOZCENTRAL-->
Add the new preprocessor.
2012-08-01 11:29:13 -07:00
<!--#include viewer-snippet-firefox-extension.html-->
Clean-up the pre-processor statements in `web/viewer.html` Some of these pre-processor statements are *many* years old, and could thus do with some clean-up. Note that the pre-processor originally didn't support else-if statements, and by using those the code becomes a bit less verbose.
2023-03-18 17:17:46 +01:00
<!--#elif CHROME-->
[CRX] Show nicely formatted URL in omnibox Before commit: chrome-extension://EXTENSIONID/content/web/viewer.html?file=http%3A%2F%2Fexample.com%2Ffile.pdf After commit: chrome-extension://EXTENSIONID/http://example/file.pdf Technical details: - The extension's background page uses the webRequest API to intercept requests for <extension host>/<real path to pdf>, and redirect it to the viewer's URL. - viewer.js uses history.replaceState to rewrite the URL, so that it's easier for users to recognize and copy-paste URLs. - The fake paths /http:, /https:, /file:, etc. have been added to the web_accessible_resources section of the manifest file, in order to avoid seeing chrome-extension://invalid/ instead of the actual URL when using history back/forward to navigate from/to the PDF viewer. - Since the relative path resolving doesn't work because relative URLs are inaccurate, a <base> tag has been added. This method has already been proven to work in the Firefox add-on. Notes: - This commit has been cherry-picked from crx-using-streams-api. - Need to merge https://github.com/mozilla/pdf.js/pull/3582 to deal with a bug in Chrome <=30 - In Chrome, getting the contents of a FTP file is not possible, so there's no support for FTP files, even though the extension router recognizes the ftp: scheme.
2013-08-15 22:47:30 +02:00
<!--#include viewer-snippet-chrome-extension.html-->
Clean-up the pre-processor statements in `web/viewer.html` Some of these pre-processor statements are *many* years old, and could thus do with some clean-up. Note that the pre-processor originally didn't support else-if statements, and by using those the code becomes a bit less verbose.
2023-03-18 17:17:46 +01:00
<!--#else-->
<!--#include viewer-snippet.html-->
Add the new preprocessor.
2012-08-01 11:29:13 -07:00
<!--#endif-->
first mockup, loads tracemonkey pages OK
2012-04-11 16:12:51 -07:00
Remove <base> tag from the Firefox built-in viewer (bug 1821408) The tag <base> is used to resolve relative URIs within the document. Newly added SVG filters use a relative URI which then use the URI in base but this one mismatches with the document URI and consequently filters are not found in the Firefox viewer. So this patch just removes <base> and replace few relative URLs by absolute ones.
2023-03-13 16:56:42 +01:00
<!--#if MOZCENTRAL-->
<!--<link rel="stylesheet" href="resource://pdf.js/web/viewer.css">-->
[api-minor] Move to Fluent for the localization (bug 1858715) - For the generic viewer we use @fluent/dom and @fluent/bundle - For the builtin pdf viewer in Firefox, we set a localization url and then we rely on document.l10n which is a DOMLocalization object.
2023-10-13 16:23:17 +02:00
<!--<link rel="localization" href="toolkit/pdfviewer/viewer.ftl"/>-->
Remove <base> tag from the Firefox built-in viewer (bug 1821408) The tag <base> is used to resolve relative URIs within the document. Newly added SVG filters use a relative URI which then use the URI in base but this one mismatches with the document URI and consequently filters are not found in the Firefox viewer. So this patch just removes <base> and replace few relative URLs by absolute ones.
2023-03-13 16:56:42 +01:00
<!--#else-->
Remove XHTML leftovers from the viewer HTML files
2016-02-14 13:23:34 +01:00
<link rel="stylesheet" href="viewer.css">
Remove <base> tag from the Firefox built-in viewer (bug 1821408) The tag <base> is used to resolve relative URIs within the document. Newly added SVG filters use a relative URI which then use the URI in base but this one mismatches with the document URI and consequently filters are not found in the Firefox viewer. So this patch just removes <base> and replace few relative URLs by absolute ones.
2023-03-13 16:56:42 +01:00
<!--#endif-->
Clean-up the pre-processor statements in `web/viewer.html` Some of these pre-processor statements are *many* years old, and could thus do with some clean-up. Note that the pre-processor originally didn't support else-if statements, and by using those the code becomes a bit less verbose.
2023-03-18 17:17:46 +01:00
<!--#if MOZCENTRAL-->
[api-major] Output JavaScript modules in the builds (issue 10317) At this point in time all browsers, and also Node.js, support standard `import`/`export` statements and we can now finally consider outputting modern JavaScript modules in the builds.[1] In order for this to work we can *only* use proper `import`/`export` statements throughout the main code-base, and (as expected) our Node.js support made this much more complicated since both the official builds and the GitHub Actions-based tests must keep working.[2] One remaining issue is that the `pdf.scripting.js` file cannot be built as a JavaScript module, since doing so breaks PDF scripting. Note that my initial goal was to try and split these changes into a couple of commits, however that unfortunately didn't really work since it turned out to be difficult for smaller patches to work correctly and pass (all) tests that way.[3] This is a classic case of every change requiring a couple of other changes, with each of those changes requiring further changes in turn and the size/scope quickly increasing as a result. One possible "issue" with these changes is that we'll now only output JavaScript modules in the builds, which could perhaps be a problem with older tools. However it unfortunately seems far too complicated/time-consuming for us to attempt to support both the old and modern module formats, hence the alternative would be to do "nothing" here and just keep our "old" builds.[4] --- [1] The final blocker was module support in workers in Firefox, which was implemented in Firefox 114; please see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#browser_compatibility [2] It's probably possible to further improve/simplify especially the Node.js-specific code, but it does appear to work as-is. [3] Having partially "broken" patches, that fail tests, as part of the commit history is *really not* a good idea in general. [4] Outputting JavaScript modules was first requested almost five years ago, see issue 10317, and nowadays there *should* be much better support for JavaScript modules in various tools.
2023-09-28 13:00:10 +02:00
<!--<script src="resource://pdf.js/web/viewer.mjs" type="module"></script>-->
[api-minor] Stop building a minified default viewer The minified default viewer has never been distributed in either official releases or through pdfjs-dist, which means that it's most likely unused, and it's has never been tested nor actively maintained.
2023-09-28 10:07:26 +02:00
<!--#elif !MOZCENTRAL-->
[api-major] Output JavaScript modules in the builds (issue 10317) At this point in time all browsers, and also Node.js, support standard `import`/`export` statements and we can now finally consider outputting modern JavaScript modules in the builds.[1] In order for this to work we can *only* use proper `import`/`export` statements throughout the main code-base, and (as expected) our Node.js support made this much more complicated since both the official builds and the GitHub Actions-based tests must keep working.[2] One remaining issue is that the `pdf.scripting.js` file cannot be built as a JavaScript module, since doing so breaks PDF scripting. Note that my initial goal was to try and split these changes into a couple of commits, however that unfortunately didn't really work since it turned out to be difficult for smaller patches to work correctly and pass (all) tests that way.[3] This is a classic case of every change requiring a couple of other changes, with each of those changes requiring further changes in turn and the size/scope quickly increasing as a result. One possible "issue" with these changes is that we'll now only output JavaScript modules in the builds, which could perhaps be a problem with older tools. However it unfortunately seems far too complicated/time-consuming for us to attempt to support both the old and modern module formats, hence the alternative would be to do "nothing" here and just keep our "old" builds.[4] --- [1] The final blocker was module support in workers in Firefox, which was implemented in Firefox 114; please see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#browser_compatibility [2] It's probably possible to further improve/simplify especially the Node.js-specific code, but it does appear to work as-is. [3] Having partially "broken" patches, that fail tests, as part of the commit history is *really not* a good idea in general. [4] Outputting JavaScript modules was first requested almost five years ago, see issue 10317, and nowadays there *should* be much better support for JavaScript modules in various tools.
2023-09-28 13:00:10 +02:00
<!--<script src="viewer.mjs" type="module"></script>-->
Remove the remaining `PRODUCTION` build-target usage After the previous patch we now have only *a single* `PRODUCTION` occurrence in the entire code-base, more specifically in the `web/viewer.html` file. This special build-target can be replaced with any condition that always evaluate to `false`, such as e.g. a comment. *Please note:* This patch might be considered too hacky, hence I completely understand if it's rejected.
2023-03-19 12:42:22 +01:00
<!--#elif /* Development mode. */-->
[api-minor] Move to Fluent for the localization (bug 1858715) - For the generic viewer we use @fluent/dom and @fluent/bundle - For the builtin pdf viewer in Firefox, we set a localization url and then we rely on document.l10n which is a DOMLocalization object.
2023-10-13 16:23:17 +02:00
<link rel="resource" type="application/l10n" href="locale/locale.json">
Add the new preprocessor.
2012-08-01 11:29:13 -07:00
Use native `import maps` in development mode This patch seem to work fine locally now, and `mozregression` points to it being fixed in bug https://bugzilla.mozilla.org/show_bug.cgi?id=1803984 which landed in Firefox 116. By using the native `import maps` functionality, we can remove a development dependency. Please find the specification at https://wicg.github.io/import-maps/
2022-04-02 13:00:25 +02:00
<script type="importmap">
Reduce usage of SystemJS, in the development viewer, even further With these changes SystemJS is now only used, during development, on the worker-thread and in the unit/font-tests, since Firefox is currently missing support for worker modules; please see https://bugzilla.mozilla.org/show_bug.cgi?id=1247687 Hence all the JavaScript files in the `web/` and `src/display/` folders are now loaded *natively* by the browser (during development) using standard `import` statements/calls, thanks to a nice `import-maps` polyfill. *Please note:* As soon as https://bugzilla.mozilla.org/show_bug.cgi?id=1247687 is fixed in Firefox, we should be able to remove all traces of SystemJS and thus finally be able to use every possible modern JavaScript feature.
2020-05-19 18:00:23 +02:00
{
"imports": {
"pdfjs/": "../src/",
"pdfjs-lib": "../src/pdf.js",
[editor] Use the `fit-curve` package (issue 15004) Rather than including all of this external code in the PDF.js repository, we should be using the npm package instead. Unfortunately this is slightly more complicated than you'd hope, since the `fit-curve` package (which is older) isn't directly compatible with modern JavaScript modules. In particular, the following cases needed to be considered: - For the development viewer (i.e. `gulp server`) and the unit-tests, we thus need to build a fitCurve-bundle that can be directly `import`ed. - For the actual PDF.js build-targets, we can slightly reduce the sizes by depending on the "raw" `fit-curve` source-code. - For the Node.js unit-tests, the `fit-curve` package can be used as-is.
2022-07-06 23:02:53 +02:00
"pdfjs-web/": "./",
[GeckoView] Reduce the size of the *built* viewer Given that the GV-viewer isn't using most of the UI-related components of the default-viewer, we can avoid including them in the *built* viewer to save space.[1] The least "invasive" way of implementing this, at least that I could come up with, is to leverage import maps with suitable stubs for the GV-viewer. The one slightly annoying thing is that we now have larger import maps across multiple html-files, and you'll need to remember to update all of them when making future changes. --- [1] With this patch, the built `viewer.js` size is 391 kB and `viewer-geckoview.js` is 285 kB.
2023-02-04 13:55:12 +01:00
[api-minor] Move to Fluent for the localization (bug 1858715) - For the generic viewer we use @fluent/dom and @fluent/bundle - For the builtin pdf viewer in Firefox, we set a localization url and then we rely on document.l10n which is a DOMLocalization object.
2023-10-13 16:23:17 +02:00
"fluent-bundle": "../node_modules/@fluent/bundle/esm/index.js",
"fluent-dom": "../node_modules/@fluent/dom/esm/index.js",
"cached-iterable": "../node_modules/cached-iterable/src/index.mjs",
Move the various DOM-factories into their own files - Over time the number and size of these factories have increased, especially the `DOMFilterFactory` class, and this split should thus aid readability/maintainability of the code. - By introducing a couple of new import maps we can avoid bundling the `DOMCMapReaderFactory`/`DOMStandardFontDataFactory` classes in the Firefox PDF Viewer, since they are dead code there given that worker-thread fetching is always being used. - This patch has been successfully tested, by running `$ ./mach test toolkit/components/pdfjs/`, in a local Firefox artifact-build. *Note:* This patch reduces the size of the `gulp mozcentral` output by `1.3` kilo-bytes, which isn't a lot but still cannot hurt.
2024-11-01 12:34:39 +01:00
"display-cmap_reader_factory": "../src/display/cmap_reader_factory.js",
"display-standard_fontdata_factory": "../src/display/standard_fontdata_factory.js",
[api-major] Add openjpeg.wasm to pdf.js (bug 1935076) In order to fix bug 1935076, we'll have to add a pure js fallback in case wasm is disabled or simd isn't supported. Unfortunately, this fallback will take some space. So, the main goal of this patch is to reduce the overall size (by ~93k). As a side effect, it should make easier to use an other wasm file (which must export _jp2_decode, _malloc and _free).
2025-01-15 20:20:11 +01:00
"display-wasm_factory": "../src/display/wasm_factory.js",
Remove most build-time `require`-calls from the `src/display/`-folder By leveraging import maps we can get rid of *most* of the remaining `require`-calls in the `src/display/`-folder, since we should strive to use modern `import`-statements wherever possible. The only remaining cases are Node.js-specific dependencies, since those seem very difficult to convert unless we start producing a bundle *specifically* for Node.js environments.
2023-07-13 11:58:16 +02:00
"display-fetch_stream": "../src/display/fetch_stream.js",
"display-network": "../src/display/network.js",
"display-node_stream": "../src/display/stubs.js",
"display-node_utils": "../src/display/stubs.js",
[GeckoView] Avoid bundling the `AltTextManager` class, since it's unused
2023-09-21 12:51:34 +02:00
"web-alt_text_manager": "./alt_text_manager.js",
[GeckoView] Reduce the size of the *built* viewer Given that the GV-viewer isn't using most of the UI-related components of the default-viewer, we can avoid including them in the *built* viewer to save space.[1] The least "invasive" way of implementing this, at least that I could come up with, is to leverage import maps with suitable stubs for the GV-viewer. The one slightly annoying thing is that we now have larger import maps across multiple html-files, and you'll need to remember to update all of them when making future changes. --- [1] With this patch, the built `viewer.js` size is 391 kB and `viewer-geckoview.js` is 285 kB.
2023-02-04 13:55:12 +01:00
"web-annotation_editor_params": "./annotation_editor_params.js",
Remove the `createDownloadManager` method from `DefaultExternalServices` Given the simplicity of the `createDownloadManager` method, we can leverage import maps to directly initialize the correct `DownloadManager`-instance depending on the build.
2024-01-26 11:50:25 +01:00
"web-download_manager": "./download_manager.js",
Re-factor `DefaultExternalServices` into a regular class, without static methods The `DefaultExternalServices` code, which is used to provide build-specific functionality, is very old. This results in a pattern where we first initialize `PDFViewerApplication.externalServices` and then *override* it for the different builds. By converting `DefaultExternalServices` into a "regular" class, and leveraging import maps, we can directly initialize the correct instance depending on the build.
2024-01-26 14:31:42 +01:00
"web-external_services": "./genericcom.js",
Implement the new alt text flow (bug 1909604) For the Firefox pdf viewer, we want to use AI to guess an alt-text when adding an image to a pdf. For now the telemtry stuff is not implemented and will come soon. In order to test it locally: - set enableAltText, enableFakeMLManager and enableUpdatedAddImage to true. or in Firefox: - set browser.ml.enable, pdfjs.enableAltText and pdfjs.enableUpdatedAddImage to true.
2024-07-24 09:34:32 +02:00
"web-new_alt_text_manager": "./new_alt_text_manager.js",
Ensure that `GenericL10n` works if the locale files cannot be loaded - Ensure that localization works in the GENERIC viewer, even if the necessary locale files cannot be loaded. This was the behaviour prior to the introduction of Fluent, and it seems worthwhile to keep that (especially since we already bundle the en-US strings anyway). - Let the `GenericL10n`-implementation use the *bundled* en-US strings directly when no language is provided. - Remove the `NullL10n`-implementation, and simply fallback to `GenericL10n`, to reduce the maintenance burden of viewer-components localization. - Indirectly, given the previous point, stop exporting `NullL10n` in the viewer-components since it's now removed. Note that it was never really intended to be used directly and only existed as a fallback. *Please note:* This doesn't affect the Firefox PDF Viewer, thanks to the use of import maps.
2024-01-30 18:32:35 +01:00
"web-null_l10n": "./genericl10n.js",
[GeckoView] Reduce the size of the *built* viewer Given that the GV-viewer isn't using most of the UI-related components of the default-viewer, we can avoid including them in the *built* viewer to save space.[1] The least "invasive" way of implementing this, at least that I could come up with, is to leverage import maps with suitable stubs for the GV-viewer. The one slightly annoying thing is that we now have larger import maps across multiple html-files, and you'll need to remember to update all of them when making future changes. --- [1] With this patch, the built `viewer.js` size is 391 kB and `viewer-geckoview.js` is 285 kB.
2023-02-04 13:55:12 +01:00
"web-pdf_attachment_viewer": "./pdf_attachment_viewer.js",
"web-pdf_cursor_tools": "./pdf_cursor_tools.js",
"web-pdf_document_properties": "./pdf_document_properties.js",
"web-pdf_find_bar": "./pdf_find_bar.js",
"web-pdf_layer_viewer": "./pdf_layer_viewer.js",
"web-pdf_outline_viewer": "./pdf_outline_viewer.js",
"web-pdf_presentation_mode": "./pdf_presentation_mode.js",
"web-pdf_sidebar": "./pdf_sidebar.js",
"web-pdf_thumbnail_viewer": "./pdf_thumbnail_viewer.js",
Remove the `createPreferences` method from `DefaultExternalServices` Given the simplicity of the `createPreferences` method, we can leverage import maps to directly initialize the correct `Preferences`-instance depending on the build.
2024-01-26 12:04:54 +01:00
"web-preferences": "./genericcom.js",
Remove most build-time `require` statements from the viewer (PR 16009 follow-up) This further extends the web-specific import maps introduced in PR 16009, to allow removing *most* of the build-time `require` statements from the viewer. The few remaining ones are fallbacks used for the COMPONENTS respectively the `legacy` GENERIC builds.
2023-02-05 16:13:18 +01:00
"web-print_service": "./pdf_print_service.js",
[GeckoView] Reduce the size of the *built* viewer Given that the GV-viewer isn't using most of the UI-related components of the default-viewer, we can avoid including them in the *built* viewer to save space.[1] The least "invasive" way of implementing this, at least that I could come up with, is to leverage import maps with suitable stubs for the GV-viewer. The one slightly annoying thing is that we now have larger import maps across multiple html-files, and you'll need to remember to update all of them when making future changes. --- [1] With this patch, the built `viewer.js` size is 391 kB and `viewer-geckoview.js` is 285 kB.
2023-02-04 13:55:12 +01:00
"web-secondary_toolbar": "./secondary_toolbar.js",
[Editor] Add a new dialog for the signature editor (bug 1945574)
2025-02-03 18:30:42 +01:00
"web-signature_manager": "./signature_manager.js",
[GeckoView] Reduce the size of the *built* viewer Given that the GV-viewer isn't using most of the UI-related components of the default-viewer, we can avoid including them in the *built* viewer to save space.[1] The least "invasive" way of implementing this, at least that I could come up with, is to leverage import maps with suitable stubs for the GV-viewer. The one slightly annoying thing is that we now have larger import maps across multiple html-files, and you'll need to remember to update all of them when making future changes. --- [1] With this patch, the built `viewer.js` size is 391 kB and `viewer-geckoview.js` is 285 kB.
2023-02-04 13:55:12 +01:00
"web-toolbar": "./toolbar.js"
Reduce usage of SystemJS, in the development viewer, even further With these changes SystemJS is now only used, during development, on the worker-thread and in the unit/font-tests, since Firefox is currently missing support for worker modules; please see https://bugzilla.mozilla.org/show_bug.cgi?id=1247687 Hence all the JavaScript files in the `web/` and `src/display/` folders are now loaded *natively* by the browser (during development) using standard `import` statements/calls, thanks to a nice `import-maps` polyfill. *Please note:* As soon as https://bugzilla.mozilla.org/show_bug.cgi?id=1247687 is fixed in Firefox, we should be able to remove all traces of SystemJS and thus finally be able to use every possible modern JavaScript feature.
2020-05-19 18:00:23 +02:00
}
}
</script>
Use native `import maps` in development mode This patch seem to work fine locally now, and `mozregression` points to it being fixed in bug https://bugzilla.mozilla.org/show_bug.cgi?id=1803984 which landed in Firefox 116. By using the native `import maps` functionality, we can remove a development dependency. Please find the specification at https://wicg.github.io/import-maps/
2022-04-02 13:00:25 +02:00
<script src="viewer.js" type="module"></script>
Add the new preprocessor.
2012-08-01 11:29:13 -07:00
<!--#endif-->
first mockup, loads tracemonkey pages OK
2012-04-11 16:12:51 -07:00
</head>
Separate js and css from the test.html file
2011-05-26 16:02:52 +02:00
Refactor the toolbar html & css to improve its overall accessibility (bug 1171799, bug 1855695) The first goal of this patch was to remove the tabindex because it helps to improve overall a11y. That led to move some html elements associated with the buttons which helped to position these elements relatively to their buttons. Consequently it was easy to change the toolbar height (configurable in Firefox with the pref browser.uidensity): it's the second goal of this patch. For a11y reasons we want to be able to change the height of the toolbar to make the buttons larger.
2024-07-01 22:37:48 +02:00
<body tabindex="0">
Small refactoring of the loadingBar hiding code
2014-08-17 00:22:05 +02:00
<div id="outerContainer">
Unify the multi_page_viewer and the basic viewer
2011-07-28 19:48:05 +02:00
Move sidebar open class.
2012-04-25 13:46:17 -07:00
<div id="sidebarContainer">
Refactor the toolbar html & css to improve its overall accessibility (bug 1171799, bug 1855695) The first goal of this patch was to remove the tabindex because it helps to improve overall a11y. That led to move some html elements associated with the buttons which helped to position these elements relatively to their buttons. Consequently it was easy to change the toolbar height (configurable in Firefox with the pref browser.uidensity): it's the second goal of this patch. For a11y reasons we want to be able to change the height of the toolbar to make the buttons larger.
2024-07-01 22:37:48 +02:00
<div id="toolbarSidebar" class="toolbarHorizontalGroup">
Add support for finding/highlighting the outlineItem, corresponding to the currently visible page, in the sidebar (issue 7557, bug 1253820, bug 1499050) This implementation is inspired by the behaviour in (recent versions of) Adobe Reader, since it leads to reasonably simple and straightforward code as far as I'm concerned. *Specifically:* We'll only consider *one* destination per page when finding/highlighting the current outline item, which is similar to e.g. Adobe Reader, and we choose the *first* outline item at the *lowest* level of the outline tree. Given that this functionality requires not only parsing of the `outline`, but looking up *all* of the destinations in the document, this feature can when initialized have a non-trivial performance overhead for larger PDF documents. In an attempt to reduce the performance impact, the following steps are taken here: - The "find current outline item"-functionality will only be enabled once *one* page has rendered and *all* the pages have been loaded[1], to prevent it interfering with data regular fetching/parsing early on during document loading and viewer initialization. - With the exception of a couple of small and simple `eventBus`-listeners, in `PDFOutlineViewer`, this new functionality is initialized *lazily* the first time that the user clicks on the `currentOutlineItem`-button. - The entire "find current outline item"-functionality is disabled when `disableAutoFetch = true` is set, since it can easily lead to the setting becoming essentially pointless[2] by triggering *a lot* of data fetching from a relatively minor viewer-feature. - Fetch the destinations *individually*, since that's generally more efficient than using `PDFDocumentProxy.getDestinations` to fetch them all at once. Despite making the overall parsing code *more* asynchronous, and leading to a lot more main/worker-thread message passing, in practice this seems faster for larger documents. Finally, we'll now always highlight an outline item that the user manually clicked on, since only highlighting when the new "find current outline item"-functionality is used seemed inconsistent. --- [1] Keep in mind that the `outline` itself already isn't fetched/parsed until at least *one* page has been rendered in the viewer. [2] And also quite slow, since it can take a fair amount of time to fetch all of the necessary `destinations` data when `disableAutoFetch = true` is set.
2020-12-25 12:57:43 +01:00
<div id="toolbarSidebarLeft">
Refactor the toolbar html & css to improve its overall accessibility (bug 1171799, bug 1855695) The first goal of this patch was to remove the tabindex because it helps to improve overall a11y. That led to move some html elements associated with the buttons which helped to position these elements relatively to their buttons. Consequently it was easy to change the toolbar height (configurable in Firefox with the pref browser.uidensity): it's the second goal of this patch. For a11y reasons we want to be able to change the height of the toolbar to make the buttons larger.
2024-07-01 22:37:48 +02:00
<div id="sidebarViewButtons" class="toolbarHorizontalGroup toggled" role="radiogroup">
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<button id="viewThumbnail" class="toolbarButton toggled" type="button" tabindex="0" data-l10n-id="pdfjs-thumbs-button" role="radio" aria-checked="true" aria-controls="thumbnailView">
<span data-l10n-id="pdfjs-thumbs-button-label"></span>
Add support for finding/highlighting the outlineItem, corresponding to the currently visible page, in the sidebar (issue 7557, bug 1253820, bug 1499050) This implementation is inspired by the behaviour in (recent versions of) Adobe Reader, since it leads to reasonably simple and straightforward code as far as I'm concerned. *Specifically:* We'll only consider *one* destination per page when finding/highlighting the current outline item, which is similar to e.g. Adobe Reader, and we choose the *first* outline item at the *lowest* level of the outline tree. Given that this functionality requires not only parsing of the `outline`, but looking up *all* of the destinations in the document, this feature can when initialized have a non-trivial performance overhead for larger PDF documents. In an attempt to reduce the performance impact, the following steps are taken here: - The "find current outline item"-functionality will only be enabled once *one* page has rendered and *all* the pages have been loaded[1], to prevent it interfering with data regular fetching/parsing early on during document loading and viewer initialization. - With the exception of a couple of small and simple `eventBus`-listeners, in `PDFOutlineViewer`, this new functionality is initialized *lazily* the first time that the user clicks on the `currentOutlineItem`-button. - The entire "find current outline item"-functionality is disabled when `disableAutoFetch = true` is set, since it can easily lead to the setting becoming essentially pointless[2] by triggering *a lot* of data fetching from a relatively minor viewer-feature. - Fetch the destinations *individually*, since that's generally more efficient than using `PDFDocumentProxy.getDestinations` to fetch them all at once. Despite making the overall parsing code *more* asynchronous, and leading to a lot more main/worker-thread message passing, in practice this seems faster for larger documents. Finally, we'll now always highlight an outline item that the user manually clicked on, since only highlighting when the new "find current outline item"-functionality is used seemed inconsistent. --- [1] Keep in mind that the `outline` itself already isn't fetched/parsed until at least *one* page has been rendered in the viewer. [2] And also quite slow, since it can take a fair amount of time to fetch all of the necessary `destinations` data when `disableAutoFetch = true` is set.
2020-12-25 12:57:43 +01:00
</button>
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<button id="viewOutline" class="toolbarButton" type="button" tabindex="0" data-l10n-id="pdfjs-document-outline-button" role="radio" aria-checked="false" aria-controls="outlineView">
<span data-l10n-id="pdfjs-document-outline-button-label"></span>
Add support for finding/highlighting the outlineItem, corresponding to the currently visible page, in the sidebar (issue 7557, bug 1253820, bug 1499050) This implementation is inspired by the behaviour in (recent versions of) Adobe Reader, since it leads to reasonably simple and straightforward code as far as I'm concerned. *Specifically:* We'll only consider *one* destination per page when finding/highlighting the current outline item, which is similar to e.g. Adobe Reader, and we choose the *first* outline item at the *lowest* level of the outline tree. Given that this functionality requires not only parsing of the `outline`, but looking up *all* of the destinations in the document, this feature can when initialized have a non-trivial performance overhead for larger PDF documents. In an attempt to reduce the performance impact, the following steps are taken here: - The "find current outline item"-functionality will only be enabled once *one* page has rendered and *all* the pages have been loaded[1], to prevent it interfering with data regular fetching/parsing early on during document loading and viewer initialization. - With the exception of a couple of small and simple `eventBus`-listeners, in `PDFOutlineViewer`, this new functionality is initialized *lazily* the first time that the user clicks on the `currentOutlineItem`-button. - The entire "find current outline item"-functionality is disabled when `disableAutoFetch = true` is set, since it can easily lead to the setting becoming essentially pointless[2] by triggering *a lot* of data fetching from a relatively minor viewer-feature. - Fetch the destinations *individually*, since that's generally more efficient than using `PDFDocumentProxy.getDestinations` to fetch them all at once. Despite making the overall parsing code *more* asynchronous, and leading to a lot more main/worker-thread message passing, in practice this seems faster for larger documents. Finally, we'll now always highlight an outline item that the user manually clicked on, since only highlighting when the new "find current outline item"-functionality is used seemed inconsistent. --- [1] Keep in mind that the `outline` itself already isn't fetched/parsed until at least *one* page has been rendered in the viewer. [2] And also quite slow, since it can take a fair amount of time to fetch all of the necessary `destinations` data when `disableAutoFetch = true` is set.
2020-12-25 12:57:43 +01:00
</button>
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<button id="viewAttachments" class="toolbarButton" type="button" tabindex="0" data-l10n-id="pdfjs-attachments-button" role="radio" aria-checked="false" aria-controls="attachmentsView">
<span data-l10n-id="pdfjs-attachments-button-label"></span>
Add support for finding/highlighting the outlineItem, corresponding to the currently visible page, in the sidebar (issue 7557, bug 1253820, bug 1499050) This implementation is inspired by the behaviour in (recent versions of) Adobe Reader, since it leads to reasonably simple and straightforward code as far as I'm concerned. *Specifically:* We'll only consider *one* destination per page when finding/highlighting the current outline item, which is similar to e.g. Adobe Reader, and we choose the *first* outline item at the *lowest* level of the outline tree. Given that this functionality requires not only parsing of the `outline`, but looking up *all* of the destinations in the document, this feature can when initialized have a non-trivial performance overhead for larger PDF documents. In an attempt to reduce the performance impact, the following steps are taken here: - The "find current outline item"-functionality will only be enabled once *one* page has rendered and *all* the pages have been loaded[1], to prevent it interfering with data regular fetching/parsing early on during document loading and viewer initialization. - With the exception of a couple of small and simple `eventBus`-listeners, in `PDFOutlineViewer`, this new functionality is initialized *lazily* the first time that the user clicks on the `currentOutlineItem`-button. - The entire "find current outline item"-functionality is disabled when `disableAutoFetch = true` is set, since it can easily lead to the setting becoming essentially pointless[2] by triggering *a lot* of data fetching from a relatively minor viewer-feature. - Fetch the destinations *individually*, since that's generally more efficient than using `PDFDocumentProxy.getDestinations` to fetch them all at once. Despite making the overall parsing code *more* asynchronous, and leading to a lot more main/worker-thread message passing, in practice this seems faster for larger documents. Finally, we'll now always highlight an outline item that the user manually clicked on, since only highlighting when the new "find current outline item"-functionality is used seemed inconsistent. --- [1] Keep in mind that the `outline` itself already isn't fetched/parsed until at least *one* page has been rendered in the viewer. [2] And also quite slow, since it can take a fair amount of time to fetch all of the necessary `destinations` data when `disableAutoFetch = true` is set.
2020-12-25 12:57:43 +01:00
</button>
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<button id="viewLayers" class="toolbarButton" type="button" tabindex="0" data-l10n-id="pdfjs-layers-button" role="radio" aria-checked="false" aria-controls="layersView">
<span data-l10n-id="pdfjs-layers-button-label"></span>
Add support for finding/highlighting the outlineItem, corresponding to the currently visible page, in the sidebar (issue 7557, bug 1253820, bug 1499050) This implementation is inspired by the behaviour in (recent versions of) Adobe Reader, since it leads to reasonably simple and straightforward code as far as I'm concerned. *Specifically:* We'll only consider *one* destination per page when finding/highlighting the current outline item, which is similar to e.g. Adobe Reader, and we choose the *first* outline item at the *lowest* level of the outline tree. Given that this functionality requires not only parsing of the `outline`, but looking up *all* of the destinations in the document, this feature can when initialized have a non-trivial performance overhead for larger PDF documents. In an attempt to reduce the performance impact, the following steps are taken here: - The "find current outline item"-functionality will only be enabled once *one* page has rendered and *all* the pages have been loaded[1], to prevent it interfering with data regular fetching/parsing early on during document loading and viewer initialization. - With the exception of a couple of small and simple `eventBus`-listeners, in `PDFOutlineViewer`, this new functionality is initialized *lazily* the first time that the user clicks on the `currentOutlineItem`-button. - The entire "find current outline item"-functionality is disabled when `disableAutoFetch = true` is set, since it can easily lead to the setting becoming essentially pointless[2] by triggering *a lot* of data fetching from a relatively minor viewer-feature. - Fetch the destinations *individually*, since that's generally more efficient than using `PDFDocumentProxy.getDestinations` to fetch them all at once. Despite making the overall parsing code *more* asynchronous, and leading to a lot more main/worker-thread message passing, in practice this seems faster for larger documents. Finally, we'll now always highlight an outline item that the user manually clicked on, since only highlighting when the new "find current outline item"-functionality is used seemed inconsistent. --- [1] Keep in mind that the `outline` itself already isn't fetched/parsed until at least *one* page has been rendered in the viewer. [2] And also quite slow, since it can take a fair amount of time to fetch all of the necessary `destinations` data when `disableAutoFetch = true` is set.
2020-12-25 12:57:43 +01:00
</button>
</div>
</div>
<div id="toolbarSidebarRight">
Refactor the toolbar html & css to improve its overall accessibility (bug 1171799, bug 1855695) The first goal of this patch was to remove the tabindex because it helps to improve overall a11y. That led to move some html elements associated with the buttons which helped to position these elements relatively to their buttons. Consequently it was easy to change the toolbar height (configurable in Firefox with the pref browser.uidensity): it's the second goal of this patch. For a11y reasons we want to be able to change the height of the toolbar to make the buttons larger.
2024-07-01 22:37:48 +02:00
<div id="outlineOptionsContainer" class="toolbarHorizontalGroup">
Add support for finding/highlighting the outlineItem, corresponding to the currently visible page, in the sidebar (issue 7557, bug 1253820, bug 1499050) This implementation is inspired by the behaviour in (recent versions of) Adobe Reader, since it leads to reasonably simple and straightforward code as far as I'm concerned. *Specifically:* We'll only consider *one* destination per page when finding/highlighting the current outline item, which is similar to e.g. Adobe Reader, and we choose the *first* outline item at the *lowest* level of the outline tree. Given that this functionality requires not only parsing of the `outline`, but looking up *all* of the destinations in the document, this feature can when initialized have a non-trivial performance overhead for larger PDF documents. In an attempt to reduce the performance impact, the following steps are taken here: - The "find current outline item"-functionality will only be enabled once *one* page has rendered and *all* the pages have been loaded[1], to prevent it interfering with data regular fetching/parsing early on during document loading and viewer initialization. - With the exception of a couple of small and simple `eventBus`-listeners, in `PDFOutlineViewer`, this new functionality is initialized *lazily* the first time that the user clicks on the `currentOutlineItem`-button. - The entire "find current outline item"-functionality is disabled when `disableAutoFetch = true` is set, since it can easily lead to the setting becoming essentially pointless[2] by triggering *a lot* of data fetching from a relatively minor viewer-feature. - Fetch the destinations *individually*, since that's generally more efficient than using `PDFDocumentProxy.getDestinations` to fetch them all at once. Despite making the overall parsing code *more* asynchronous, and leading to a lot more main/worker-thread message passing, in practice this seems faster for larger documents. Finally, we'll now always highlight an outline item that the user manually clicked on, since only highlighting when the new "find current outline item"-functionality is used seemed inconsistent. --- [1] Keep in mind that the `outline` itself already isn't fetched/parsed until at least *one* page has been rendered in the viewer. [2] And also quite slow, since it can take a fair amount of time to fetch all of the necessary `destinations` data when `disableAutoFetch = true` is set.
2020-12-25 12:57:43 +01:00
<div class="verticalToolbarSeparator"></div>
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<button id="currentOutlineItem" class="toolbarButton" type="button" disabled="disabled" tabindex="0" data-l10n-id="pdfjs-current-outline-item-button">
<span data-l10n-id="pdfjs-current-outline-item-button-label"></span>
Add support for finding/highlighting the outlineItem, corresponding to the currently visible page, in the sidebar (issue 7557, bug 1253820, bug 1499050) This implementation is inspired by the behaviour in (recent versions of) Adobe Reader, since it leads to reasonably simple and straightforward code as far as I'm concerned. *Specifically:* We'll only consider *one* destination per page when finding/highlighting the current outline item, which is similar to e.g. Adobe Reader, and we choose the *first* outline item at the *lowest* level of the outline tree. Given that this functionality requires not only parsing of the `outline`, but looking up *all* of the destinations in the document, this feature can when initialized have a non-trivial performance overhead for larger PDF documents. In an attempt to reduce the performance impact, the following steps are taken here: - The "find current outline item"-functionality will only be enabled once *one* page has rendered and *all* the pages have been loaded[1], to prevent it interfering with data regular fetching/parsing early on during document loading and viewer initialization. - With the exception of a couple of small and simple `eventBus`-listeners, in `PDFOutlineViewer`, this new functionality is initialized *lazily* the first time that the user clicks on the `currentOutlineItem`-button. - The entire "find current outline item"-functionality is disabled when `disableAutoFetch = true` is set, since it can easily lead to the setting becoming essentially pointless[2] by triggering *a lot* of data fetching from a relatively minor viewer-feature. - Fetch the destinations *individually*, since that's generally more efficient than using `PDFDocumentProxy.getDestinations` to fetch them all at once. Despite making the overall parsing code *more* asynchronous, and leading to a lot more main/worker-thread message passing, in practice this seems faster for larger documents. Finally, we'll now always highlight an outline item that the user manually clicked on, since only highlighting when the new "find current outline item"-functionality is used seemed inconsistent. --- [1] Keep in mind that the `outline` itself already isn't fetched/parsed until at least *one* page has been rendered in the viewer. [2] And also quite slow, since it can take a fair amount of time to fetch all of the necessary `destinations` data when `disableAutoFetch = true` is set.
2020-12-25 12:57:43 +01:00
</button>
</div>
Minor css tweaks for small viewer and aligning borders.
2012-10-29 14:35:07 -07:00
</div>
Unify the multi_page_viewer and the basic viewer
2011-07-28 19:48:05 +02:00
</div>
Remove flex box. Add side animation. Add dashed line around unload thumbnails.
2012-04-25 11:34:28 -07:00
<div id="sidebarContent">
<div id="thumbnailView">
first mockup, loads tracemonkey pages OK
2012-04-11 16:12:51 -07:00
</div>
Remove flex box. Add side animation. Add dashed line around unload thumbnails.
2012-04-25 11:34:28 -07:00
<div id="outlineView" class="hidden">
first mockup, loads tracemonkey pages OK
2012-04-11 16:12:51 -07:00
</div>
Preliminary attachments support Added a partial Filespec support Added getAttachments in API Added a new attachments view in UI (with a new icon by @shorlander)
2014-03-18 16:32:47 -04:00
<div id="attachmentsView" class="hidden">
</div>
[api-minor] Add support for toggling of Optional Content in the viewer (issue 12096) *Besides, obviously, adding viewer support:* This patch attempts to improve the general API for Optional Content Groups slightly, by adding a couple of new methods for interacting with the (more complex) data structures of `OptionalContentConfig`-instances. (Thus allowing us to mark some of the data as "private", given that it probably shouldn't be manipulated directly.) By utilizing not just the "raw" Optional Content Groups, but the data from the `/Order` array when available, we can thus display the Layers in a proper tree-structure with collapsible headings for PDF documents that utilizes that feature. Note that it's possible to reset all Optional Content Groups to their default visibility state, simply by double-clicking on the Layers-button in the sidebar. (Currently that's indicated in the Layers-button tooltip, which is obviously easy to overlook, however it's probably the best we can do for now without adding more buttons, or even a dropdown-toolbar, to the sidebar.) Also, the current Layers-button icons are a little rough around the edges, quite literally, but given that the viewer will soon have its UI modernized anyway they hopefully suffice in the meantime. To give users *full* control of the visibility of the various Optional Content Groups, even those which according to the `/Order` array should not (by default) be toggleable in the UI, this patch will place those under a *custom* heading which: - Is collapsed by default, and placed at the bottom of the Layers-tree, to be a bit less obtrusive. - Uses a slightly different formatting, compared to the "regular" headings. - Is localizable. Finally, note that the thumbnails are *purposely* always rendered with all Optional Content Groups at their default visibility state, since that seems the most useful and it's also consistent with other viewers. To ensure that this works as intended, we'll thus disable the `PDFThumbnailView.setImage` functionality when the Optional Content Groups have been changed in the viewer. (This obviously means that we'll re-render thumbnails instead of using the rendered pages. However, this situation ought to be rare enough for this to not really be a problem.)
2020-08-06 21:01:03 +02:00
<div id="layersView" class="hidden">
</div>
Switching to the document outline view if the document structure is present
2011-08-21 21:05:10 -05:00
</div>
Remove CSS variables feature-testing from `PDFSidebarResizer` CSS variables are now supported in all reasonably modern browsers, according to: - https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_custom_properties#Browser_compatibility - https://caniuse.com/css-variables
2020-09-09 13:29:44 +02:00
<div id="sidebarResizer"></div>
Remove flex box. Add side animation. Add dashed line around unload thumbnails.
2012-04-25 11:34:28 -07:00
</div> <!-- sidebarContainer -->
<div id="mainContainer">
<div class="toolbar">
<div id="toolbarContainer">
Refactor the toolbar html & css to improve its overall accessibility (bug 1171799, bug 1855695) The first goal of this patch was to remove the tabindex because it helps to improve overall a11y. That led to move some html elements associated with the buttons which helped to position these elements relatively to their buttons. Consequently it was easy to change the toolbar height (configurable in Firefox with the pref browser.uidensity): it's the second goal of this patch. For a11y reasons we want to be able to change the height of the toolbar to make the buttons larger.
2024-07-01 22:37:48 +02:00
<div id="toolbarViewer" class="toolbarHorizontalGroup">
<div id="toolbarViewerLeft" class="toolbarHorizontalGroup">
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<button id="sidebarToggleButton" class="toolbarButton" type="button" tabindex="0" data-l10n-id="pdfjs-toggle-sidebar-button" aria-expanded="false" aria-haspopup="true" aria-controls="sidebarContainer">
<span data-l10n-id="pdfjs-toggle-sidebar-button-label"></span>
Addressing accessebility aspects
2012-05-04 09:51:21 -05:00
</button>
Remove flex box. Add side animation. Add dashed line around unload thumbnails.
2012-04-25 11:34:28 -07:00
<div class="toolbarButtonSpacer"></div>
Refactor the toolbar html & css to improve its overall accessibility (bug 1171799, bug 1855695) The first goal of this patch was to remove the tabindex because it helps to improve overall a11y. That led to move some html elements associated with the buttons which helped to position these elements relatively to their buttons. Consequently it was easy to change the toolbar height (configurable in Firefox with the pref browser.uidensity): it's the second goal of this patch. For a11y reasons we want to be able to change the height of the toolbar to make the buttons larger.
2024-07-01 22:37:48 +02:00
<div class="toolbarButtonWithContainer">
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<button id="viewFindButton" class="toolbarButton" type="button" tabindex="0" data-l10n-id="pdfjs-findbar-button" aria-expanded="false" aria-controls="findbar">
<span data-l10n-id="pdfjs-findbar-button-label"></span>
Refactor the toolbar html & css to improve its overall accessibility (bug 1171799, bug 1855695) The first goal of this patch was to remove the tabindex because it helps to improve overall a11y. That led to move some html elements associated with the buttons which helped to position these elements relatively to their buttons. Consequently it was easy to change the toolbar height (configurable in Firefox with the pref browser.uidensity): it's the second goal of this patch. For a11y reasons we want to be able to change the height of the toolbar to make the buttons larger.
2024-07-01 22:37:48 +02:00
</button>
<div class="hidden doorHanger toolbarHorizontalGroup" id="findbar">
<div id="findInputContainer" class="toolbarHorizontalGroup">
<span class="loadingInput end toolbarHorizontalGroup">
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<input id="findInput" class="toolbarField" tabindex="0" data-l10n-id="pdfjs-find-input" aria-invalid="false">
Refactor the toolbar html & css to improve its overall accessibility (bug 1171799, bug 1855695) The first goal of this patch was to remove the tabindex because it helps to improve overall a11y. That led to move some html elements associated with the buttons which helped to position these elements relatively to their buttons. Consequently it was easy to change the toolbar height (configurable in Firefox with the pref browser.uidensity): it's the second goal of this patch. For a11y reasons we want to be able to change the height of the toolbar to make the buttons larger.
2024-07-01 22:37:48 +02:00
</span>
<div class="toolbarHorizontalGroup">
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<button id="findPreviousButton" class="toolbarButton" type="button" tabindex="0" data-l10n-id="pdfjs-find-previous-button">
<span data-l10n-id="pdfjs-find-previous-button-label"></span>
Refactor the toolbar html & css to improve its overall accessibility (bug 1171799, bug 1855695) The first goal of this patch was to remove the tabindex because it helps to improve overall a11y. That led to move some html elements associated with the buttons which helped to position these elements relatively to their buttons. Consequently it was easy to change the toolbar height (configurable in Firefox with the pref browser.uidensity): it's the second goal of this patch. For a11y reasons we want to be able to change the height of the toolbar to make the buttons larger.
2024-07-01 22:37:48 +02:00
</button>
<div class="splitToolbarButtonSeparator"></div>
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<button id="findNextButton" class="toolbarButton" type="button" tabindex="0" data-l10n-id="pdfjs-find-next-button">
<span data-l10n-id="pdfjs-find-next-button-label"></span>
Refactor the toolbar html & css to improve its overall accessibility (bug 1171799, bug 1855695) The first goal of this patch was to remove the tabindex because it helps to improve overall a11y. That led to move some html elements associated with the buttons which helped to position these elements relatively to their buttons. Consequently it was easy to change the toolbar height (configurable in Firefox with the pref browser.uidensity): it's the second goal of this patch. For a11y reasons we want to be able to change the height of the toolbar to make the buttons larger.
2024-07-01 22:37:48 +02:00
</button>
</div>
</div>
<div id="findbarOptionsOneContainer" class="toolbarHorizontalGroup">
<div class="toggleButton toolbarLabel">
<input type="checkbox" id="findHighlightAll" tabindex="0" />
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<label for="findHighlightAll" data-l10n-id="pdfjs-find-highlight-checkbox"></label>
Refactor the toolbar html & css to improve its overall accessibility (bug 1171799, bug 1855695) The first goal of this patch was to remove the tabindex because it helps to improve overall a11y. That led to move some html elements associated with the buttons which helped to position these elements relatively to their buttons. Consequently it was easy to change the toolbar height (configurable in Firefox with the pref browser.uidensity): it's the second goal of this patch. For a11y reasons we want to be able to change the height of the toolbar to make the buttons larger.
2024-07-01 22:37:48 +02:00
</div>
<div class="toggleButton toolbarLabel">
<input type="checkbox" id="findMatchCase" tabindex="0" />
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<label for="findMatchCase" data-l10n-id="pdfjs-find-match-case-checkbox-label"></label>
Refactor the toolbar html & css to improve its overall accessibility (bug 1171799, bug 1855695) The first goal of this patch was to remove the tabindex because it helps to improve overall a11y. That led to move some html elements associated with the buttons which helped to position these elements relatively to their buttons. Consequently it was easy to change the toolbar height (configurable in Firefox with the pref browser.uidensity): it's the second goal of this patch. For a11y reasons we want to be able to change the height of the toolbar to make the buttons larger.
2024-07-01 22:37:48 +02:00
</div>
</div>
<div id="findbarOptionsTwoContainer" class="toolbarHorizontalGroup">
<div class="toggleButton toolbarLabel">
<input type="checkbox" id="findMatchDiacritics" tabindex="0" />
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<label for="findMatchDiacritics" data-l10n-id="pdfjs-find-match-diacritics-checkbox-label"></label>
Refactor the toolbar html & css to improve its overall accessibility (bug 1171799, bug 1855695) The first goal of this patch was to remove the tabindex because it helps to improve overall a11y. That led to move some html elements associated with the buttons which helped to position these elements relatively to their buttons. Consequently it was easy to change the toolbar height (configurable in Firefox with the pref browser.uidensity): it's the second goal of this patch. For a11y reasons we want to be able to change the height of the toolbar to make the buttons larger.
2024-07-01 22:37:48 +02:00
</div>
<div class="toggleButton toolbarLabel">
<input type="checkbox" id="findEntireWord" tabindex="0" />
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<label for="findEntireWord" data-l10n-id="pdfjs-find-entire-word-checkbox-label"></label>
Refactor the toolbar html & css to improve its overall accessibility (bug 1171799, bug 1855695) The first goal of this patch was to remove the tabindex because it helps to improve overall a11y. That led to move some html elements associated with the buttons which helped to position these elements relatively to their buttons. Consequently it was easy to change the toolbar height (configurable in Firefox with the pref browser.uidensity): it's the second goal of this patch. For a11y reasons we want to be able to change the height of the toolbar to make the buttons larger.
2024-07-01 22:37:48 +02:00
</div>
</div>
<div id="findbarMessageContainer" class="toolbarHorizontalGroup" aria-live="polite">
<span id="findResultsCount" class="toolbarLabel"></span>
<span id="findMsg" class="toolbarLabel"></span>
</div>
</div> <!-- findbar -->
</div>
<div class="toolbarHorizontalGroup hiddenSmallView">
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<button class="toolbarButton" type="button" id="previous" tabindex="0" data-l10n-id="pdfjs-previous-button">
<span data-l10n-id="pdfjs-previous-button-label"></span>
Addressing accessebility aspects
2012-05-04 09:51:21 -05:00
</button>
Remove flex box. Add side animation. Add dashed line around unload thumbnails.
2012-04-25 11:34:28 -07:00
<div class="splitToolbarButtonSeparator"></div>
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<button class="toolbarButton" type="button" id="next" tabindex="0" data-l10n-id="pdfjs-next-button">
<span data-l10n-id="pdfjs-next-button-label"></span>
Addressing accessebility aspects
2012-05-04 09:51:21 -05:00
</button>
Remove flex box. Add side animation. Add dashed line around unload thumbnails.
2012-04-25 11:34:28 -07:00
</div>
Refactor the toolbar html & css to improve its overall accessibility (bug 1171799, bug 1855695) The first goal of this patch was to remove the tabindex because it helps to improve overall a11y. That led to move some html elements associated with the buttons which helped to position these elements relatively to their buttons. Consequently it was easy to change the toolbar height (configurable in Firefox with the pref browser.uidensity): it's the second goal of this patch. For a11y reasons we want to be able to change the height of the toolbar to make the buttons larger.
2024-07-01 22:37:48 +02:00
<div class="toolbarHorizontalGroup">
<span class="loadingInput start toolbarHorizontalGroup">
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<input type="number" id="pageNumber" class="toolbarField" value="1" min="1" tabindex="0" data-l10n-id="pdfjs-page-input" autocomplete="off">
Refactor the toolbar html & css to improve its overall accessibility (bug 1171799, bug 1855695) The first goal of this patch was to remove the tabindex because it helps to improve overall a11y. That led to move some html elements associated with the buttons which helped to position these elements relatively to their buttons. Consequently it was easy to change the toolbar height (configurable in Firefox with the pref browser.uidensity): it's the second goal of this patch. For a11y reasons we want to be able to change the height of the toolbar to make the buttons larger.
2024-07-01 22:37:48 +02:00
</span>
<span id="numPages" class="toolbarLabel"></span>
[editor] Support disabling of editing when `pdfjs.enablePermissions` is set (issue 15049) For encrypted PDF documents without the required permissions set, this patch adds support for disabling of Annotation-editing. However, please note that it also requires that the `pdfjs.enablePermissions` preference is set to `true` (since PDF document permissions could be seen as user hostile).[1] As I started looking at the issue, it soon became clear that *only* trying to fix the issue without slightly re-factor the surrounding code would be somewhat difficult. The following is an overview of the changes in this patch; sorry about the size/scope of this! - Use a new `AnnotationEditorUIManager`-instance *for each* PDF document opened in the GENERIC viewer, to prevent user-added Annotations from "leaking" from one document into the next. - Re-factor the `BaseViewer.#initializePermissions`-method, to simplify handling of temporarily disabled modes (e.g. for both Annotation-rendering and Annotation-editing). - When editing is enabled, let the Editor-buttons be `disabled` until the document has loaded. This way we avoid the buttons becoming clickable temporarily, for PDF documents that use permissions. - Slightly re-factor how the Editor-buttons are shown/hidden in the viewer, and reset the toolbar-state when a new PDF document is opened. - Flip the order of the Editor-buttons and the pre-exising toolbarButtons in the "toolbarViewerRight"-div. (To help reduce the size, a little bit, for the PR that adds new Editor-toolbars.) - Enable editing by default in the development viewer, i.e. `gulp server`, since having to (repeatedly) do that manually becomes annoying after a while. - Finally, support disabling of editing when `pdfjs.enablePermissions` is set; fixes issue 15049. --- [1] Either manually with `about:config`, or using e.g. a [Group Policy](https://github.com/mozilla/policy-templates).
2022-06-20 18:08:41 +02:00
</div>
Remove flex box. Add side animation. Add dashed line around unload thumbnails.
2012-04-25 11:34:28 -07:00
</div>
Refactor the toolbar html & css to improve its overall accessibility (bug 1171799, bug 1855695) The first goal of this patch was to remove the tabindex because it helps to improve overall a11y. That led to move some html elements associated with the buttons which helped to position these elements relatively to their buttons. Consequently it was easy to change the toolbar height (configurable in Firefox with the pref browser.uidensity): it's the second goal of this patch. For a11y reasons we want to be able to change the height of the toolbar to make the buttons larger.
2024-07-01 22:37:48 +02:00
<div id="toolbarViewerMiddle" class="toolbarHorizontalGroup">
<div class="toolbarHorizontalGroup">
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<button id="zoomOutButton" class="toolbarButton" type="button" tabindex="0" data-l10n-id="pdfjs-zoom-out-button">
<span data-l10n-id="pdfjs-zoom-out-button-label"></span>
Viewer: improve responsiveness and clean up CSS This patch resolves the responsiveness issues for the toolbar in the viewer. Depending on the language (for example the Dutch language), elements could overlap when the viewport size is reduced. The main issue here is that the CSS rules are unnecessarily complex and handle lots of different cases (LTR/RTL, displacements for specific viewport widths, et cetera). By removing this complexity and letting the browser handle the responsiveness, we not only get simpler CSS rules and HTML mark-up, but the responsiveness issues are mostly fixed at the same time. We no longer have to position the elements manually (by setting their `left` attribute value) anymore.
2016-11-03 16:56:57 +01:00
</button>
<div class="splitToolbarButtonSeparator"></div>
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<button id="zoomInButton" class="toolbarButton" type="button" tabindex="0" data-l10n-id="pdfjs-zoom-in-button">
<span data-l10n-id="pdfjs-zoom-in-button-label"></span>
Refactor the toolbar html & css to improve its overall accessibility (bug 1171799, bug 1855695) The first goal of this patch was to remove the tabindex because it helps to improve overall a11y. That led to move some html elements associated with the buttons which helped to position these elements relatively to their buttons. Consequently it was easy to change the toolbar height (configurable in Firefox with the pref browser.uidensity): it's the second goal of this patch. For a11y reasons we want to be able to change the height of the toolbar to make the buttons larger.
2024-07-01 22:37:48 +02:00
</button>
Remove flex box. Add side animation. Add dashed line around unload thumbnails.
2012-04-25 11:34:28 -07:00
</div>
Viewer: improve responsiveness and clean up CSS This patch resolves the responsiveness issues for the toolbar in the viewer. Depending on the language (for example the Dutch language), elements could overlap when the viewport size is reduced. The main issue here is that the CSS rules are unnecessarily complex and handle lots of different cases (LTR/RTL, displacements for specific viewport widths, et cetera). By removing this complexity and letting the browser handle the responsiveness, we not only get simpler CSS rules and HTML mark-up, but the responsiveness issues are mostly fixed at the same time. We no longer have to position the elements manually (by setting their `left` attribute value) anymore.
2016-11-03 16:56:57 +01:00
<span id="scaleSelectContainer" class="dropdownToolbarButton">
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<select id="scaleSelect" tabindex="0" data-l10n-id="pdfjs-zoom-select">
<option id="pageAutoOption" value="auto" selected="selected" data-l10n-id="pdfjs-page-scale-auto"></option>
<option id="pageActualOption" value="page-actual" data-l10n-id="pdfjs-page-scale-actual"></option>
<option id="pageFitOption" value="page-fit" data-l10n-id="pdfjs-page-scale-fit"></option>
<option id="pageWidthOption" value="page-width" data-l10n-id="pdfjs-page-scale-width"></option>
<option id="customScaleOption" value="custom" disabled="disabled" hidden="true" data-l10n-id="pdfjs-page-scale-percent" data-l10n-args='{ "scale": 0 }'></option>
<option value="0.5" data-l10n-id="pdfjs-page-scale-percent" data-l10n-args='{ "scale": 50 }'></option>
<option value="0.75" data-l10n-id="pdfjs-page-scale-percent" data-l10n-args='{ "scale": 75 }'></option>
<option value="1" data-l10n-id="pdfjs-page-scale-percent" data-l10n-args='{ "scale": 100 }'></option>
<option value="1.25" data-l10n-id="pdfjs-page-scale-percent" data-l10n-args='{ "scale": 125 }'></option>
<option value="1.5" data-l10n-id="pdfjs-page-scale-percent" data-l10n-args='{ "scale": 150 }'></option>
<option value="2" data-l10n-id="pdfjs-page-scale-percent" data-l10n-args='{ "scale": 200 }'></option>
<option value="3" data-l10n-id="pdfjs-page-scale-percent" data-l10n-args='{ "scale": 300 }'></option>
<option value="4" data-l10n-id="pdfjs-page-scale-percent" data-l10n-args='{ "scale": 400 }'></option>
Viewer: improve responsiveness and clean up CSS This patch resolves the responsiveness issues for the toolbar in the viewer. Depending on the language (for example the Dutch language), elements could overlap when the viewport size is reduced. The main issue here is that the CSS rules are unnecessarily complex and handle lots of different cases (LTR/RTL, displacements for specific viewport widths, et cetera). By removing this complexity and letting the browser handle the responsiveness, we not only get simpler CSS rules and HTML mark-up, but the responsiveness issues are mostly fixed at the same time. We no longer have to position the elements manually (by setting their `left` attribute value) anymore.
2016-11-03 16:56:57 +01:00
</select>
</span>
Remove flex box. Add side animation. Add dashed line around unload thumbnails.
2012-04-25 11:34:28 -07:00
</div>
Refactor the toolbar html & css to improve its overall accessibility (bug 1171799, bug 1855695) The first goal of this patch was to remove the tabindex because it helps to improve overall a11y. That led to move some html elements associated with the buttons which helped to position these elements relatively to their buttons. Consequently it was easy to change the toolbar height (configurable in Firefox with the pref browser.uidensity): it's the second goal of this patch. For a11y reasons we want to be able to change the height of the toolbar to make the buttons larger.
2024-07-01 22:37:48 +02:00
<div id="toolbarViewerRight" class="toolbarHorizontalGroup">
<div id="editorModeButtons" class="toolbarHorizontalGroup" role="radiogroup">
[Editor] Add an icon for the signature tool and move it before the highlight one
2025-02-06 20:58:59 +01:00
<div id="editorSignature" class="toolbarButtonWithContainer" hidden="true">
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<button id="editorSignatureButton" class="toolbarButton" type="button" tabindex="0" disabled="disabled" role="radio" aria-expanded="false" aria-haspopup="true" aria-controls="editorSignatureParamsToolbar" data-l10n-id="pdfjs-editor-signature-button">
<span data-l10n-id="pdfjs-editor-signature-button-label"></span>
[Editor] Add an icon for the signature tool and move it before the highlight one
2025-02-06 20:58:59 +01:00
</button>
<div class="editorParamsToolbar hidden doorHangerRight menu" id="editorSignatureParamsToolbar">
[Editor] Fix the title of saved signature button (bug 1953298)
2025-03-13 10:01:31 +01:00
<div id="addSignatureDoorHanger" class="menuContainer" role="region" data-l10n-id="pdfjs-editor-add-signature-container">
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<button id="editorSignatureAddSignature" class="toolbarButton labeled" type="button" tabindex="0" data-l10n-id="pdfjs-editor-signature-add-signature-button">
<span data-l10n-id="pdfjs-editor-signature-add-signature-button-label" class="editorParamsLabel"></span>
[Editor] Add an icon for the signature tool and move it before the highlight one
2025-02-06 20:58:59 +01:00
</button>
</div>
</div>
</div>
Refactor the toolbar html & css to improve its overall accessibility (bug 1171799, bug 1855695) The first goal of this patch was to remove the tabindex because it helps to improve overall a11y. That led to move some html elements associated with the buttons which helped to position these elements relatively to their buttons. Consequently it was easy to change the toolbar height (configurable in Firefox with the pref browser.uidensity): it's the second goal of this patch. For a11y reasons we want to be able to change the height of the toolbar to make the buttons larger.
2024-07-01 22:37:48 +02:00
<div id="editorHighlight" class="toolbarButtonWithContainer">
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<button id="editorHighlightButton" class="toolbarButton" type="button" disabled="disabled" role="radio" aria-expanded="false" aria-haspopup="true" aria-controls="editorHighlightParamsToolbar" tabindex="0" data-l10n-id="pdfjs-editor-highlight-button">
<span data-l10n-id="pdfjs-editor-highlight-button-label"></span>
Refactor the toolbar html & css to improve its overall accessibility (bug 1171799, bug 1855695) The first goal of this patch was to remove the tabindex because it helps to improve overall a11y. That led to move some html elements associated with the buttons which helped to position these elements relatively to their buttons. Consequently it was easy to change the toolbar height (configurable in Firefox with the pref browser.uidensity): it's the second goal of this patch. For a11y reasons we want to be able to change the height of the toolbar to make the buttons larger.
2024-07-01 22:37:48 +02:00
</button>
<div class="editorParamsToolbar hidden doorHangerRight" id="editorHighlightParamsToolbar">
<div id="highlightParamsToolbarContainer" class="editorParamsToolbarContainer">
<div id="editorHighlightColorPicker" class="colorPicker">
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<span id="highlightColorPickerLabel" class="editorParamsLabel" data-l10n-id="pdfjs-editor-highlight-colorpicker-label"></span>
Refactor the toolbar html & css to improve its overall accessibility (bug 1171799, bug 1855695) The first goal of this patch was to remove the tabindex because it helps to improve overall a11y. That led to move some html elements associated with the buttons which helped to position these elements relatively to their buttons. Consequently it was easy to change the toolbar height (configurable in Firefox with the pref browser.uidensity): it's the second goal of this patch. For a11y reasons we want to be able to change the height of the toolbar to make the buttons larger.
2024-07-01 22:37:48 +02:00
</div>
<div id="editorHighlightThickness">
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<label for="editorFreeHighlightThickness" class="editorParamsLabel" data-l10n-id="pdfjs-editor-free-highlight-thickness-input"></label>
Refactor the toolbar html & css to improve its overall accessibility (bug 1171799, bug 1855695) The first goal of this patch was to remove the tabindex because it helps to improve overall a11y. That led to move some html elements associated with the buttons which helped to position these elements relatively to their buttons. Consequently it was easy to change the toolbar height (configurable in Firefox with the pref browser.uidensity): it's the second goal of this patch. For a11y reasons we want to be able to change the height of the toolbar to make the buttons larger.
2024-07-01 22:37:48 +02:00
<div class="thicknessPicker">
<input type="range" id="editorFreeHighlightThickness" class="editorParamsSlider" data-l10n-id="pdfjs-editor-free-highlight-thickness-title" value="12" min="8" max="24" step="1" tabindex="0">
</div>
</div>
<div id="editorHighlightVisibility">
<div class="divider"></div>
<div class="toggler">
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<label for="editorHighlightShowAll" class="editorParamsLabel" data-l10n-id="pdfjs-editor-highlight-show-all-button-label"></label>
Refactor the toolbar html & css to improve its overall accessibility (bug 1171799, bug 1855695) The first goal of this patch was to remove the tabindex because it helps to improve overall a11y. That led to move some html elements associated with the buttons which helped to position these elements relatively to their buttons. Consequently it was easy to change the toolbar height (configurable in Firefox with the pref browser.uidensity): it's the second goal of this patch. For a11y reasons we want to be able to change the height of the toolbar to make the buttons larger.
2024-07-01 22:37:48 +02:00
<button id="editorHighlightShowAll" class="toggle-button" type="button" data-l10n-id="pdfjs-editor-highlight-show-all-button" aria-pressed="true" tabindex="0"></button>
</div>
</div>
</div>
</div>
</div>
<div id="editorFreeText" class="toolbarButtonWithContainer">
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<button id="editorFreeTextButton" class="toolbarButton" type="button" disabled="disabled" role="radio" aria-expanded="false" aria-haspopup="true" aria-controls="editorFreeTextParamsToolbar" tabindex="0" data-l10n-id="pdfjs-editor-free-text-button">
<span data-l10n-id="pdfjs-editor-free-text-button-label"></span>
Refactor the toolbar html & css to improve its overall accessibility (bug 1171799, bug 1855695) The first goal of this patch was to remove the tabindex because it helps to improve overall a11y. That led to move some html elements associated with the buttons which helped to position these elements relatively to their buttons. Consequently it was easy to change the toolbar height (configurable in Firefox with the pref browser.uidensity): it's the second goal of this patch. For a11y reasons we want to be able to change the height of the toolbar to make the buttons larger.
2024-07-01 22:37:48 +02:00
</button>
<div class="editorParamsToolbar hidden doorHangerRight" id="editorFreeTextParamsToolbar">
<div class="editorParamsToolbarContainer">
<div class="editorParamsSetter">
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<label for="editorFreeTextColor" class="editorParamsLabel" data-l10n-id="pdfjs-editor-free-text-color-input"></label>
Refactor the toolbar html & css to improve its overall accessibility (bug 1171799, bug 1855695) The first goal of this patch was to remove the tabindex because it helps to improve overall a11y. That led to move some html elements associated with the buttons which helped to position these elements relatively to their buttons. Consequently it was easy to change the toolbar height (configurable in Firefox with the pref browser.uidensity): it's the second goal of this patch. For a11y reasons we want to be able to change the height of the toolbar to make the buttons larger.
2024-07-01 22:37:48 +02:00
<input type="color" id="editorFreeTextColor" class="editorParamsColor" tabindex="0">
</div>
<div class="editorParamsSetter">
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<label for="editorFreeTextFontSize" class="editorParamsLabel" data-l10n-id="pdfjs-editor-free-text-size-input"></label>
Refactor the toolbar html & css to improve its overall accessibility (bug 1171799, bug 1855695) The first goal of this patch was to remove the tabindex because it helps to improve overall a11y. That led to move some html elements associated with the buttons which helped to position these elements relatively to their buttons. Consequently it was easy to change the toolbar height (configurable in Firefox with the pref browser.uidensity): it's the second goal of this patch. For a11y reasons we want to be able to change the height of the toolbar to make the buttons larger.
2024-07-01 22:37:48 +02:00
<input type="range" id="editorFreeTextFontSize" class="editorParamsSlider" value="10" min="5" max="100" step="1" tabindex="0">
</div>
</div>
</div>
</div>
<div id="editorInk" class="toolbarButtonWithContainer">
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<button id="editorInkButton" class="toolbarButton" type="button" disabled="disabled" role="radio" aria-expanded="false" aria-haspopup="true" aria-controls="editorInkParamsToolbar" tabindex="0" data-l10n-id="pdfjs-editor-ink-button">
<span data-l10n-id="pdfjs-editor-ink-button-label"></span>
Refactor the toolbar html & css to improve its overall accessibility (bug 1171799, bug 1855695) The first goal of this patch was to remove the tabindex because it helps to improve overall a11y. That led to move some html elements associated with the buttons which helped to position these elements relatively to their buttons. Consequently it was easy to change the toolbar height (configurable in Firefox with the pref browser.uidensity): it's the second goal of this patch. For a11y reasons we want to be able to change the height of the toolbar to make the buttons larger.
2024-07-01 22:37:48 +02:00
</button>
<div class="editorParamsToolbar hidden doorHangerRight" id="editorInkParamsToolbar">
<div class="editorParamsToolbarContainer">
<div class="editorParamsSetter">
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<label for="editorInkColor" class="editorParamsLabel" data-l10n-id="pdfjs-editor-ink-color-input"></label>
Refactor the toolbar html & css to improve its overall accessibility (bug 1171799, bug 1855695) The first goal of this patch was to remove the tabindex because it helps to improve overall a11y. That led to move some html elements associated with the buttons which helped to position these elements relatively to their buttons. Consequently it was easy to change the toolbar height (configurable in Firefox with the pref browser.uidensity): it's the second goal of this patch. For a11y reasons we want to be able to change the height of the toolbar to make the buttons larger.
2024-07-01 22:37:48 +02:00
<input type="color" id="editorInkColor" class="editorParamsColor" tabindex="0">
</div>
<div class="editorParamsSetter">
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<label for="editorInkThickness" class="editorParamsLabel" data-l10n-id="pdfjs-editor-ink-thickness-input"></label>
Refactor the toolbar html & css to improve its overall accessibility (bug 1171799, bug 1855695) The first goal of this patch was to remove the tabindex because it helps to improve overall a11y. That led to move some html elements associated with the buttons which helped to position these elements relatively to their buttons. Consequently it was easy to change the toolbar height (configurable in Firefox with the pref browser.uidensity): it's the second goal of this patch. For a11y reasons we want to be able to change the height of the toolbar to make the buttons larger.
2024-07-01 22:37:48 +02:00
<input type="range" id="editorInkThickness" class="editorParamsSlider" value="1" min="1" max="20" step="1" tabindex="0">
</div>
<div class="editorParamsSetter">
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<label for="editorInkOpacity" class="editorParamsLabel" data-l10n-id="pdfjs-editor-ink-opacity-input"></label>
[Editor] Add a new base class to allow to add a drawing in the SVG layer. This patch makes a clear separation between the way to draw and the editing stuff. It adds a class DrawEditor which should be extended in order to create new drawing tools. As an example, the ink tool has been rewritten in order to use it.
2024-11-20 22:26:38 +01:00
<input type="range" id="editorInkOpacity" class="editorParamsSlider" value="1" min="0.05" max="1" step="0.05" tabindex="0">
Refactor the toolbar html & css to improve its overall accessibility (bug 1171799, bug 1855695) The first goal of this patch was to remove the tabindex because it helps to improve overall a11y. That led to move some html elements associated with the buttons which helped to position these elements relatively to their buttons. Consequently it was easy to change the toolbar height (configurable in Firefox with the pref browser.uidensity): it's the second goal of this patch. For a11y reasons we want to be able to change the height of the toolbar to make the buttons larger.
2024-07-01 22:37:48 +02:00
</div>
</div>
</div>
</div>
<div id="editorStamp" class="toolbarButtonWithContainer">
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<button id="editorStampButton" class="toolbarButton" type="button" disabled="disabled" role="radio" aria-expanded="false" aria-haspopup="true" aria-controls="editorStampParamsToolbar" tabindex="0" data-l10n-id="pdfjs-editor-stamp-button">
<span data-l10n-id="pdfjs-editor-stamp-button-label"></span>
Refactor the toolbar html & css to improve its overall accessibility (bug 1171799, bug 1855695) The first goal of this patch was to remove the tabindex because it helps to improve overall a11y. That led to move some html elements associated with the buttons which helped to position these elements relatively to their buttons. Consequently it was easy to change the toolbar height (configurable in Firefox with the pref browser.uidensity): it's the second goal of this patch. For a11y reasons we want to be able to change the height of the toolbar to make the buttons larger.
2024-07-01 22:37:48 +02:00
</button>
Increase the size of the toolbar depending on the uidensity (bug 1171799)
2024-09-24 15:37:42 +02:00
<div class="editorParamsToolbar hidden doorHangerRight menu" id="editorStampParamsToolbar">
Refactor the toolbar html & css to improve its overall accessibility (bug 1171799, bug 1855695) The first goal of this patch was to remove the tabindex because it helps to improve overall a11y. That led to move some html elements associated with the buttons which helped to position these elements relatively to their buttons. Consequently it was easy to change the toolbar height (configurable in Firefox with the pref browser.uidensity): it's the second goal of this patch. For a11y reasons we want to be able to change the height of the toolbar to make the buttons larger.
2024-07-01 22:37:48 +02:00
<div class="menuContainer">
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<button id="editorStampAddImage" class="toolbarButton labeled" type="button" tabindex="0" data-l10n-id="pdfjs-editor-stamp-add-image-button">
<span class="editorParamsLabel" data-l10n-id="pdfjs-editor-stamp-add-image-button-label"></span>
Refactor the toolbar html & css to improve its overall accessibility (bug 1171799, bug 1855695) The first goal of this patch was to remove the tabindex because it helps to improve overall a11y. That led to move some html elements associated with the buttons which helped to position these elements relatively to their buttons. Consequently it was easy to change the toolbar height (configurable in Firefox with the pref browser.uidensity): it's the second goal of this patch. For a11y reasons we want to be able to change the height of the toolbar to make the buttons larger.
2024-07-01 22:37:48 +02:00
</button>
[Editor] (WIP) Add a new tool in order to add an handwritten signature to a pdf (bug 1942343) This patch is adding some code in order to extract a drawing as curves from an image. The algorithm is basically the following: - reduce the dimensions - make it gray - apply a bilateral filter in order to add some blurryness while keeping the edges - compute the histogram - guess what's the background color which should contain a large majority of the pixels - make a binary image - extract the contours in using the Suzuki algorithm - apply the Douglas-Peucker algorithm in order to reduce the number of points The algorithm is improvable but it should work pretty well if there's a clear difference between the background and the drawing. In a v2 we could use a ML model in order to improve the extraction. There's few changes related to the UI in order to make the tool usable, but they're very basic for the moment.
2025-01-17 18:04:34 +01:00
</div>
</div>
</div>
Refactor the toolbar html & css to improve its overall accessibility (bug 1171799, bug 1855695) The first goal of this patch was to remove the tabindex because it helps to improve overall a11y. That led to move some html elements associated with the buttons which helped to position these elements relatively to their buttons. Consequently it was easy to change the toolbar height (configurable in Firefox with the pref browser.uidensity): it's the second goal of this patch. For a11y reasons we want to be able to change the height of the toolbar to make the buttons larger.
2024-07-01 22:37:48 +02:00
</div>
<div id="editorModeSeparator" class="verticalToolbarSeparator"></div>
<div class="toolbarHorizontalGroup hiddenMediumView">
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<button id="printButton" class="toolbarButton" type="button" tabindex="0" data-l10n-id="pdfjs-print-button">
<span data-l10n-id="pdfjs-print-button-label"></span>
Refactor the toolbar html & css to improve its overall accessibility (bug 1171799, bug 1855695) The first goal of this patch was to remove the tabindex because it helps to improve overall a11y. That led to move some html elements associated with the buttons which helped to position these elements relatively to their buttons. Consequently it was easy to change the toolbar height (configurable in Firefox with the pref browser.uidensity): it's the second goal of this patch. For a11y reasons we want to be able to change the height of the toolbar to make the buttons larger.
2024-07-01 22:37:48 +02:00
</button>
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<button id="downloadButton" class="toolbarButton" type="button" tabindex="0" data-l10n-id="pdfjs-save-button">
<span data-l10n-id="pdfjs-save-button-label"></span>
Refactor the toolbar html & css to improve its overall accessibility (bug 1171799, bug 1855695) The first goal of this patch was to remove the tabindex because it helps to improve overall a11y. That led to move some html elements associated with the buttons which helped to position these elements relatively to their buttons. Consequently it was easy to change the toolbar height (configurable in Firefox with the pref browser.uidensity): it's the second goal of this patch. For a11y reasons we want to be able to change the height of the toolbar to make the buttons larger.
2024-07-01 22:37:48 +02:00
</button>
</div>
<div class="verticalToolbarSeparator hiddenMediumView"></div>
<div id="secondaryToolbarToggle" class="toolbarButtonWithContainer">
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<button id="secondaryToolbarToggleButton" class="toolbarButton" type="button" tabindex="0" data-l10n-id="pdfjs-tools-button" aria-expanded="false" aria-haspopup="true" aria-controls="secondaryToolbar">
<span data-l10n-id="pdfjs-tools-button-label"></span>
Refactor the toolbar html & css to improve its overall accessibility (bug 1171799, bug 1855695) The first goal of this patch was to remove the tabindex because it helps to improve overall a11y. That led to move some html elements associated with the buttons which helped to position these elements relatively to their buttons. Consequently it was easy to change the toolbar height (configurable in Firefox with the pref browser.uidensity): it's the second goal of this patch. For a11y reasons we want to be able to change the height of the toolbar to make the buttons larger.
2024-07-01 22:37:48 +02:00
</button>
Increase the size of the toolbar depending on the uidensity (bug 1171799)
2024-09-24 15:37:42 +02:00
<div id="secondaryToolbar" class="hidden doorHangerRight menu">
Refactor the toolbar html & css to improve its overall accessibility (bug 1171799, bug 1855695) The first goal of this patch was to remove the tabindex because it helps to improve overall a11y. That led to move some html elements associated with the buttons which helped to position these elements relatively to their buttons. Consequently it was easy to change the toolbar height (configurable in Firefox with the pref browser.uidensity): it's the second goal of this patch. For a11y reasons we want to be able to change the height of the toolbar to make the buttons larger.
2024-07-01 22:37:48 +02:00
<div id="secondaryToolbarButtonContainer" class="menuContainer">
<!--#if GENERIC-->
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<button id="secondaryOpenFile" class="toolbarButton labeled" type="button" tabindex="0" data-l10n-id="pdfjs-open-file-button">
<span data-l10n-id="pdfjs-open-file-button-label"></span>
Refactor the toolbar html & css to improve its overall accessibility (bug 1171799, bug 1855695) The first goal of this patch was to remove the tabindex because it helps to improve overall a11y. That led to move some html elements associated with the buttons which helped to position these elements relatively to their buttons. Consequently it was easy to change the toolbar height (configurable in Firefox with the pref browser.uidensity): it's the second goal of this patch. For a11y reasons we want to be able to change the height of the toolbar to make the buttons larger.
2024-07-01 22:37:48 +02:00
</button>
<!--#endif-->
<div class="visibleMediumView">
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<button id="secondaryPrint" class="toolbarButton labeled" type="button" tabindex="0" data-l10n-id="pdfjs-print-button">
<span data-l10n-id="pdfjs-print-button-label"></span>
Refactor the toolbar html & css to improve its overall accessibility (bug 1171799, bug 1855695) The first goal of this patch was to remove the tabindex because it helps to improve overall a11y. That led to move some html elements associated with the buttons which helped to position these elements relatively to their buttons. Consequently it was easy to change the toolbar height (configurable in Firefox with the pref browser.uidensity): it's the second goal of this patch. For a11y reasons we want to be able to change the height of the toolbar to make the buttons larger.
2024-07-01 22:37:48 +02:00
</button>
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<button id="secondaryDownload" class="toolbarButton labeled" type="button" tabindex="0" data-l10n-id="pdfjs-save-button">
<span data-l10n-id="pdfjs-save-button-label"></span>
Refactor the toolbar html & css to improve its overall accessibility (bug 1171799, bug 1855695) The first goal of this patch was to remove the tabindex because it helps to improve overall a11y. That led to move some html elements associated with the buttons which helped to position these elements relatively to their buttons. Consequently it was easy to change the toolbar height (configurable in Firefox with the pref browser.uidensity): it's the second goal of this patch. For a11y reasons we want to be able to change the height of the toolbar to make the buttons larger.
2024-07-01 22:37:48 +02:00
</button>
<!--#if !GENERIC-->
<!-- <div class="horizontalToolbarSeparator"></div>-->
<!--#endif-->
</div>
<!--#if GENERIC-->
<div class="horizontalToolbarSeparator"></div>
<!--#endif-->
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<button id="presentationMode" class="toolbarButton labeled" type="button" tabindex="0" data-l10n-id="pdfjs-presentation-mode-button">
<span data-l10n-id="pdfjs-presentation-mode-button-label"></span>
Refactor the toolbar html & css to improve its overall accessibility (bug 1171799, bug 1855695) The first goal of this patch was to remove the tabindex because it helps to improve overall a11y. That led to move some html elements associated with the buttons which helped to position these elements relatively to their buttons. Consequently it was easy to change the toolbar height (configurable in Firefox with the pref browser.uidensity): it's the second goal of this patch. For a11y reasons we want to be able to change the height of the toolbar to make the buttons larger.
2024-07-01 22:37:48 +02:00
</button>
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<a href="#" id="viewBookmark" class="toolbarButton labeled" tabindex="0" data-l10n-id="pdfjs-bookmark-button">
<span data-l10n-id="pdfjs-bookmark-button-label"></span>
Refactor the toolbar html & css to improve its overall accessibility (bug 1171799, bug 1855695) The first goal of this patch was to remove the tabindex because it helps to improve overall a11y. That led to move some html elements associated with the buttons which helped to position these elements relatively to their buttons. Consequently it was easy to change the toolbar height (configurable in Firefox with the pref browser.uidensity): it's the second goal of this patch. For a11y reasons we want to be able to change the height of the toolbar to make the buttons larger.
2024-07-01 22:37:48 +02:00
</a>
<div id="viewBookmarkSeparator" class="horizontalToolbarSeparator"></div>
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<button id="firstPage" class="toolbarButton labeled" type="button" tabindex="0" data-l10n-id="pdfjs-first-page-button">
<span data-l10n-id="pdfjs-first-page-button-label"></span>
Refactor the toolbar html & css to improve its overall accessibility (bug 1171799, bug 1855695) The first goal of this patch was to remove the tabindex because it helps to improve overall a11y. That led to move some html elements associated with the buttons which helped to position these elements relatively to their buttons. Consequently it was easy to change the toolbar height (configurable in Firefox with the pref browser.uidensity): it's the second goal of this patch. For a11y reasons we want to be able to change the height of the toolbar to make the buttons larger.
2024-07-01 22:37:48 +02:00
</button>
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<button id="lastPage" class="toolbarButton labeled" type="button" tabindex="0" data-l10n-id="pdfjs-last-page-button">
<span data-l10n-id="pdfjs-last-page-button-label"></span>
Refactor the toolbar html & css to improve its overall accessibility (bug 1171799, bug 1855695) The first goal of this patch was to remove the tabindex because it helps to improve overall a11y. That led to move some html elements associated with the buttons which helped to position these elements relatively to their buttons. Consequently it was easy to change the toolbar height (configurable in Firefox with the pref browser.uidensity): it's the second goal of this patch. For a11y reasons we want to be able to change the height of the toolbar to make the buttons larger.
2024-07-01 22:37:48 +02:00
</button>
<div class="horizontalToolbarSeparator"></div>
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<button id="pageRotateCw" class="toolbarButton labeled" type="button" tabindex="0" data-l10n-id="pdfjs-page-rotate-cw-button">
<span data-l10n-id="pdfjs-page-rotate-cw-button-label"></span>
Refactor the toolbar html & css to improve its overall accessibility (bug 1171799, bug 1855695) The first goal of this patch was to remove the tabindex because it helps to improve overall a11y. That led to move some html elements associated with the buttons which helped to position these elements relatively to their buttons. Consequently it was easy to change the toolbar height (configurable in Firefox with the pref browser.uidensity): it's the second goal of this patch. For a11y reasons we want to be able to change the height of the toolbar to make the buttons larger.
2024-07-01 22:37:48 +02:00
</button>
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<button id="pageRotateCcw" class="toolbarButton labeled" type="button" tabindex="0" data-l10n-id="pdfjs-page-rotate-ccw-button">
<span data-l10n-id="pdfjs-page-rotate-ccw-button-label"></span>
Refactor the toolbar html & css to improve its overall accessibility (bug 1171799, bug 1855695) The first goal of this patch was to remove the tabindex because it helps to improve overall a11y. That led to move some html elements associated with the buttons which helped to position these elements relatively to their buttons. Consequently it was easy to change the toolbar height (configurable in Firefox with the pref browser.uidensity): it's the second goal of this patch. For a11y reasons we want to be able to change the height of the toolbar to make the buttons larger.
2024-07-01 22:37:48 +02:00
</button>
<div class="horizontalToolbarSeparator"></div>
<div id="cursorToolButtons" role="radiogroup">
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<button id="cursorSelectTool" class="toolbarButton labeled toggled" type="button" tabindex="0" data-l10n-id="pdfjs-cursor-text-select-tool-button" role="radio" aria-checked="true">
<span data-l10n-id="pdfjs-cursor-text-select-tool-button-label"></span>
Refactor the toolbar html & css to improve its overall accessibility (bug 1171799, bug 1855695) The first goal of this patch was to remove the tabindex because it helps to improve overall a11y. That led to move some html elements associated with the buttons which helped to position these elements relatively to their buttons. Consequently it was easy to change the toolbar height (configurable in Firefox with the pref browser.uidensity): it's the second goal of this patch. For a11y reasons we want to be able to change the height of the toolbar to make the buttons larger.
2024-07-01 22:37:48 +02:00
</button>
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<button id="cursorHandTool" class="toolbarButton labeled" type="button" tabindex="0" data-l10n-id="pdfjs-cursor-hand-tool-button" role="radio" aria-checked="false">
<span data-l10n-id="pdfjs-cursor-hand-tool-button-label"></span>
Refactor the toolbar html & css to improve its overall accessibility (bug 1171799, bug 1855695) The first goal of this patch was to remove the tabindex because it helps to improve overall a11y. That led to move some html elements associated with the buttons which helped to position these elements relatively to their buttons. Consequently it was easy to change the toolbar height (configurable in Firefox with the pref browser.uidensity): it's the second goal of this patch. For a11y reasons we want to be able to change the height of the toolbar to make the buttons larger.
2024-07-01 22:37:48 +02:00
</button>
</div>
<div class="horizontalToolbarSeparator"></div>
<div id="scrollModeButtons" role="radiogroup">
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<button id="scrollPage" class="toolbarButton labeled" type="button" tabindex="0" data-l10n-id="pdfjs-scroll-page-button" role="radio" aria-checked="false">
<span data-l10n-id="pdfjs-scroll-page-button-label"></span>
Refactor the toolbar html & css to improve its overall accessibility (bug 1171799, bug 1855695) The first goal of this patch was to remove the tabindex because it helps to improve overall a11y. That led to move some html elements associated with the buttons which helped to position these elements relatively to their buttons. Consequently it was easy to change the toolbar height (configurable in Firefox with the pref browser.uidensity): it's the second goal of this patch. For a11y reasons we want to be able to change the height of the toolbar to make the buttons larger.
2024-07-01 22:37:48 +02:00
</button>
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<button id="scrollVertical" class="toolbarButton labeled toggled" type="button" tabindex="0" data-l10n-id="pdfjs-scroll-vertical-button" role="radio" aria-checked="true">
<span data-l10n-id="pdfjs-scroll-vertical-button-label"></span>
Refactor the toolbar html & css to improve its overall accessibility (bug 1171799, bug 1855695) The first goal of this patch was to remove the tabindex because it helps to improve overall a11y. That led to move some html elements associated with the buttons which helped to position these elements relatively to their buttons. Consequently it was easy to change the toolbar height (configurable in Firefox with the pref browser.uidensity): it's the second goal of this patch. For a11y reasons we want to be able to change the height of the toolbar to make the buttons larger.
2024-07-01 22:37:48 +02:00
</button>
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<button id="scrollHorizontal" class="toolbarButton labeled" type="button" tabindex="0" data-l10n-id="pdfjs-scroll-horizontal-button" role="radio" aria-checked="false">
<span data-l10n-id="pdfjs-scroll-horizontal-button-label"></span>
Refactor the toolbar html & css to improve its overall accessibility (bug 1171799, bug 1855695) The first goal of this patch was to remove the tabindex because it helps to improve overall a11y. That led to move some html elements associated with the buttons which helped to position these elements relatively to their buttons. Consequently it was easy to change the toolbar height (configurable in Firefox with the pref browser.uidensity): it's the second goal of this patch. For a11y reasons we want to be able to change the height of the toolbar to make the buttons larger.
2024-07-01 22:37:48 +02:00
</button>
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<button id="scrollWrapped" class="toolbarButton labeled" type="button" tabindex="0" data-l10n-id="pdfjs-scroll-wrapped-button" role="radio" aria-checked="false">
<span data-l10n-id="pdfjs-scroll-wrapped-button-label"></span>
Refactor the toolbar html & css to improve its overall accessibility (bug 1171799, bug 1855695) The first goal of this patch was to remove the tabindex because it helps to improve overall a11y. That led to move some html elements associated with the buttons which helped to position these elements relatively to their buttons. Consequently it was easy to change the toolbar height (configurable in Firefox with the pref browser.uidensity): it's the second goal of this patch. For a11y reasons we want to be able to change the height of the toolbar to make the buttons larger.
2024-07-01 22:37:48 +02:00
</button>
</div>
<div class="horizontalToolbarSeparator"></div>
<div id="spreadModeButtons" role="radiogroup">
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<button id="spreadNone" class="toolbarButton labeled toggled" type="button" tabindex="0" data-l10n-id="pdfjs-spread-none-button" role="radio" aria-checked="true">
<span data-l10n-id="pdfjs-spread-none-button-label"></span>
Refactor the toolbar html & css to improve its overall accessibility (bug 1171799, bug 1855695) The first goal of this patch was to remove the tabindex because it helps to improve overall a11y. That led to move some html elements associated with the buttons which helped to position these elements relatively to their buttons. Consequently it was easy to change the toolbar height (configurable in Firefox with the pref browser.uidensity): it's the second goal of this patch. For a11y reasons we want to be able to change the height of the toolbar to make the buttons larger.
2024-07-01 22:37:48 +02:00
</button>
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<button id="spreadOdd" class="toolbarButton labeled" type="button" tabindex="0" data-l10n-id="pdfjs-spread-odd-button" role="radio" aria-checked="false">
<span data-l10n-id="pdfjs-spread-odd-button-label"></span>
Refactor the toolbar html & css to improve its overall accessibility (bug 1171799, bug 1855695) The first goal of this patch was to remove the tabindex because it helps to improve overall a11y. That led to move some html elements associated with the buttons which helped to position these elements relatively to their buttons. Consequently it was easy to change the toolbar height (configurable in Firefox with the pref browser.uidensity): it's the second goal of this patch. For a11y reasons we want to be able to change the height of the toolbar to make the buttons larger.
2024-07-01 22:37:48 +02:00
</button>
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<button id="spreadEven" class="toolbarButton labeled" type="button" tabindex="0" data-l10n-id="pdfjs-spread-even-button" role="radio" aria-checked="false">
<span data-l10n-id="pdfjs-spread-even-button-label"></span>
Refactor the toolbar html & css to improve its overall accessibility (bug 1171799, bug 1855695) The first goal of this patch was to remove the tabindex because it helps to improve overall a11y. That led to move some html elements associated with the buttons which helped to position these elements relatively to their buttons. Consequently it was easy to change the toolbar height (configurable in Firefox with the pref browser.uidensity): it's the second goal of this patch. For a11y reasons we want to be able to change the height of the toolbar to make the buttons larger.
2024-07-01 22:37:48 +02:00
</button>
</div>
<div id="imageAltTextSettingsSeparator" class="horizontalToolbarSeparator hidden"></div>
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<button id="imageAltTextSettings" type="button" class="toolbarButton labeled hidden" tabindex="0" data-l10n-id="pdfjs-image-alt-text-settings-button" aria-controls="altTextSettingsDialog">
<span data-l10n-id="pdfjs-image-alt-text-settings-button-label"></span>
Refactor the toolbar html & css to improve its overall accessibility (bug 1171799, bug 1855695) The first goal of this patch was to remove the tabindex because it helps to improve overall a11y. That led to move some html elements associated with the buttons which helped to position these elements relatively to their buttons. Consequently it was easy to change the toolbar height (configurable in Firefox with the pref browser.uidensity): it's the second goal of this patch. For a11y reasons we want to be able to change the height of the toolbar to make the buttons larger.
2024-07-01 22:37:48 +02:00
</button>
<div class="horizontalToolbarSeparator"></div>
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<button id="documentProperties" class="toolbarButton labeled" type="button" tabindex="0" data-l10n-id="pdfjs-document-properties-button" aria-controls="documentPropertiesDialog">
<span data-l10n-id="pdfjs-document-properties-button-label"></span>
Refactor the toolbar html & css to improve its overall accessibility (bug 1171799, bug 1855695) The first goal of this patch was to remove the tabindex because it helps to improve overall a11y. That led to move some html elements associated with the buttons which helped to position these elements relatively to their buttons. Consequently it was easy to change the toolbar height (configurable in Firefox with the pref browser.uidensity): it's the second goal of this patch. For a11y reasons we want to be able to change the height of the toolbar to make the buttons larger.
2024-07-01 22:37:48 +02:00
</button>
</div>
</div> <!-- secondaryToolbar -->
</div>
</div>
Remove flex box. Add side animation. Add dashed line around unload thumbnails.
2012-04-25 11:34:28 -07:00
</div>
Implement progressive loading of PDFs
2013-02-06 15:19:29 -08:00
<div id="loadingBar">
<div class="progress">
<div class="glimmer">
</div>
</div>
</div>
Simple search results
2011-12-11 19:38:20 -06:00
</div>
</div>
Separate js and css from the test.html file
2011-05-26 16:02:52 +02:00
Allow scrolling by keyboard in Chrome/Opera Set "tabindex" attribute to allow focus; Added "outline: none" to prevent focus ring from appearing. Fixes #3443
2013-07-06 15:37:03 +02:00
<div id="viewerContainer" tabindex="0">
Move text_layer_builder and pdf_viewer styles out
2014-09-30 10:48:29 -05:00
<div id="viewer" class="pdfViewer"></div>
Unify the multi_page_viewer and the basic viewer
2011-07-28 19:48:05 +02:00
</div>
Remove flex box. Add side animation. Add dashed line around unload thumbnails.
2012-04-25 11:34:28 -07:00
</div> <!-- mainContainer -->
Make worker support work again after file split. Add PDFJS_WORKER_DIR/PDFJS_WORKER_FILE to specify where to load files if worker support is enabled
2011-10-28 14:32:36 +02:00
Convert the existing overlays to use `<dialog>` elements (issue 14698) This replaces our *custom* overlays with standard `<dialog>` DOM elements, see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog, thus simplifying the related CSS, HTML, and JavaScript code. With these changes, some of the functionality of the `OverlayManager` class is now handled natively (e.g. `Esc` to close the dialog). However, since we still need to be able to prevent dialogs from overlaying one another, it still makes sense to keep this functionality (as far as I'm concerned).
2022-03-25 14:10:13 +01:00
<div id="dialogContainer">
<dialog id="passwordDialog">
<div class="row">
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<label for="password" id="passwordText" data-l10n-id="pdfjs-password-label"></label>
Document properties
2014-01-22 00:07:07 +01:00
</div>
Convert the existing overlays to use `<dialog>` elements (issue 14698) This replaces our *custom* overlays with standard `<dialog>` DOM elements, see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog, thus simplifying the related CSS, HTML, and JavaScript code. With these changes, some of the functionality of the `OverlayManager` class is now handled natively (e.g. `Esc` to close the dialog). However, since we still need to be able to prevent dialogs from overlaying one another, it still makes sense to keep this functionality (as far as I'm concerned).
2022-03-25 14:10:13 +01:00
<div class="row">
<input type="password" id="password" class="toolbarField">
Improved password prompt
2013-09-24 17:46:54 +02:00
</div>
Convert the existing overlays to use `<dialog>` elements (issue 14698) This replaces our *custom* overlays with standard `<dialog>` DOM elements, see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog, thus simplifying the related CSS, HTML, and JavaScript code. With these changes, some of the functionality of the `OverlayManager` class is now handled natively (e.g. `Esc` to close the dialog). However, since we still need to be able to prevent dialogs from overlaying one another, it still makes sense to keep this functionality (as far as I'm concerned).
2022-03-25 14:10:13 +01:00
<div class="buttonRow">
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<button id="passwordCancel" class="dialogButton" type="button"><span data-l10n-id="pdfjs-password-cancel-button"></span></button>
<button id="passwordSubmit" class="dialogButton" type="button"><span data-l10n-id="pdfjs-password-ok-button"></span></button>
Convert the existing overlays to use `<dialog>` elements (issue 14698) This replaces our *custom* overlays with standard `<dialog>` DOM elements, see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog, thus simplifying the related CSS, HTML, and JavaScript code. With these changes, some of the functionality of the `OverlayManager` class is now handled natively (e.g. `Esc` to close the dialog). However, since we still need to be able to prevent dialogs from overlaying one another, it still makes sense to keep this functionality (as far as I'm concerned).
2022-03-25 14:10:13 +01:00
</div>
</dialog>
<dialog id="documentPropertiesDialog">
<div class="row">
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<span id="fileNameLabel" data-l10n-id="pdfjs-document-properties-file-name"></span>
Try to improve a11y for the `PasswordPrompt` and `PDFDocumentProperties` dialogs This will hopefully improve the a11y a little bit in these dialogs, however there's most definately more things that can be done here (by someone more knowledgeable about a11y).
2022-03-25 14:10:28 +01:00
<p id="fileNameField" aria-labelledby="fileNameLabel">-</p>
Convert the existing overlays to use `<dialog>` elements (issue 14698) This replaces our *custom* overlays with standard `<dialog>` DOM elements, see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog, thus simplifying the related CSS, HTML, and JavaScript code. With these changes, some of the functionality of the `OverlayManager` class is now handled natively (e.g. `Esc` to close the dialog). However, since we still need to be able to prevent dialogs from overlaying one another, it still makes sense to keep this functionality (as far as I'm concerned).
2022-03-25 14:10:13 +01:00
</div>
<div class="row">
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<span id="fileSizeLabel" data-l10n-id="pdfjs-document-properties-file-size"></span>
Try to improve a11y for the `PasswordPrompt` and `PDFDocumentProperties` dialogs This will hopefully improve the a11y a little bit in these dialogs, however there's most definately more things that can be done here (by someone more knowledgeable about a11y).
2022-03-25 14:10:28 +01:00
<p id="fileSizeField" aria-labelledby="fileSizeLabel">-</p>
Convert the existing overlays to use `<dialog>` elements (issue 14698) This replaces our *custom* overlays with standard `<dialog>` DOM elements, see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog, thus simplifying the related CSS, HTML, and JavaScript code. With these changes, some of the functionality of the `OverlayManager` class is now handled natively (e.g. `Esc` to close the dialog). However, since we still need to be able to prevent dialogs from overlaying one another, it still makes sense to keep this functionality (as far as I'm concerned).
2022-03-25 14:10:13 +01:00
</div>
<div class="separator"></div>
<div class="row">
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<span id="titleLabel" data-l10n-id="pdfjs-document-properties-title"></span>
Try to improve a11y for the `PasswordPrompt` and `PDFDocumentProperties` dialogs This will hopefully improve the a11y a little bit in these dialogs, however there's most definately more things that can be done here (by someone more knowledgeable about a11y).
2022-03-25 14:10:28 +01:00
<p id="titleField" aria-labelledby="titleLabel">-</p>
Convert the existing overlays to use `<dialog>` elements (issue 14698) This replaces our *custom* overlays with standard `<dialog>` DOM elements, see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog, thus simplifying the related CSS, HTML, and JavaScript code. With these changes, some of the functionality of the `OverlayManager` class is now handled natively (e.g. `Esc` to close the dialog). However, since we still need to be able to prevent dialogs from overlaying one another, it still makes sense to keep this functionality (as far as I'm concerned).
2022-03-25 14:10:13 +01:00
</div>
<div class="row">
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<span id="authorLabel" data-l10n-id="pdfjs-document-properties-author"></span>
Try to improve a11y for the `PasswordPrompt` and `PDFDocumentProperties` dialogs This will hopefully improve the a11y a little bit in these dialogs, however there's most definately more things that can be done here (by someone more knowledgeable about a11y).
2022-03-25 14:10:28 +01:00
<p id="authorField" aria-labelledby="authorLabel">-</p>
Convert the existing overlays to use `<dialog>` elements (issue 14698) This replaces our *custom* overlays with standard `<dialog>` DOM elements, see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog, thus simplifying the related CSS, HTML, and JavaScript code. With these changes, some of the functionality of the `OverlayManager` class is now handled natively (e.g. `Esc` to close the dialog). However, since we still need to be able to prevent dialogs from overlaying one another, it still makes sense to keep this functionality (as far as I'm concerned).
2022-03-25 14:10:13 +01:00
</div>
<div class="row">
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<span id="subjectLabel" data-l10n-id="pdfjs-document-properties-subject"></span>
Try to improve a11y for the `PasswordPrompt` and `PDFDocumentProperties` dialogs This will hopefully improve the a11y a little bit in these dialogs, however there's most definately more things that can be done here (by someone more knowledgeable about a11y).
2022-03-25 14:10:28 +01:00
<p id="subjectField" aria-labelledby="subjectLabel">-</p>
Convert the existing overlays to use `<dialog>` elements (issue 14698) This replaces our *custom* overlays with standard `<dialog>` DOM elements, see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog, thus simplifying the related CSS, HTML, and JavaScript code. With these changes, some of the functionality of the `OverlayManager` class is now handled natively (e.g. `Esc` to close the dialog). However, since we still need to be able to prevent dialogs from overlaying one another, it still makes sense to keep this functionality (as far as I'm concerned).
2022-03-25 14:10:13 +01:00
</div>
<div class="row">
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<span id="keywordsLabel" data-l10n-id="pdfjs-document-properties-keywords"></span>
Try to improve a11y for the `PasswordPrompt` and `PDFDocumentProperties` dialogs This will hopefully improve the a11y a little bit in these dialogs, however there's most definately more things that can be done here (by someone more knowledgeable about a11y).
2022-03-25 14:10:28 +01:00
<p id="keywordsField" aria-labelledby="keywordsLabel">-</p>
Convert the existing overlays to use `<dialog>` elements (issue 14698) This replaces our *custom* overlays with standard `<dialog>` DOM elements, see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog, thus simplifying the related CSS, HTML, and JavaScript code. With these changes, some of the functionality of the `OverlayManager` class is now handled natively (e.g. `Esc` to close the dialog). However, since we still need to be able to prevent dialogs from overlaying one another, it still makes sense to keep this functionality (as far as I'm concerned).
2022-03-25 14:10:13 +01:00
</div>
<div class="row">
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<span id="creationDateLabel" data-l10n-id="pdfjs-document-properties-creation-date"></span>
Try to improve a11y for the `PasswordPrompt` and `PDFDocumentProperties` dialogs This will hopefully improve the a11y a little bit in these dialogs, however there's most definately more things that can be done here (by someone more knowledgeable about a11y).
2022-03-25 14:10:28 +01:00
<p id="creationDateField" aria-labelledby="creationDateLabel">-</p>
Convert the existing overlays to use `<dialog>` elements (issue 14698) This replaces our *custom* overlays with standard `<dialog>` DOM elements, see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog, thus simplifying the related CSS, HTML, and JavaScript code. With these changes, some of the functionality of the `OverlayManager` class is now handled natively (e.g. `Esc` to close the dialog). However, since we still need to be able to prevent dialogs from overlaying one another, it still makes sense to keep this functionality (as far as I'm concerned).
2022-03-25 14:10:13 +01:00
</div>
<div class="row">
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<span id="modificationDateLabel" data-l10n-id="pdfjs-document-properties-modification-date"></span>
Try to improve a11y for the `PasswordPrompt` and `PDFDocumentProperties` dialogs This will hopefully improve the a11y a little bit in these dialogs, however there's most definately more things that can be done here (by someone more knowledgeable about a11y).
2022-03-25 14:10:28 +01:00
<p id="modificationDateField" aria-labelledby="modificationDateLabel">-</p>
Convert the existing overlays to use `<dialog>` elements (issue 14698) This replaces our *custom* overlays with standard `<dialog>` DOM elements, see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog, thus simplifying the related CSS, HTML, and JavaScript code. With these changes, some of the functionality of the `OverlayManager` class is now handled natively (e.g. `Esc` to close the dialog). However, since we still need to be able to prevent dialogs from overlaying one another, it still makes sense to keep this functionality (as far as I'm concerned).
2022-03-25 14:10:13 +01:00
</div>
<div class="row">
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<span id="creatorLabel" data-l10n-id="pdfjs-document-properties-creator"></span>
Try to improve a11y for the `PasswordPrompt` and `PDFDocumentProperties` dialogs This will hopefully improve the a11y a little bit in these dialogs, however there's most definately more things that can be done here (by someone more knowledgeable about a11y).
2022-03-25 14:10:28 +01:00
<p id="creatorField" aria-labelledby="creatorLabel">-</p>
Convert the existing overlays to use `<dialog>` elements (issue 14698) This replaces our *custom* overlays with standard `<dialog>` DOM elements, see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog, thus simplifying the related CSS, HTML, and JavaScript code. With these changes, some of the functionality of the `OverlayManager` class is now handled natively (e.g. `Esc` to close the dialog). However, since we still need to be able to prevent dialogs from overlaying one another, it still makes sense to keep this functionality (as far as I'm concerned).
2022-03-25 14:10:13 +01:00
</div>
<div class="separator"></div>
<div class="row">
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<span id="producerLabel" data-l10n-id="pdfjs-document-properties-producer"></span>
Try to improve a11y for the `PasswordPrompt` and `PDFDocumentProperties` dialogs This will hopefully improve the a11y a little bit in these dialogs, however there's most definately more things that can be done here (by someone more knowledgeable about a11y).
2022-03-25 14:10:28 +01:00
<p id="producerField" aria-labelledby="producerLabel">-</p>
Convert the existing overlays to use `<dialog>` elements (issue 14698) This replaces our *custom* overlays with standard `<dialog>` DOM elements, see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog, thus simplifying the related CSS, HTML, and JavaScript code. With these changes, some of the functionality of the `OverlayManager` class is now handled natively (e.g. `Esc` to close the dialog). However, since we still need to be able to prevent dialogs from overlaying one another, it still makes sense to keep this functionality (as far as I'm concerned).
2022-03-25 14:10:13 +01:00
</div>
<div class="row">
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<span id="versionLabel" data-l10n-id="pdfjs-document-properties-version"></span>
Try to improve a11y for the `PasswordPrompt` and `PDFDocumentProperties` dialogs This will hopefully improve the a11y a little bit in these dialogs, however there's most definately more things that can be done here (by someone more knowledgeable about a11y).
2022-03-25 14:10:28 +01:00
<p id="versionField" aria-labelledby="versionLabel">-</p>
Convert the existing overlays to use `<dialog>` elements (issue 14698) This replaces our *custom* overlays with standard `<dialog>` DOM elements, see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog, thus simplifying the related CSS, HTML, and JavaScript code. With these changes, some of the functionality of the `OverlayManager` class is now handled natively (e.g. `Esc` to close the dialog). However, since we still need to be able to prevent dialogs from overlaying one another, it still makes sense to keep this functionality (as far as I'm concerned).
2022-03-25 14:10:13 +01:00
</div>
<div class="row">
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<span id="pageCountLabel" data-l10n-id="pdfjs-document-properties-page-count"></span>
Try to improve a11y for the `PasswordPrompt` and `PDFDocumentProperties` dialogs This will hopefully improve the a11y a little bit in these dialogs, however there's most definately more things that can be done here (by someone more knowledgeable about a11y).
2022-03-25 14:10:28 +01:00
<p id="pageCountField" aria-labelledby="pageCountLabel">-</p>
Convert the existing overlays to use `<dialog>` elements (issue 14698) This replaces our *custom* overlays with standard `<dialog>` DOM elements, see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog, thus simplifying the related CSS, HTML, and JavaScript code. With these changes, some of the functionality of the `OverlayManager` class is now handled natively (e.g. `Esc` to close the dialog). However, since we still need to be able to prevent dialogs from overlaying one another, it still makes sense to keep this functionality (as far as I'm concerned).
2022-03-25 14:10:13 +01:00
</div>
<div class="row">
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<span id="pageSizeLabel" data-l10n-id="pdfjs-document-properties-page-size"></span>
Try to improve a11y for the `PasswordPrompt` and `PDFDocumentProperties` dialogs This will hopefully improve the a11y a little bit in these dialogs, however there's most definately more things that can be done here (by someone more knowledgeable about a11y).
2022-03-25 14:10:28 +01:00
<p id="pageSizeField" aria-labelledby="pageSizeLabel">-</p>
Convert the existing overlays to use `<dialog>` elements (issue 14698) This replaces our *custom* overlays with standard `<dialog>` DOM elements, see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog, thus simplifying the related CSS, HTML, and JavaScript code. With these changes, some of the functionality of the `OverlayManager` class is now handled natively (e.g. `Esc` to close the dialog). However, since we still need to be able to prevent dialogs from overlaying one another, it still makes sense to keep this functionality (as far as I'm concerned).
2022-03-25 14:10:13 +01:00
</div>
<div class="separator"></div>
<div class="row">
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<span id="linearizedLabel" data-l10n-id="pdfjs-document-properties-linearized"></span>
Try to improve a11y for the `PasswordPrompt` and `PDFDocumentProperties` dialogs This will hopefully improve the a11y a little bit in these dialogs, however there's most definately more things that can be done here (by someone more knowledgeable about a11y).
2022-03-25 14:10:28 +01:00
<p id="linearizedField" aria-labelledby="linearizedLabel">-</p>
Convert the existing overlays to use `<dialog>` elements (issue 14698) This replaces our *custom* overlays with standard `<dialog>` DOM elements, see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog, thus simplifying the related CSS, HTML, and JavaScript code. With these changes, some of the functionality of the `OverlayManager` class is now handled natively (e.g. `Esc` to close the dialog). However, since we still need to be able to prevent dialogs from overlaying one another, it still makes sense to keep this functionality (as far as I'm concerned).
2022-03-25 14:10:13 +01:00
</div>
<div class="buttonRow">
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<button id="documentPropertiesClose" class="dialogButton" type="button"><span data-l10n-id="pdfjs-document-properties-close-button"></span></button>
Convert the existing overlays to use `<dialog>` elements (issue 14698) This replaces our *custom* overlays with standard `<dialog>` DOM elements, see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog, thus simplifying the related CSS, HTML, and JavaScript code. With these changes, some of the functionality of the `OverlayManager` class is now handled natively (e.g. `Esc` to close the dialog). However, since we still need to be able to prevent dialogs from overlaying one another, it still makes sense to keep this functionality (as far as I'm concerned).
2022-03-25 14:10:13 +01:00
</div>
</dialog>
Move the dialog css stuff in its own file In order to share common parts between different dialogs, this patch aims to slightly refactor the css in making it more generic. This way it'll simplify adding a new dialog (we want to add a new one when leaving an unsaved document).
2024-05-27 12:38:31 +02:00
<dialog class="dialog altText" id="altTextDialog" aria-labelledby="dialogLabel" aria-describedby="dialogDescription">
<div id="altTextContainer" class="mainContainer">
[Editor] Add a dialog box in order to get alt-text data (bug 1844952) Implement the specifications provided by UX for light, dark and HCM modes.
2023-09-15 14:06:50 +02:00
<div id="overallDescription">
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<span id="dialogLabel" data-l10n-id="pdfjs-editor-alt-text-dialog-label" class="title"></span>
<span id="dialogDescription" data-l10n-id="pdfjs-editor-alt-text-dialog-description"></span>
[Editor] Add a dialog box in order to get alt-text data (bug 1844952) Implement the specifications provided by UX for light, dark and HCM modes.
2023-09-15 14:06:50 +02:00
</div>
<div id="addDescription">
<div class="radio">
<div class="radioButton">
[Editor] Change the colors for the disabled Save button in alt text dialoag in HCM
2023-09-20 10:45:26 +02:00
<input type="radio" id="descriptionButton" name="altTextOption" tabindex="0" aria-describedby="descriptionAreaLabel" checked>
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<label for="descriptionButton" data-l10n-id="pdfjs-editor-alt-text-add-description-label"></label>
[Editor] Add a dialog box in order to get alt-text data (bug 1844952) Implement the specifications provided by UX for light, dark and HCM modes.
2023-09-15 14:06:50 +02:00
</div>
<div class="radioLabel">
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<span id="descriptionAreaLabel" data-l10n-id="pdfjs-editor-alt-text-add-description-description"></span>
[Editor] Add a dialog box in order to get alt-text data (bug 1844952) Implement the specifications provided by UX for light, dark and HCM modes.
2023-09-15 14:06:50 +02:00
</div>
</div>
<div class="descriptionArea">
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<textarea id="descriptionTextarea" aria-labelledby="descriptionAreaLabel" data-l10n-id="pdfjs-editor-alt-text-textarea" tabindex="0"></textarea>
[Editor] Add a dialog box in order to get alt-text data (bug 1844952) Implement the specifications provided by UX for light, dark and HCM modes.
2023-09-15 14:06:50 +02:00
</div>
</div>
<div id="markAsDecorative">
<div class="radio">
<div class="radioButton">
[Editor] Change the colors for the disabled Save button in alt text dialoag in HCM
2023-09-20 10:45:26 +02:00
<input type="radio" id="decorativeButton" name="altTextOption" aria-describedby="decorativeLabel">
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<label for="decorativeButton" data-l10n-id="pdfjs-editor-alt-text-mark-decorative-label"></label>
[Editor] Add a dialog box in order to get alt-text data (bug 1844952) Implement the specifications provided by UX for light, dark and HCM modes.
2023-09-15 14:06:50 +02:00
</div>
<div class="radioLabel">
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<span id="decorativeLabel" data-l10n-id="pdfjs-editor-alt-text-mark-decorative-description"></span>
[Editor] Add a dialog box in order to get alt-text data (bug 1844952) Implement the specifications provided by UX for light, dark and HCM modes.
2023-09-15 14:06:50 +02:00
</div>
</div>
</div>
<div id="buttons">
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<button id="altTextCancel" class="secondaryButton" type="button" tabindex="0"><span data-l10n-id="pdfjs-editor-alt-text-cancel-button"></span></button>
<button id="altTextSave" class="primaryButton" type="button" tabindex="0"><span data-l10n-id="pdfjs-editor-alt-text-save-button"></span></button>
[Editor] Add a dialog box in order to get alt-text data (bug 1844952) Implement the specifications provided by UX for light, dark and HCM modes.
2023-09-15 14:06:50 +02:00
</div>
</div>
</dialog>
Implement the new alt text flow (bug 1909604) For the Firefox pdf viewer, we want to use AI to guess an alt-text when adding an image to a pdf. For now the telemtry stuff is not implemented and will come soon. In order to test it locally: - set enableAltText, enableFakeMLManager and enableUpdatedAddImage to true. or in Firefox: - set browser.ml.enable, pdfjs.enableAltText and pdfjs.enableUpdatedAddImage to true.
2024-07-24 09:34:32 +02:00
<dialog class="dialog newAltText" id="newAltTextDialog" aria-labelledby="newAltTextTitle" aria-describedby="newAltTextDescription" tabindex="0">
<div id="newAltTextContainer" class="mainContainer">
<div class="title">
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<span id="newAltTextTitle" data-l10n-id="pdfjs-editor-new-alt-text-dialog-edit-label" role="sectionhead" tabindex="0"></span>
Implement the new alt text flow (bug 1909604) For the Firefox pdf viewer, we want to use AI to guess an alt-text when adding an image to a pdf. For now the telemtry stuff is not implemented and will come soon. In order to test it locally: - set enableAltText, enableFakeMLManager and enableUpdatedAddImage to true. or in Firefox: - set browser.ml.enable, pdfjs.enableAltText and pdfjs.enableUpdatedAddImage to true.
2024-07-24 09:34:32 +02:00
</div>
<div id="mainContent">
<div id="descriptionAndSettings">
<div id="descriptionInstruction">
<div id="newAltTextDescriptionContainer">
<div class="altTextSpinner" role="status" aria-live="polite"></div>
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<textarea id="newAltTextDescriptionTextarea" aria-labelledby="descriptionAreaLabel" data-l10n-id="pdfjs-editor-new-alt-text-textarea" tabindex="0"></textarea>
Implement the new alt text flow (bug 1909604) For the Firefox pdf viewer, we want to use AI to guess an alt-text when adding an image to a pdf. For now the telemtry stuff is not implemented and will come soon. In order to test it locally: - set enableAltText, enableFakeMLManager and enableUpdatedAddImage to true. or in Firefox: - set browser.ml.enable, pdfjs.enableAltText and pdfjs.enableUpdatedAddImage to true.
2024-07-24 09:34:32 +02:00
</div>
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<span id="newAltTextDescription" role="note" data-l10n-id="pdfjs-editor-new-alt-text-description"></span>
<div id="newAltTextDisclaimer" role="note"><div><span data-l10n-id="pdfjs-editor-new-alt-text-disclaimer1"></span> <a href="https://support.mozilla.org/en-US/kb/pdf-alt-text" target="_blank" rel="noopener noreferrer" id="newAltTextLearnMore" data-l10n-id="pdfjs-editor-new-alt-text-disclaimer-learn-more-url" tabindex="0"></a></div></div>
Implement the new alt text flow (bug 1909604) For the Firefox pdf viewer, we want to use AI to guess an alt-text when adding an image to a pdf. For now the telemtry stuff is not implemented and will come soon. In order to test it locally: - set enableAltText, enableFakeMLManager and enableUpdatedAddImage to true. or in Firefox: - set browser.ml.enable, pdfjs.enableAltText and pdfjs.enableUpdatedAddImage to true.
2024-07-24 09:34:32 +02:00
</div>
<div id="newAltTextCreateAutomatically" class="toggler">
Give all HTML button elements a type The HTML button elements we use are all regular buttons that don't submit form data to a server. According to https://developer.mozilla.org/en-US/docs/Web/HTML/Element/button#notes those buttons should all have their type set to `button` explicitly, but we only do that a handful of them. This commit fixes the issue by consistently giving all our buttons the `button` type. Co-authored-by: Calixte Denizet <calixte.denizet@gmail.com>
2024-07-30 18:35:12 +02:00
<button id="newAltTextCreateAutomaticallyButton" class="toggle-button" type="button" aria-pressed="true" tabindex="0"></button>
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<label for="newAltTextCreateAutomaticallyButton" class="togglerLabel" data-l10n-id="pdfjs-editor-new-alt-text-create-automatically-button-label"></label>
Implement the new alt text flow (bug 1909604) For the Firefox pdf viewer, we want to use AI to guess an alt-text when adding an image to a pdf. For now the telemtry stuff is not implemented and will come soon. In order to test it locally: - set enableAltText, enableFakeMLManager and enableUpdatedAddImage to true. or in Firefox: - set browser.ml.enable, pdfjs.enableAltText and pdfjs.enableUpdatedAddImage to true.
2024-07-24 09:34:32 +02:00
</div>
<div id="newAltTextDownloadModel" class="hidden">
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<span id="newAltTextDownloadModelDescription" data-l10n-id="pdfjs-editor-new-alt-text-ai-model-downloading-progress" aria-valuemin="0" data-l10n-args='{ "totalSize": 0, "downloadedSize": 0 }'></span>
Implement the new alt text flow (bug 1909604) For the Firefox pdf viewer, we want to use AI to guess an alt-text when adding an image to a pdf. For now the telemtry stuff is not implemented and will come soon. In order to test it locally: - set enableAltText, enableFakeMLManager and enableUpdatedAddImage to true. or in Firefox: - set browser.ml.enable, pdfjs.enableAltText and pdfjs.enableUpdatedAddImage to true.
2024-07-24 09:34:32 +02:00
</div>
</div>
<div id="newAltTextImagePreview"></div>
</div>
<div id="newAltTextError" class="messageBar">
<div>
<div>
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<span class="title" data-l10n-id="pdfjs-editor-new-alt-text-error-title"></span>
<span class="description" data-l10n-id="pdfjs-editor-new-alt-text-error-description"></span>
Implement the new alt text flow (bug 1909604) For the Firefox pdf viewer, we want to use AI to guess an alt-text when adding an image to a pdf. For now the telemtry stuff is not implemented and will come soon. In order to test it locally: - set enableAltText, enableFakeMLManager and enableUpdatedAddImage to true. or in Firefox: - set browser.ml.enable, pdfjs.enableAltText and pdfjs.enableUpdatedAddImage to true.
2024-07-24 09:34:32 +02:00
</div>
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<button id="newAltTextCloseButton" class="closeButton" type="button" tabindex="0"><span data-l10n-id="pdfjs-editor-new-alt-text-error-close-button"></span></button>
Implement the new alt text flow (bug 1909604) For the Firefox pdf viewer, we want to use AI to guess an alt-text when adding an image to a pdf. For now the telemtry stuff is not implemented and will come soon. In order to test it locally: - set enableAltText, enableFakeMLManager and enableUpdatedAddImage to true. or in Firefox: - set browser.ml.enable, pdfjs.enableAltText and pdfjs.enableUpdatedAddImage to true.
2024-07-24 09:34:32 +02:00
</div>
</div>
<div id="newAltTextButtons" class="dialogButtonsGroup">
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<button id="newAltTextCancel" type="button" class="secondaryButton hidden" tabindex="0"><span data-l10n-id="pdfjs-editor-alt-text-cancel-button"></span></button>
<button id="newAltTextNotNow" type="button" class="secondaryButton" tabindex="0"><span data-l10n-id="pdfjs-editor-new-alt-text-not-now-button"></span></button>
<button id="newAltTextSave" type="button" class="primaryButton" tabindex="0"><span data-l10n-id="pdfjs-editor-alt-text-save-button"></span></button>
Implement the new alt text flow (bug 1909604) For the Firefox pdf viewer, we want to use AI to guess an alt-text when adding an image to a pdf. For now the telemtry stuff is not implemented and will come soon. In order to test it locally: - set enableAltText, enableFakeMLManager and enableUpdatedAddImage to true. or in Firefox: - set browser.ml.enable, pdfjs.enableAltText and pdfjs.enableUpdatedAddImage to true.
2024-07-24 09:34:32 +02:00
</div>
</div>
</dialog>
[Editor] Add a new dialog for alt-text settings (bug 1909604) This patch adds a new entry in the secondary menu in order to open a dialog to let the user: - disables the alt-text generation thanks to a ML model; - deletes the alt-text model downloaded in Firefox; - disabled the new alt-text flow.
2024-08-01 15:29:01 +02:00
<dialog class="dialog" id="altTextSettingsDialog" aria-labelledby="altTextSettingsTitle">
<div id="altTextSettingsContainer" class="mainContainer">
<div class="title">
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<span id="altTextSettingsTitle" data-l10n-id="pdfjs-editor-alt-text-settings-dialog-label" role="sectionhead" tabindex="0" class="title"></span>
[Editor] Add a new dialog for alt-text settings (bug 1909604) This patch adds a new entry in the secondary menu in order to open a dialog to let the user: - disables the alt-text generation thanks to a ML model; - deletes the alt-text model downloaded in Firefox; - disabled the new alt-text flow.
2024-08-01 15:29:01 +02:00
</div>
<div id="automaticAltText">
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<span data-l10n-id="pdfjs-editor-alt-text-settings-automatic-title"></span>
[Editor] Add a new dialog for alt-text settings (bug 1909604) This patch adds a new entry in the secondary menu in order to open a dialog to let the user: - disables the alt-text generation thanks to a ML model; - deletes the alt-text model downloaded in Firefox; - disabled the new alt-text flow.
2024-08-01 15:29:01 +02:00
<div id="automaticSettings">
<div id="createModelSetting">
<div class="toggler">
<button id="createModelButton" type="button" class="toggle-button" aria-pressed="true" tabindex="0"></button>
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<label for="createModelButton" class="togglerLabel" data-l10n-id="pdfjs-editor-alt-text-settings-create-model-button-label"></label>
[Editor] Add a new dialog for alt-text settings (bug 1909604) This patch adds a new entry in the secondary menu in order to open a dialog to let the user: - disables the alt-text generation thanks to a ML model; - deletes the alt-text model downloaded in Firefox; - disabled the new alt-text flow.
2024-08-01 15:29:01 +02:00
</div>
<div id="createModelDescription" class="description">
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<span data-l10n-id="pdfjs-editor-alt-text-settings-create-model-description"></span> <a href="https://support.mozilla.org/en-US/kb/pdf-alt-text" target="_blank" rel="noopener noreferrer" id="altTextSettingsLearnMore" data-l10n-id="pdfjs-editor-new-alt-text-disclaimer-learn-more-url" tabindex="0"></a>
[Editor] Add a new dialog for alt-text settings (bug 1909604) This patch adds a new entry in the secondary menu in order to open a dialog to let the user: - disables the alt-text generation thanks to a ML model; - deletes the alt-text model downloaded in Firefox; - disabled the new alt-text flow.
2024-08-01 15:29:01 +02:00
</div>
</div>
<div id="aiModelSettings">
<div>
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<span data-l10n-id="pdfjs-editor-alt-text-settings-download-model-label" data-l10n-args='{ "totalSize": 180 }'></span>
[Editor] Add a new dialog for alt-text settings (bug 1909604) This patch adds a new entry in the secondary menu in order to open a dialog to let the user: - disables the alt-text generation thanks to a ML model; - deletes the alt-text model downloaded in Firefox; - disabled the new alt-text flow.
2024-08-01 15:29:01 +02:00
<div id="aiModelDescription" class="description">
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<span data-l10n-id="pdfjs-editor-alt-text-settings-ai-model-description"></span>
[Editor] Add a new dialog for alt-text settings (bug 1909604) This patch adds a new entry in the secondary menu in order to open a dialog to let the user: - disables the alt-text generation thanks to a ML model; - deletes the alt-text model downloaded in Firefox; - disabled the new alt-text flow.
2024-08-01 15:29:01 +02:00
</div>
</div>
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<button id="deleteModelButton" type="button" class="secondaryButton" tabindex="0"><span data-l10n-id="pdfjs-editor-alt-text-settings-delete-model-button"></span></button>
<button id="downloadModelButton" type="button" class="secondaryButton" tabindex="0"><span data-l10n-id="pdfjs-editor-alt-text-settings-download-model-button"></span></button>
[Editor] Add a new dialog for alt-text settings (bug 1909604) This patch adds a new entry in the secondary menu in order to open a dialog to let the user: - disables the alt-text generation thanks to a ML model; - deletes the alt-text model downloaded in Firefox; - disabled the new alt-text flow.
2024-08-01 15:29:01 +02:00
</div>
</div>
</div>
<div class="dialogSeparator"></div>
<div id="altTextEditor">
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<span data-l10n-id="pdfjs-editor-alt-text-settings-editor-title"></span>
[Editor] Add a new dialog for alt-text settings (bug 1909604) This patch adds a new entry in the secondary menu in order to open a dialog to let the user: - disables the alt-text generation thanks to a ML model; - deletes the alt-text model downloaded in Firefox; - disabled the new alt-text flow.
2024-08-01 15:29:01 +02:00
<div id="showAltTextEditor">
<div class="toggler">
<button id="showAltTextDialogButton" type="button" class="toggle-button" aria-pressed="true" tabindex="0"></button>
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<label for="showAltTextDialogButton" class="togglerLabel" data-l10n-id="pdfjs-editor-alt-text-settings-show-dialog-button-label"></label>
[Editor] Add a new dialog for alt-text settings (bug 1909604) This patch adds a new entry in the secondary menu in order to open a dialog to let the user: - disables the alt-text generation thanks to a ML model; - deletes the alt-text model downloaded in Firefox; - disabled the new alt-text flow.
2024-08-01 15:29:01 +02:00
</div>
<div id="showAltTextDialogDescription" class="description">
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<span data-l10n-id="pdfjs-editor-alt-text-settings-show-dialog-description"></span>
[Editor] Add a new dialog for alt-text settings (bug 1909604) This patch adds a new entry in the secondary menu in order to open a dialog to let the user: - disables the alt-text generation thanks to a ML model; - deletes the alt-text model downloaded in Firefox; - disabled the new alt-text flow.
2024-08-01 15:29:01 +02:00
</div>
</div>
</div>
<div id="buttons" class="dialogButtonsGroup">
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<button id="altTextSettingsCloseButton" type="button" class="primaryButton" tabindex="0"><span data-l10n-id="pdfjs-editor-alt-text-settings-close-button"></span></button>
[Editor] Add a new dialog for alt-text settings (bug 1909604) This patch adds a new entry in the secondary menu in order to open a dialog to let the user: - disables the alt-text generation thanks to a ML model; - deletes the alt-text model downloaded in Firefox; - disabled the new alt-text flow.
2024-08-01 15:29:01 +02:00
</div>
</div>
</dialog>
[Editor] Add a new dialog for the signature editor (bug 1945574)
2025-02-03 18:30:42 +01:00
[Editor] Add the possibility to change a signature description (bug 1948116)
2025-02-13 21:15:27 +01:00
<dialog class="dialog signatureDialog" id="addSignatureDialog" aria-labelledby="addSignatureDialogLabel">
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<span id="addSignatureDialogLabel" data-l10n-id="pdfjs-editor-add-signature-dialog-label"></span>
[Editor] Add a new dialog for the signature editor (bug 1945574)
2025-02-03 18:30:42 +01:00
<div id="addSignatureContainer" class="mainContainer">
<div class="title">
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<span role="sectionhead" data-l10n-id="pdfjs-editor-add-signature-dialog-title" tabindex="0"></span>
[Editor] Add a new dialog for the signature editor (bug 1945574)
2025-02-03 18:30:42 +01:00
</div>
<div role="tablist" id="addSignatureOptions">
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<button id="addSignatureTypeButton" type="button" role="tab" aria-selected="true" aria-controls="addSignatureTypeContainer" data-l10n-id="pdfjs-editor-add-signature-type-button" tabindex="0"></button>
<button id="addSignatureDrawButton" type="button" role="tab" aria-selected="false" aria-controls="addSignatureDrawContainer" data-l10n-id="pdfjs-editor-add-signature-draw-button" tabindex="0"></button>
<button id="addSignatureImageButton" type="button" role="tab" aria-selected="false" aria-controls="addSignatureImageContainer" data-l10n-id="pdfjs-editor-add-signature-image-button" tabindex="-1"></button>
[Editor] Add a new dialog for the signature editor (bug 1945574)
2025-02-03 18:30:42 +01:00
</div>
<div id="addSignatureActionContainer" data-selected="type">
<div id="addSignatureTypeContainer" role="tabpanel" aria-labelledby="addSignatureTypeContainer">
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<input id="addSignatureTypeInput" type="text" data-l10n-id="pdfjs-editor-add-signature-type-input" tabindex="0"></input>
[Editor] Add a new dialog for the signature editor (bug 1945574)
2025-02-03 18:30:42 +01:00
</div>
<div id="addSignatureDrawContainer" role="tabpanel" aria-labelledby="addSignatureDrawButton" tabindex="-1">
<svg id="addSignatureDraw" xmlns="http://www.w3.org/2000/svg" aria-labelledby="addSignatureDrawPlaceholder"></svg>
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<span id="addSignatureDrawPlaceholder" data-l10n-id="pdfjs-editor-add-signature-draw-placeholder"></span>
[Editor] Add a new dialog for the signature editor (bug 1945574)
2025-02-03 18:30:42 +01:00
<div id="thickness">
<div>
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<label for="addSignatureDrawThickness" data-l10n-id="pdfjs-editor-add-signature-draw-thickness-range-label"></label>
[Editor] Add a new dialog for the signature editor (bug 1945574)
2025-02-03 18:30:42 +01:00
<input type="range" id="addSignatureDrawThickness" min="1" max="5" step="1" value="1" data-l10n-id="pdfjs-editor-add-signature-draw-thickness-range" data-l10n-args='{ "thickness": 1 }' tabindex="0">
</div>
</div>
</div>
<div id="addSignatureImageContainer" role="tabpanel" aria-labelledby="addSignatureImageButton" tabindex="-1">
<svg id="addSignatureImage" xmlns="http://www.w3.org/2000/svg" aria-labelledby="addSignatureImagePlaceholder"></svg>
<div id="addSignatureImagePlaceholder">
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<span data-l10n-id="pdfjs-editor-add-signature-image-placeholder"></span>
[Editor] Add a new dialog for the signature editor (bug 1945574)
2025-02-03 18:30:42 +01:00
<label id="addSignatureImageBrowse" for="addSignatureFilePicker" tabindex="0">
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<a data-l10n-id="pdfjs-editor-add-signature-image-browse-link"></a>
[Editor] Add a new dialog for the signature editor (bug 1945574)
2025-02-03 18:30:42 +01:00
</label>
<input id="addSignatureFilePicker" type="file"></input>
</div>
</div>
[Editor] Make sure the save checkbox isn't focusable when saving is disabled (bug 1952558) And fix the the width of the warning message when the limit of signatures has been reached: in french the string is longer than the dialog's one.
2025-03-10 16:50:38 +01:00
<div id="addSignatureControls">
[Editor] Add a new dialog for the signature editor (bug 1945574)
2025-02-03 18:30:42 +01:00
<div id="horizontalContainer">
<div id="addSignatureDescriptionContainer">
Improve `addSignatureDescription`/`editSignatureDescription` handling (issue 19683) - Point the `addSignatureDescription` respectively `editSignatureDescription` labels to their actual `input`-elements (this way clicking the label will actually focus the input). - Add the event listener to the `addSignatureDescription`-input, rather than its `span`-element (this is consistent with the `editSignatureDescription` case). - Correctly check if the `addSignatureDescription`-input is empty, since we're accidentally comparing with its `span`-element. - Remove unbalanced, and likely accidentally added, `</span>` tags.
2025-03-19 11:19:47 +01:00
<label for="addSignatureDescInput" data-l10n-id="pdfjs-editor-add-signature-description-label"></label>
[Editor] Add the possibility to change a signature description (bug 1948116)
2025-02-13 21:15:27 +01:00
<span id="addSignatureDescription" class="inputWithClearButton">
Improve `addSignatureDescription`/`editSignatureDescription` handling (issue 19683) - Point the `addSignatureDescription` respectively `editSignatureDescription` labels to their actual `input`-elements (this way clicking the label will actually focus the input). - Add the event listener to the `addSignatureDescription`-input, rather than its `span`-element (this is consistent with the `editSignatureDescription` case). - Correctly check if the `addSignatureDescription`-input is empty, since we're accidentally comparing with its `span`-element. - Remove unbalanced, and likely accidentally added, `</span>` tags.
2025-03-19 11:19:47 +01:00
<input id="addSignatureDescInput" type="text" data-l10n-id="pdfjs-editor-add-signature-description-input" tabindex="0"></input>
[Editor] Add the possibility to change a signature description (bug 1948116)
2025-02-13 21:15:27 +01:00
<button class="clearInputButton" type="button" tabindex="0" aria-hidden="true"></button>
[Editor] Add a new dialog for the signature editor (bug 1945574)
2025-02-03 18:30:42 +01:00
</span>
</div>
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<button id="clearSignatureButton" type="button" data-l10n-id="pdfjs-editor-add-signature-clear-button" tabindex="0"><span data-l10n-id="pdfjs-editor-add-signature-clear-button-label"></span></button>
[Editor] Add a new dialog for the signature editor (bug 1945574)
2025-02-03 18:30:42 +01:00
</div>
<div id="addSignatureSaveContainer">
[Editor] Make sure the save checkbox isn't focusable when saving is disabled (bug 1952558) And fix the the width of the warning message when the limit of signatures has been reached: in french the string is longer than the dialog's one.
2025-03-10 16:50:38 +01:00
<input type="checkbox" id="addSignatureSaveCheckbox" checked="true"></input>
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<label for="addSignatureSaveCheckbox" data-l10n-id="pdfjs-editor-add-signature-save-checkbox"></label>
[Editor] Add a new dialog for the signature editor (bug 1945574)
2025-02-03 18:30:42 +01:00
<span></span>
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<span id="addSignatureSaveWarning" data-l10n-id="pdfjs-editor-add-signature-save-warning-message"></span>
[Editor] Add a new dialog for the signature editor (bug 1945574)
2025-02-03 18:30:42 +01:00
</div>
</div>
<div id="addSignatureError" hidden="true" class="messageBar">
<div>
<div>
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<span class="title" data-l10n-id="pdfjs-editor-add-signature-image-upload-error-title"></span>
<span class="description" data-l10n-id="pdfjs-editor-add-signature-image-upload-error-description"></span>
[Editor] Add a new dialog for the signature editor (bug 1945574)
2025-02-03 18:30:42 +01:00
</div>
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<button id="addSignatureErrorCloseButton" class="closeButton" type="button" tabindex="0"><span data-l10n-id="pdfjs-editor-add-signature-error-close-button"></span></button>
[Editor] Add a new dialog for the signature editor (bug 1945574)
2025-02-03 18:30:42 +01:00
</div>
</div>
[Editor] Add the possibility to change a signature description (bug 1948116)
2025-02-13 21:15:27 +01:00
<div class="dialogButtonsGroup">
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<button id="addSignatureCancelButton" type="button" class="secondaryButton" tabindex="0"><span data-l10n-id="pdfjs-editor-add-signature-cancel-button"></span></button>
<button id="addSignatureAddButton" type="button" class="primaryButton" disabled tabindex="0"><span data-l10n-id="pdfjs-editor-add-signature-add-button"></span></button>
[Editor] Add a new dialog for the signature editor (bug 1945574)
2025-02-03 18:30:42 +01:00
</div>
</div>
</div>
</dialog>
[Editor] Add the possibility to change a signature description (bug 1948116)
2025-02-13 21:15:27 +01:00
<dialog class="dialog signatureDialog" id="editSignatureDescriptionDialog" aria-labelledby="editSignatureDescriptionTitle">
<div id="editSignatureDescriptionContainer" class="mainContainer">
<div class="title">
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<span id="editSignatureDescriptionTitle" role="sectionhead" data-l10n-id="pdfjs-editor-edit-signature-dialog-title" tabindex="0"></span>
[Editor] Add the possibility to change a signature description (bug 1948116)
2025-02-13 21:15:27 +01:00
</div>
<div id="editSignatureDescriptionAndView">
<div id="editSignatureDescriptionContainer">
Improve `addSignatureDescription`/`editSignatureDescription` handling (issue 19683) - Point the `addSignatureDescription` respectively `editSignatureDescription` labels to their actual `input`-elements (this way clicking the label will actually focus the input). - Add the event listener to the `addSignatureDescription`-input, rather than its `span`-element (this is consistent with the `editSignatureDescription` case). - Correctly check if the `addSignatureDescription`-input is empty, since we're accidentally comparing with its `span`-element. - Remove unbalanced, and likely accidentally added, `</span>` tags.
2025-03-19 11:19:47 +01:00
<label for="editSignatureDescInput" data-l10n-id="pdfjs-editor-add-signature-description-label"></label>
[Editor] Add the possibility to change a signature description (bug 1948116)
2025-02-13 21:15:27 +01:00
<span id="editSignatureDescription" class="inputWithClearButton">
Improve `addSignatureDescription`/`editSignatureDescription` handling (issue 19683) - Point the `addSignatureDescription` respectively `editSignatureDescription` labels to their actual `input`-elements (this way clicking the label will actually focus the input). - Add the event listener to the `addSignatureDescription`-input, rather than its `span`-element (this is consistent with the `editSignatureDescription` case). - Correctly check if the `addSignatureDescription`-input is empty, since we're accidentally comparing with its `span`-element. - Remove unbalanced, and likely accidentally added, `</span>` tags.
2025-03-19 11:19:47 +01:00
<input id="editSignatureDescInput" type="text" data-l10n-id="pdfjs-editor-add-signature-description-input" tabindex="0"></input>
[Editor] Add the possibility to change a signature description (bug 1948116)
2025-02-13 21:15:27 +01:00
<button class="clearInputButton" type="button" tabindex="0" aria-hidden="true"></button>
</span>
</div>
<svg id="editSignatureView" xmlns="http://www.w3.org/2000/svg"></svg>
</div>
<div class="dialogButtonsGroup">
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<button id="editSignatureCancelButton" type="button" class="secondaryButton" tabindex="0"><span data-l10n-id="pdfjs-editor-add-signature-cancel-button"></span></button>
<button id="editSignatureUpdateButton" type="button" class="primaryButton" disabled tabindex="0"><span data-l10n-id="pdfjs-editor-edit-signature-update-button"></span></button>
[Editor] Add the possibility to change a signature description (bug 1948116)
2025-02-13 21:15:27 +01: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 13:57:31 +01:00
<!--#if !MOZCENTRAL-->
Try to improve a11y for the `PasswordPrompt` and `PDFDocumentProperties` dialogs This will hopefully improve the a11y a little bit in these dialogs, however there's most definately more things that can be done here (by someone more knowledgeable about a11y).
2022-03-25 14:10:28 +01:00
<dialog id="printServiceDialog" style="min-width: 200px;">
Convert the existing overlays to use `<dialog>` elements (issue 14698) This replaces our *custom* overlays with standard `<dialog>` DOM elements, see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog, thus simplifying the related CSS, HTML, and JavaScript code. With these changes, some of the functionality of the `OverlayManager` class is now handled natively (e.g. `Esc` to close the dialog). However, since we still need to be able to prevent dialogs from overlaying one another, it still makes sense to keep this functionality (as far as I'm concerned).
2022-03-25 14:10:13 +01:00
<div class="row">
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<span data-l10n-id="pdfjs-print-progress-message"></span>
Removes mozPrintCallback polyfill, converts canvas to PNG.
2016-10-08 07:36:55 -05:00
</div>
Convert the existing overlays to use `<dialog>` elements (issue 14698) This replaces our *custom* overlays with standard `<dialog>` DOM elements, see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog, thus simplifying the related CSS, HTML, and JavaScript code. With these changes, some of the functionality of the `OverlayManager` class is now handled natively (e.g. `Esc` to close the dialog). However, since we still need to be able to prevent dialogs from overlaying one another, it still makes sense to keep this functionality (as far as I'm concerned).
2022-03-25 14:10:13 +01:00
<div class="row">
<progress value="0" max="100"></progress>
[api-minor] Move to Fluent for the localization (bug 1858715) - For the generic viewer we use @fluent/dom and @fluent/bundle - For the builtin pdf viewer in Firefox, we set a localization url and then we rely on document.l10n which is a DOMLocalization object.
2023-10-13 16:23:17 +02:00
<span data-l10n-id="pdfjs-print-progress-percent" data-l10n-args='{ "progress": 0 }' class="relative-progress">0%</span>
Convert the existing overlays to use `<dialog>` elements (issue 14698) This replaces our *custom* overlays with standard `<dialog>` DOM elements, see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog, thus simplifying the related CSS, HTML, and JavaScript code. With these changes, some of the functionality of the `OverlayManager` class is now handled natively (e.g. `Esc` to close the dialog). However, since we still need to be able to prevent dialogs from overlaying one another, it still makes sense to keep this functionality (as far as I'm concerned).
2022-03-25 14:10:13 +01:00
</div>
<div class="buttonRow">
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<button id="printCancel" class="dialogButton" type="button"><span data-l10n-id="pdfjs-print-progress-close-button"></span></button>
Convert the existing overlays to use `<dialog>` elements (issue 14698) This replaces our *custom* overlays with standard `<dialog>` DOM elements, see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog, thus simplifying the related CSS, HTML, and JavaScript code. With these changes, some of the functionality of the `OverlayManager` class is now handled natively (e.g. `Esc` to close the dialog). However, since we still need to be able to prevent dialogs from overlaying one another, it still makes sense to keep this functionality (as far as I'm concerned).
2022-03-25 14:10:13 +01:00
</div>
</dialog>
Removes mozPrintCallback polyfill, converts canvas to PNG.
2016-10-08 07:36:55 -05:00
<!--#endif-->
Teach users how to enable access to local files.
2015-07-18 17:11:33 +02:00
<!--#if CHROME-->
<!--#include viewer-snippet-chrome-overlays.html-->
<!--#endif-->
Convert the existing overlays to use `<dialog>` elements (issue 14698) This replaces our *custom* overlays with standard `<dialog>` DOM elements, see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog, thus simplifying the related CSS, HTML, and JavaScript code. With these changes, some of the functionality of the `OverlayManager` class is now handled natively (e.g. `Esc` to close the dialog). However, since we still need to be able to prevent dialogs from overlaying one another, it still makes sense to keep this functionality (as far as I'm concerned).
2022-03-25 14:10:13 +01:00
</div> <!-- dialogContainer -->
Improved password prompt
2013-09-24 17:46:54 +02:00
Pop open a message when user deletes an annotation When a user deletes any number of annotations, they are notified of the action by a popup message with an undo button. Besides that, this change reuses the existing messageBar CSS class from the new alt-text dialog as much as possible.
2024-10-22 13:23:47 +05:30
<div id="editorUndoBar" class="messageBar" role="status" aria-labelledby="editorUndoBarMessage" tabindex="-1" hidden>
<div>
<div>
<span id="editorUndoBarMessage" class="description"></span>
</div>
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<button id="editorUndoBarUndoButton" class="undoButton" type="button" tabindex="0" data-l10n-id="pdfjs-editor-undo-bar-undo-button">
<span data-l10n-id="pdfjs-editor-undo-bar-undo-button-label"></span>
Pop open a message when user deletes an annotation When a user deletes any number of annotations, they are notified of the action by a popup message with an undo button. Besides that, this change reuses the existing messageBar CSS class from the new alt-text dialog as much as possible.
2024-10-22 13:23:47 +05:30
</button>
Remove all the translatable strings from the html
2025-03-13 17:19:40 +01:00
<button id="editorUndoBarCloseButton" class="closeButton" type="button" tabindex="0" data-l10n-id="pdfjs-editor-undo-bar-close-button">
<span data-l10n-id="pdfjs-editor-undo-bar-close-button-label"></span>
Pop open a message when user deletes an annotation When a user deletes any number of annotations, they are notified of the action by a popup message with an undo button. Besides that, this change reuses the existing messageBar CSS class from the new alt-text dialog as much as possible.
2024-10-22 13:23:47 +05:30
</button>
</div>
</div> <!-- editorUndoBar -->
text selection OK, switch outline OK
2012-04-12 16:29:15 -07:00
</div> <!-- outerContainer -->
Adds support for the new mozPrintCallback api.
2012-06-28 09:50:25 -07:00
<div id="printContainer"></div>
Separate js and css from the test.html file
2011-05-26 16:02:52 +02:00
</body>
Factor out mock tests, add browser test page, initial canvas backend
2011-05-04 19:32:59 -05:00
</html>
Copy permalink