Currently non-embedded ArialBlack fonts are not rendered bold enough, compared to e.g. Adobe Reader.
The issue is that we set the font weight to `bolder`, but since that is actually relative to the font weight of the parent, the result is that there's no practical difference from just using `bold`.
This patch attempts to address that, by explicitly setting the font weight to the maximum value instead (see https://developer.mozilla.org/en-US/docs/Web/CSS/font-weight).
*Note:* I expect one test "failure" in `issue5801`, which in this case is an improvement, since that PDF file uses ArialBlack.
Currently `PDFLinkService` requires access to a `PDFHistory` instance in order for it to work correctly (and to avoid errors). If we want `PDFLinkService` to be more useful in custom viewers, I don't think that we actually want to force it to have a `PDFHistory` instance.
Hence this patch, which contains a very simply approach to make `PDFHistory` optional.
For some reason, https://bugzilla.mozilla.org/show_bug.cgi?id=1167053 changed methods of `NetUtil` yet *again*. This patch thus attempts to handle those changes, while keeping the addon backwards compatible.
I've tested this using all current Firefox versions (Nightly, Aurora/DevEdition, Beta, Release, ESR), and things still appears to work correctly.
The 'Version' field of the most recent document catalog, if present, is
intended to supersede the value in the file prologue.
This is significant for incrementally-built PDF documents and generators that
emit a low version in the prologue and later apply a format version based on
PDF features used, such as Apple's CoreGraphics/Quartz PDF backend.
Fixes the internal version variable, as well as the PDFFormatVersion reported
by the API and consumed by viewers.
This adds a checkbox with which one can disable scrolling, for example to look back at output during testing. Note that the styles are inline because the test runner removes all <style> elements for each test.
- Improve variable names and move variables to the top of the method
- Use constants where possible
- Only print the delay text if there is an atual delay set
- Simplify continuation logic in _nextTask
- Do not pass anything to clearCanvas: we can get the context from this.canvas there.
- Remove innerHTML and replace it with textContent. Add a comment why insertAdjancentHTML is so important for performance and runtime.
- Merge _quit and _sendQuitRequest.
- Extract NullTextLayerBuilder and SimpleTextLayerBuilder from the driver code and create classes for them.
- Move options to the constructor and pass in HTML elements instead of getting them in the driver.
- Remove unused masterMode variable.
- Minor method name updates.
The rest is only moving/indenting existing code and adding 'this'.
Reuse the existing getOutputScale() machinery to render and/or rescale
thumbnail images to the native display resolution. Fixes blurry thumbnails on
HiDPI displays making it a lot easier to make out the content.
During A/B testing we found a significant preference (increased engagement
time, reduced downloads of original PDF for local viewing) for the version that
doesn't animate loading thumbnails.
Profiling shows that the transition effects hit at a pessimal time when the
compositor is busy rendering the main PDF page view, and rendering thumbnail
previews, causing the main scroll view to stutter. With the transition removed
scrolling is perceptibly smoother in Chrome and Firefox. We also hypothesize
that the transition effects added to a perception of slowness but presumably
the aforementioned stutter is the primary issue here.
- Remove a hack for Chrome on Windows because we do not run Chrome on the Windows bot anymore, so it added unneeded complexity.
- Merge nextTask and continueNextTask functions. nextTask did nothing more than calling cleanup. This change also allows us to remove the callback for that function.
- Remove unnecessary one-line functions.
Having recently spent some time staring at the PasswordPrompt, while fixing issue 6010, I felt that the current border style does not really give a good visual indication that the input field actually has focus.
The current appearance was first introduced in PR 3527; but I don't know if having a different border style in Overlay dialogs was intentional, or if it just "happened".
However, given the colour palette used in the viewer UI, I think that using the same border style for all .toolbarFields makes sense.
Jonas Jenwald
Rob Wu
Brendan Dahl
Yury Delendik
Mike Corbin
Tim van der Meij
Xiliang Chen