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

419 lines
22 KiB
HTML
Raw Normal View History

Add BOM to viewer.
2013-11-23 04:10:43 +09:00
<!DOCTYPE html>
Change to the Apache v2 license.
2012-09-01 07:48:21 +09:00
<!--
Copyright 2012 Mozilla Foundation
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
Add note about adobe license.
2014-03-11 05:03:35 +09:00
Update Adobe CMaps URL and license They are now using Apache 2.0 as well.
2015-06-30 16:33:25 +09:00
Adobe CMap resources are covered by their own copyright but the same license:
Copyright 1990-2015 Adobe Systems Incorporated.
See https://github.com/adobe-type-tools/cmap-resources
Change to the Apache v2 license.
2012-09-01 07:48:21 +09:00
-->
Remove `moznomarginboxes`
2018-01-20 06:05:50 +09:00
<html dir="ltr" mozdisallowselectionprint>
first mockup, loads tracemonkey pages OK
2012-04-12 08:12:51 +09:00
<head>
Embed locale.properties in the viewer.html for extension
2012-05-01 11:55:21 +09:00
<meta charset="utf-8">
Add viewport metatag
2012-05-24 06:50:54 +09:00
<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1">
Disable Google Translate on viewer in Chrome. test/pdfs/yo01.pdf triggered "This page is in Japanese. Would you like to translate it?" info bar in Chrome.
2013-07-16 07:13:05 +09:00
<!--#if GENERIC || CHROME-->
<meta name="google" content="notranslate">
Update viewer.html for Internet Explorer Compatibility If your Internet Explorer 11 default compatibility settings are set to "I.E 7 Compatibility", the PDF plugin will not load. This fix is the same one used by AngularJS to force the browser to use HTML5 mode.
2015-07-21 20:40:07 +09:00
<!--#endif-->
<!--#if GENERIC-->
<meta http-equiv="X-UA-Compatible" content="IE=edge">
Disable Google Translate on viewer in Chrome. test/pdfs/yo01.pdf triggered "This page is in Japanese. Would you like to translate it?" info bar in Chrome.
2013-07-16 07:13:05 +09:00
<!--#endif-->
Merge branch 'master' into new-ui Conflicts: web/viewer.html web/viewer.js
2012-04-19 04:02:49 +09:00
<title>PDF.js viewer</title>
Add the new preprocessor.
2012-08-02 03:29:13 +09:00
Remove the `FIREFOX` build flag, since it's completely unused After PR 9566, which removed all of the old Firefox extension code, the `FIREFOX` build flag is no longer used for anything. It thus seems to me that it should be removed, for a couple of reasons: - It's simply dead code now, which only serves to add confusion when looking at the `PDFJSDev` calls. - It used to be that `MOZCENTRAL` and `FIREFOX` was *almost* always used together. However, ever since PR 9566 there's obviously been no effort put into keeping the `FIREFOX` build flags up to date. - In the event that a new, Webextension based, Firefox addon is created in the future you'd still need to audit all `MOZCENTRAL` (and possibly `CHROME`) build flags to see what'd make sense for the addon.
2020-01-08 21:57:31 +09:00
<!--#if MOZCENTRAL-->
Add the new preprocessor.
2012-08-02 03:29:13 +09:00
<!--#include viewer-snippet-firefox-extension.html-->
[CRX] Show nicely formatted URL in omnibox Before commit: chrome-extension://EXTENSIONID/content/web/viewer.html?file=http%3A%2F%2Fexample.com%2Ffile.pdf After commit: chrome-extension://EXTENSIONID/http://example/file.pdf Technical details: - The extension's background page uses the webRequest API to intercept requests for <extension host>/<real path to pdf>, and redirect it to the viewer's URL. - viewer.js uses history.replaceState to rewrite the URL, so that it's easier for users to recognize and copy-paste URLs. - The fake paths /http:, /https:, /file:, etc. have been added to the web_accessible_resources section of the manifest file, in order to avoid seeing chrome-extension://invalid/ instead of the actual URL when using history back/forward to navigate from/to the PDF viewer. - Since the relative path resolving doesn't work because relative URLs are inaccurate, a <base> tag has been added. This method has already been proven to work in the Firefox add-on. Notes: - This commit has been cherry-picked from crx-using-streams-api. - Need to merge https://github.com/mozilla/pdf.js/pull/3582 to deal with a bug in Chrome <=30 - In Chrome, getting the contents of a FTP file is not possible, so there's no support for FTP files, even though the extension router recognizes the ftp: scheme.
2013-08-16 05:47:30 +09:00
<!--#endif-->
<!--#if CHROME-->
<!--#include viewer-snippet-chrome-extension.html-->
Add the new preprocessor.
2012-08-02 03:29:13 +09:00
<!--#endif-->
first mockup, loads tracemonkey pages OK
2012-04-12 08:12:51 +09:00
Remove XHTML leftovers from the viewer HTML files
2016-02-14 21:23:34 +09:00
<link rel="stylesheet" href="viewer.css">
Add the new preprocessor.
2012-08-02 03:29:13 +09:00
<!--#if !PRODUCTION-->
Remove XHTML leftovers from the viewer HTML files
2016-02-14 21:23:34 +09:00
<link rel="resource" type="application/l10n" href="locale/locale.properties">
Add the new preprocessor.
2012-08-02 03:29:13 +09:00
<!--#endif-->
<!--#if !PRODUCTION-->
Replaces RequireJS to SystemJS.
2017-02-10 00:53:52 +09:00
<script src="../node_modules/systemjs/dist/system.js"></script>
<script src="../systemjs.config.js"></script>
Add the new preprocessor.
2012-08-02 03:29:13 +09:00
<!--#endif-->
Adds make minified command
2014-01-18 01:50:54 +09:00
<!--#if (GENERIC && !MINIFIED) -->
Add the new preprocessor.
2012-08-02 03:29:13 +09:00
<!--#include viewer-snippet.html-->
<!--#endif-->
Adds make minified command
2014-01-18 01:50:54 +09:00
<!--#if !MINIFIED -->
Remove type="text/javascript" from script tags. "text/javascript" is not a correct MIME type (the correct one is "application/javascript") but it's not even needed; all browsers default to the correct type and treat it as executable JS when type is ommited. Since not all browsers recognize the "application/javascript" MIME type the only way to both stay compliant and to support all popular browsers is to omit the type. It's also shorter this way.
2014-05-13 09:41:01 +09:00
<script src="viewer.js"></script>
Adds make minified command
2014-01-18 01:50:54 +09:00
<!--#else-->
<!--#include viewer-snippet-minified.html-->
<!--#endif-->
pr #3356 squashing commits.
2013-06-19 01:05:55 +09:00
first mockup, loads tracemonkey pages OK
2012-04-12 08:12:51 +09:00
</head>
Separate js and css from the test.html file
2011-05-26 23:02:52 +09:00
Small refactoring of the loadingBar hiding code
2014-08-17 07:22:05 +09:00
<body tabindex="1" class="loadingInProgress">
<div id="outerContainer">
Unify the multi_page_viewer and the basic viewer
2011-07-29 02:48:05 +09:00
Move sidebar open class.
2012-04-26 05:46:17 +09:00
<div id="sidebarContainer">
Minor css tweaks for small viewer and aligning borders.
2012-10-30 06:35:07 +09:00
<div id="toolbarSidebar">
<div class="splitToolbarButton toggled">
Remove unnecessary `.toolbarButton.group` CSS class I noticed that we have a `.toolbarButton.group` CSS class, which is currently applied to some buttons in the viewer. Since it attempts to adjust the `margin-right` property, I was initially a bit puzzled as to why there wasn't different rules for LTR/RTL locales. However, checking the viewer with the DevTools inspector, in both LTR and RTL locales, I quickly found that the rule in question is *always* being overridden by other CSS rules. It thus seem to me that while this rule was probably useful at some point, it has been dead for years and could now be removed.
2017-03-10 21:34:49 +09:00
<button id="viewThumbnail" class="toolbarButton toggled" title="Show Thumbnails" tabindex="2" data-l10n-id="thumbs">
Minor css tweaks for small viewer and aligning borders.
2012-10-30 06:35:07 +09:00
<span data-l10n-id="thumbs_label">Thumbnails</span>
</button>
Remove unnecessary `.toolbarButton.group` CSS class I noticed that we have a `.toolbarButton.group` CSS class, which is currently applied to some buttons in the viewer. Since it attempts to adjust the `margin-right` property, I was initially a bit puzzled as to why there wasn't different rules for LTR/RTL locales. However, checking the viewer with the DevTools inspector, in both LTR and RTL locales, I quickly found that the rule in question is *always* being overridden by other CSS rules. It thus seem to me that while this rule was probably useful at some point, it has been dead for years and could now be removed.
2017-03-10 21:34:49 +09:00
<button id="viewOutline" class="toolbarButton" title="Show Document Outline (double-click to expand/collapse all items)" tabindex="3" data-l10n-id="document_outline">
Explain double-click behaviour on tool tip The outline toggle button has a feature where it can be double-clicked to expand/collapse all items shown therein. Although this is described in the FAQ, can go potentially unnoticed. This, however, being a useful feature, advertise on the tool tip itself. l10n translation for en-US and IDs updated. Signed-off-by: Jeenu Viswambharan <jeenuv@gmail.com>
2016-10-13 17:55:58 +09:00
<span data-l10n-id="document_outline_label">Document Outline</span>
Minor css tweaks for small viewer and aligning borders.
2012-10-30 06:35:07 +09:00
</button>
Remove unnecessary `.toolbarButton.group` CSS class I noticed that we have a `.toolbarButton.group` CSS class, which is currently applied to some buttons in the viewer. Since it attempts to adjust the `margin-right` property, I was initially a bit puzzled as to why there wasn't different rules for LTR/RTL locales. However, checking the viewer with the DevTools inspector, in both LTR and RTL locales, I quickly found that the rule in question is *always* being overridden by other CSS rules. It thus seem to me that while this rule was probably useful at some point, it has been dead for years and could now be removed.
2017-03-10 21:34:49 +09:00
<button id="viewAttachments" class="toolbarButton" title="Show Attachments" tabindex="4" data-l10n-id="attachments">
Preliminary attachments support Added a partial Filespec support Added getAttachments in API Added a new attachments view in UI (with a new icon by @shorlander)
2014-03-19 05:32:47 +09:00
<span data-l10n-id="attachments_label">Attachments</span>
</button>
Minor css tweaks for small viewer and aligning borders.
2012-10-30 06:35:07 +09:00
</div>
Unify the multi_page_viewer and the basic viewer
2011-07-29 02:48:05 +09:00
</div>
Remove flex box. Add side animation. Add dashed line around unload thumbnails.
2012-04-26 03:34:28 +09:00
<div id="sidebarContent">
<div id="thumbnailView">
first mockup, loads tracemonkey pages OK
2012-04-12 08:12:51 +09:00
</div>
Remove flex box. Add side animation. Add dashed line around unload thumbnails.
2012-04-26 03:34:28 +09:00
<div id="outlineView" class="hidden">
first mockup, loads tracemonkey pages OK
2012-04-12 08:12:51 +09:00
</div>
Preliminary attachments support Added a partial Filespec support Added getAttachments in API Added a new attachments view in UI (with a new icon by @shorlander)
2014-03-19 05:32:47 +09:00
<div id="attachmentsView" class="hidden">
</div>
Switching to the document outline view if the document structure is present
2011-08-22 11:05:10 +09:00
</div>
Implement sidebar resizing for modern browsers, by utilizing CSS variables (issue 2072) By making use of modern CSS features, in this case [CSS variables](https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_variables), implementing sidebar resizing is actually quite simple. Not only will the amount of added code be fairly small, but it should also be easy to maintain since there's no need for complicated JavaScript hacks in order to update the CSS. Another benefit is that the JavaScript code doesn't need to make detailed assumptions about the exact structure of the HTML/CSS code. Obviously this will not work in older browsers, such as IE, that lack support for CSS variables. In those cases sidebar resizing is simply disabled (via feature detection), and the resizing DOM element hidden, and the behaviour is thus *identical* to the current (fixed-width) sidebar. However, considering the simplicity of the implementation, I really don't see why limiting this feature to "modern" browsers is a problem. Finally, note that a few edge-cases meant that the patch is a bit larger than what the basic functionality would dictate. Among those is first of all proper RTL support, and secondly (automatic) resizing of the sidebar when the width of the *entire* viewer changes. Another, pre-existing, issue fixed here is the incomplete interface of `NullL10n`. *Please note:* This patch has been successfully tested in both LTR and RTL viewer locales, in recent versions of Firefox and Chrome. Fixes 2072.
2017-10-10 23:16:05 +09:00
<div id="sidebarResizer" class="hidden"></div>
Remove flex box. Add side animation. Add dashed line around unload thumbnails.
2012-04-26 03:34:28 +09:00
</div> <!-- sidebarContainer -->
<div id="mainContainer">
Viewer: enable find functionality for small devices The find functionality is currently not available for small devices because the find dialog is not responsive. This patch fixes that. To achieve this goal, the HTML is changed to always show the find button. To prevent issues because of the addition of an extra button for small views, the previous/next page buttons are hidden if the view becomes small. These buttons are not useful anyway because on small devices navigation is usually done via scrolling. The find functionality is much more useful to have in this case. Moreover, we wrap the existing elements into separate `div`s so that the browser can position the elements itself when the view becomes smaller and logically connected elements stay together when this happens. In the CSS, extra rules for the find bar have been added to ensure that the dialog's doorhanger is always below the find button. All findbar `div`s are forced to be 32 pixels high to prevent the find message text being aligned under the checkboxes. Finally, the find message is only visible when there is actually text to display. This prevents wrapping issues because, by default, the label has padding and margin even if there is no text.
2017-03-09 07:54:28 +09:00
<div class="findbar hidden doorHanger" id="findbar">
<div id="findbarInputContainer">
Add (and adjust) a couple of findbar `title` attributes, in `viewer.html`, that doesn't agree with the `l10n/en-US/viewer.properties` file The point of this patch is to fix a couple of inconsistencies in `viewer.html`, compared to the locale files, such that the viewer would work correctly even without the `l10n/` files present. *Note:* Since this isn't changing any of the locale files, we should *not* need to update any of the string names. Looking through the history of the findbar code, it seems that the `findPrevious`/`findNext` buttons have never had a `title` set (note PR 2168, which was the initial findbar implementation). Furthermore, the `placeholder` of the `findInput` didn't agree 100% with locale file either, so this is also adjusted.
2017-03-12 17:42:20 +09:00
<input id="findInput" class="toolbarField" title="Find" placeholder="Find in document…" tabindex="91" data-l10n-id="find_input">
Viewer: enable find functionality for small devices The find functionality is currently not available for small devices because the find dialog is not responsive. This patch fixes that. To achieve this goal, the HTML is changed to always show the find button. To prevent issues because of the addition of an extra button for small views, the previous/next page buttons are hidden if the view becomes small. These buttons are not useful anyway because on small devices navigation is usually done via scrolling. The find functionality is much more useful to have in this case. Moreover, we wrap the existing elements into separate `div`s so that the browser can position the elements itself when the view becomes smaller and logically connected elements stay together when this happens. In the CSS, extra rules for the find bar have been added to ensure that the dialog's doorhanger is always below the find button. All findbar `div`s are forced to be 32 pixels high to prevent the find message text being aligned under the checkboxes. Finally, the find message is only visible when there is actually text to display. This prevents wrapping issues because, by default, the label has padding and margin even if there is no text.
2017-03-09 07:54:28 +09:00
<div class="splitToolbarButton">
Add (and adjust) a couple of findbar `title` attributes, in `viewer.html`, that doesn't agree with the `l10n/en-US/viewer.properties` file The point of this patch is to fix a couple of inconsistencies in `viewer.html`, compared to the locale files, such that the viewer would work correctly even without the `l10n/` files present. *Note:* Since this isn't changing any of the locale files, we should *not* need to update any of the string names. Looking through the history of the findbar code, it seems that the `findPrevious`/`findNext` buttons have never had a `title` set (note PR 2168, which was the initial findbar implementation). Furthermore, the `placeholder` of the `findInput` didn't agree 100% with locale file either, so this is also adjusted.
2017-03-12 17:42:20 +09:00
<button id="findPrevious" class="toolbarButton findPrevious" title="Find the previous occurrence of the phrase" tabindex="92" data-l10n-id="find_previous">
Viewer: enable find functionality for small devices The find functionality is currently not available for small devices because the find dialog is not responsive. This patch fixes that. To achieve this goal, the HTML is changed to always show the find button. To prevent issues because of the addition of an extra button for small views, the previous/next page buttons are hidden if the view becomes small. These buttons are not useful anyway because on small devices navigation is usually done via scrolling. The find functionality is much more useful to have in this case. Moreover, we wrap the existing elements into separate `div`s so that the browser can position the elements itself when the view becomes smaller and logically connected elements stay together when this happens. In the CSS, extra rules for the find bar have been added to ensure that the dialog's doorhanger is always below the find button. All findbar `div`s are forced to be 32 pixels high to prevent the find message text being aligned under the checkboxes. Finally, the find message is only visible when there is actually text to display. This prevents wrapping issues because, by default, the label has padding and margin even if there is no text.
2017-03-09 07:54:28 +09:00
<span data-l10n-id="find_previous_label">Previous</span>
</button>
<div class="splitToolbarButtonSeparator"></div>
Add (and adjust) a couple of findbar `title` attributes, in `viewer.html`, that doesn't agree with the `l10n/en-US/viewer.properties` file The point of this patch is to fix a couple of inconsistencies in `viewer.html`, compared to the locale files, such that the viewer would work correctly even without the `l10n/` files present. *Note:* Since this isn't changing any of the locale files, we should *not* need to update any of the string names. Looking through the history of the findbar code, it seems that the `findPrevious`/`findNext` buttons have never had a `title` set (note PR 2168, which was the initial findbar implementation). Furthermore, the `placeholder` of the `findInput` didn't agree 100% with locale file either, so this is also adjusted.
2017-03-12 17:42:20 +09:00
<button id="findNext" class="toolbarButton findNext" title="Find the next occurrence of the phrase" tabindex="93" data-l10n-id="find_next">
Viewer: enable find functionality for small devices The find functionality is currently not available for small devices because the find dialog is not responsive. This patch fixes that. To achieve this goal, the HTML is changed to always show the find button. To prevent issues because of the addition of an extra button for small views, the previous/next page buttons are hidden if the view becomes small. These buttons are not useful anyway because on small devices navigation is usually done via scrolling. The find functionality is much more useful to have in this case. Moreover, we wrap the existing elements into separate `div`s so that the browser can position the elements itself when the view becomes smaller and logically connected elements stay together when this happens. In the CSS, extra rules for the find bar have been added to ensure that the dialog's doorhanger is always below the find button. All findbar `div`s are forced to be 32 pixels high to prevent the find message text being aligned under the checkboxes. Finally, the find message is only visible when there is actually text to display. This prevents wrapping issues because, by default, the label has padding and margin even if there is no text.
2017-03-09 07:54:28 +09:00
<span data-l10n-id="find_next_label">Next</span>
</button>
</div>
</div>
Add initial support for "Whole words" searching in the viewer As outlined in https://bugzilla.mozilla.org/show_bug.cgi?id=1282759 the internal Firefox name for the feature is `entireWord`, hence that name is used here as well for consistency (with "Whole words" being limited to the UI). Given existing limitations of the PDF.js search functionality, e.g. the existing problems of searching across "new lines", there's some edge-cases where "Whole words" searching will ignore (valid) results. However, considering that this is a pre-existing issue related to the way that the find controller joins text-content together, that shouldn't have to block this new feature in my opionion. *Please note:* In order to enable this feature in the `MOZCENTRAL` version, a small follow-up patch for [PdfjsChromeUtils.jsm](https://hg.mozilla.org/mozilla-central/file/tip/browser/extensions/pdfjs/content/PdfjsChromeUtils.jsm) will be required once this has landed in `mozilla-central`.
2018-09-01 08:28:19 +09:00
<div id="findbarOptionsOneContainer">
Viewer: enable find functionality for small devices The find functionality is currently not available for small devices because the find dialog is not responsive. This patch fixes that. To achieve this goal, the HTML is changed to always show the find button. To prevent issues because of the addition of an extra button for small views, the previous/next page buttons are hidden if the view becomes small. These buttons are not useful anyway because on small devices navigation is usually done via scrolling. The find functionality is much more useful to have in this case. Moreover, we wrap the existing elements into separate `div`s so that the browser can position the elements itself when the view becomes smaller and logically connected elements stay together when this happens. In the CSS, extra rules for the find bar have been added to ensure that the dialog's doorhanger is always below the find button. All findbar `div`s are forced to be 32 pixels high to prevent the find message text being aligned under the checkboxes. Finally, the find message is only visible when there is actually text to display. This prevents wrapping issues because, by default, the label has padding and margin even if there is no text.
2017-03-09 07:54:28 +09:00
<input type="checkbox" id="findHighlightAll" class="toolbarField" tabindex="94">
<label for="findHighlightAll" class="toolbarLabel" data-l10n-id="find_highlight">Highlight all</label>
<input type="checkbox" id="findMatchCase" class="toolbarField" tabindex="95">
<label for="findMatchCase" class="toolbarLabel" data-l10n-id="find_match_case_label">Match case</label>
</div>
Add initial support for "Whole words" searching in the viewer As outlined in https://bugzilla.mozilla.org/show_bug.cgi?id=1282759 the internal Firefox name for the feature is `entireWord`, hence that name is used here as well for consistency (with "Whole words" being limited to the UI). Given existing limitations of the PDF.js search functionality, e.g. the existing problems of searching across "new lines", there's some edge-cases where "Whole words" searching will ignore (valid) results. However, considering that this is a pre-existing issue related to the way that the find controller joins text-content together, that shouldn't have to block this new feature in my opionion. *Please note:* In order to enable this feature in the `MOZCENTRAL` version, a small follow-up patch for [PdfjsChromeUtils.jsm](https://hg.mozilla.org/mozilla-central/file/tip/browser/extensions/pdfjs/content/PdfjsChromeUtils.jsm) will be required once this has landed in `mozilla-central`.
2018-09-01 08:28:19 +09:00
<div id="findbarOptionsTwoContainer">
<input type="checkbox" id="findEntireWord" class="toolbarField" tabindex="96">
<label for="findEntireWord" class="toolbarLabel" data-l10n-id="find_entire_word_label">Whole words</label>
<span id="findResultsCount" class="toolbarLabel hidden"></span>
</div>
Viewer: enable find functionality for small devices The find functionality is currently not available for small devices because the find dialog is not responsive. This patch fixes that. To achieve this goal, the HTML is changed to always show the find button. To prevent issues because of the addition of an extra button for small views, the previous/next page buttons are hidden if the view becomes small. These buttons are not useful anyway because on small devices navigation is usually done via scrolling. The find functionality is much more useful to have in this case. Moreover, we wrap the existing elements into separate `div`s so that the browser can position the elements itself when the view becomes smaller and logically connected elements stay together when this happens. In the CSS, extra rules for the find bar have been added to ensure that the dialog's doorhanger is always below the find button. All findbar `div`s are forced to be 32 pixels high to prevent the find message text being aligned under the checkboxes. Finally, the find message is only visible when there is actually text to display. This prevents wrapping issues because, by default, the label has padding and margin even if there is no text.
2017-03-09 07:54:28 +09:00
<div id="findbarMessageContainer">
<span id="findMsg" class="toolbarLabel"></span>
Add pilot find next/prev icons; localization
2012-10-06 09:15:06 +09:00
</div>
Secondary toolbar
2013-09-05 06:48:31 +09:00
</div> <!-- findbar -->
<div id="secondaryToolbar" class="secondaryToolbar hidden doorHangerRight">
<div id="secondaryToolbarButtonContainer">
Adjust the tabindices in the viewer The current way that the tabindices are defined, has the unfortunate consequence that adding a single button to the UI might mean having to change almost all tabindices. (This was the case in e.g. PR 4329.) This patch attempts to avoid that situation happening again, by re-defining the tabindices slightly.
2014-07-19 19:16:44 +09:00
<button id="secondaryPresentationMode" class="secondaryToolbarButton presentationMode visibleLargeView" title="Switch to Presentation Mode" tabindex="51" data-l10n-id="presentation_mode">
Secondary toolbar
2013-09-05 06:48:31 +09:00
<span data-l10n-id="presentation_mode_label">Presentation Mode</span>
</button>
Adjust the tabindices in the viewer The current way that the tabindices are defined, has the unfortunate consequence that adding a single button to the UI might mean having to change almost all tabindices. (This was the case in e.g. PR 4329.) This patch attempts to avoid that situation happening again, by re-defining the tabindices slightly.
2014-07-19 19:16:44 +09:00
<button id="secondaryOpenFile" class="secondaryToolbarButton openFile visibleLargeView" title="Open File" tabindex="52" data-l10n-id="open_file">
Secondary toolbar
2013-09-05 06:48:31 +09:00
<span data-l10n-id="open_file_label">Open</span>
</button>
Adjust the tabindices in the viewer The current way that the tabindices are defined, has the unfortunate consequence that adding a single button to the UI might mean having to change almost all tabindices. (This was the case in e.g. PR 4329.) This patch attempts to avoid that situation happening again, by re-defining the tabindices slightly.
2014-07-19 19:16:44 +09:00
<button id="secondaryPrint" class="secondaryToolbarButton print visibleMediumView" title="Print" tabindex="53" data-l10n-id="print">
Secondary toolbar
2013-09-05 06:48:31 +09:00
<span data-l10n-id="print_label">Print</span>
</button>
Adjust the tabindices in the viewer The current way that the tabindices are defined, has the unfortunate consequence that adding a single button to the UI might mean having to change almost all tabindices. (This was the case in e.g. PR 4329.) This patch attempts to avoid that situation happening again, by re-defining the tabindices slightly.
2014-07-19 19:16:44 +09:00
<button id="secondaryDownload" class="secondaryToolbarButton download visibleMediumView" title="Download" tabindex="54" data-l10n-id="download">
Secondary toolbar
2013-09-05 06:48:31 +09:00
<span data-l10n-id="download_label">Download</span>
</button>
Adjust the tabindices in the viewer The current way that the tabindices are defined, has the unfortunate consequence that adding a single button to the UI might mean having to change almost all tabindices. (This was the case in e.g. PR 4329.) This patch attempts to avoid that situation happening again, by re-defining the tabindices slightly.
2014-07-19 19:16:44 +09:00
<a href="#" id="secondaryViewBookmark" class="secondaryToolbarButton bookmark visibleSmallView" title="Current view (copy or open in new window)" tabindex="55" data-l10n-id="bookmark">
Add the viewBookmark button to the secondary toolbar
2013-09-27 18:44:45 +09:00
<span data-l10n-id="bookmark_label">Current View</span>
</a>
Secondary toolbar
2013-09-05 06:48:31 +09:00
<div class="horizontalToolbarSeparator visibleLargeView"></div>
Adjust the tabindices in the viewer The current way that the tabindices are defined, has the unfortunate consequence that adding a single button to the UI might mean having to change almost all tabindices. (This was the case in e.g. PR 4329.) This patch attempts to avoid that situation happening again, by re-defining the tabindices slightly.
2014-07-19 19:16:44 +09:00
<button id="firstPage" class="secondaryToolbarButton firstPage" title="Go to First Page" tabindex="56" data-l10n-id="first_page">
Secondary toolbar
2013-09-05 06:48:31 +09:00
<span data-l10n-id="first_page_label">Go to First Page</span>
</button>
Adjust the tabindices in the viewer The current way that the tabindices are defined, has the unfortunate consequence that adding a single button to the UI might mean having to change almost all tabindices. (This was the case in e.g. PR 4329.) This patch attempts to avoid that situation happening again, by re-defining the tabindices slightly.
2014-07-19 19:16:44 +09:00
<button id="lastPage" class="secondaryToolbarButton lastPage" title="Go to Last Page" tabindex="57" data-l10n-id="last_page">
Secondary toolbar
2013-09-05 06:48:31 +09:00
<span data-l10n-id="last_page_label">Go to Last Page</span>
</button>
<div class="horizontalToolbarSeparator"></div>
Adjust the tabindices in the viewer The current way that the tabindices are defined, has the unfortunate consequence that adding a single button to the UI might mean having to change almost all tabindices. (This was the case in e.g. PR 4329.) This patch attempts to avoid that situation happening again, by re-defining the tabindices slightly.
2014-07-19 19:16:44 +09:00
<button id="pageRotateCw" class="secondaryToolbarButton rotateCw" title="Rotate Clockwise" tabindex="58" data-l10n-id="page_rotate_cw">
Secondary toolbar
2013-09-05 06:48:31 +09:00
<span data-l10n-id="page_rotate_cw_label">Rotate Clockwise</span>
</button>
Adjust the tabindices in the viewer The current way that the tabindices are defined, has the unfortunate consequence that adding a single button to the UI might mean having to change almost all tabindices. (This was the case in e.g. PR 4329.) This patch attempts to avoid that situation happening again, by re-defining the tabindices slightly.
2014-07-19 19:16:44 +09:00
<button id="pageRotateCcw" class="secondaryToolbarButton rotateCcw" title="Rotate Counterclockwise" tabindex="59" data-l10n-id="page_rotate_ccw">
Secondary toolbar
2013-09-05 06:48:31 +09:00
<span data-l10n-id="page_rotate_ccw_label">Rotate Counterclockwise</span>
</button>
Implement hand tool The logic for the hand tool is implemented in a separate project, maintained at https://github.com/Rob--W/grab-to-pan.js Integration notes - Added toggle as an entry under the Secondary toolbar - Added shortcut "h" to toggle hand tool (to-do: document this in wiki after merge). This shortcut is also used in Adobe's Acrobat Reader. To-do: localizations for: hand_tool_enable.title= hand_tool_enable_label= hand_tool_disable.title= hand_tool_disable_label= To-do (wish): persistence of hand tool preference, preferably a global setting. secondaryToolbarButton-handTool.png created by Stephen Horlander <shorlander@mozilla.com>
2013-10-03 05:09:43 +09:00
<div class="horizontalToolbarSeparator"></div>
Unify handling of various cursor tools, e.g. the current Hand Tool and a possible future Zoom Tool, in a new `PDFCursorTools` module With the current way that the `HandTool` is implemented, if someone would try to also add a Zoom tool (as issue 1260 asks for) that probably wouldn't work very well given that you'd then have two cursor tools which may not play nice together. Hence this patch, which attempts to refactor things so that it should be simpler to add e.g. a Zoom tool as well (given that that issue is marked as "good-beginner-bug", and I'm not sure if that really applies considering the current state of the code). Note that I personally have no interest in implementing a Zoom tool (similar to Adobe Reader) since I wouldn't use it, but I figured that it can't hurt to make this code a bit more future proof.
2016-09-07 20:30:26 +09:00
<button id="cursorSelectTool" class="secondaryToolbarButton selectTool toggled" title="Enable Text Selection Tool" tabindex="60" data-l10n-id="cursor_text_select_tool">
<span data-l10n-id="cursor_text_select_tool_label">Text Selection Tool</span>
</button>
<button id="cursorHandTool" class="secondaryToolbarButton handTool" title="Enable Hand Tool" tabindex="61" data-l10n-id="cursor_hand_tool">
<span data-l10n-id="cursor_hand_tool_label">Hand Tool</span>
Implement hand tool The logic for the hand tool is implemented in a separate project, maintained at https://github.com/Rob--W/grab-to-pan.js Integration notes - Added toggle as an entry under the Secondary toolbar - Added shortcut "h" to toggle hand tool (to-do: document this in wiki after merge). This shortcut is also used in Adobe's Acrobat Reader. To-do: localizations for: hand_tool_enable.title= hand_tool_enable_label= hand_tool_disable.title= hand_tool_disable_label= To-do (wish): persistence of hand tool preference, preferably a global setting. secondaryToolbarButton-handTool.png created by Stephen Horlander <shorlander@mozilla.com>
2013-10-03 05:09:43 +09:00
</button>
cleaned whitespace
2015-02-03 00:12:52 +09:00
Document properties
2014-01-22 08:07:07 +09:00
<div class="horizontalToolbarSeparator"></div>
Hide the Scroll/Spread mode buttons when the viewer is a `PDFSinglePageViewer` instance If the current viewer is a `PDFSinglePageViewer` instance the Scroll/Spread modes are no-ops, hence displaying buttons that do *nothing* when clicked will probably do very little besides confuse users.
2018-07-08 17:56:01 +09:00
<button id="scrollVertical" class="secondaryToolbarButton scrollModeButtons scrollVertical toggled" title="Use Vertical Scrolling" tabindex="62" data-l10n-id="scroll_vertical">
Add scrolling modes to web viewer In addition to the default scrolling mode (vertical), this commit adds horizontal and wrapped scrolling, implemented primarily with CSS.
2018-05-15 12:10:32 +09:00
<span data-l10n-id="scroll_vertical_label">Vertical Scrolling</span>
</button>
Hide the Scroll/Spread mode buttons when the viewer is a `PDFSinglePageViewer` instance If the current viewer is a `PDFSinglePageViewer` instance the Scroll/Spread modes are no-ops, hence displaying buttons that do *nothing* when clicked will probably do very little besides confuse users.
2018-07-08 17:56:01 +09:00
<button id="scrollHorizontal" class="secondaryToolbarButton scrollModeButtons scrollHorizontal" title="Use Horizontal Scrolling" tabindex="63" data-l10n-id="scroll_horizontal">
Add scrolling modes to web viewer In addition to the default scrolling mode (vertical), this commit adds horizontal and wrapped scrolling, implemented primarily with CSS.
2018-05-15 12:10:32 +09:00
<span data-l10n-id="scroll_horizontal_label">Horizontal Scrolling</span>
</button>
Hide the Scroll/Spread mode buttons when the viewer is a `PDFSinglePageViewer` instance If the current viewer is a `PDFSinglePageViewer` instance the Scroll/Spread modes are no-ops, hence displaying buttons that do *nothing* when clicked will probably do very little besides confuse users.
2018-07-08 17:56:01 +09:00
<button id="scrollWrapped" class="secondaryToolbarButton scrollModeButtons scrollWrapped" title="Use Wrapped Scrolling" tabindex="64" data-l10n-id="scroll_wrapped">
Add scrolling modes to web viewer In addition to the default scrolling mode (vertical), this commit adds horizontal and wrapped scrolling, implemented primarily with CSS.
2018-05-15 12:10:32 +09:00
<span data-l10n-id="scroll_wrapped_label">Wrapped Scrolling</span>
</button>
Hide the Scroll/Spread mode buttons when the viewer is a `PDFSinglePageViewer` instance If the current viewer is a `PDFSinglePageViewer` instance the Scroll/Spread modes are no-ops, hence displaying buttons that do *nothing* when clicked will probably do very little besides confuse users.
2018-07-08 17:56:01 +09:00
<div class="horizontalToolbarSeparator scrollModeButtons"></div>
Add scrolling modes to web viewer In addition to the default scrolling mode (vertical), this commit adds horizontal and wrapped scrolling, implemented primarily with CSS.
2018-05-15 12:10:32 +09:00
Hide the Scroll/Spread mode buttons when the viewer is a `PDFSinglePageViewer` instance If the current viewer is a `PDFSinglePageViewer` instance the Scroll/Spread modes are no-ops, hence displaying buttons that do *nothing* when clicked will probably do very little besides confuse users.
2018-07-08 17:56:01 +09:00
<button id="spreadNone" class="secondaryToolbarButton spreadModeButtons spreadNone toggled" title="Do not join page spreads" tabindex="65" data-l10n-id="spread_none">
Add spread modes to web viewer This builds on the scrolling mode work to add three buttons for joining page spreads together: one for the default view, with no page spreads, and two for spreads starting on odd-numbered or even-numbered pages.
2018-05-15 12:10:32 +09:00
<span data-l10n-id="spread_none_label">No Spreads</span>
</button>
Hide the Scroll/Spread mode buttons when the viewer is a `PDFSinglePageViewer` instance If the current viewer is a `PDFSinglePageViewer` instance the Scroll/Spread modes are no-ops, hence displaying buttons that do *nothing* when clicked will probably do very little besides confuse users.
2018-07-08 17:56:01 +09:00
<button id="spreadOdd" class="secondaryToolbarButton spreadModeButtons spreadOdd" title="Join page spreads starting with odd-numbered pages" tabindex="66" data-l10n-id="spread_odd">
Add spread modes to web viewer This builds on the scrolling mode work to add three buttons for joining page spreads together: one for the default view, with no page spreads, and two for spreads starting on odd-numbered or even-numbered pages.
2018-05-15 12:10:32 +09:00
<span data-l10n-id="spread_odd_label">Odd Spreads</span>
</button>
Hide the Scroll/Spread mode buttons when the viewer is a `PDFSinglePageViewer` instance If the current viewer is a `PDFSinglePageViewer` instance the Scroll/Spread modes are no-ops, hence displaying buttons that do *nothing* when clicked will probably do very little besides confuse users.
2018-07-08 17:56:01 +09:00
<button id="spreadEven" class="secondaryToolbarButton spreadModeButtons spreadEven" title="Join page spreads starting with even-numbered pages" tabindex="67" data-l10n-id="spread_even">
Add spread modes to web viewer This builds on the scrolling mode work to add three buttons for joining page spreads together: one for the default view, with no page spreads, and two for spreads starting on odd-numbered or even-numbered pages.
2018-05-15 12:10:32 +09:00
<span data-l10n-id="spread_even_label">Even Spreads</span>
</button>
Hide the Scroll/Spread mode buttons when the viewer is a `PDFSinglePageViewer` instance If the current viewer is a `PDFSinglePageViewer` instance the Scroll/Spread modes are no-ops, hence displaying buttons that do *nothing* when clicked will probably do very little besides confuse users.
2018-07-08 17:56:01 +09:00
<div class="horizontalToolbarSeparator spreadModeButtons"></div>
Add spread modes to web viewer This builds on the scrolling mode work to add three buttons for joining page spreads together: one for the default view, with no page spreads, and two for spreads starting on odd-numbered or even-numbered pages.
2018-05-15 12:10:32 +09:00
<button id="documentProperties" class="secondaryToolbarButton documentProperties" title="Document Properties…" tabindex="68" data-l10n-id="document_properties">
Miscellaneous improvements for the document properties dialog
2014-01-23 08:30:48 +09:00
<span data-l10n-id="document_properties_label">Document Properties…</span>
Document properties
2014-01-22 08:07:07 +09:00
</button>
Secondary toolbar
2013-09-05 06:48:31 +09:00
</div>
</div> <!-- secondaryToolbar -->
Remove flex box. Add side animation. Add dashed line around unload thumbnails.
2012-04-26 03:34:28 +09:00
<div class="toolbar">
<div id="toolbarContainer">
<div id="toolbarViewer">
<div id="toolbarViewerLeft">
Adjust the tabindices in the viewer The current way that the tabindices are defined, has the unfortunate consequence that adding a single button to the UI might mean having to change almost all tabindices. (This was the case in e.g. PR 4329.) This patch attempts to avoid that situation happening again, by re-defining the tabindices slightly.
2014-07-19 19:16:44 +09:00
<button id="sidebarToggle" class="toolbarButton" title="Toggle Sidebar" tabindex="11" data-l10n-id="toggle_sidebar">
Bug #767698 Slider Rename Bug #767698 Slider Rename
2013-01-31 22:14:48 +09:00
<span data-l10n-id="toggle_sidebar_label">Toggle Sidebar</span>
Addressing accessebility aspects
2012-05-04 23:51:21 +09:00
</button>
Remove flex box. Add side animation. Add dashed line around unload thumbnails.
2012-04-26 03:34:28 +09:00
<div class="toolbarButtonSpacer"></div>
Remove unnecessary `.toolbarButton.group` CSS class I noticed that we have a `.toolbarButton.group` CSS class, which is currently applied to some buttons in the viewer. Since it attempts to adjust the `margin-right` property, I was initially a bit puzzled as to why there wasn't different rules for LTR/RTL locales. However, checking the viewer with the DevTools inspector, in both LTR and RTL locales, I quickly found that the rule in question is *always* being overridden by other CSS rules. It thus seem to me that while this rule was probably useful at some point, it has been dead for years and could now be removed.
2017-03-10 21:34:49 +09:00
<button id="viewFind" class="toolbarButton" title="Find in Document" tabindex="12" data-l10n-id="findbar">
Add (and adjust) a couple of findbar `title` attributes, in `viewer.html`, that doesn't agree with the `l10n/en-US/viewer.properties` file The point of this patch is to fix a couple of inconsistencies in `viewer.html`, compared to the locale files, such that the viewer would work correctly even without the `l10n/` files present. *Note:* Since this isn't changing any of the locale files, we should *not* need to update any of the string names. Looking through the history of the findbar code, it seems that the `findPrevious`/`findNext` buttons have never had a `title` set (note PR 2168, which was the initial findbar implementation). Furthermore, the `placeholder` of the `findInput` didn't agree 100% with locale file either, so this is also adjusted.
2017-03-12 17:42:20 +09:00
<span data-l10n-id="findbar_label">Find</span>
Add some door hanger styling for the find bar
2012-09-29 04:30:07 +09:00
</button>
Viewer: enable find functionality for small devices The find functionality is currently not available for small devices because the find dialog is not responsive. This patch fixes that. To achieve this goal, the HTML is changed to always show the find button. To prevent issues because of the addition of an extra button for small views, the previous/next page buttons are hidden if the view becomes small. These buttons are not useful anyway because on small devices navigation is usually done via scrolling. The find functionality is much more useful to have in this case. Moreover, we wrap the existing elements into separate `div`s so that the browser can position the elements itself when the view becomes smaller and logically connected elements stay together when this happens. In the CSS, extra rules for the find bar have been added to ensure that the dialog's doorhanger is always below the find button. All findbar `div`s are forced to be 32 pixels high to prevent the find message text being aligned under the checkboxes. Finally, the find message is only visible when there is actually text to display. This prevents wrapping issues because, by default, the label has padding and margin even if there is no text.
2017-03-09 07:54:28 +09:00
<div class="splitToolbarButton hiddenSmallView">
Adjust the tabindices in the viewer The current way that the tabindices are defined, has the unfortunate consequence that adding a single button to the UI might mean having to change almost all tabindices. (This was the case in e.g. PR 4329.) This patch attempts to avoid that situation happening again, by re-defining the tabindices slightly.
2014-07-19 19:16:44 +09:00
<button class="toolbarButton pageUp" title="Previous Page" id="previous" tabindex="13" data-l10n-id="previous">
Merge branch 'master' of git://github.com/mozilla/pdf.js.git into l10n Conflicts: web/viewer.html
2012-05-05 03:13:29 +09:00
<span data-l10n-id="previous_label">Previous</span>
Addressing accessebility aspects
2012-05-04 23:51:21 +09:00
</button>
Remove flex box. Add side animation. Add dashed line around unload thumbnails.
2012-04-26 03:34:28 +09:00
<div class="splitToolbarButtonSeparator"></div>
Adjust the tabindices in the viewer The current way that the tabindices are defined, has the unfortunate consequence that adding a single button to the UI might mean having to change almost all tabindices. (This was the case in e.g. PR 4329.) This patch attempts to avoid that situation happening again, by re-defining the tabindices slightly.
2014-07-19 19:16:44 +09:00
<button class="toolbarButton pageDown" title="Next Page" id="next" tabindex="14" data-l10n-id="next">
Merge branch 'master' of git://github.com/mozilla/pdf.js.git into l10n Conflicts: web/viewer.html
2012-05-05 03:13:29 +09:00
<span data-l10n-id="next_label">Next</span>
Addressing accessebility aspects
2012-05-04 23:51:21 +09:00
</button>
Remove flex box. Add side animation. Add dashed line around unload thumbnails.
2012-04-26 03:34:28 +09:00
</div>
Suppress browser autofill on page number What the user did: Open the PDF Viewer in Chrome; Mouse click into the “Page number” input field; What they saw: A pop-up list with seemingly random numbers What you were expecting to see: Nothing What they see is the Chrome “Autofill” feature at work – that is suggesting values that you have previously entered into number fields in forms, as possible values you may want to enter into this field. The list has nothing to do with the PDF currently open but the user does not know this.
2020-04-16 17:49:17 +09:00
<input type="number" id="pageNumber" class="toolbarField pageNumber" title="Page" value="1" size="4" min="1" tabindex="15" data-l10n-id="page" autocomplete="off">
Remove flex box. Add side animation. Add dashed line around unload thumbnails.
2012-04-26 03:34:28 +09:00
<span id="numPages" class="toolbarLabel"></span>
</div>
<div id="toolbarViewerRight">
Adjust the tabindices in the viewer The current way that the tabindices are defined, has the unfortunate consequence that adding a single button to the UI might mean having to change almost all tabindices. (This was the case in e.g. PR 4329.) This patch attempts to avoid that situation happening again, by re-defining the tabindices slightly.
2014-07-19 19:16:44 +09:00
<button id="presentationMode" class="toolbarButton presentationMode hiddenLargeView" title="Switch to Presentation Mode" tabindex="31" data-l10n-id="presentation_mode">
Renames fullscreen to presentation mode
2012-09-21 23:35:18 +09:00
<span data-l10n-id="presentation_mode_label">Presentation Mode</span>
Correct l10n and address yury's comments
2012-07-31 00:58:34 +09:00
</button>
Initial support for Presentation Mode
2012-07-31 00:12:49 +09:00
Adjust the tabindices in the viewer The current way that the tabindices are defined, has the unfortunate consequence that adding a single button to the UI might mean having to change almost all tabindices. (This was the case in e.g. PR 4329.) This patch attempts to avoid that situation happening again, by re-defining the tabindices slightly.
2014-07-19 19:16:44 +09:00
<button id="openFile" class="toolbarButton openFile hiddenLargeView" title="Open File" tabindex="32" data-l10n-id="open_file">
Secondary toolbar
2013-09-05 06:48:31 +09:00
<span data-l10n-id="open_file_label">Open</span>
Addressing accessebility aspects
2012-05-04 23:51:21 +09:00
</button>
Fixes tab order and focus highlight
2012-05-02 01:43:48 +09:00
Adjust the tabindices in the viewer The current way that the tabindices are defined, has the unfortunate consequence that adding a single button to the UI might mean having to change almost all tabindices. (This was the case in e.g. PR 4329.) This patch attempts to avoid that situation happening again, by re-defining the tabindices slightly.
2014-07-19 19:16:44 +09:00
<button id="print" class="toolbarButton print hiddenMediumView" title="Print" tabindex="33" data-l10n-id="print">
Merge branch 'master' of git://github.com/mozilla/pdf.js.git into l10n Conflicts: web/viewer.html
2012-05-05 03:13:29 +09:00
<span data-l10n-id="print_label">Print</span>
Addressing accessebility aspects
2012-05-04 23:51:21 +09:00
</button>
Adjust the tabindices in the viewer The current way that the tabindices are defined, has the unfortunate consequence that adding a single button to the UI might mean having to change almost all tabindices. (This was the case in e.g. PR 4329.) This patch attempts to avoid that situation happening again, by re-defining the tabindices slightly.
2014-07-19 19:16:44 +09:00
<button id="download" class="toolbarButton download hiddenMediumView" title="Download" tabindex="34" data-l10n-id="download">
Merge branch 'master' of git://github.com/mozilla/pdf.js.git into l10n Conflicts: web/viewer.html
2012-05-05 03:13:29 +09:00
<span data-l10n-id="download_label">Download</span>
Addressing accessebility aspects
2012-05-04 23:51:21 +09:00
</button>
Adjust the tabindices in the viewer The current way that the tabindices are defined, has the unfortunate consequence that adding a single button to the UI might mean having to change almost all tabindices. (This was the case in e.g. PR 4329.) This patch attempts to avoid that situation happening again, by re-defining the tabindices slightly.
2014-07-19 19:16:44 +09:00
<a href="#" id="viewBookmark" class="toolbarButton bookmark hiddenSmallView" title="Current view (copy or open in new window)" tabindex="35" data-l10n-id="bookmark">
Add the viewBookmark button to the secondary toolbar
2013-09-27 18:44:45 +09:00
<span data-l10n-id="bookmark_label">Current View</span>
</a>
Secondary toolbar
2013-09-05 06:48:31 +09:00
<div class="verticalToolbarSeparator hiddenSmallView"></div>
cleaned whitespace
2015-02-03 00:12:52 +09:00
Adjust the tabindices in the viewer The current way that the tabindices are defined, has the unfortunate consequence that adding a single button to the UI might mean having to change almost all tabindices. (This was the case in e.g. PR 4329.) This patch attempts to avoid that situation happening again, by re-defining the tabindices slightly.
2014-07-19 19:16:44 +09:00
<button id="secondaryToolbarToggle" class="toolbarButton" title="Tools" tabindex="36" data-l10n-id="tools">
Secondary toolbar
2013-09-05 06:48:31 +09:00
<span data-l10n-id="tools_label">Tools</span>
cleaned whitespace
2015-02-03 00:12:52 +09:00
</button>
Remove flex box. Add side animation. Add dashed line around unload thumbnails.
2012-04-26 03:34:28 +09:00
</div>
Viewer: improve responsiveness and clean up CSS This patch resolves the responsiveness issues for the toolbar in the viewer. Depending on the language (for example the Dutch language), elements could overlap when the viewport size is reduced. The main issue here is that the CSS rules are unnecessarily complex and handle lots of different cases (LTR/RTL, displacements for specific viewport widths, et cetera). By removing this complexity and letting the browser handle the responsiveness, we not only get simpler CSS rules and HTML mark-up, but the responsiveness issues are mostly fixed at the same time. We no longer have to position the elements manually (by setting their `left` attribute value) anymore.
2016-11-04 00:56:57 +09:00
<div id="toolbarViewerMiddle">
<div class="splitToolbarButton">
<button id="zoomOut" class="toolbarButton zoomOut" title="Zoom Out" tabindex="21" data-l10n-id="zoom_out">
<span data-l10n-id="zoom_out_label">Zoom Out</span>
</button>
<div class="splitToolbarButtonSeparator"></div>
<button id="zoomIn" class="toolbarButton zoomIn" title="Zoom In" tabindex="22" data-l10n-id="zoom_in">
<span data-l10n-id="zoom_in_label">Zoom In</span>
</button>
Remove flex box. Add side animation. Add dashed line around unload thumbnails.
2012-04-26 03:34:28 +09:00
</div>
Viewer: improve responsiveness and clean up CSS This patch resolves the responsiveness issues for the toolbar in the viewer. Depending on the language (for example the Dutch language), elements could overlap when the viewport size is reduced. The main issue here is that the CSS rules are unnecessarily complex and handle lots of different cases (LTR/RTL, displacements for specific viewport widths, et cetera). By removing this complexity and letting the browser handle the responsiveness, we not only get simpler CSS rules and HTML mark-up, but the responsiveness issues are mostly fixed at the same time. We no longer have to position the elements manually (by setting their `left` attribute value) anymore.
2016-11-04 00:56:57 +09:00
<span id="scaleSelectContainer" class="dropdownToolbarButton">
<select id="scaleSelect" title="Zoom" tabindex="23" data-l10n-id="zoom">
<option id="pageAutoOption" title="" value="auto" selected="selected" data-l10n-id="page_scale_auto">Automatic Zoom</option>
<option id="pageActualOption" title="" value="page-actual" data-l10n-id="page_scale_actual">Actual Size</option>
update inconsistent names
2017-07-11 04:27:39 +09:00
<option id="pageFitOption" title="" value="page-fit" data-l10n-id="page_scale_fit">Page Fit</option>
<option id="pageWidthOption" title="" value="page-width" data-l10n-id="page_scale_width">Page Width</option>
Make the `customScaleOption` disabled to prevent it being keyboard accessible (bug 1315608) Given that the `customScaleOption` should already be hidden, provided that the browser supports that, this patch also prevents it from being accessible via the keyboard. As far as my testing goes in various browsers, this doesn't seem to have any ill effects, and note that we're already explicitly ignoring the `custom` value in the `select` event handler. Fixes https://bugzilla.mozilla.org/show_bug.cgi?id=1315608.
2016-11-08 20:04:55 +09:00
<option id="customScaleOption" title="" value="custom" disabled="disabled" hidden="true"></option>
Viewer: improve responsiveness and clean up CSS This patch resolves the responsiveness issues for the toolbar in the viewer. Depending on the language (for example the Dutch language), elements could overlap when the viewport size is reduced. The main issue here is that the CSS rules are unnecessarily complex and handle lots of different cases (LTR/RTL, displacements for specific viewport widths, et cetera). By removing this complexity and letting the browser handle the responsiveness, we not only get simpler CSS rules and HTML mark-up, but the responsiveness issues are mostly fixed at the same time. We no longer have to position the elements manually (by setting their `left` attribute value) anymore.
2016-11-04 00:56:57 +09:00
<option title="" value="0.5" data-l10n-id="page_scale_percent" data-l10n-args='{ "scale": 50 }'>50%</option>
<option title="" value="0.75" data-l10n-id="page_scale_percent" data-l10n-args='{ "scale": 75 }'>75%</option>
<option title="" value="1" data-l10n-id="page_scale_percent" data-l10n-args='{ "scale": 100 }'>100%</option>
<option title="" value="1.25" data-l10n-id="page_scale_percent" data-l10n-args='{ "scale": 125 }'>125%</option>
<option title="" value="1.5" data-l10n-id="page_scale_percent" data-l10n-args='{ "scale": 150 }'>150%</option>
<option title="" value="2" data-l10n-id="page_scale_percent" data-l10n-args='{ "scale": 200 }'>200%</option>
<option title="" value="3" data-l10n-id="page_scale_percent" data-l10n-args='{ "scale": 300 }'>300%</option>
<option title="" value="4" data-l10n-id="page_scale_percent" data-l10n-args='{ "scale": 400 }'>400%</option>
</select>
</span>
Remove flex box. Add side animation. Add dashed line around unload thumbnails.
2012-04-26 03:34:28 +09:00
</div>
</div>
Implement progressive loading of PDFs
2013-02-07 08:19:29 +09:00
<div id="loadingBar">
<div class="progress">
<div class="glimmer">
</div>
</div>
</div>
Simple search results
2011-12-12 10:38:20 +09:00
</div>
</div>
Separate js and css from the test.html file
2011-05-26 23:02:52 +09:00
Implement page rotation controls using keyboard (R/shift-R) and context menu.
2012-09-08 08:05:14 +09:00
<menu type="context" id="viewerContextMenu">
Secondary toolbar
2013-09-05 06:48:31 +09:00
<menuitem id="contextFirstPage" label="First Page"
data-l10n-id="first_page"></menuitem>
<menuitem id="contextLastPage" label="Last Page"
data-l10n-id="last_page"></menuitem>
<menuitem id="contextPageRotateCw" label="Rotate Clockwise"
data-l10n-id="page_rotate_cw"></menuitem>
<menuitem id="contextPageRotateCcw" label="Rotate Counter-Clockwise"
data-l10n-id="page_rotate_ccw"></menuitem>
Implement page rotation controls using keyboard (R/shift-R) and context menu.
2012-09-08 08:05:14 +09:00
</menu>
Allow scrolling by keyboard in Chrome/Opera Set "tabindex" attribute to allow focus; Added "outline: none" to prevent focus ring from appearing. Fixes #3443
2013-07-06 22:37:03 +09:00
<div id="viewerContainer" tabindex="0">
Move text_layer_builder and pdf_viewer styles out
2014-10-01 00:48:29 +09:00
<div id="viewer" class="pdfViewer"></div>
Unify the multi_page_viewer and the basic viewer
2011-07-29 02:48:05 +09:00
</div>
first mockup, loads tracemonkey pages OK
2012-04-12 08:12:51 +09:00
Fix the error box.
2012-04-26 09:20:13 +09:00
<div id="errorWrapper" hidden='true'>
<div id="errorMessageLeft">
<span id="errorMessage"></span>
Viewer: Remove inline events; set height on error Move inline event handlers to viewer.js to comply with a Content-Security-Policy where directive "unsafe-inline" is not set. Change textarea.rows = <number of newlines> to textarea.style.height = textarea.scrollHeight. (The former is extremely unreliable; consider long lines...)
2013-07-18 07:40:15 +09:00
<button id="errorShowMore" data-l10n-id="error_more_info">
Fix the error box.
2012-04-26 09:20:13 +09:00
More Information
</button>
Viewer: Remove inline events; set height on error Move inline event handlers to viewer.js to comply with a Content-Security-Policy where directive "unsafe-inline" is not set. Change textarea.rows = <number of newlines> to textarea.style.height = textarea.scrollHeight. (The former is extremely unreliable; consider long lines...)
2013-07-18 07:40:15 +09:00
<button id="errorShowLess" data-l10n-id="error_less_info" hidden='true'>
Fix the error box.
2012-04-26 09:20:13 +09:00
Less Information
</button>
</div>
<div id="errorMessageRight">
Viewer: Remove inline events; set height on error Move inline event handlers to viewer.js to comply with a Content-Security-Policy where directive "unsafe-inline" is not set. Change textarea.rows = <number of newlines> to textarea.style.height = textarea.scrollHeight. (The former is extremely unreliable; consider long lines...)
2013-07-18 07:40:15 +09:00
<button id="errorClose" data-l10n-id="error_close">
Fix the error box.
2012-04-26 09:20:13 +09:00
Close
</button>
</div>
<div class="clearBoth"></div>
<textarea id="errorMoreInfo" hidden='true' readonly="readonly"></textarea>
Switching to the document outline view if the document structure is present
2011-08-22 11:05:10 +09:00
</div>
Remove flex box. Add side animation. Add dashed line around unload thumbnails.
2012-04-26 03:34:28 +09:00
</div> <!-- mainContainer -->
Make worker support work again after file split. Add PDFJS_WORKER_DIR/PDFJS_WORKER_FILE to specify where to load files if worker support is enabled
2011-10-28 21:32:36 +09:00
Improved password prompt
2013-09-25 00:46:54 +09:00
<div id="overlayContainer" class="hidden">
Refactor the CSS rules for the overlayContainer
2014-05-12 22:50:13 +09:00
<div id="passwordOverlay" class="container hidden">
<div class="dialog">
Improved password prompt
2013-09-25 00:46:54 +09:00
<div class="row">
<p id="passwordText" data-l10n-id="password_label">Enter the password to open this PDF file:</p>
</div>
<div class="row">
Remove the password prompt input type hack The browsers have become smarter and made this hack no longer functional. Since this is now enforced by practically all browsers, there is nothing more we can do about this. It is up to the user to serve the viewer over HTTPS or deal with the warning. Note that this is in no way specific for PDF.js. Any site with password inputs served over HTTP has this problem right now. This hack was provided as a convenience for the users, but nothing more than that.
2017-04-16 07:28:24 +09:00
<input type="password" id="password" class="toolbarField">
Improved password prompt
2013-09-25 00:46:54 +09:00
</div>
Document properties
2014-01-22 08:07:07 +09:00
<div class="buttonRow">
<button id="passwordCancel" class="overlayButton"><span data-l10n-id="password_cancel">Cancel</span></button>
<button id="passwordSubmit" class="overlayButton"><span data-l10n-id="password_ok">OK</span></button>
</div>
</div>
</div>
Refactor the CSS rules for the overlayContainer
2014-05-12 22:50:13 +09:00
<div id="documentPropertiesOverlay" class="container hidden">
<div class="dialog">
Document properties
2014-01-22 08:07:07 +09:00
<div class="row">
<span data-l10n-id="document_properties_file_name">File name:</span> <p id="fileNameField">-</p>
</div>
Improved password prompt
2013-09-25 00:46:54 +09:00
<div class="row">
Document properties
2014-01-22 08:07:07 +09:00
<span data-l10n-id="document_properties_file_size">File size:</span> <p id="fileSizeField">-</p>
</div>
<div class="separator"></div>
<div class="row">
<span data-l10n-id="document_properties_title">Title:</span> <p id="titleField">-</p>
</div>
<div class="row">
<span data-l10n-id="document_properties_author">Author:</span> <p id="authorField">-</p>
</div>
<div class="row">
<span data-l10n-id="document_properties_subject">Subject:</span> <p id="subjectField">-</p>
</div>
<div class="row">
<span data-l10n-id="document_properties_keywords">Keywords:</span> <p id="keywordsField">-</p>
</div>
<div class="row">
<span data-l10n-id="document_properties_creation_date">Creation Date:</span> <p id="creationDateField">-</p>
</div>
<div class="row">
<span data-l10n-id="document_properties_modification_date">Modification Date:</span> <p id="modificationDateField">-</p>
</div>
<div class="row">
<span data-l10n-id="document_properties_creator">Creator:</span> <p id="creatorField">-</p>
</div>
<div class="separator"></div>
<div class="row">
<span data-l10n-id="document_properties_producer">PDF Producer:</span> <p id="producerField">-</p>
</div>
<div class="row">
<span data-l10n-id="document_properties_version">PDF Version:</span> <p id="versionField">-</p>
</div>
<div class="row">
<span data-l10n-id="document_properties_page_count">Page Count:</span> <p id="pageCountField">-</p>
</div>
Add page size to the document properties dialog
2018-03-09 02:23:47 +09:00
<div class="row">
Display the pageSize, in the document properties dialog, with locale dependent units This uses a whitelist, based on the locale, to determine where non-metric units should be used. Note that the behaviour implemented here seem consistent with desktop PDF viewers (e.g. Adobe Reader), where the pageSizes are *always* displayed with locale dependent units rather than pageSize dependent ones (since the latter would probably be quite confusing).
2018-03-20 21:51:56 +09:00
<span data-l10n-id="document_properties_page_size">Page Size:</span> <p id="pageSizeField">-</p>
Add page size to the document properties dialog
2018-03-09 02:23:47 +09:00
</div>
Expose the Linearization status in the document properties dialog This uses the same terminology, i.e. "Fast Web View", as is used by Adobe software.
2018-07-24 23:24:30 +09:00
<div class="separator"></div>
<div class="row">
<span data-l10n-id="document_properties_linearized">Fast Web View:</span> <p id="linearizedField">-</p>
</div>
Document properties
2014-01-22 08:07:07 +09:00
<div class="buttonRow">
Refactor the CSS rules for the overlayContainer
2014-05-12 22:50:13 +09:00
<button id="documentPropertiesClose" class="overlayButton"><span data-l10n-id="document_properties_close">Close</span></button>
Improved password prompt
2013-09-25 00:46:54 +09:00
</div>
</div>
</div>
Remove the `FIREFOX` build flag, since it's completely unused After PR 9566, which removed all of the old Firefox extension code, the `FIREFOX` build flag is no longer used for anything. It thus seems to me that it should be removed, for a couple of reasons: - It's simply dead code now, which only serves to add confusion when looking at the `PDFJSDev` calls. - It used to be that `MOZCENTRAL` and `FIREFOX` was *almost* always used together. However, ever since PR 9566 there's obviously been no effort put into keeping the `FIREFOX` build flags up to date. - In the event that a new, Webextension based, Firefox addon is created in the future you'd still need to audit all `MOZCENTRAL` (and possibly `CHROME`) build flags to see what'd make sense for the addon.
2020-01-08 21:57:31 +09:00
<!--#if !MOZCENTRAL-->
Removes mozPrintCallback polyfill, converts canvas to PNG.
2016-10-08 21:36:55 +09:00
<div id="printServiceOverlay" class="container hidden">
<div class="dialog">
<div class="row">
Localization of the print dialog.
2016-10-08 21:55:34 +09:00
<span data-l10n-id="print_progress_message">Preparing document for printing…</span>
Removes mozPrintCallback polyfill, converts canvas to PNG.
2016-10-08 21:36:55 +09:00
</div>
<div class="row">
<progress value="0" max="100"></progress>
Localization of the print dialog.
2016-10-08 21:55:34 +09:00
<span data-l10n-id="print_progress_percent" data-l10n-args='{ "progress": 0 }' class="relative-progress">0%</span>
Removes mozPrintCallback polyfill, converts canvas to PNG.
2016-10-08 21:36:55 +09:00
</div>
<div class="buttonRow">
Localization of the print dialog.
2016-10-08 21:55:34 +09:00
<button id="printCancel" class="overlayButton"><span data-l10n-id="print_progress_close">Cancel</span></button>
Removes mozPrintCallback polyfill, converts canvas to PNG.
2016-10-08 21:36:55 +09:00
</div>
</div>
</div>
<!--#endif-->
Teach users how to enable access to local files.
2015-07-19 00:11:33 +09:00
<!--#if CHROME-->
<!--#include viewer-snippet-chrome-overlays.html-->
<!--#endif-->
Document properties
2014-01-22 08:07:07 +09:00
</div> <!-- overlayContainer -->
Improved password prompt
2013-09-25 00:46:54 +09:00
text selection OK, switch outline OK
2012-04-13 08:29:15 +09:00
</div> <!-- outerContainer -->
Adds support for the new mozPrintCallback api.
2012-06-29 01:50:25 +09:00
<div id="printContainer"></div>
Separate js and css from the test.html file
2011-05-26 23:02:52 +09:00
</body>
Factor out mock tests, add browser test page, initial canvas backend
2011-05-05 09:32:59 +09:00
</html>
Reference in New Issue Copy Permalink