Sakurai/pdf.js
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
c1cb9ee9fc
pdf.js/src/core/evaluator.js

3822 lines
128 KiB
JavaScript
Raw Normal View History

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.
*/
'use strict' everywhere
2011-10-26 10:18:22 +09:00
Convert the files in the `/src/core` folder to ES6 modules Please note that the `glyphlist.js` and `unicode.js` files are converted to CommonJS modules instead, since Babel cannot handle files that large and they are thus excluded from transpilation.
2017-04-02 23:14:30 +09:00
import {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
AbortException,
assert,
CMapCompressionType,
createPromiseCapability,
FONT_IDENTITY_MATRIX,
FormatError,
IDENTITY_MATRIX,
info,
isArrayEqual,
isNum,
isString,
OPS,
stringToPDFString,
TextRenderingMode,
UNSUPPORTED_FEATURES,
Util,
warn,
Ensure that all `import` and `require` statements, in the entire code-base, have a `.js` file extension In order to eventually get rid of SystemJS and start using native `import`s instead, we'll need to provide "complete" file identifiers since otherwise there'll be MIME type errors when attempting to use `import`.
2020-01-02 20:00:16 +09:00
} from "../shared/util.js";
import { CMapFactory, IdentityCMap } from "./cmap.js";
Convert the files in the `/src/core` folder to ES6 modules Please note that the `glyphlist.js` and `unicode.js` files are converted to CommonJS modules instead, since Babel cannot handle files that large and they are thus excluded from transpilation.
2017-04-02 23:14:30 +09:00
import {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
Cmd,
Dict,
EOF,
isDict,
isName,
isRef,
isStream,
Name,
Ref,
Ensure that all `import` and `require` statements, in the entire code-base, have a `.js` file extension In order to eventually get rid of SystemJS and start using native `import`s instead, we'll need to provide "complete" file identifiers since otherwise there'll be MIME type errors when attempting to use `import`.
2020-01-02 20:00:16 +09:00
} from "./primitives.js";
Convert the files in the `/src/core` folder to ES6 modules Please note that the `glyphlist.js` and `unicode.js` files are converted to CommonJS modules instead, since Babel cannot handle files that large and they are thus excluded from transpilation.
2017-04-02 23:14:30 +09:00
import {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
ErrorFont,
Font,
FontFlags,
getFontType,
IdentityToUnicodeMap,
ToUnicodeMap,
Ensure that all `import` and `require` statements, in the entire code-base, have a `.js` file extension In order to eventually get rid of SystemJS and start using native `import`s instead, we'll need to provide "complete" file identifiers since otherwise there'll be MIME type errors when attempting to use `import`.
2020-01-02 20:00:16 +09:00
} from "./fonts.js";
Convert the files in the `/src/core` folder to ES6 modules Please note that the `glyphlist.js` and `unicode.js` files are converted to CommonJS modules instead, since Babel cannot handle files that large and they are thus excluded from transpilation.
2017-04-02 23:14:30 +09:00
import {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
getEncoding,
MacRomanEncoding,
StandardEncoding,
SymbolSetEncoding,
WinAnsiEncoding,
ZapfDingbatsEncoding,
Ensure that all `import` and `require` statements, in the entire code-base, have a `.js` file extension In order to eventually get rid of SystemJS and start using native `import`s instead, we'll need to provide "complete" file identifiers since otherwise there'll be MIME type errors when attempting to use `import`.
2020-01-02 20:00:16 +09:00
} from "./encodings.js";
Prevent lookup errors in `PartialEvaluator.hasBlendModes` from breaking all parsing/rendering of a page (issue 11678) The PDF document in question is *corrupt*, since it contains an XObject with a truncated dictionary and where the stream contents start without a "stream" operator.
2020-03-09 19:37:33 +09:00
import { getLookupTableFactory, MissingDataException } from "./core_utils.js";
Convert the files in the `/src/core` folder to ES6 modules Please note that the `glyphlist.js` and `unicode.js` files are converted to CommonJS modules instead, since Babel cannot handle files that large and they are thus excluded from transpilation.
2017-04-02 23:14:30 +09:00
import {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
getNormalizedUnicodes,
getUnicodeForGlyph,
reverseIfRtl,
Ensure that all `import` and `require` statements, in the entire code-base, have a `.js` file extension In order to eventually get rid of SystemJS and start using native `import`s instead, we'll need to provide "complete" file identifiers since otherwise there'll be MIME type errors when attempting to use `import`.
2020-01-02 20:00:16 +09:00
} from "./unicode.js";
Convert the files in the `/src/core` folder to ES6 modules Please note that the `glyphlist.js` and `unicode.js` files are converted to CommonJS modules instead, since Babel cannot handle files that large and they are thus excluded from transpilation.
2017-04-02 23:14:30 +09:00
import {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
getSerifFonts,
getStdFontMap,
getSymbolsFonts,
Ensure that all `import` and `require` statements, in the entire code-base, have a `.js` file extension In order to eventually get rid of SystemJS and start using native `import`s instead, we'll need to provide "complete" file identifiers since otherwise there'll be MIME type errors when attempting to use `import`.
2020-01-02 20:00:16 +09:00
} from "./standard_fonts.js";
import { getTilingPatternIR, Pattern } from "./pattern.js";
import { Lexer, Parser } from "./parser.js";
import { bidi } from "./bidi.js";
import { ColorSpace } from "./colorspace.js";
import { DecodeStream } from "./stream.js";
import { getGlyphsUnicode } from "./glyphlist.js";
import { getMetrics } from "./metrics.js";
import { isPDFFunction } from "./function.js";
Improve the *local* image caching in `PartialEvaluator.getOperatorList` Currently the local `imageCache`, as used in `PartialEvaluator.getOperatorList`, will miss certain cases of repeated images because the caching is *only* done by name (usually using a format such as e.g. "Im0", "Im1", ...). However, in some PDF documents the `/XObject` dictionaries many contain hundreds (or even thousands) of distinctly named images, despite them referring to only a handful of actual image objects (via the XRef table). With these changes we'll now cache *local* images using both name and (where applicable) reference, thus improving re-usage of images resources even further. This patch was tested using the PDF file from [bug 857031](https://bugzilla.mozilla.org/show_bug.cgi?id=857031), i.e. https://bug857031.bmoattachments.org/attachment.cgi?id=732270, with the following manifest file: ``` [ { "id": "bug857031", "file": "../web/pdfs/bug857031.pdf", "md5": "", "rounds": 250, "lastPage": 1, "type": "eq" } ] ``` which gave the following results when comparing this patch against the `master` branch: ``` -- Grouped By browser, page, stat -- browser | page | stat | Count | Baseline(ms) | Current(ms) | +/- | % | Result(P<.05) ------- | ---- | ------------ | ----- | ------------ | ----------- | --- | ----- | ------------- firefox | 0 | Overall | 250 | 2749 | 2656 | -93 | -3.38 | faster firefox | 0 | Page Request | 250 | 3 | 4 | 1 | 50.14 | slower firefox | 0 | Rendering | 250 | 2746 | 2652 | -94 | -3.44 | faster ``` While this is certainly an improvement, since we now avoid re-parsing ~1000 images on the first page, all of the image resources are small enough that the total rendering time doesn't improve that much in this particular case. In pathological cases, such as e.g. the PDF document in issue 4958, the improvements with this patch can be very significant. Looking for example at page 2, from issue 4958, the rendering time drops from ~60 seconds with `master` to ~30 seconds with this patch (obviously still slow, but it really showcases the potential of this patch nicely). Finally, note that there's also potential for additional improvements by re-using `LocalImageCache` instances for e.g. /XObject data of the `Form`-type. However, given that recent changes in this area I purposely didn't want to complicate *this* patch more than necessary.
2020-05-23 20:55:31 +09:00
import { LocalImageCache } from "./image_utils.js";
Ensure that all `import` and `require` statements, in the entire code-base, have a `.js` file extension In order to eventually get rid of SystemJS and start using native `import`s instead, we'll need to provide "complete" file identifiers since otherwise there'll be MIME type errors when attempting to use `import`.
2020-01-02 20:00:16 +09:00
import { MurmurHash3_64 } from "./murmurhash3.js";
import { OperatorList } from "./operator_list.js";
import { PDFImage } from "./image.js";
Adds UMD headers to core, display and shared files.
2015-11-22 01:32:47 +09:00
Name all constructors.
2011-12-09 07:18:43 +09:00
var PartialEvaluator = (function PartialEvaluatorClosure() {
Change the signatures of the `PartialEvaluator` "constructor" and its `getOperatorList`/`getTextContent` methods to take parameter objects Currently these methods accept a large number of parameters, which creates quite unwieldy call-sites. When invoking them, you have to remember not only what arguments to supply, but also the correct order, to avoid runtime errors. Furthermore, since some of the parameters are optional, you also have to remember to pass e.g. `null` or `undefined` for those ones. Also, adding new parameters to these methods (which happens occasionally), often becomes unnecessarily tedious (based on personal experience). Please note that I do *not* think that we need/should convert *every* single method in `evaluator.js` (or elsewhere in `/core` files) to take parameter objects. However, in my opinion, once a method starts relying on approximately five parameter (or even more), passing them in individually becomes quite cumbersome. With these changes, I obviously needed to update the `evaluator_spec.js` unit-tests. The main change there, except the new method signatures[1], is that it's now re-using *one* `PartialEvalutor` instance, since I couldn't see any compelling reason for creating a new one in every single test. *Note:* If this patch is accepted, my intention is to (time permitting) see if it makes sense to convert additional methods in `evaluator.js` (and other `/core` files) in a similar fashion, but I figured that it'd be a good idea to limit the initial scope somewhat. --- [1] A fun fact here, note how the `PartialEvaluator` signature used in `evaluator_spec.js` wasn't even correct in the current `master`.
2017-04-30 06:13:51 +09:00
const DefaultPartialEvaluatorOptions = {
Removes global PDFJS usage from the src/core/.
2016-03-03 09:48:21 +09:00
maxImageSize: -1,
disableFontFace: false,
[api-minor] Always allow e.g. rendering to continue even if there are errors, and add a `stopAtErrors` parameter to `getDocument` to opt-out of this behaviour (issue 6342, issue 3795, bug 1130815) Other PDF readers, e.g. Adobe Reader and PDFium (in Chrome), will attempt to render as much of a page as possible even if there are errors present. Currently we just bail as soon the first error is hit, which means that we'll usually not render anything in these cases and just display a blank page instead. NOTE: This patch changes the default behaviour of the PDF.js API to always attempt to recover as much data as possible, even when encountering errors during e.g. `getOperatorList`/`getTextContent`, which thus improve our handling of corrupt PDF files and allow the default viewer to handle errors slightly more gracefully. In the event that an API consumer wishes to use the old behaviour, where we stop parsing as soon as an error is encountered, the `stopAtErrors` parameter can be set at `getDocument`. Fixes, inasmuch it's possible since the PDF files are corrupt, e.g. issue 6342, issue 3795, and [bug 1130815](https://bugzilla.mozilla.org/show_bug.cgi?id=1130815) (and probably others too).
2017-02-19 22:03:08 +09:00
ignoreErrors: false,
Check `isEvalSupported`, and test that `eval` is actually supported, before attempting to use the `PostScriptCompiler` (issue 5573) Currently `PDFFunction` is implemented (basically) like a class with only `static` methods. Since it's used directly in a number of different `src/core/` files, attempting to pass in `isEvalSupported` would result in code that's *very* messy, not to mention difficult to maintain (since *every* single `PDFFunction` method call would need to include a `isEvalSupported` argument). Rather than having to wait for a possible re-factoring of `PDFFunction` that would avoid the above problems by design, it probably makes sense to at least set `isEvalSupported` globally for `PDFFunction`. Please note that there's one caveat with this solution: If `PDFJS.getDocument` is used to open multiple files simultaneously, with *different* `PDFJS.isEvalSupported` values set before each call, then the last one will always win. However, that seems like enough of an edge-case that we shouldn't have to worry about it. Besides, since we'll also test that `eval` is actually supported, it should be fine. Fixes 5573.
2017-09-14 22:38:57 +09:00
isEvalSupported: true,
[api-minor] Change `Font.exportData` to, by default, stop exporting properties which are completely unused on the main-thread and/or in the API (PR 11773 follow-up) For years now, the `Font.exportData` method has (because of its previous implementation) been exporting many properties despite them being completely unused on the main-thread and/or in the API. This is unfortunate, since among those properties there's a number of potentially very large data-structures, containing e.g. Arrays and Objects, which thus have to be first structured cloned and then stored on the main-thread. With the changes in this patch, we'll thus by default save memory for *every* `Font` instance created (there can be a lot in longer documents). The memory savings obviously depends a lot on the actual font data, but some approximate figures are: For non-embedded fonts it can save a couple of kilobytes, for simple embedded fonts a handful of kilobytes, and for composite fonts the size of this auxiliary can even be larger than the actual font program itself. All-in-all, there's no good reason to keep exporting these properties by default when they're unused. However, since we cannot be sure that every property is unused in custom implementations of the PDF.js library, this patch adds a new `getDocument` option (named `fontExtraProperties`) that still allows access to the following properties: - "cMap": An internal data structure, only used with composite fonts and never really intended to be exposed on the main-thread and/or in the API. Note also that the `CMap`/`IdentityCMap` classes are a lot more complex than simple Objects, but only their "internal" properties survive the structured cloning used to send data to the main-thread. Given that CMaps can often be *very* large, not exporting them can also save a fair bit of memory. - "defaultEncoding": An internal property used with simple fonts, and used when building the glyph mapping on the worker-thread. Considering how complex that topic is, and given that not all font types are handled identically, exposing this on the main-thread and/or in the API most likely isn't useful. - "differences": An internal property used with simple fonts, and used when building the glyph mapping on the worker-thread. Considering how complex that topic is, and given that not all font types are handled identically, exposing this on the main-thread and/or in the API most likely isn't useful. - "isSymbolicFont": An internal property, used during font parsing and building of the glyph mapping on the worker-thread. - "seacMap": An internal map, only potentially used with *some* Type1/CFF fonts and never intended to be exposed in the API. The existing `Font.{charToGlyph, charToGlyphs}` functionality already takes this data into account when handling text. - "toFontChar": The glyph map, necessary for mapping characters to glyphs in the font, which is built upon the various encoding information contained in the font dictionary and/or font program. This is not directly used on the main-thread and/or in the API. - "toUnicode": The unicode map, necessary for text-extraction to work correctly, which is built upon the ToUnicode/CMap information contained in the font dictionary, but not directly used on the main-thread and/or in the API. - "vmetrics": An array of width data used with fonts which are composite *and* vertical, but not directly used on the main-thread and/or in the API. - "widths": An array of width data used with most fonts, but not directly used on the main-thread and/or in the API.
2020-04-03 18:51:46 +09:00
fontExtraProperties: false,
Removes global PDFJS usage from the src/core/.
2016-03-03 09:48:21 +09:00
};
Whitelist closure related cases to address the remaining `no-shadow` linting errors Given the way that "classes" were previously implemented in PDF.js, using regular functions and closures, there's a fair number of false positives when the `no-shadow` ESLint rule was enabled. Note that while *some* of these `eslint-disable` statements can be removed if/when the relevant code is converted to proper `class`es, we'll probably never be able to get rid of all of them given our naming/coding conventions (however I don't really see this being a problem).
2020-03-25 18:15:50 +09:00
// eslint-disable-next-line no-shadow
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
function PartialEvaluator({
xref,
handler,
pageIndex,
idFactory,
fontCache,
builtInCMapCache,
Attempt to cache repeated images at the document, rather than the page, level (issue 11878) Currently image resources, as opposed to e.g. font resources, are handled exclusively on a page-specific basis. Generally speaking this makes sense, since pages are separate from each other, however there's PDF documents where many (or even all) pages actually references exactly the same image resources (through the XRef table). Hence, in some cases, we're decoding the *same* images over and over for every page which is obviously slow and wasting both CPU and memory resources better used elsewhere.[1] Obviously we cannot simply treat all image resources as-if they're used throughout the entire PDF document, since that would end up increasing memory usage too much.[2] However, by introducing a `GlobalImageCache` in the worker we can track image resources that appear on more than one page. Hence we can switch image resources from being page-specific to being document-specific, once the image resource has been seen on more than a certain number of pages. In many cases, such as e.g. the referenced issue, this patch will thus lead to reduced memory usage for image resources. Scrolling through all pages of the document, there's now only a few main-thread copies of the same image data, as opposed to one for each rendered page (i.e. there could theoretically be *twenty* copies of the image data). While this obviously benefit both CPU and memory usage in this case, for *very* large image data this patch *may* possibly increase persistent main-thread memory usage a tiny bit. Thus to avoid negatively affecting memory usage too much in general, particularly on the main-thread, the `GlobalImageCache` will *only* cache a certain number of image resources at the document level and simply fallback to the default behaviour. Unfortunately the asynchronous nature of the code, with ranged/streamed loading of data, actually makes all of this much more complicated than if all data could be assumed to be immediately available.[3] *Please note:* The patch will lead to *small* movement in some existing test-cases, since we're now using the built-in PDF.js JPEG decoder more. This was done in order to simplify the overall implementation, especially on the main-thread, by limiting it to only the `OPS.paintImageXObject` operator. --- [1] There's e.g. PDF documents that use the same image as background on all pages. [2] Given that data stored in the `commonObjs`, on the main-thread, are only cleared manually through `PDFDocumentProxy.cleanup`. This as opposed to data stored in the `objs` of each page, which is automatically removed when the page is cleaned-up e.g. by being evicted from the cache in the default viewer. [3] If the latter case were true, we could simply check for repeat images *before* parsing started and thus avoid handling *any* duplicate image resources.
2020-05-18 21:17:56 +09:00
globalImageCache,
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
options = null,
pdfFunctionFactory,
}) {
Splitting files
2011-10-25 08:55:23 +09:00
this.xref = xref;
this.handler = handler;
Separate page objects/images from the fonts; does not store large images
2012-10-29 05:10:34 +09:00
this.pageIndex = pageIndex;
Replace direct lookup of `uniquePrefix`/`idCounters`, in `Page` instances, with an `idFactory` containing an `createObjId` method instead We're currently making use of `uniquePrefix`/`idCounters` in multiple files, to create unique object id's, and adding a new occurrence of them requires some care to ensure that an object id isn't accidentally reused. Furthermore, having to pass around multiple parameters as we currently do seem like something you want to avoid. Instead, this patch adds a factory which means that there's only *one* thing that needs to be passed around. And since it's now only necessary to call a method in order to obtain a unique object id, the details are thus abstracted away at the call-sites which avoids accidental reuse of object id's. To test that this works as expected a very simple `Page` unit-test is added, and the existing `Annotation layer` tests are also adjusted slightly.
2017-01-09 00:51:30 +09:00
this.idFactory = idFactory;
Cleaning up fonts when viewer is idle for some time
2013-11-15 06:43:38 +09:00
this.fontCache = fontCache;
Cache built-in binary CMap files in the worker (issue 4794)
2017-02-14 22:28:31 +09:00
this.builtInCMapCache = builtInCMapCache;
Attempt to cache repeated images at the document, rather than the page, level (issue 11878) Currently image resources, as opposed to e.g. font resources, are handled exclusively on a page-specific basis. Generally speaking this makes sense, since pages are separate from each other, however there's PDF documents where many (or even all) pages actually references exactly the same image resources (through the XRef table). Hence, in some cases, we're decoding the *same* images over and over for every page which is obviously slow and wasting both CPU and memory resources better used elsewhere.[1] Obviously we cannot simply treat all image resources as-if they're used throughout the entire PDF document, since that would end up increasing memory usage too much.[2] However, by introducing a `GlobalImageCache` in the worker we can track image resources that appear on more than one page. Hence we can switch image resources from being page-specific to being document-specific, once the image resource has been seen on more than a certain number of pages. In many cases, such as e.g. the referenced issue, this patch will thus lead to reduced memory usage for image resources. Scrolling through all pages of the document, there's now only a few main-thread copies of the same image data, as opposed to one for each rendered page (i.e. there could theoretically be *twenty* copies of the image data). While this obviously benefit both CPU and memory usage in this case, for *very* large image data this patch *may* possibly increase persistent main-thread memory usage a tiny bit. Thus to avoid negatively affecting memory usage too much in general, particularly on the main-thread, the `GlobalImageCache` will *only* cache a certain number of image resources at the document level and simply fallback to the default behaviour. Unfortunately the asynchronous nature of the code, with ranged/streamed loading of data, actually makes all of this much more complicated than if all data could be assumed to be immediately available.[3] *Please note:* The patch will lead to *small* movement in some existing test-cases, since we're now using the built-in PDF.js JPEG decoder more. This was done in order to simplify the overall implementation, especially on the main-thread, by limiting it to only the `OPS.paintImageXObject` operator. --- [1] There's e.g. PDF documents that use the same image as background on all pages. [2] Given that data stored in the `commonObjs`, on the main-thread, are only cleared manually through `PDFDocumentProxy.cleanup`. This as opposed to data stored in the `objs` of each page, which is automatically removed when the page is cleaned-up e.g. by being evicted from the cache in the default viewer. [3] If the latter case were true, we could simply check for repeat images *before* parsing started and thus avoid handling *any* duplicate image resources.
2020-05-18 21:17:56 +09:00
this.globalImageCache = globalImageCache;
Removes global PDFJS usage from the src/core/.
2016-03-03 09:48:21 +09:00
this.options = options || DefaultPartialEvaluatorOptions;
Split the existing `PDFFunction` in two classes, a private `PDFFunction` and a public `PDFFunctionFactory``, and utilize the latter in `PDFDocument` to allow various code to access the methods of `PDFFunction` *Follow-up to PR 8909.* This requires us to pass around `pdfFunctionFactory` to quite a lot of existing code, however I don't see another way of handling this while still guaranteeing that we can access `PDFFunction` as freely as in the old code. Please note that the patch passes all tests locally (unit, font, reference), and I *very* much hope that we have sufficient test-coverage for the code in question to catch any typos/mistakes in the re-factoring.
2017-09-19 20:49:30 +09:00
this.pdfFunctionFactory = pdfFunctionFactory;
Support (rare) Type3 fonts which contains image resources (issue 10717) The Type3 font type is not commonly used in PDF documents, as can be seen from telemetry data such as: https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0&end_date=2019-04-09&include_spill=0&keys=__none__!__none__!__none__&max_channel_version=nightly%252F68&measure=PDF_VIEWER_FONT_TYPES&min_channel_version=nightly%252F57&processType=*&product=Firefox&sanitize=1&sort_by_value=0&sort_keys=submissions&start_date=2019-03-18&table=0&trim=1&use_submission_date=0 (see also https://github.com/mozilla/pdf.js/wiki/Enumeration-Assignments-for-the-Telemetry-Histograms#pdf_viewer_font_types). Type3 fonts containing image resources are *very* rare in practice, usually they only contain path rendering operators, but as the issue shows they unfortunately do exist. Currently these Type3-related image resources are not handled in any special way, and given that fonts are document rather than page specific rendering breaks since the image resources are thus not available to the *entire* document. Fortunately fixing this isn't too difficult, but it does require adding a couple of Type3-specific code-paths to the `PartialEvaluator`. In order to keep the implementation simple, particularily on the main-thread, these Type3 image resources are completely decoded on the worker-thread to avoid adding too many special cases. This should not cause any issues, only marginally less efficient code, but given how rare this kind of Type3 font is adding premature optimizations didn't seem at all warranted at this point.
2019-04-11 19:26:15 +09:00
this.parsingType3Font = false;
[api-minor] Refactor fetching of built-in CMaps to utilize a factory on the `display` side instead, to allow users of the API to provide a custom CMap loading factory (e.g. for use with Node.js) Currently the built-in CMap files are loaded in `src/core/cmap.js` using `XMLHttpRequest` directly. For some environments that might be a problem, hence this patch refactors that to instead use a factory to load built-in CMaps on the main thread and message the data to the worker thread. This is inspired by other recent work, e.g. the addition of the `CanvasFactory`, and to a large extent on the IRC discussion starting at http://logs.glob.uno/?c=mozilla%23pdfjs&s=12+Oct+2016&e=12+Oct+2016#c53010.
2017-02-12 23:54:41 +09:00
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
this.fetchBuiltInCMap = async name => {
[Regression] Convert `Catalog.builtInCMapCache` into a `Map`, instead of an Object, to ensure that it's correctly reset (PR 8064 follow-up) With the `builtInCMapCache` being a simple Object, it unfortunately means that the `Catalog.cleanup` method isn't resetting it as intended. By just replacing the `builtInCMapCache` with an empty Object, existing references to it will not actually be updated. The result is that e.g. `Page` instances still keeps references to, what should have been removed, CMap data. To fix these problems, the `builtInCMapCache` is converted into a `Map` instead (since it can be easily reset).
2018-07-25 23:11:48 +09:00
if (this.builtInCMapCache.has(name)) {
Add support for `async`/`await` using Babel For proof-of-concept, this patch converts a couple of `Promise` returning methods to use `async` instead. Please note that the `generic` build, based on this patch, has been successfully testing in IE11 (i.e. the viewer loads and nothing is obviously broken). Being able to use modern JavaScript features like `async`/`await` is a huge plus, but there's one (obvious) side-effect: The size of the built files will increase slightly (unless `SKIP_BABEL == true`). That's unavoidable, but seems like a small price to pay in the grand scheme of things. Finally, note that the `chromium` build target was changed to no longer skip Babel translation, since the Chrome extension still supports version `49` of the browser (where native `async` support isn't available).
2018-07-30 20:58:09 +09:00
return this.builtInCMapCache.get(name);
Cache built-in binary CMap files in the worker (issue 4794)
2017-02-14 22:28:31 +09:00
}
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
const readableStream = this.handler.sendWithStream("FetchBuiltInCMap", {
Transfer, rather than copy, CMap data to the worker-thread It recently occurred to me that the CMap data should be an excellent candidate for transfering. This will help reduce peak memory usage for PDF documents using CMaps, since transfering of data avoids duplicating it on both the main- and worker-threads. Unfortunately it's not possible to actually transfer data when *returning* data through `sendWithPromise`, and another solution had to be used. Initially I looked at using one message for requesting the data, and another message for returning the actual CMap data. While that should have worked, it would have meant adding a lot more complexity particularly on the worker-thread. Hence the simplest solution, at least in my opinion, is to utilize `sendWithStream` since that makes it *really* easy to transfer the CMap data. (This required PR 11115 to land first, since otherwise CMap fetch errors won't propagate correctly to the worker-thread.) Please note that the patch *purposely* only changes the API to Worker communication, and not the API *itself* since changing the interface of `CMapReaderFactory` would be a breaking change. Furthermore, given the relatively small size of the `.bcmap` files (the largest one is smaller than the default range-request size) streaming doesn't really seem necessary either.
2019-09-04 18:20:14 +09:00
name,
});
const reader = readableStream.getReader();
Update Prettier to version 2.0 Please note that these changes were done automatically, using `gulp lint --fix`. Given that the major version number was increased, there's a fair number of (primarily whitespace) changes; please see https://prettier.io/blog/2020/03/21/2.0.0.html In order to reduce the size of these changes somewhat, this patch maintains the old "arrowParens" style for now (once mozilla-central updates Prettier we can simply choose the same formatting, assuming it will differ here).
2020-04-14 19:28:14 +09:00
const data = await new Promise(function (resolve, reject) {
Transfer, rather than copy, CMap data to the worker-thread It recently occurred to me that the CMap data should be an excellent candidate for transfering. This will help reduce peak memory usage for PDF documents using CMaps, since transfering of data avoids duplicating it on both the main- and worker-threads. Unfortunately it's not possible to actually transfer data when *returning* data through `sendWithPromise`, and another solution had to be used. Initially I looked at using one message for requesting the data, and another message for returning the actual CMap data. While that should have worked, it would have meant adding a lot more complexity particularly on the worker-thread. Hence the simplest solution, at least in my opinion, is to utilize `sendWithStream` since that makes it *really* easy to transfer the CMap data. (This required PR 11115 to land first, since otherwise CMap fetch errors won't propagate correctly to the worker-thread.) Please note that the patch *purposely* only changes the API to Worker communication, and not the API *itself* since changing the interface of `CMapReaderFactory` would be a breaking change. Furthermore, given the relatively small size of the `.bcmap` files (the largest one is smaller than the default range-request size) streaming doesn't really seem necessary either.
2019-09-04 18:20:14 +09:00
function pump() {
Update Prettier to version 2.0 Please note that these changes were done automatically, using `gulp lint --fix`. Given that the major version number was increased, there's a fair number of (primarily whitespace) changes; please see https://prettier.io/blog/2020/03/21/2.0.0.html In order to reduce the size of these changes somewhat, this patch maintains the old "arrowParens" style for now (once mozilla-central updates Prettier we can simply choose the same formatting, assuming it will differ here).
2020-04-14 19:28:14 +09:00
reader.read().then(function ({ value, done }) {
Transfer, rather than copy, CMap data to the worker-thread It recently occurred to me that the CMap data should be an excellent candidate for transfering. This will help reduce peak memory usage for PDF documents using CMaps, since transfering of data avoids duplicating it on both the main- and worker-threads. Unfortunately it's not possible to actually transfer data when *returning* data through `sendWithPromise`, and another solution had to be used. Initially I looked at using one message for requesting the data, and another message for returning the actual CMap data. While that should have worked, it would have meant adding a lot more complexity particularly on the worker-thread. Hence the simplest solution, at least in my opinion, is to utilize `sendWithStream` since that makes it *really* easy to transfer the CMap data. (This required PR 11115 to land first, since otherwise CMap fetch errors won't propagate correctly to the worker-thread.) Please note that the patch *purposely* only changes the API to Worker communication, and not the API *itself* since changing the interface of `CMapReaderFactory` would be a breaking change. Furthermore, given the relatively small size of the `.bcmap` files (the largest one is smaller than the default range-request size) streaming doesn't really seem necessary either.
2019-09-04 18:20:14 +09:00
if (done) {
return;
}
resolve(value);
pump();
}, reject);
}
pump();
});
Add support for `async`/`await` using Babel For proof-of-concept, this patch converts a couple of `Promise` returning methods to use `async` instead. Please note that the `generic` build, based on this patch, has been successfully testing in IE11 (i.e. the viewer loads and nothing is obviously broken). Being able to use modern JavaScript features like `async`/`await` is a huge plus, but there's one (obvious) side-effect: The size of the built files will increase slightly (unless `SKIP_BABEL == true`). That's unavoidable, but seems like a small price to pay in the grand scheme of things. Finally, note that the `chromium` build target was changed to no longer skip Babel translation, since the Chrome extension still supports version `49` of the browser (where native `async` support isn't available).
2018-07-30 20:58:09 +09:00
if (data.compressionType !== CMapCompressionType.NONE) {
// Given the size of uncompressed CMaps, only cache compressed ones.
this.builtInCMapCache.set(name, data);
}
return data;
[api-minor] Refactor fetching of built-in CMaps to utilize a factory on the `display` side instead, to allow users of the API to provide a custom CMap loading factory (e.g. for use with Node.js) Currently the built-in CMap files are loaded in `src/core/cmap.js` using `XMLHttpRequest` directly. For some environments that might be a problem, hence this patch refactors that to instead use a factory to load built-in CMaps on the main thread and message the data to the worker thread. This is inspired by other recent work, e.g. the addition of the `CanvasFactory`, and to a large extent on the IRC discussion starting at http://logs.glob.uno/?c=mozilla%23pdfjs&s=12+Oct+2016&e=12+Oct+2016#c53010.
2017-02-12 23:54:41 +09:00
};
Splitting files
2011-10-25 08:55:23 +09:00
}
Terminate getOperationList and getTextContent every 20 ms
2014-05-10 10:41:03 +09:00
// Trying to minimize Date.now() usage and check every 100 time
var TIME_SLOT_DURATION_MS = 20;
var CHECK_TIME_EVERY = 100;
function TimeSlotManager() {
this.reset();
}
TimeSlotManager.prototype = {
check: function TimeSlotManager_check() {
if (++this.checked < CHECK_TIME_EVERY) {
return false;
}
this.checked = 0;
return this.endTime <= Date.now();
},
reset: function TimeSlotManager_reset() {
this.endTime = Date.now() + TIME_SLOT_DURATION_MS;
this.checked = 0;
Fix inconsistent spacing and trailing commas in objects in `src/core/` files, so we can enable the `comma-dangle` and `object-curly-spacing` ESLint rules later on *Unfortunately this patch is fairly big, even though it only covers the `src/core` folder, but splitting it even further seemed difficult.* http://eslint.org/docs/rules/comma-dangle http://eslint.org/docs/rules/object-curly-spacing Given that we currently have quite inconsistent object formatting, fixing this in *one* big patch probably wouldn't be feasible (since I cannot imagine anyone wanting to review that); hence I've opted to try and do this piecewise instead. Please note: This patch was created automatically, using the ESLint --fix command line option. In a couple of places this caused lines to become too long, and I've fixed those manually; please refer to the interdiff below for the only hand-edits in this patch. ```diff diff --git a/src/core/evaluator.js b/src/core/evaluator.js index abab9027..dcd3594b 100644 --- a/src/core/evaluator.js +++ b/src/core/evaluator.js @@ -2785,7 +2785,8 @@ var EvaluatorPreprocessor = (function EvaluatorPreprocessorClosure() { t['Tz'] = { id: OPS.setHScale, numArgs: 1, variableArgs: false, }; t['TL'] = { id: OPS.setLeading, numArgs: 1, variableArgs: false, }; t['Tf'] = { id: OPS.setFont, numArgs: 2, variableArgs: false, }; - t['Tr'] = { id: OPS.setTextRenderingMode, numArgs: 1, variableArgs: false, }; + t['Tr'] = { id: OPS.setTextRenderingMode, numArgs: 1, + variableArgs: false, }; t['Ts'] = { id: OPS.setTextRise, numArgs: 1, variableArgs: false, }; t['Td'] = { id: OPS.moveText, numArgs: 2, variableArgs: false, }; t['TD'] = { id: OPS.setLeadingMoveText, numArgs: 2, variableArgs: false, }; diff --git a/src/core/jbig2.js b/src/core/jbig2.js index 5a17d482..71671541 100644 --- a/src/core/jbig2.js +++ b/src/core/jbig2.js @@ -123,19 +123,22 @@ var Jbig2Image = (function Jbig2ImageClosure() { { x: -1, y: -1, }, { x: 0, y: -1, }, { x: 1, y: -1, }, { x: -2, y: 0, }, { x: -1, y: 0, }], [{ x: -3, y: -1, }, { x: -2, y: -1, }, { x: -1, y: -1, }, { x: 0, y: -1, }, - { x: 1, y: -1, }, { x: -4, y: 0, }, { x: -3, y: 0, }, { x: -2, y: 0, }, { x: -1, y: 0, }] + { x: 1, y: -1, }, { x: -4, y: 0, }, { x: -3, y: 0, }, { x: -2, y: 0, }, + { x: -1, y: 0, }] ]; var RefinementTemplates = [ { coding: [{ x: 0, y: -1, }, { x: 1, y: -1, }, { x: -1, y: 0, }], - reference: [{ x: 0, y: -1, }, { x: 1, y: -1, }, { x: -1, y: 0, }, { x: 0, y: 0, }, - { x: 1, y: 0, }, { x: -1, y: 1, }, { x: 0, y: 1, }, { x: 1, y: 1, }], + reference: [{ x: 0, y: -1, }, { x: 1, y: -1, }, { x: -1, y: 0, }, + { x: 0, y: 0, }, { x: 1, y: 0, }, { x: -1, y: 1, }, + { x: 0, y: 1, }, { x: 1, y: 1, }], }, { - coding: [{ x: -1, y: -1, }, { x: 0, y: -1, }, { x: 1, y: -1, }, { x: -1, y: 0, }], - reference: [{ x: 0, y: -1, }, { x: -1, y: 0, }, { x: 0, y: 0, }, { x: 1, y: 0, }, - { x: 0, y: 1, }, { x: 1, y: 1, }], + coding: [{ x: -1, y: -1, }, { x: 0, y: -1, }, { x: 1, y: -1, }, + { x: -1, y: 0, }], + reference: [{ x: 0, y: -1, }, { x: -1, y: 0, }, { x: 0, y: 0, }, + { x: 1, y: 0, }, { x: 0, y: 1, }, { x: 1, y: 1, }], } ]; ```
2017-06-02 18:16:24 +09:00
},
Terminate getOperationList and getTextContent every 20 ms
2014-05-10 10:41:03 +09:00
};
Normalize blend mode names.
2017-04-11 03:58:02 +09:00
// Convert PDF blend mode names to HTML5 blend mode names.
Support Blend Modes which are specified in an Array of Names (issue 11279) According to the specification, the first *supported* Blend Mode should be choosen in this case; please see https://www.adobe.com/content/dam/acom/en/devnet/acrobat/pdfs/PDF32000_2008.pdf#G10.4848607
2019-10-26 18:57:56 +09:00
function normalizeBlendMode(value, parsingArray = false) {
if (Array.isArray(value)) {
// Use the first *supported* BM value in the Array (fixes issue11279.pdf).
for (let i = 0, ii = value.length; i < ii; i++) {
const maybeBM = normalizeBlendMode(value[i], /* parsingArray = */ true);
if (maybeBM) {
return maybeBM;
}
}
warn(`Unsupported blend mode Array: ${value}`);
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
return "source-over";
Support Blend Modes which are specified in an Array of Names (issue 11279) According to the specification, the first *supported* Blend Mode should be choosen in this case; please see https://www.adobe.com/content/dam/acom/en/devnet/acrobat/pdfs/PDF32000_2008.pdf#G10.4848607
2019-10-26 18:57:56 +09:00
}
Normalize blend mode names.
2017-04-11 03:58:02 +09:00
if (!isName(value)) {
Support Blend Modes which are specified in an Array of Names (issue 11279) According to the specification, the first *supported* Blend Mode should be choosen in this case; please see https://www.adobe.com/content/dam/acom/en/devnet/acrobat/pdfs/PDF32000_2008.pdf#G10.4848607
2019-10-26 18:57:56 +09:00
if (parsingArray) {
return null;
}
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
return "source-over";
Normalize blend mode names.
2017-04-11 03:58:02 +09:00
}
switch (value.name) {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
case "Normal":
case "Compatible":
return "source-over";
case "Multiply":
return "multiply";
case "Screen":
return "screen";
case "Overlay":
return "overlay";
case "Darken":
return "darken";
case "Lighten":
return "lighten";
case "ColorDodge":
return "color-dodge";
case "ColorBurn":
return "color-burn";
case "HardLight":
return "hard-light";
case "SoftLight":
return "soft-light";
case "Difference":
return "difference";
case "Exclusion":
return "exclusion";
case "Hue":
return "hue";
case "Saturation":
return "saturation";
case "Color":
return "color";
case "Luminosity":
return "luminosity";
Normalize blend mode names.
2017-04-11 03:58:02 +09:00
}
Support Blend Modes which are specified in an Array of Names (issue 11279) According to the specification, the first *supported* Blend Mode should be choosen in this case; please see https://www.adobe.com/content/dam/acom/en/devnet/acrobat/pdfs/PDF32000_2008.pdf#G10.4848607
2019-10-26 18:57:56 +09:00
if (parsingArray) {
return null;
}
warn(`Unsupported blend mode: ${value.name}`);
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
return "source-over";
Normalize blend mode names.
2017-04-11 03:58:02 +09:00
}
Terminate getOperationList and getTextContent every 20 ms
2014-05-10 10:41:03 +09:00
var deferred = Promise.resolve();
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
var TILING_PATTERN = 1,
SHADING_PATTERN = 2;
Make getOperatorList() calls independent and merge queues at end
2013-04-09 07:14:56 +09:00
Name all constructors.
2011-12-09 07:18:43 +09:00
PartialEvaluator.prototype = {
Enable the `object-shorthand` ESLint rule in `src/shared` Please see http://eslint.org/docs/rules/object-shorthand. For the most part, these changes are of the search-and-replace kind, and the previously enabled `no-undef` rule should complement the tests in helping ensure that no stupid errors crept into to the patch.
2017-04-27 19:58:44 +09:00
clone(newOptions = DefaultPartialEvaluatorOptions) {
Always ignore Type3 glyphs if their `OperatorList`s contain errors, regardless of the value of the `stopAtErrors` option Compared to the parsing of e.g. an entire page, it doesn't really make sense to only be able to render a Type3 glyph partially.
2017-04-05 20:32:36 +09:00
var newEvaluator = Object.create(this);
newEvaluator.options = newOptions;
return newEvaluator;
},
Incrementally render by sending the operator list by chunks as they're ready.
2013-08-01 03:17:36 +09:00
hasBlendModes: function PartialEvaluator_hasBlendModes(resources) {
Inline all the possible type checks in `PartialEvaluator.hasBlendModes` to avoid unnecessary function calls For badly generated PDF documents, with issue 6961 being one example, there's well over one hundred thousand function calls being made in total for just the *two* pages.
2019-10-12 18:24:37 +09:00
if (!(resources instanceof Dict)) {
Incrementally render by sending the operator list by chunks as they're ready.
2013-08-01 03:17:36 +09:00
return false;
}
Doesn't traverse cyclic references in Dict.getAll; reduces empty-Dict garbage
2014-03-26 23:07:38 +09:00
var processed = Object.create(null);
if (resources.objId) {
processed[resources.objId] = true;
}
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
var nodes = [resources],
xref = this.xref;
Incrementally render by sending the operator list by chunks as they're ready.
2013-08-01 03:17:36 +09:00
while (nodes.length) {
var node = nodes.shift();
// First check the current resources for blend modes.
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
var graphicStates = node.get("ExtGState");
Inline all the possible type checks in `PartialEvaluator.hasBlendModes` to avoid unnecessary function calls For badly generated PDF documents, with issue 6961 being one example, there's well over one hundred thousand function calls being made in total for just the *two* pages.
2019-10-12 18:24:37 +09:00
if (graphicStates instanceof Dict) {
Replace `getAll` with `getKeys` in `PartialEvaluator_hasBlendModes` to speed up loading of badly generated PDF files (issue 6961) Some bad PDF generators, in particular "Scribus PDF", duplicates resources *a lot* at various levels of the PDF files. This can lead to `PartialEvaluator_hasBlendModes` taking an unreasonable amount of time to complete. The reason is that the current code is using `Dict_getAll`, which recursively dereferences *all* indirect objects, which can be really slow. This patch instead uses `Dict_getKeys`, and then manually looks up only the necessary indirect objects. I've added the PDF file as a `load` test. The most important thing here is probably to ensure that the file remains available in the repo, and the comment should help reduced the chance of regressions. (Note that locally, the `load` test times out without this patch, but we cannot really assume that that always happens.) Fixes 6961.
2016-02-10 01:09:17 +09:00
var graphicStatesKeys = graphicStates.getKeys();
Inline all the possible type checks in `PartialEvaluator.hasBlendModes` to avoid unnecessary function calls For badly generated PDF documents, with issue 6961 being one example, there's well over one hundred thousand function calls being made in total for just the *two* pages.
2019-10-12 18:24:37 +09:00
for (let i = 0, ii = graphicStatesKeys.length; i < ii; i++) {
const key = graphicStatesKeys[i];
Replace `getAll` with `getKeys` in `PartialEvaluator_hasBlendModes` to speed up loading of badly generated PDF files (issue 6961) Some bad PDF generators, in particular "Scribus PDF", duplicates resources *a lot* at various levels of the PDF files. This can lead to `PartialEvaluator_hasBlendModes` taking an unreasonable amount of time to complete. The reason is that the current code is using `Dict_getAll`, which recursively dereferences *all* indirect objects, which can be really slow. This patch instead uses `Dict_getKeys`, and then manually looks up only the necessary indirect objects. I've added the PDF file as a `load` test. The most important thing here is probably to ensure that the file remains available in the repo, and the comment should help reduced the chance of regressions. (Note that locally, the `load` test times out without this patch, but we cannot really assume that that always happens.) Fixes 6961.
2016-02-10 01:09:17 +09:00
Cache processed 'ExtGState's in `PartialEvaluator.hasBlendModes` to avoid unnecessary parsing/lookups This simply extends the already existing caching of processed resources to avoid duplicated parsing of 'ExtGState's, which should help with badly generated PDF documents. This patch was tested using the PDF file from issue 6961, i.e. https://github.com/mozilla/pdf.js/files/121712/test.pdf, with the following manifest file: ``` [ { "id": "issue6961", "file": "../web/pdfs/issue6961.pdf", "md5": "", "rounds": 200, "type": "eq" } ] ``` which gave the following *overall* results when comparing this patch against the `master` branch: ``` -- Grouped By browser, stat -- browser | stat | Count | Baseline(ms) | Current(ms) | +/- | % | Result(P<.05) ------- | ------------ | ----- | ------------ | ----------- | --- | ----- | ------------- Firefox | Overall | 400 | 1063 | 1051 | -12 | -1.17 | faster Firefox | Page Request | 400 | 552 | 543 | -9 | -1.69 | faster Firefox | Rendering | 400 | 511 | 508 | -3 | -0.61 | ``` and the following *page-specific* results: ``` -- Grouped By page, stat -- page | stat | Count | Baseline(ms) | Current(ms) | +/- | % | Result(P<.05) ---- | ------------ | ----- | ------------ | ----------- | --- | ----- | ------------- 0 | Overall | 200 | 1122 | 1110 | -12 | -1.03 | 0 | Page Request | 200 | 552 | 544 | -8 | -1.48 | faster 0 | Rendering | 200 | 570 | 566 | -4 | -0.62 | 1 | Overall | 200 | 1005 | 992 | -13 | -1.33 | faster 1 | Page Request | 200 | 552 | 542 | -11 | -1.91 | faster 1 | Rendering | 200 | 452 | 450 | -3 | -0.61 | ```
2019-10-12 18:44:07 +09:00
let graphicState = graphicStates.getRaw(key);
if (graphicState instanceof Ref) {
if (processed[graphicState.toString()]) {
continue; // The ExtGState has already been processed.
}
Prevent lookup errors in `PartialEvaluator.hasBlendModes` from breaking all parsing/rendering of a page (issue 11678) The PDF document in question is *corrupt*, since it contains an XObject with a truncated dictionary and where the stream contents start without a "stream" operator.
2020-03-09 19:37:33 +09:00
try {
graphicState = xref.fetch(graphicState);
} catch (ex) {
if (ex instanceof MissingDataException) {
throw ex;
}
if (this.options.ignoreErrors) {
if (graphicState instanceof Ref) {
// Avoid parsing a corrupt ExtGState more than once.
processed[graphicState.toString()] = true;
}
// Error(s) in the ExtGState -- sending unsupported feature
// notification and allow parsing/rendering to continue.
this.handler.send("UnsupportedFeature", {
Add more categories of unsupported features. Fixes #11815
2020-05-01 07:27:37 +09:00
featureId: UNSUPPORTED_FEATURES.errorExtGState,
Prevent lookup errors in `PartialEvaluator.hasBlendModes` from breaking all parsing/rendering of a page (issue 11678) The PDF document in question is *corrupt*, since it contains an XObject with a truncated dictionary and where the stream contents start without a "stream" operator.
2020-03-09 19:37:33 +09:00
});
warn(`hasBlendModes - ignoring ExtGState: "${ex}".`);
continue;
}
throw ex;
}
Cache processed 'ExtGState's in `PartialEvaluator.hasBlendModes` to avoid unnecessary parsing/lookups This simply extends the already existing caching of processed resources to avoid duplicated parsing of 'ExtGState's, which should help with badly generated PDF documents. This patch was tested using the PDF file from issue 6961, i.e. https://github.com/mozilla/pdf.js/files/121712/test.pdf, with the following manifest file: ``` [ { "id": "issue6961", "file": "../web/pdfs/issue6961.pdf", "md5": "", "rounds": 200, "type": "eq" } ] ``` which gave the following *overall* results when comparing this patch against the `master` branch: ``` -- Grouped By browser, stat -- browser | stat | Count | Baseline(ms) | Current(ms) | +/- | % | Result(P<.05) ------- | ------------ | ----- | ------------ | ----------- | --- | ----- | ------------- Firefox | Overall | 400 | 1063 | 1051 | -12 | -1.17 | faster Firefox | Page Request | 400 | 552 | 543 | -9 | -1.69 | faster Firefox | Rendering | 400 | 511 | 508 | -3 | -0.61 | ``` and the following *page-specific* results: ``` -- Grouped By page, stat -- page | stat | Count | Baseline(ms) | Current(ms) | +/- | % | Result(P<.05) ---- | ------------ | ----- | ------------ | ----------- | --- | ----- | ------------- 0 | Overall | 200 | 1122 | 1110 | -12 | -1.03 | 0 | Page Request | 200 | 552 | 544 | -8 | -1.48 | faster 0 | Rendering | 200 | 570 | 566 | -4 | -0.62 | 1 | Overall | 200 | 1005 | 992 | -13 | -1.33 | faster 1 | Page Request | 200 | 552 | 542 | -11 | -1.91 | faster 1 | Rendering | 200 | 452 | 450 | -3 | -0.61 | ```
2019-10-12 18:44:07 +09:00
}
if (!(graphicState instanceof Dict)) {
continue;
}
if (graphicState.objId) {
processed[graphicState.objId] = true;
}
Ensure that `PartialEvaluator.hasBlendModes` handles Blend Modes in Arrays (PR 11281 follow-up) I completely overlooked this in PR 11281, but you obviously need to make similar changes in `PartialEvaluator.hasBlendModes` since it will otherwise ignore valid Blend Modes.
2019-10-28 19:28:13 +09:00
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
const bm = graphicState.get("BM");
Ensure that `PartialEvaluator.hasBlendModes` handles Blend Modes in Arrays (PR 11281 follow-up) I completely overlooked this in PR 11281, but you obviously need to make similar changes in `PartialEvaluator.hasBlendModes` since it will otherwise ignore valid Blend Modes.
2019-10-28 19:28:13 +09:00
if (bm instanceof Name) {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
if (bm.name !== "Normal") {
Ensure that `PartialEvaluator.hasBlendModes` handles Blend Modes in Arrays (PR 11281 follow-up) I completely overlooked this in PR 11281, but you obviously need to make similar changes in `PartialEvaluator.hasBlendModes` since it will otherwise ignore valid Blend Modes.
2019-10-28 19:28:13 +09:00
return true;
}
continue;
}
if (bm !== undefined && Array.isArray(bm)) {
for (let j = 0, jj = bm.length; j < jj; j++) {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
if (bm[j] instanceof Name && bm[j].name !== "Normal") {
Ensure that `PartialEvaluator.hasBlendModes` handles Blend Modes in Arrays (PR 11281 follow-up) I completely overlooked this in PR 11281, but you obviously need to make similar changes in `PartialEvaluator.hasBlendModes` since it will otherwise ignore valid Blend Modes.
2019-10-28 19:28:13 +09:00
return true;
}
}
Incrementally render by sending the operator list by chunks as they're ready.
2013-08-01 03:17:36 +09:00
}
}
}
// Descend into the XObjects to look for more resources and blend modes.
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
var xObjects = node.get("XObject");
Inline all the possible type checks in `PartialEvaluator.hasBlendModes` to avoid unnecessary function calls For badly generated PDF documents, with issue 6961 being one example, there's well over one hundred thousand function calls being made in total for just the *two* pages.
2019-10-12 18:24:37 +09:00
if (!(xObjects instanceof Dict)) {
Incrementally render by sending the operator list by chunks as they're ready.
2013-08-01 03:17:36 +09:00
continue;
}
Replace `getAll` with `getKeys` in `PartialEvaluator_hasBlendModes` to speed up loading of badly generated PDF files (issue 6961) Some bad PDF generators, in particular "Scribus PDF", duplicates resources *a lot* at various levels of the PDF files. This can lead to `PartialEvaluator_hasBlendModes` taking an unreasonable amount of time to complete. The reason is that the current code is using `Dict_getAll`, which recursively dereferences *all* indirect objects, which can be really slow. This patch instead uses `Dict_getKeys`, and then manually looks up only the necessary indirect objects. I've added the PDF file as a `load` test. The most important thing here is probably to ensure that the file remains available in the repo, and the comment should help reduced the chance of regressions. (Note that locally, the `load` test times out without this patch, but we cannot really assume that that always happens.) Fixes 6961.
2016-02-10 01:09:17 +09:00
var xObjectsKeys = xObjects.getKeys();
Inline all the possible type checks in `PartialEvaluator.hasBlendModes` to avoid unnecessary function calls For badly generated PDF documents, with issue 6961 being one example, there's well over one hundred thousand function calls being made in total for just the *two* pages.
2019-10-12 18:24:37 +09:00
for (let i = 0, ii = xObjectsKeys.length; i < ii; i++) {
const key = xObjectsKeys[i];
Replace `getAll` with `getKeys` in `PartialEvaluator_hasBlendModes` to speed up loading of badly generated PDF files (issue 6961) Some bad PDF generators, in particular "Scribus PDF", duplicates resources *a lot* at various levels of the PDF files. This can lead to `PartialEvaluator_hasBlendModes` taking an unreasonable amount of time to complete. The reason is that the current code is using `Dict_getAll`, which recursively dereferences *all* indirect objects, which can be really slow. This patch instead uses `Dict_getKeys`, and then manually looks up only the necessary indirect objects. I've added the PDF file as a `load` test. The most important thing here is probably to ensure that the file remains available in the repo, and the comment should help reduced the chance of regressions. (Note that locally, the `load` test times out without this patch, but we cannot really assume that that always happens.) Fixes 6961.
2016-02-10 01:09:17 +09:00
var xObject = xObjects.getRaw(key);
Inline all the possible type checks in `PartialEvaluator.hasBlendModes` to avoid unnecessary function calls For badly generated PDF documents, with issue 6961 being one example, there's well over one hundred thousand function calls being made in total for just the *two* pages.
2019-10-12 18:24:37 +09:00
if (xObject instanceof Ref) {
Replace `getAll` with `getKeys` in `PartialEvaluator_hasBlendModes` to speed up loading of badly generated PDF files (issue 6961) Some bad PDF generators, in particular "Scribus PDF", duplicates resources *a lot* at various levels of the PDF files. This can lead to `PartialEvaluator_hasBlendModes` taking an unreasonable amount of time to complete. The reason is that the current code is using `Dict_getAll`, which recursively dereferences *all* indirect objects, which can be really slow. This patch instead uses `Dict_getKeys`, and then manually looks up only the necessary indirect objects. I've added the PDF file as a `load` test. The most important thing here is probably to ensure that the file remains available in the repo, and the comment should help reduced the chance of regressions. (Note that locally, the `load` test times out without this patch, but we cannot really assume that that always happens.) Fixes 6961.
2016-02-10 01:09:17 +09:00
if (processed[xObject.toString()]) {
// The XObject has already been processed, and by avoiding a
// redundant `xref.fetch` we can *significantly* reduce the load
// time for badly generated PDF files (fixes issue6961.pdf).
continue;
}
Prevent lookup errors in `PartialEvaluator.hasBlendModes` from breaking all parsing/rendering of a page (issue 11678) The PDF document in question is *corrupt*, since it contains an XObject with a truncated dictionary and where the stream contents start without a "stream" operator.
2020-03-09 19:37:33 +09:00
try {
xObject = xref.fetch(xObject);
} catch (ex) {
if (ex instanceof MissingDataException) {
throw ex;
}
if (this.options.ignoreErrors) {
if (xObject instanceof Ref) {
// Avoid parsing a corrupt XObject more than once.
processed[xObject.toString()] = true;
}
// Error(s) in the XObject -- sending unsupported feature
// notification and allow parsing/rendering to continue.
this.handler.send("UnsupportedFeature", {
Add more categories of unsupported features. Fixes #11815
2020-05-01 07:27:37 +09:00
featureId: UNSUPPORTED_FEATURES.errorXObject,
Prevent lookup errors in `PartialEvaluator.hasBlendModes` from breaking all parsing/rendering of a page (issue 11678) The PDF document in question is *corrupt*, since it contains an XObject with a truncated dictionary and where the stream contents start without a "stream" operator.
2020-03-09 19:37:33 +09:00
});
warn(`hasBlendModes - ignoring XObject: "${ex}".`);
continue;
}
throw ex;
}
Replace `getAll` with `getKeys` in `PartialEvaluator_hasBlendModes` to speed up loading of badly generated PDF files (issue 6961) Some bad PDF generators, in particular "Scribus PDF", duplicates resources *a lot* at various levels of the PDF files. This can lead to `PartialEvaluator_hasBlendModes` taking an unreasonable amount of time to complete. The reason is that the current code is using `Dict_getAll`, which recursively dereferences *all* indirect objects, which can be really slow. This patch instead uses `Dict_getKeys`, and then manually looks up only the necessary indirect objects. I've added the PDF file as a `load` test. The most important thing here is probably to ensure that the file remains available in the repo, and the comment should help reduced the chance of regressions. (Note that locally, the `load` test times out without this patch, but we cannot really assume that that always happens.) Fixes 6961.
2016-02-10 01:09:17 +09:00
}
Incrementally render by sending the operator list by chunks as they're ready.
2013-08-01 03:17:36 +09:00
if (!isStream(xObject)) {
continue;
}
add object id to streams to prevent infinite loops. fixes http://bugzil.la/1020858
2014-06-10 18:29:25 +09:00
if (xObject.dict.objId) {
if (processed[xObject.dict.objId]) {
Inline all the possible type checks in `PartialEvaluator.hasBlendModes` to avoid unnecessary function calls For badly generated PDF documents, with issue 6961 being one example, there's well over one hundred thousand function calls being made in total for just the *two* pages.
2019-10-12 18:24:37 +09:00
continue; // Stream has objId and was processed already.
add object id to streams to prevent infinite loops. fixes http://bugzil.la/1020858
2014-06-10 18:29:25 +09:00
}
processed[xObject.dict.objId] = true;
}
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
var xResources = xObject.dict.get("Resources");
Doesn't traverse cyclic references in Dict.getAll; reduces empty-Dict garbage
2014-03-26 23:07:38 +09:00
// Checking objId to detect an infinite loop.
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
if (
xResources instanceof Dict &&
(!xResources.objId || !processed[xResources.objId])
) {
Incrementally render by sending the operator list by chunks as they're ready.
2013-08-01 03:17:36 +09:00
nodes.push(xResources);
Doesn't traverse cyclic references in Dict.getAll; reduces empty-Dict garbage
2014-03-26 23:07:38 +09:00
if (xResources.objId) {
processed[xResources.objId] = true;
}
Incrementally render by sending the operator list by chunks as they're ready.
2013-08-01 03:17:36 +09:00
}
}
}
return false;
},
Refactor text extraction / font loading logic
2012-09-14 00:09:46 +09:00
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
async buildFormXObject(
resources,
xobj,
smask,
operatorList,
task,
Add local caching of `ColorSpace`s, by name, in `PartialEvaluator.getOperatorList` (issue 2504) By caching parsed `ColorSpace`s, we thus don't need to re-parse the same data over and over which saves CPU cycles *and* reduces peak memory usage. (Obviously persistent memory usage *may* increase a tiny bit, but since the caching is done per `PartialEvaluator.getOperatorList` invocation and given that `ColorSpace` instances generally hold very little data this shouldn't be much of an issue.) Furthermore, by caching `ColorSpace`s we can also lookup the already parsed ones *synchronously* during the `OperatorList` building, instead of having to defer to the event loop/microtask queue since the parsing is done asynchronously (such that error handling is easier). Possible future improvements: - Cache/lookup parsed `ColorSpaces` used in `Pattern`s and `Image`s. - Attempt to cache *local* `ColorSpace`s by reference as well, in addition to only by name, assuming that there's documents where that would be beneficial and that it's not too difficult to implement. - Assuming there's documents that would benefit from it, also cache repeated `ColorSpace`s *globally* as well. Given that we've never, until now, been doing *any* caching of parsed `ColorSpace`s and that even using a simple name-only *local* cache helps tremendously in pathological cases, I purposely decided against complicating the implementation too much initially. Also, compared to parsing of `Image`s, simply creating a `ColorSpace` instance isn't that expensive (hence I'd be somewhat surprised if adding a *global* cache would help much). --- This patch was tested using: - The default `tracemonkey` PDF file, which was included mostly to show that "normal" documents aren't negatively affected by these changes. - The PDF file from issue 2504, i.e. https://dl-ctlg.panasonic.com/jp/manual/sd/sd_rbm1000_0.pdf, where most pages will switch *thousands* of times between a handful of `ColorSpace`s. with the following manifest file: ``` [ { "id": "tracemonkey", "file": "pdfs/tracemonkey.pdf", "md5": "9a192d8b1a7dc652a19835f6f08098bd", "rounds": 100, "type": "eq" }, { "id": "issue2504", "file": "../web/pdfs/issue2504.pdf", "md5": "", "rounds": 20, "type": "eq" } ] ``` which gave the following results when comparing this patch against the `master` branch: - Overall ``` -- Grouped By browser, pdf, stat -- browser | pdf | stat | Count | Baseline(ms) | Current(ms) | +/- | % | Result(P<.05) ------- | ----------- | ------------ | ----- | ------------ | ----------- | ---- | ------ | ------------- firefox | issue2504 | Overall | 640 | 977 | 497 | -479 | -49.08 | faster firefox | issue2504 | Page Request | 640 | 3 | 4 | 1 | 59.18 | firefox | issue2504 | Rendering | 640 | 974 | 493 | -481 | -49.37 | faster firefox | tracemonkey | Overall | 1400 | 116 | 111 | -5 | -4.43 | firefox | tracemonkey | Page Request | 1400 | 2 | 2 | 0 | -2.86 | firefox | tracemonkey | Rendering | 1400 | 114 | 109 | -5 | -4.47 | ``` - Page-specific ``` -- Grouped By browser, pdf, page, stat -- browser | pdf | page | stat | Count | Baseline(ms) | Current(ms) | +/- | % | Result(P<.05) ------- | ----------- | ---- | ------------ | ----- | ------------ | ----------- | ----- | ------- | ------------- firefox | issue2504 | 0 | Overall | 20 | 2295 | 1268 | -1027 | -44.76 | faster firefox | issue2504 | 0 | Page Request | 20 | 6 | 7 | 1 | 15.32 | firefox | issue2504 | 0 | Rendering | 20 | 2288 | 1260 | -1028 | -44.93 | faster firefox | issue2504 | 1 | Overall | 20 | 3059 | 2806 | -252 | -8.25 | faster firefox | issue2504 | 1 | Page Request | 20 | 11 | 14 | 3 | 23.25 | slower firefox | issue2504 | 1 | Rendering | 20 | 3047 | 2792 | -255 | -8.37 | faster firefox | issue2504 | 2 | Overall | 20 | 411 | 295 | -116 | -28.20 | faster firefox | issue2504 | 2 | Page Request | 20 | 2 | 42 | 40 | 1897.62 | firefox | issue2504 | 2 | Rendering | 20 | 409 | 253 | -156 | -38.09 | faster firefox | issue2504 | 3 | Overall | 20 | 736 | 299 | -437 | -59.34 | faster firefox | issue2504 | 3 | Page Request | 20 | 2 | 2 | 0 | 0.00 | firefox | issue2504 | 3 | Rendering | 20 | 734 | 297 | -437 | -59.49 | faster firefox | issue2504 | 4 | Overall | 20 | 356 | 458 | 102 | 28.63 | firefox | issue2504 | 4 | Page Request | 20 | 1 | 2 | 1 | 57.14 | slower firefox | issue2504 | 4 | Rendering | 20 | 354 | 455 | 101 | 28.53 | firefox | issue2504 | 5 | Overall | 20 | 1381 | 765 | -616 | -44.59 | faster firefox | issue2504 | 5 | Page Request | 20 | 3 | 5 | 2 | 50.00 | slower firefox | issue2504 | 5 | Rendering | 20 | 1378 | 760 | -617 | -44.81 | faster firefox | issue2504 | 6 | Overall | 20 | 757 | 299 | -459 | -60.57 | faster firefox | issue2504 | 6 | Page Request | 20 | 2 | 5 | 3 | 150.00 | slower firefox | issue2504 | 6 | Rendering | 20 | 755 | 294 | -462 | -61.11 | faster firefox | issue2504 | 7 | Overall | 20 | 394 | 302 | -92 | -23.39 | faster firefox | issue2504 | 7 | Page Request | 20 | 2 | 1 | -1 | -34.88 | faster firefox | issue2504 | 7 | Rendering | 20 | 392 | 301 | -91 | -23.32 | faster firefox | issue2504 | 8 | Overall | 20 | 2875 | 979 | -1896 | -65.95 | faster firefox | issue2504 | 8 | Page Request | 20 | 1 | 2 | 0 | 11.11 | firefox | issue2504 | 8 | Rendering | 20 | 2874 | 978 | -1896 | -65.99 | faster firefox | issue2504 | 9 | Overall | 20 | 700 | 332 | -368 | -52.60 | faster firefox | issue2504 | 9 | Page Request | 20 | 3 | 2 | 0 | -4.00 | firefox | issue2504 | 9 | Rendering | 20 | 698 | 329 | -368 | -52.78 | faster firefox | issue2504 | 10 | Overall | 20 | 3296 | 926 | -2370 | -71.91 | faster firefox | issue2504 | 10 | Page Request | 20 | 2 | 2 | 0 | -18.75 | firefox | issue2504 | 10 | Rendering | 20 | 3293 | 924 | -2370 | -71.96 | faster firefox | issue2504 | 11 | Overall | 20 | 524 | 197 | -327 | -62.34 | faster firefox | issue2504 | 11 | Page Request | 20 | 2 | 3 | 1 | 58.54 | firefox | issue2504 | 11 | Rendering | 20 | 522 | 194 | -328 | -62.81 | faster firefox | issue2504 | 12 | Overall | 20 | 752 | 369 | -384 | -50.98 | faster firefox | issue2504 | 12 | Page Request | 20 | 3 | 2 | -1 | -36.51 | faster firefox | issue2504 | 12 | Rendering | 20 | 749 | 367 | -382 | -51.05 | faster firefox | issue2504 | 13 | Overall | 20 | 679 | 487 | -193 | -28.38 | faster firefox | issue2504 | 13 | Page Request | 20 | 4 | 2 | -2 | -48.68 | faster firefox | issue2504 | 13 | Rendering | 20 | 676 | 485 | -191 | -28.28 | faster firefox | issue2504 | 14 | Overall | 20 | 474 | 283 | -191 | -40.26 | faster firefox | issue2504 | 14 | Page Request | 20 | 2 | 4 | 2 | 78.57 | firefox | issue2504 | 14 | Rendering | 20 | 471 | 279 | -192 | -40.79 | faster firefox | issue2504 | 15 | Overall | 20 | 860 | 618 | -241 | -28.05 | faster firefox | issue2504 | 15 | Page Request | 20 | 2 | 3 | 0 | 10.87 | firefox | issue2504 | 15 | Rendering | 20 | 857 | 616 | -241 | -28.15 | faster firefox | issue2504 | 16 | Overall | 20 | 389 | 243 | -147 | -37.71 | faster firefox | issue2504 | 16 | Page Request | 20 | 2 | 2 | 0 | 2.33 | firefox | issue2504 | 16 | Rendering | 20 | 387 | 240 | -147 | -37.94 | faster firefox | issue2504 | 17 | Overall | 20 | 1484 | 672 | -812 | -54.70 | faster firefox | issue2504 | 17 | Page Request | 20 | 2 | 3 | 1 | 37.21 | firefox | issue2504 | 17 | Rendering | 20 | 1482 | 669 | -812 | -54.84 | faster firefox | issue2504 | 18 | Overall | 20 | 575 | 252 | -323 | -56.12 | faster firefox | issue2504 | 18 | Page Request | 20 | 2 | 2 | 0 | -16.22 | firefox | issue2504 | 18 | Rendering | 20 | 573 | 251 | -322 | -56.24 | faster firefox | issue2504 | 19 | Overall | 20 | 517 | 227 | -290 | -56.08 | faster firefox | issue2504 | 19 | Page Request | 20 | 2 | 2 | 0 | 21.62 | firefox | issue2504 | 19 | Rendering | 20 | 515 | 225 | -290 | -56.37 | faster firefox | issue2504 | 20 | Overall | 20 | 668 | 670 | 2 | 0.31 | firefox | issue2504 | 20 | Page Request | 20 | 4 | 2 | -1 | -34.29 | firefox | issue2504 | 20 | Rendering | 20 | 664 | 667 | 3 | 0.49 | firefox | issue2504 | 21 | Overall | 20 | 486 | 309 | -177 | -36.44 | faster firefox | issue2504 | 21 | Page Request | 20 | 2 | 2 | 0 | 16.13 | firefox | issue2504 | 21 | Rendering | 20 | 484 | 307 | -177 | -36.60 | faster firefox | issue2504 | 22 | Overall | 20 | 543 | 267 | -276 | -50.85 | faster firefox | issue2504 | 22 | Page Request | 20 | 2 | 2 | 0 | 10.26 | firefox | issue2504 | 22 | Rendering | 20 | 541 | 265 | -276 | -51.07 | faster firefox | issue2504 | 23 | Overall | 20 | 3246 | 871 | -2375 | -73.17 | faster firefox | issue2504 | 23 | Page Request | 20 | 2 | 3 | 1 | 37.21 | firefox | issue2504 | 23 | Rendering | 20 | 3243 | 868 | -2376 | -73.25 | faster firefox | issue2504 | 24 | Overall | 20 | 379 | 156 | -223 | -58.83 | faster firefox | issue2504 | 24 | Page Request | 20 | 2 | 2 | 0 | -2.86 | firefox | issue2504 | 24 | Rendering | 20 | 378 | 154 | -223 | -59.10 | faster firefox | issue2504 | 25 | Overall | 20 | 176 | 127 | -50 | -28.19 | faster firefox | issue2504 | 25 | Page Request | 20 | 2 | 1 | 0 | -15.63 | firefox | issue2504 | 25 | Rendering | 20 | 175 | 125 | -49 | -28.31 | faster firefox | issue2504 | 26 | Overall | 20 | 181 | 108 | -74 | -40.67 | faster firefox | issue2504 | 26 | Page Request | 20 | 3 | 2 | -1 | -39.13 | faster firefox | issue2504 | 26 | Rendering | 20 | 178 | 105 | -72 | -40.69 | faster firefox | issue2504 | 27 | Overall | 20 | 208 | 104 | -104 | -49.92 | faster firefox | issue2504 | 27 | Page Request | 20 | 2 | 2 | 1 | 48.39 | firefox | issue2504 | 27 | Rendering | 20 | 206 | 102 | -104 | -50.64 | faster firefox | issue2504 | 28 | Overall | 20 | 241 | 111 | -131 | -54.16 | faster firefox | issue2504 | 28 | Page Request | 20 | 2 | 2 | -1 | -33.33 | firefox | issue2504 | 28 | Rendering | 20 | 239 | 109 | -130 | -54.39 | faster firefox | issue2504 | 29 | Overall | 20 | 321 | 196 | -125 | -39.05 | faster firefox | issue2504 | 29 | Page Request | 20 | 1 | 2 | 0 | 17.86 | firefox | issue2504 | 29 | Rendering | 20 | 319 | 194 | -126 | -39.35 | faster firefox | issue2504 | 30 | Overall | 20 | 651 | 271 | -380 | -58.41 | faster firefox | issue2504 | 30 | Page Request | 20 | 1 | 2 | 1 | 50.00 | firefox | issue2504 | 30 | Rendering | 20 | 649 | 269 | -381 | -58.60 | faster firefox | issue2504 | 31 | Overall | 20 | 1635 | 647 | -988 | -60.42 | faster firefox | issue2504 | 31 | Page Request | 20 | 1 | 2 | 0 | 30.43 | firefox | issue2504 | 31 | Rendering | 20 | 1634 | 645 | -988 | -60.49 | faster firefox | tracemonkey | 0 | Overall | 100 | 51 | 51 | 0 | 0.02 | firefox | tracemonkey | 0 | Page Request | 100 | 1 | 1 | 0 | -4.76 | firefox | tracemonkey | 0 | Rendering | 100 | 50 | 50 | 0 | 0.12 | firefox | tracemonkey | 1 | Overall | 100 | 97 | 91 | -5 | -5.52 | faster firefox | tracemonkey | 1 | Page Request | 100 | 3 | 3 | 0 | -1.32 | firefox | tracemonkey | 1 | Rendering | 100 | 94 | 88 | -5 | -5.73 | faster firefox | tracemonkey | 2 | Overall | 100 | 40 | 40 | 0 | 0.50 | firefox | tracemonkey | 2 | Page Request | 100 | 1 | 1 | 0 | 3.16 | firefox | tracemonkey | 2 | Rendering | 100 | 39 | 39 | 0 | 0.54 | firefox | tracemonkey | 3 | Overall | 100 | 62 | 62 | -1 | -0.94 | firefox | tracemonkey | 3 | Page Request | 100 | 1 | 1 | 0 | 17.05 | firefox | tracemonkey | 3 | Rendering | 100 | 61 | 61 | -1 | -1.11 | firefox | tracemonkey | 4 | Overall | 100 | 56 | 58 | 2 | 3.41 | firefox | tracemonkey | 4 | Page Request | 100 | 1 | 1 | 0 | 15.31 | firefox | tracemonkey | 4 | Rendering | 100 | 55 | 57 | 2 | 3.23 | firefox | tracemonkey | 5 | Overall | 100 | 73 | 71 | -2 | -2.28 | firefox | tracemonkey | 5 | Page Request | 100 | 2 | 2 | 0 | 12.20 | firefox | tracemonkey | 5 | Rendering | 100 | 71 | 69 | -2 | -2.69 | firefox | tracemonkey | 6 | Overall | 100 | 85 | 69 | -16 | -18.73 | faster firefox | tracemonkey | 6 | Page Request | 100 | 2 | 2 | 0 | -9.90 | firefox | tracemonkey | 6 | Rendering | 100 | 83 | 67 | -16 | -18.97 | faster firefox | tracemonkey | 7 | Overall | 100 | 65 | 64 | 0 | -0.37 | firefox | tracemonkey | 7 | Page Request | 100 | 1 | 1 | 0 | -11.94 | firefox | tracemonkey | 7 | Rendering | 100 | 63 | 63 | 0 | -0.05 | firefox | tracemonkey | 8 | Overall | 100 | 53 | 54 | 1 | 2.04 | firefox | tracemonkey | 8 | Page Request | 100 | 1 | 1 | 0 | 17.02 | firefox | tracemonkey | 8 | Rendering | 100 | 52 | 53 | 1 | 1.82 | firefox | tracemonkey | 9 | Overall | 100 | 79 | 73 | -6 | -7.86 | faster firefox | tracemonkey | 9 | Page Request | 100 | 2 | 2 | 0 | -15.14 | firefox | tracemonkey | 9 | Rendering | 100 | 77 | 71 | -6 | -7.86 | faster firefox | tracemonkey | 10 | Overall | 100 | 545 | 519 | -27 | -4.86 | faster firefox | tracemonkey | 10 | Page Request | 100 | 14 | 13 | 0 | -3.56 | firefox | tracemonkey | 10 | Rendering | 100 | 532 | 506 | -26 | -4.90 | faster firefox | tracemonkey | 11 | Overall | 100 | 42 | 41 | -1 | -2.50 | firefox | tracemonkey | 11 | Page Request | 100 | 1 | 1 | 0 | -27.42 | faster firefox | tracemonkey | 11 | Rendering | 100 | 41 | 40 | -1 | -1.75 | firefox | tracemonkey | 12 | Overall | 100 | 350 | 332 | -18 | -5.16 | faster firefox | tracemonkey | 12 | Page Request | 100 | 3 | 3 | 0 | -5.17 | firefox | tracemonkey | 12 | Rendering | 100 | 347 | 329 | -18 | -5.15 | faster firefox | tracemonkey | 13 | Overall | 100 | 31 | 31 | 0 | 0.52 | firefox | tracemonkey | 13 | Page Request | 100 | 1 | 1 | 0 | 4.95 | firefox | tracemonkey | 13 | Rendering | 100 | 30 | 30 | 0 | 0.20 | ```
2020-06-13 21:12:40 +09:00
initialState,
localColorSpaceCache
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
) {
[api-minor] Always allow e.g. rendering to continue even if there are errors, and add a `stopAtErrors` parameter to `getDocument` to opt-out of this behaviour (issue 6342, issue 3795, bug 1130815) Other PDF readers, e.g. Adobe Reader and PDFium (in Chrome), will attempt to render as much of a page as possible even if there are errors present. Currently we just bail as soon the first error is hit, which means that we'll usually not render anything in these cases and just display a blank page instead. NOTE: This patch changes the default behaviour of the PDF.js API to always attempt to recover as much data as possible, even when encountering errors during e.g. `getOperatorList`/`getTextContent`, which thus improve our handling of corrupt PDF files and allow the default viewer to handle errors slightly more gracefully. In the event that an API consumer wishes to use the old behaviour, where we stop parsing as soon as an error is encountered, the `stopAtErrors` parameter can be set at `getDocument`. Fixes, inasmuch it's possible since the PDF files are corrupt, e.g. issue 6342, issue 3795, and [bug 1130815](https://bugzilla.mozilla.org/show_bug.cgi?id=1130815) (and probably others too).
2017-02-19 22:03:08 +09:00
var dict = xobj.dict;
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
var matrix = dict.getArray("Matrix");
var bbox = dict.getArray("BBox");
Normalize the BBox of form XObjects on the /core side
2018-10-16 22:23:14 +09:00
if (Array.isArray(bbox) && bbox.length === 4) {
bbox = Util.normalizeRect(bbox);
} else {
bbox = null;
}
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
var group = dict.get("Group");
Make getOperatorList() calls independent and merge queues at end
2013-04-09 07:14:56 +09:00
if (group) {
var groupOptions = {
Enable the `object-shorthand` ESLint rule in `src/shared` Please see http://eslint.org/docs/rules/object-shorthand. For the most part, these changes are of the search-and-replace kind, and the previously enabled `no-undef` rule should complement the tests in helping ensure that no stupid errors crept into to the patch.
2017-04-27 19:58:44 +09:00
matrix,
bbox,
smask,
Make getOperatorList() calls independent and merge queues at end
2013-04-09 07:14:56 +09:00
isolated: false,
Fix inconsistent spacing and trailing commas in objects in `src/core/` files, so we can enable the `comma-dangle` and `object-curly-spacing` ESLint rules later on *Unfortunately this patch is fairly big, even though it only covers the `src/core` folder, but splitting it even further seemed difficult.* http://eslint.org/docs/rules/comma-dangle http://eslint.org/docs/rules/object-curly-spacing Given that we currently have quite inconsistent object formatting, fixing this in *one* big patch probably wouldn't be feasible (since I cannot imagine anyone wanting to review that); hence I've opted to try and do this piecewise instead. Please note: This patch was created automatically, using the ESLint --fix command line option. In a couple of places this caused lines to become too long, and I've fixed those manually; please refer to the interdiff below for the only hand-edits in this patch. ```diff diff --git a/src/core/evaluator.js b/src/core/evaluator.js index abab9027..dcd3594b 100644 --- a/src/core/evaluator.js +++ b/src/core/evaluator.js @@ -2785,7 +2785,8 @@ var EvaluatorPreprocessor = (function EvaluatorPreprocessorClosure() { t['Tz'] = { id: OPS.setHScale, numArgs: 1, variableArgs: false, }; t['TL'] = { id: OPS.setLeading, numArgs: 1, variableArgs: false, }; t['Tf'] = { id: OPS.setFont, numArgs: 2, variableArgs: false, }; - t['Tr'] = { id: OPS.setTextRenderingMode, numArgs: 1, variableArgs: false, }; + t['Tr'] = { id: OPS.setTextRenderingMode, numArgs: 1, + variableArgs: false, }; t['Ts'] = { id: OPS.setTextRise, numArgs: 1, variableArgs: false, }; t['Td'] = { id: OPS.moveText, numArgs: 2, variableArgs: false, }; t['TD'] = { id: OPS.setLeadingMoveText, numArgs: 2, variableArgs: false, }; diff --git a/src/core/jbig2.js b/src/core/jbig2.js index 5a17d482..71671541 100644 --- a/src/core/jbig2.js +++ b/src/core/jbig2.js @@ -123,19 +123,22 @@ var Jbig2Image = (function Jbig2ImageClosure() { { x: -1, y: -1, }, { x: 0, y: -1, }, { x: 1, y: -1, }, { x: -2, y: 0, }, { x: -1, y: 0, }], [{ x: -3, y: -1, }, { x: -2, y: -1, }, { x: -1, y: -1, }, { x: 0, y: -1, }, - { x: 1, y: -1, }, { x: -4, y: 0, }, { x: -3, y: 0, }, { x: -2, y: 0, }, { x: -1, y: 0, }] + { x: 1, y: -1, }, { x: -4, y: 0, }, { x: -3, y: 0, }, { x: -2, y: 0, }, + { x: -1, y: 0, }] ]; var RefinementTemplates = [ { coding: [{ x: 0, y: -1, }, { x: 1, y: -1, }, { x: -1, y: 0, }], - reference: [{ x: 0, y: -1, }, { x: 1, y: -1, }, { x: -1, y: 0, }, { x: 0, y: 0, }, - { x: 1, y: 0, }, { x: -1, y: 1, }, { x: 0, y: 1, }, { x: 1, y: 1, }], + reference: [{ x: 0, y: -1, }, { x: 1, y: -1, }, { x: -1, y: 0, }, + { x: 0, y: 0, }, { x: 1, y: 0, }, { x: -1, y: 1, }, + { x: 0, y: 1, }, { x: 1, y: 1, }], }, { - coding: [{ x: -1, y: -1, }, { x: 0, y: -1, }, { x: 1, y: -1, }, { x: -1, y: 0, }], - reference: [{ x: 0, y: -1, }, { x: -1, y: 0, }, { x: 0, y: 0, }, { x: 1, y: 0, }, - { x: 0, y: 1, }, { x: 1, y: 1, }], + coding: [{ x: -1, y: -1, }, { x: 0, y: -1, }, { x: 1, y: -1, }, + { x: -1, y: 0, }], + reference: [{ x: 0, y: -1, }, { x: -1, y: 0, }, { x: 0, y: 0, }, + { x: 1, y: 0, }, { x: 0, y: 1, }, { x: 1, y: 1, }], } ]; ```
2017-06-02 18:16:24 +09:00
knockout: false,
Falls back to ErrorFont when font object is not available or corrupted
2012-10-16 01:48:45 +09:00
};
Make getOperatorList() calls independent and merge queues at end
2013-04-09 07:14:56 +09:00
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
var groupSubtype = group.get("S");
Split the existing `PDFFunction` in two classes, a private `PDFFunction` and a public `PDFFunctionFactory``, and utilize the latter in `PDFDocument` to allow various code to access the methods of `PDFFunction` *Follow-up to PR 8909.* This requires us to pass around `pdfFunctionFactory` to quite a lot of existing code, however I don't see another way of handling this while still guaranteeing that we can access `PDFFunction` as freely as in the old code. Please note that the patch passes all tests locally (unit, font, reference), and I *very* much hope that we have sufficient test-coverage for the code in question to catch any typos/mistakes in the re-factoring.
2017-09-19 20:49:30 +09:00
var colorSpace = null;
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
if (isName(groupSubtype, "Transparency")) {
groupOptions.isolated = group.get("I") || false;
groupOptions.knockout = group.get("K") || false;
if (group.has("CS")) {
Add local caching of `ColorSpace`s, by name, in `PartialEvaluator.getOperatorList` (issue 2504) By caching parsed `ColorSpace`s, we thus don't need to re-parse the same data over and over which saves CPU cycles *and* reduces peak memory usage. (Obviously persistent memory usage *may* increase a tiny bit, but since the caching is done per `PartialEvaluator.getOperatorList` invocation and given that `ColorSpace` instances generally hold very little data this shouldn't be much of an issue.) Furthermore, by caching `ColorSpace`s we can also lookup the already parsed ones *synchronously* during the `OperatorList` building, instead of having to defer to the event loop/microtask queue since the parsing is done asynchronously (such that error handling is easier). Possible future improvements: - Cache/lookup parsed `ColorSpaces` used in `Pattern`s and `Image`s. - Attempt to cache *local* `ColorSpace`s by reference as well, in addition to only by name, assuming that there's documents where that would be beneficial and that it's not too difficult to implement. - Assuming there's documents that would benefit from it, also cache repeated `ColorSpace`s *globally* as well. Given that we've never, until now, been doing *any* caching of parsed `ColorSpace`s and that even using a simple name-only *local* cache helps tremendously in pathological cases, I purposely decided against complicating the implementation too much initially. Also, compared to parsing of `Image`s, simply creating a `ColorSpace` instance isn't that expensive (hence I'd be somewhat surprised if adding a *global* cache would help much). --- This patch was tested using: - The default `tracemonkey` PDF file, which was included mostly to show that "normal" documents aren't negatively affected by these changes. - The PDF file from issue 2504, i.e. https://dl-ctlg.panasonic.com/jp/manual/sd/sd_rbm1000_0.pdf, where most pages will switch *thousands* of times between a handful of `ColorSpace`s. with the following manifest file: ``` [ { "id": "tracemonkey", "file": "pdfs/tracemonkey.pdf", "md5": "9a192d8b1a7dc652a19835f6f08098bd", "rounds": 100, "type": "eq" }, { "id": "issue2504", "file": "../web/pdfs/issue2504.pdf", "md5": "", "rounds": 20, "type": "eq" } ] ``` which gave the following results when comparing this patch against the `master` branch: - Overall ``` -- Grouped By browser, pdf, stat -- browser | pdf | stat | Count | Baseline(ms) | Current(ms) | +/- | % | Result(P<.05) ------- | ----------- | ------------ | ----- | ------------ | ----------- | ---- | ------ | ------------- firefox | issue2504 | Overall | 640 | 977 | 497 | -479 | -49.08 | faster firefox | issue2504 | Page Request | 640 | 3 | 4 | 1 | 59.18 | firefox | issue2504 | Rendering | 640 | 974 | 493 | -481 | -49.37 | faster firefox | tracemonkey | Overall | 1400 | 116 | 111 | -5 | -4.43 | firefox | tracemonkey | Page Request | 1400 | 2 | 2 | 0 | -2.86 | firefox | tracemonkey | Rendering | 1400 | 114 | 109 | -5 | -4.47 | ``` - Page-specific ``` -- Grouped By browser, pdf, page, stat -- browser | pdf | page | stat | Count | Baseline(ms) | Current(ms) | +/- | % | Result(P<.05) ------- | ----------- | ---- | ------------ | ----- | ------------ | ----------- | ----- | ------- | ------------- firefox | issue2504 | 0 | Overall | 20 | 2295 | 1268 | -1027 | -44.76 | faster firefox | issue2504 | 0 | Page Request | 20 | 6 | 7 | 1 | 15.32 | firefox | issue2504 | 0 | Rendering | 20 | 2288 | 1260 | -1028 | -44.93 | faster firefox | issue2504 | 1 | Overall | 20 | 3059 | 2806 | -252 | -8.25 | faster firefox | issue2504 | 1 | Page Request | 20 | 11 | 14 | 3 | 23.25 | slower firefox | issue2504 | 1 | Rendering | 20 | 3047 | 2792 | -255 | -8.37 | faster firefox | issue2504 | 2 | Overall | 20 | 411 | 295 | -116 | -28.20 | faster firefox | issue2504 | 2 | Page Request | 20 | 2 | 42 | 40 | 1897.62 | firefox | issue2504 | 2 | Rendering | 20 | 409 | 253 | -156 | -38.09 | faster firefox | issue2504 | 3 | Overall | 20 | 736 | 299 | -437 | -59.34 | faster firefox | issue2504 | 3 | Page Request | 20 | 2 | 2 | 0 | 0.00 | firefox | issue2504 | 3 | Rendering | 20 | 734 | 297 | -437 | -59.49 | faster firefox | issue2504 | 4 | Overall | 20 | 356 | 458 | 102 | 28.63 | firefox | issue2504 | 4 | Page Request | 20 | 1 | 2 | 1 | 57.14 | slower firefox | issue2504 | 4 | Rendering | 20 | 354 | 455 | 101 | 28.53 | firefox | issue2504 | 5 | Overall | 20 | 1381 | 765 | -616 | -44.59 | faster firefox | issue2504 | 5 | Page Request | 20 | 3 | 5 | 2 | 50.00 | slower firefox | issue2504 | 5 | Rendering | 20 | 1378 | 760 | -617 | -44.81 | faster firefox | issue2504 | 6 | Overall | 20 | 757 | 299 | -459 | -60.57 | faster firefox | issue2504 | 6 | Page Request | 20 | 2 | 5 | 3 | 150.00 | slower firefox | issue2504 | 6 | Rendering | 20 | 755 | 294 | -462 | -61.11 | faster firefox | issue2504 | 7 | Overall | 20 | 394 | 302 | -92 | -23.39 | faster firefox | issue2504 | 7 | Page Request | 20 | 2 | 1 | -1 | -34.88 | faster firefox | issue2504 | 7 | Rendering | 20 | 392 | 301 | -91 | -23.32 | faster firefox | issue2504 | 8 | Overall | 20 | 2875 | 979 | -1896 | -65.95 | faster firefox | issue2504 | 8 | Page Request | 20 | 1 | 2 | 0 | 11.11 | firefox | issue2504 | 8 | Rendering | 20 | 2874 | 978 | -1896 | -65.99 | faster firefox | issue2504 | 9 | Overall | 20 | 700 | 332 | -368 | -52.60 | faster firefox | issue2504 | 9 | Page Request | 20 | 3 | 2 | 0 | -4.00 | firefox | issue2504 | 9 | Rendering | 20 | 698 | 329 | -368 | -52.78 | faster firefox | issue2504 | 10 | Overall | 20 | 3296 | 926 | -2370 | -71.91 | faster firefox | issue2504 | 10 | Page Request | 20 | 2 | 2 | 0 | -18.75 | firefox | issue2504 | 10 | Rendering | 20 | 3293 | 924 | -2370 | -71.96 | faster firefox | issue2504 | 11 | Overall | 20 | 524 | 197 | -327 | -62.34 | faster firefox | issue2504 | 11 | Page Request | 20 | 2 | 3 | 1 | 58.54 | firefox | issue2504 | 11 | Rendering | 20 | 522 | 194 | -328 | -62.81 | faster firefox | issue2504 | 12 | Overall | 20 | 752 | 369 | -384 | -50.98 | faster firefox | issue2504 | 12 | Page Request | 20 | 3 | 2 | -1 | -36.51 | faster firefox | issue2504 | 12 | Rendering | 20 | 749 | 367 | -382 | -51.05 | faster firefox | issue2504 | 13 | Overall | 20 | 679 | 487 | -193 | -28.38 | faster firefox | issue2504 | 13 | Page Request | 20 | 4 | 2 | -2 | -48.68 | faster firefox | issue2504 | 13 | Rendering | 20 | 676 | 485 | -191 | -28.28 | faster firefox | issue2504 | 14 | Overall | 20 | 474 | 283 | -191 | -40.26 | faster firefox | issue2504 | 14 | Page Request | 20 | 2 | 4 | 2 | 78.57 | firefox | issue2504 | 14 | Rendering | 20 | 471 | 279 | -192 | -40.79 | faster firefox | issue2504 | 15 | Overall | 20 | 860 | 618 | -241 | -28.05 | faster firefox | issue2504 | 15 | Page Request | 20 | 2 | 3 | 0 | 10.87 | firefox | issue2504 | 15 | Rendering | 20 | 857 | 616 | -241 | -28.15 | faster firefox | issue2504 | 16 | Overall | 20 | 389 | 243 | -147 | -37.71 | faster firefox | issue2504 | 16 | Page Request | 20 | 2 | 2 | 0 | 2.33 | firefox | issue2504 | 16 | Rendering | 20 | 387 | 240 | -147 | -37.94 | faster firefox | issue2504 | 17 | Overall | 20 | 1484 | 672 | -812 | -54.70 | faster firefox | issue2504 | 17 | Page Request | 20 | 2 | 3 | 1 | 37.21 | firefox | issue2504 | 17 | Rendering | 20 | 1482 | 669 | -812 | -54.84 | faster firefox | issue2504 | 18 | Overall | 20 | 575 | 252 | -323 | -56.12 | faster firefox | issue2504 | 18 | Page Request | 20 | 2 | 2 | 0 | -16.22 | firefox | issue2504 | 18 | Rendering | 20 | 573 | 251 | -322 | -56.24 | faster firefox | issue2504 | 19 | Overall | 20 | 517 | 227 | -290 | -56.08 | faster firefox | issue2504 | 19 | Page Request | 20 | 2 | 2 | 0 | 21.62 | firefox | issue2504 | 19 | Rendering | 20 | 515 | 225 | -290 | -56.37 | faster firefox | issue2504 | 20 | Overall | 20 | 668 | 670 | 2 | 0.31 | firefox | issue2504 | 20 | Page Request | 20 | 4 | 2 | -1 | -34.29 | firefox | issue2504 | 20 | Rendering | 20 | 664 | 667 | 3 | 0.49 | firefox | issue2504 | 21 | Overall | 20 | 486 | 309 | -177 | -36.44 | faster firefox | issue2504 | 21 | Page Request | 20 | 2 | 2 | 0 | 16.13 | firefox | issue2504 | 21 | Rendering | 20 | 484 | 307 | -177 | -36.60 | faster firefox | issue2504 | 22 | Overall | 20 | 543 | 267 | -276 | -50.85 | faster firefox | issue2504 | 22 | Page Request | 20 | 2 | 2 | 0 | 10.26 | firefox | issue2504 | 22 | Rendering | 20 | 541 | 265 | -276 | -51.07 | faster firefox | issue2504 | 23 | Overall | 20 | 3246 | 871 | -2375 | -73.17 | faster firefox | issue2504 | 23 | Page Request | 20 | 2 | 3 | 1 | 37.21 | firefox | issue2504 | 23 | Rendering | 20 | 3243 | 868 | -2376 | -73.25 | faster firefox | issue2504 | 24 | Overall | 20 | 379 | 156 | -223 | -58.83 | faster firefox | issue2504 | 24 | Page Request | 20 | 2 | 2 | 0 | -2.86 | firefox | issue2504 | 24 | Rendering | 20 | 378 | 154 | -223 | -59.10 | faster firefox | issue2504 | 25 | Overall | 20 | 176 | 127 | -50 | -28.19 | faster firefox | issue2504 | 25 | Page Request | 20 | 2 | 1 | 0 | -15.63 | firefox | issue2504 | 25 | Rendering | 20 | 175 | 125 | -49 | -28.31 | faster firefox | issue2504 | 26 | Overall | 20 | 181 | 108 | -74 | -40.67 | faster firefox | issue2504 | 26 | Page Request | 20 | 3 | 2 | -1 | -39.13 | faster firefox | issue2504 | 26 | Rendering | 20 | 178 | 105 | -72 | -40.69 | faster firefox | issue2504 | 27 | Overall | 20 | 208 | 104 | -104 | -49.92 | faster firefox | issue2504 | 27 | Page Request | 20 | 2 | 2 | 1 | 48.39 | firefox | issue2504 | 27 | Rendering | 20 | 206 | 102 | -104 | -50.64 | faster firefox | issue2504 | 28 | Overall | 20 | 241 | 111 | -131 | -54.16 | faster firefox | issue2504 | 28 | Page Request | 20 | 2 | 2 | -1 | -33.33 | firefox | issue2504 | 28 | Rendering | 20 | 239 | 109 | -130 | -54.39 | faster firefox | issue2504 | 29 | Overall | 20 | 321 | 196 | -125 | -39.05 | faster firefox | issue2504 | 29 | Page Request | 20 | 1 | 2 | 0 | 17.86 | firefox | issue2504 | 29 | Rendering | 20 | 319 | 194 | -126 | -39.35 | faster firefox | issue2504 | 30 | Overall | 20 | 651 | 271 | -380 | -58.41 | faster firefox | issue2504 | 30 | Page Request | 20 | 1 | 2 | 1 | 50.00 | firefox | issue2504 | 30 | Rendering | 20 | 649 | 269 | -381 | -58.60 | faster firefox | issue2504 | 31 | Overall | 20 | 1635 | 647 | -988 | -60.42 | faster firefox | issue2504 | 31 | Page Request | 20 | 1 | 2 | 0 | 30.43 | firefox | issue2504 | 31 | Rendering | 20 | 1634 | 645 | -988 | -60.49 | faster firefox | tracemonkey | 0 | Overall | 100 | 51 | 51 | 0 | 0.02 | firefox | tracemonkey | 0 | Page Request | 100 | 1 | 1 | 0 | -4.76 | firefox | tracemonkey | 0 | Rendering | 100 | 50 | 50 | 0 | 0.12 | firefox | tracemonkey | 1 | Overall | 100 | 97 | 91 | -5 | -5.52 | faster firefox | tracemonkey | 1 | Page Request | 100 | 3 | 3 | 0 | -1.32 | firefox | tracemonkey | 1 | Rendering | 100 | 94 | 88 | -5 | -5.73 | faster firefox | tracemonkey | 2 | Overall | 100 | 40 | 40 | 0 | 0.50 | firefox | tracemonkey | 2 | Page Request | 100 | 1 | 1 | 0 | 3.16 | firefox | tracemonkey | 2 | Rendering | 100 | 39 | 39 | 0 | 0.54 | firefox | tracemonkey | 3 | Overall | 100 | 62 | 62 | -1 | -0.94 | firefox | tracemonkey | 3 | Page Request | 100 | 1 | 1 | 0 | 17.05 | firefox | tracemonkey | 3 | Rendering | 100 | 61 | 61 | -1 | -1.11 | firefox | tracemonkey | 4 | Overall | 100 | 56 | 58 | 2 | 3.41 | firefox | tracemonkey | 4 | Page Request | 100 | 1 | 1 | 0 | 15.31 | firefox | tracemonkey | 4 | Rendering | 100 | 55 | 57 | 2 | 3.23 | firefox | tracemonkey | 5 | Overall | 100 | 73 | 71 | -2 | -2.28 | firefox | tracemonkey | 5 | Page Request | 100 | 2 | 2 | 0 | 12.20 | firefox | tracemonkey | 5 | Rendering | 100 | 71 | 69 | -2 | -2.69 | firefox | tracemonkey | 6 | Overall | 100 | 85 | 69 | -16 | -18.73 | faster firefox | tracemonkey | 6 | Page Request | 100 | 2 | 2 | 0 | -9.90 | firefox | tracemonkey | 6 | Rendering | 100 | 83 | 67 | -16 | -18.97 | faster firefox | tracemonkey | 7 | Overall | 100 | 65 | 64 | 0 | -0.37 | firefox | tracemonkey | 7 | Page Request | 100 | 1 | 1 | 0 | -11.94 | firefox | tracemonkey | 7 | Rendering | 100 | 63 | 63 | 0 | -0.05 | firefox | tracemonkey | 8 | Overall | 100 | 53 | 54 | 1 | 2.04 | firefox | tracemonkey | 8 | Page Request | 100 | 1 | 1 | 0 | 17.02 | firefox | tracemonkey | 8 | Rendering | 100 | 52 | 53 | 1 | 1.82 | firefox | tracemonkey | 9 | Overall | 100 | 79 | 73 | -6 | -7.86 | faster firefox | tracemonkey | 9 | Page Request | 100 | 2 | 2 | 0 | -15.14 | firefox | tracemonkey | 9 | Rendering | 100 | 77 | 71 | -6 | -7.86 | faster firefox | tracemonkey | 10 | Overall | 100 | 545 | 519 | -27 | -4.86 | faster firefox | tracemonkey | 10 | Page Request | 100 | 14 | 13 | 0 | -3.56 | firefox | tracemonkey | 10 | Rendering | 100 | 532 | 506 | -26 | -4.90 | faster firefox | tracemonkey | 11 | Overall | 100 | 42 | 41 | -1 | -2.50 | firefox | tracemonkey | 11 | Page Request | 100 | 1 | 1 | 0 | -27.42 | faster firefox | tracemonkey | 11 | Rendering | 100 | 41 | 40 | -1 | -1.75 | firefox | tracemonkey | 12 | Overall | 100 | 350 | 332 | -18 | -5.16 | faster firefox | tracemonkey | 12 | Page Request | 100 | 3 | 3 | 0 | -5.17 | firefox | tracemonkey | 12 | Rendering | 100 | 347 | 329 | -18 | -5.15 | faster firefox | tracemonkey | 13 | Overall | 100 | 31 | 31 | 0 | 0.52 | firefox | tracemonkey | 13 | Page Request | 100 | 1 | 1 | 0 | 4.95 | firefox | tracemonkey | 13 | Rendering | 100 | 30 | 30 | 0 | 0.20 | ```
2020-06-13 21:12:40 +09:00
const cs = group.get("CS");
const localColorSpace =
cs instanceof Name && localColorSpaceCache.getByName(cs.name);
if (localColorSpace) {
colorSpace = localColorSpace;
} else {
colorSpace = await this.parseColorSpace({
cs,
resources,
localColorSpaceCache,
});
}
Split the existing `PDFFunction` in two classes, a private `PDFFunction` and a public `PDFFunctionFactory``, and utilize the latter in `PDFDocument` to allow various code to access the methods of `PDFFunction` *Follow-up to PR 8909.* This requires us to pass around `pdfFunctionFactory` to quite a lot of existing code, however I don't see another way of handling this while still guaranteeing that we can access `PDFFunction` as freely as in the old code. Please note that the patch passes all tests locally (unit, font, reference), and I *very* much hope that we have sufficient test-coverage for the code in question to catch any typos/mistakes in the re-factoring.
2017-09-19 20:49:30 +09:00
}
Make getOperatorList() calls independent and merge queues at end
2013-04-09 07:14:56 +09:00
}
Moves ColorSpace logic into evaluator
2014-05-22 02:47:42 +09:00
if (smask && smask.backdrop) {
colorSpace = colorSpace || ColorSpace.singletons.rgb;
smask.backdrop = colorSpace.getRgb(smask.backdrop, 0);
}
Reduce the memory usage of the operator list.
2013-11-14 04:43:38 +09:00
operatorList.addOp(OPS.beginGroup, [groupOptions]);
Falls back to ErrorFont when font object is not available or corrupted
2012-10-16 01:48:45 +09:00
}
Refactor text extraction / font loading logic
2012-09-14 00:09:46 +09:00
Reduce the memory usage of the operator list.
2013-11-14 04:43:38 +09:00
operatorList.addOp(OPS.paintFormXObjectBegin, [matrix, bbox]);
Refactor text extraction / font loading logic
2012-09-14 00:09:46 +09:00
Change the signatures of the `PartialEvaluator` "constructor" and its `getOperatorList`/`getTextContent` methods to take parameter objects Currently these methods accept a large number of parameters, which creates quite unwieldy call-sites. When invoking them, you have to remember not only what arguments to supply, but also the correct order, to avoid runtime errors. Furthermore, since some of the parameters are optional, you also have to remember to pass e.g. `null` or `undefined` for those ones. Also, adding new parameters to these methods (which happens occasionally), often becomes unnecessarily tedious (based on personal experience). Please note that I do *not* think that we need/should convert *every* single method in `evaluator.js` (or elsewhere in `/core` files) to take parameter objects. However, in my opinion, once a method starts relying on approximately five parameter (or even more), passing them in individually becomes quite cumbersome. With these changes, I obviously needed to update the `evaluator_spec.js` unit-tests. The main change there, except the new method signatures[1], is that it's now re-using *one* `PartialEvalutor` instance, since I couldn't see any compelling reason for creating a new one in every single test. *Note:* If this patch is accepted, my intention is to (time permitting) see if it makes sense to convert additional methods in `evaluator.js` (and other `/core` files) in a similar fashion, but I figured that it'd be a good idea to limit the initial scope somewhat. --- [1] A fun fact here, note how the `PartialEvaluator` signature used in `evaluator_spec.js` wasn't even correct in the current `master`.
2017-04-30 06:13:51 +09:00
return this.getOperatorList({
stream: xobj,
task,
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
resources: dict.get("Resources") || resources,
Change the signatures of the `PartialEvaluator` "constructor" and its `getOperatorList`/`getTextContent` methods to take parameter objects Currently these methods accept a large number of parameters, which creates quite unwieldy call-sites. When invoking them, you have to remember not only what arguments to supply, but also the correct order, to avoid runtime errors. Furthermore, since some of the parameters are optional, you also have to remember to pass e.g. `null` or `undefined` for those ones. Also, adding new parameters to these methods (which happens occasionally), often becomes unnecessarily tedious (based on personal experience). Please note that I do *not* think that we need/should convert *every* single method in `evaluator.js` (or elsewhere in `/core` files) to take parameter objects. However, in my opinion, once a method starts relying on approximately five parameter (or even more), passing them in individually becomes quite cumbersome. With these changes, I obviously needed to update the `evaluator_spec.js` unit-tests. The main change there, except the new method signatures[1], is that it's now re-using *one* `PartialEvalutor` instance, since I couldn't see any compelling reason for creating a new one in every single test. *Note:* If this patch is accepted, my intention is to (time permitting) see if it makes sense to convert additional methods in `evaluator.js` (and other `/core` files) in a similar fashion, but I figured that it'd be a good idea to limit the initial scope somewhat. --- [1] A fun fact here, note how the `PartialEvaluator` signature used in `evaluator_spec.js` wasn't even correct in the current `master`.
2017-04-30 06:13:51 +09:00
operatorList,
initialState,
Update Prettier to version 2.0 Please note that these changes were done automatically, using `gulp lint --fix`. Given that the major version number was increased, there's a fair number of (primarily whitespace) changes; please see https://prettier.io/blog/2020/03/21/2.0.0.html In order to reduce the size of these changes somewhat, this patch maintains the old "arrowParens" style for now (once mozilla-central updates Prettier we can simply choose the same formatting, assuming it will differ here).
2020-04-14 19:28:14 +09:00
}).then(function () {
Change the signatures of the `PartialEvaluator` "constructor" and its `getOperatorList`/`getTextContent` methods to take parameter objects Currently these methods accept a large number of parameters, which creates quite unwieldy call-sites. When invoking them, you have to remember not only what arguments to supply, but also the correct order, to avoid runtime errors. Furthermore, since some of the parameters are optional, you also have to remember to pass e.g. `null` or `undefined` for those ones. Also, adding new parameters to these methods (which happens occasionally), often becomes unnecessarily tedious (based on personal experience). Please note that I do *not* think that we need/should convert *every* single method in `evaluator.js` (or elsewhere in `/core` files) to take parameter objects. However, in my opinion, once a method starts relying on approximately five parameter (or even more), passing them in individually becomes quite cumbersome. With these changes, I obviously needed to update the `evaluator_spec.js` unit-tests. The main change there, except the new method signatures[1], is that it's now re-using *one* `PartialEvalutor` instance, since I couldn't see any compelling reason for creating a new one in every single test. *Note:* If this patch is accepted, my intention is to (time permitting) see if it makes sense to convert additional methods in `evaluator.js` (and other `/core` files) in a similar fashion, but I figured that it'd be a good idea to limit the initial scope somewhat. --- [1] A fun fact here, note how the `PartialEvaluator` signature used in `evaluator_spec.js` wasn't even correct in the current `master`.
2017-04-30 06:13:51 +09:00
operatorList.addOp(OPS.paintFormXObjectEnd, []);
if (group) {
operatorList.addOp(OPS.endGroup, [groupOptions]);
}
});
Make getOperatorList() calls independent and merge queues at end
2013-04-09 07:14:56 +09:00
},
Splitting files
2011-10-25 08:55:23 +09:00
Extract the actual sending of image data from the `PartialEvaluator.buildPaintImageXObject` method After PRs 10727 and 11912, the code responsible for sending the decoded image data to the main-thread has now become a fair bit more involved the previously. To reduce the amount of duplication here, the actual code responsible for sending the data is thus extracted into a new helper method instead.
2020-06-07 19:01:51 +09:00
_sendImgData(objId, imgData, cacheGlobally = false) {
const transfers = imgData ? [imgData.data.buffer] : null;
if (this.parsingType3Font) {
return this.handler.sendWithPromise(
"commonobj",
[objId, "FontType3Res", imgData],
transfers
);
}
if (cacheGlobally) {
return this.handler.send(
"commonobj",
[objId, "Image", imgData],
transfers
);
}
return this.handler.send(
"obj",
[objId, this.pageIndex, "Image", imgData],
transfers
);
},
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
async buildPaintImageXObject({
resources,
image,
isInline = false,
operatorList,
cacheKey,
Improve the *local* image caching in `PartialEvaluator.getOperatorList` Currently the local `imageCache`, as used in `PartialEvaluator.getOperatorList`, will miss certain cases of repeated images because the caching is *only* done by name (usually using a format such as e.g. "Im0", "Im1", ...). However, in some PDF documents the `/XObject` dictionaries many contain hundreds (or even thousands) of distinctly named images, despite them referring to only a handful of actual image objects (via the XRef table). With these changes we'll now cache *local* images using both name and (where applicable) reference, thus improving re-usage of images resources even further. This patch was tested using the PDF file from [bug 857031](https://bugzilla.mozilla.org/show_bug.cgi?id=857031), i.e. https://bug857031.bmoattachments.org/attachment.cgi?id=732270, with the following manifest file: ``` [ { "id": "bug857031", "file": "../web/pdfs/bug857031.pdf", "md5": "", "rounds": 250, "lastPage": 1, "type": "eq" } ] ``` which gave the following results when comparing this patch against the `master` branch: ``` -- Grouped By browser, page, stat -- browser | page | stat | Count | Baseline(ms) | Current(ms) | +/- | % | Result(P<.05) ------- | ---- | ------------ | ----- | ------------ | ----------- | --- | ----- | ------------- firefox | 0 | Overall | 250 | 2749 | 2656 | -93 | -3.38 | faster firefox | 0 | Page Request | 250 | 3 | 4 | 1 | 50.14 | slower firefox | 0 | Rendering | 250 | 2746 | 2652 | -94 | -3.44 | faster ``` While this is certainly an improvement, since we now avoid re-parsing ~1000 images on the first page, all of the image resources are small enough that the total rendering time doesn't improve that much in this particular case. In pathological cases, such as e.g. the PDF document in issue 4958, the improvements with this patch can be very significant. Looking for example at page 2, from issue 4958, the rendering time drops from ~60 seconds with `master` to ~30 seconds with this patch (obviously still slow, but it really showcases the potential of this patch nicely). Finally, note that there's also potential for additional improvements by re-using `LocalImageCache` instances for e.g. /XObject data of the `Form`-type. However, given that recent changes in this area I purposely didn't want to complicate *this* patch more than necessary.
2020-05-23 20:55:31 +09:00
localImageCache,
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
}) {
Make getOperatorList() calls independent and merge queues at end
2013-04-09 07:14:56 +09:00
var dict = image.dict;
Attempt to cache repeated images at the document, rather than the page, level (issue 11878) Currently image resources, as opposed to e.g. font resources, are handled exclusively on a page-specific basis. Generally speaking this makes sense, since pages are separate from each other, however there's PDF documents where many (or even all) pages actually references exactly the same image resources (through the XRef table). Hence, in some cases, we're decoding the *same* images over and over for every page which is obviously slow and wasting both CPU and memory resources better used elsewhere.[1] Obviously we cannot simply treat all image resources as-if they're used throughout the entire PDF document, since that would end up increasing memory usage too much.[2] However, by introducing a `GlobalImageCache` in the worker we can track image resources that appear on more than one page. Hence we can switch image resources from being page-specific to being document-specific, once the image resource has been seen on more than a certain number of pages. In many cases, such as e.g. the referenced issue, this patch will thus lead to reduced memory usage for image resources. Scrolling through all pages of the document, there's now only a few main-thread copies of the same image data, as opposed to one for each rendered page (i.e. there could theoretically be *twenty* copies of the image data). While this obviously benefit both CPU and memory usage in this case, for *very* large image data this patch *may* possibly increase persistent main-thread memory usage a tiny bit. Thus to avoid negatively affecting memory usage too much in general, particularly on the main-thread, the `GlobalImageCache` will *only* cache a certain number of image resources at the document level and simply fallback to the default behaviour. Unfortunately the asynchronous nature of the code, with ranged/streamed loading of data, actually makes all of this much more complicated than if all data could be assumed to be immediately available.[3] *Please note:* The patch will lead to *small* movement in some existing test-cases, since we're now using the built-in PDF.js JPEG decoder more. This was done in order to simplify the overall implementation, especially on the main-thread, by limiting it to only the `OPS.paintImageXObject` operator. --- [1] There's e.g. PDF documents that use the same image as background on all pages. [2] Given that data stored in the `commonObjs`, on the main-thread, are only cleared manually through `PDFDocumentProxy.cleanup`. This as opposed to data stored in the `objs` of each page, which is automatically removed when the page is cleaned-up e.g. by being evicted from the cache in the default viewer. [3] If the latter case were true, we could simply check for repeat images *before* parsing started and thus avoid handling *any* duplicate image resources.
2020-05-18 21:17:56 +09:00
const imageRef = dict.objId;
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
var w = dict.get("Width", "W");
var h = dict.get("Height", "H");
Splitting files
2011-10-25 08:55:23 +09:00
Check that images have valid dimensions (issue 4575)
2014-04-09 20:04:27 +09:00
if (!(w && isNum(w)) || !(h && isNum(h))) {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
warn("Image dimensions are missing, or not numbers.");
Enable the `consistent-return` ESLint rule This rule is already enabled in mozilla-central, and helps ensure more consistent functions/methods, see https://searchfox.org/mozilla-central/rev/b9da45f63cb567244933c77b2c7e827a057d3f9b/tools/lint/eslint/eslint-plugin-mozilla/lib/configs/recommended.js#119-120 Please see https://eslint.org/docs/rules/consistent-return for additional information.
2019-05-10 19:54:06 +09:00
return undefined;
Check that images have valid dimensions (issue 4575)
2014-04-09 20:04:27 +09:00
}
Removes global PDFJS usage from the src/core/.
2016-03-03 09:48:21 +09:00
var maxImageSize = this.options.maxImageSize;
if (maxImageSize !== -1 && w * h > maxImageSize) {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
warn("Image exceeded maximum allowed size and was removed.");
Enable the `consistent-return` ESLint rule This rule is already enabled in mozilla-central, and helps ensure more consistent functions/methods, see https://searchfox.org/mozilla-central/rev/b9da45f63cb567244933c77b2c7e827a057d3f9b/tools/lint/eslint/eslint-plugin-mozilla/lib/configs/recommended.js#119-120 Please see https://eslint.org/docs/rules/consistent-return for additional information.
2019-05-10 19:54:06 +09:00
return undefined;
Limit image size to 1024*1024 for b2g.
2013-07-11 01:52:37 +09:00
}
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
var imageMask = dict.get("ImageMask", "IM") || false;
Fixes lint warning W004 in src/core
2014-04-08 06:42:54 +09:00
var imgData, args;
Make getOperatorList() calls independent and merge queues at end
2013-04-09 07:14:56 +09:00
if (imageMask) {
Making src/core/evaluator.js adhere to the style guide
2014-03-23 03:15:51 +09:00
// This depends on a tmpCanvas being filled with the
Make getOperatorList() calls independent and merge queues at end
2013-04-09 07:14:56 +09:00
// current fillStyle, such that processing the pixel
// data can't be done here. Instead of creating a
// complete PDFImage, only read the information needed
// for later.
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
var width = dict.get("Width", "W");
var height = dict.get("Height", "H");
Make getOperatorList() calls independent and merge queues at end
2013-04-09 07:14:56 +09:00
var bitStrideLength = (width + 7) >> 3;
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
var imgArray = image.getBytes(
bitStrideLength * height,
/* forceClamped = */ true
);
var decode = dict.getArray("Decode", "D");
Make getOperatorList() calls independent and merge queues at end
2013-04-09 07:14:56 +09:00
Remove the unused `inline` parameter from various methods/functions in `PDFImage`, and change a couple of methods to use Objects rather than plain parameters The `inline` parameter is passed to a number of methods/functions in `PDFImage`, despite not actually being used. Its value is never checked, nor is it ever assigned to the current `PDFImage` instance (i.e. no `this.inline = inline` exists). Looking briefly at the history of this code, I was also unable to find a point in time where `inline` was being used. As far as I'm concerned, `inline` does nothing more than add clutter to already very unwieldy method/function signatures, hence why I'm proposing that we just remove it. To further simplify call-sites using `PDFImage`/`NativeImageDecoder`, a number of methods/functions are changed to take Objects rather than a bunch of (somewhat) randomly ordered parameters.
2017-09-21 19:14:05 +09:00
imgData = PDFImage.createMask({
imgArray,
width,
height,
imageIsFromDecodeStream: image instanceof DecodeStream,
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
inverseDecode: !!decode && decode[0] > 0,
Remove the unused `inline` parameter from various methods/functions in `PDFImage`, and change a couple of methods to use Objects rather than plain parameters The `inline` parameter is passed to a number of methods/functions in `PDFImage`, despite not actually being used. Its value is never checked, nor is it ever assigned to the current `PDFImage` instance (i.e. no `this.inline = inline` exists). Looking briefly at the history of this code, I was also unable to find a point in time where `inline` was being used. As far as I'm concerned, `inline` does nothing more than add clutter to already very unwieldy method/function signatures, hence why I'm proposing that we just remove it. To further simplify call-sites using `PDFImage`/`NativeImageDecoder`, a number of methods/functions are changed to take Objects rather than a bunch of (somewhat) randomly ordered parameters.
2017-09-21 19:14:05 +09:00
});
Actually transfer eligible ImageMask data, rather than always copying it By transfering `ArrayBuffer`s you can avoid having two copies of the same data, i.e. one copy on each of the worker/main-thread, for data that's used only *once* on the worker-thread. Note how the code in [`PDFImage.createMask`](https://github.com/mozilla/pdf.js/blob/80135378cadd98b55a835446f0857e4bc30524e0/src/core/image.js#L284-L285) goes to great lengths to actually enable tranfering of the image data. However in [`PartialEvaluator.buildPaintImageXObject`](https://github.com/mozilla/pdf.js/blob/80135378cadd98b55a835446f0857e4bc30524e0/src/core/evaluator.js#L336) the `cached` property is always set to `true`, which disqualifies the image data from being transfered; see [`getTransfers`](https://github.com/mozilla/pdf.js/blob/80135378cadd98b55a835446f0857e4bc30524e0/src/core/operator_list.js#L552-L554). For most ImageMask data this patch won't matter, since images found in the `/Resources -> /XObject` dictionary will always be indexed by name. However for *inline* images which contains ImageMask data, where only "small" images are cached (in both `parser.js` and `evaluator.js`), the current code will result in some unnecessary memory usage.
2019-03-16 20:09:14 +09:00
imgData.cached = !!cacheKey;
Fixes lint warning W004 in src/core
2014-04-08 06:42:54 +09:00
args = [imgData];
Actually transfer eligible ImageMask data, rather than always copying it By transfering `ArrayBuffer`s you can avoid having two copies of the same data, i.e. one copy on each of the worker/main-thread, for data that's used only *once* on the worker-thread. Note how the code in [`PDFImage.createMask`](https://github.com/mozilla/pdf.js/blob/80135378cadd98b55a835446f0857e4bc30524e0/src/core/image.js#L284-L285) goes to great lengths to actually enable tranfering of the image data. However in [`PartialEvaluator.buildPaintImageXObject`](https://github.com/mozilla/pdf.js/blob/80135378cadd98b55a835446f0857e4bc30524e0/src/core/evaluator.js#L336) the `cached` property is always set to `true`, which disqualifies the image data from being transfered; see [`getTransfers`](https://github.com/mozilla/pdf.js/blob/80135378cadd98b55a835446f0857e4bc30524e0/src/core/operator_list.js#L552-L554). For most ImageMask data this patch won't matter, since images found in the `/Resources -> /XObject` dictionary will always be indexed by name. However for *inline* images which contains ImageMask data, where only "small" images are cached (in both `parser.js` and `evaluator.js`), the current code will result in some unnecessary memory usage.
2019-03-16 20:09:14 +09:00
Caching inlined mask images
2014-02-25 00:59:02 +09:00
operatorList.addOp(OPS.paintImageMaskXObject, args);
if (cacheKey) {
Improve the *local* image caching in `PartialEvaluator.getOperatorList` Currently the local `imageCache`, as used in `PartialEvaluator.getOperatorList`, will miss certain cases of repeated images because the caching is *only* done by name (usually using a format such as e.g. "Im0", "Im1", ...). However, in some PDF documents the `/XObject` dictionaries many contain hundreds (or even thousands) of distinctly named images, despite them referring to only a handful of actual image objects (via the XRef table). With these changes we'll now cache *local* images using both name and (where applicable) reference, thus improving re-usage of images resources even further. This patch was tested using the PDF file from [bug 857031](https://bugzilla.mozilla.org/show_bug.cgi?id=857031), i.e. https://bug857031.bmoattachments.org/attachment.cgi?id=732270, with the following manifest file: ``` [ { "id": "bug857031", "file": "../web/pdfs/bug857031.pdf", "md5": "", "rounds": 250, "lastPage": 1, "type": "eq" } ] ``` which gave the following results when comparing this patch against the `master` branch: ``` -- Grouped By browser, page, stat -- browser | page | stat | Count | Baseline(ms) | Current(ms) | +/- | % | Result(P<.05) ------- | ---- | ------------ | ----- | ------------ | ----------- | --- | ----- | ------------- firefox | 0 | Overall | 250 | 2749 | 2656 | -93 | -3.38 | faster firefox | 0 | Page Request | 250 | 3 | 4 | 1 | 50.14 | slower firefox | 0 | Rendering | 250 | 2746 | 2652 | -94 | -3.44 | faster ``` While this is certainly an improvement, since we now avoid re-parsing ~1000 images on the first page, all of the image resources are small enough that the total rendering time doesn't improve that much in this particular case. In pathological cases, such as e.g. the PDF document in issue 4958, the improvements with this patch can be very significant. Looking for example at page 2, from issue 4958, the rendering time drops from ~60 seconds with `master` to ~30 seconds with this patch (obviously still slow, but it really showcases the potential of this patch nicely). Finally, note that there's also potential for additional improvements by re-using `LocalImageCache` instances for e.g. /XObject data of the `Form`-type. However, given that recent changes in this area I purposely didn't want to complicate *this* patch more than necessary.
2020-05-23 20:55:31 +09:00
localImageCache.set(cacheKey, imageRef, {
fixes caching of inline images during parsing. As described in #5444, the evaluator will perform identity checking of paintImageMaskXObjects to decide if it can use paintImageMaskXObjectRepeat instead of paintImageMaskXObjectGroup. This can only ever work if the entry is a cache hit. However the previous caching implementation was doing a lazy caching, which would only consider a image cache worthy if it is repeated. Only then the repeated instance would be cached. As a result of this the sequence of identical images A1 A2 A3 A4 would be seen as A1 A2 A2 A2 by the evaluator, which prevents using the "repeat" optimization. Also only the last encountered image is cached, so A1 B1 A2 B2, would stay A1 B1 A2 B2. The new implementation drops the "lazy" init of the cache. The threshold for enabling an image to be cached is rather small, so the potential waste in storage and adler32 calculation is rather low. It also caches any eligible image by its adler32. The two example from above would now be A1 A1 A1 A1 and A1 B1 A1 B1 which not only saves temporary storage, but also prevents computing identical masks over and over again (which is the main performance impact of #2618)
2014-10-27 01:03:44 +09:00
fn: OPS.paintImageMaskXObject,
Enable the `object-shorthand` ESLint rule in `src/shared` Please see http://eslint.org/docs/rules/object-shorthand. For the most part, these changes are of the search-and-replace kind, and the previously enabled `no-undef` rule should complement the tests in helping ensure that no stupid errors crept into to the patch.
2017-04-27 19:58:44 +09:00
args,
Improve the *local* image caching in `PartialEvaluator.getOperatorList` Currently the local `imageCache`, as used in `PartialEvaluator.getOperatorList`, will miss certain cases of repeated images because the caching is *only* done by name (usually using a format such as e.g. "Im0", "Im1", ...). However, in some PDF documents the `/XObject` dictionaries many contain hundreds (or even thousands) of distinctly named images, despite them referring to only a handful of actual image objects (via the XRef table). With these changes we'll now cache *local* images using both name and (where applicable) reference, thus improving re-usage of images resources even further. This patch was tested using the PDF file from [bug 857031](https://bugzilla.mozilla.org/show_bug.cgi?id=857031), i.e. https://bug857031.bmoattachments.org/attachment.cgi?id=732270, with the following manifest file: ``` [ { "id": "bug857031", "file": "../web/pdfs/bug857031.pdf", "md5": "", "rounds": 250, "lastPage": 1, "type": "eq" } ] ``` which gave the following results when comparing this patch against the `master` branch: ``` -- Grouped By browser, page, stat -- browser | page | stat | Count | Baseline(ms) | Current(ms) | +/- | % | Result(P<.05) ------- | ---- | ------------ | ----- | ------------ | ----------- | --- | ----- | ------------- firefox | 0 | Overall | 250 | 2749 | 2656 | -93 | -3.38 | faster firefox | 0 | Page Request | 250 | 3 | 4 | 1 | 50.14 | slower firefox | 0 | Rendering | 250 | 2746 | 2652 | -94 | -3.44 | faster ``` While this is certainly an improvement, since we now avoid re-parsing ~1000 images on the first page, all of the image resources are small enough that the total rendering time doesn't improve that much in this particular case. In pathological cases, such as e.g. the PDF document in issue 4958, the improvements with this patch can be very significant. Looking for example at page 2, from issue 4958, the rendering time drops from ~60 seconds with `master` to ~30 seconds with this patch (obviously still slow, but it really showcases the potential of this patch nicely). Finally, note that there's also potential for additional improvements by re-using `LocalImageCache` instances for e.g. /XObject data of the `Form`-type. However, given that recent changes in this area I purposely didn't want to complicate *this* patch more than necessary.
2020-05-23 20:55:31 +09:00
});
Caching inlined mask images
2014-02-25 00:59:02 +09:00
}
Enable the `consistent-return` ESLint rule This rule is already enabled in mozilla-central, and helps ensure more consistent functions/methods, see https://searchfox.org/mozilla-central/rev/b9da45f63cb567244933c77b2c7e827a057d3f9b/tools/lint/eslint/eslint-plugin-mozilla/lib/configs/recommended.js#119-120 Please see https://eslint.org/docs/rules/consistent-return for additional information.
2019-05-10 19:54:06 +09:00
return undefined;
Make getOperatorList() calls independent and merge queues at end
2013-04-09 07:14:56 +09:00
}
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
var softMask = dict.get("SMask", "SM") || false;
var mask = dict.get("Mask") || false;
Make getOperatorList() calls independent and merge queues at end
2013-04-09 07:14:56 +09:00
var SMALL_IMAGE_DIMENSIONS = 200;
// Inlining small images into the queue as RGB data
[api-minor] Decode all JPEG images with the built-in PDF.js decoder in `src/core/jpg.js` Currently some JPEG images are decoded by the built-in PDF.js decoder in `src/core/jpg.js`, while others attempt to use the browser JPEG decoder. This inconsistency seem unfortunate for a number of reasons: - It adds, compared to the other image formats supported in the PDF specification, a fair amount of code/complexity to the image handling in the PDF.js library. - The PDF specification support JPEG images with features, e.g. certain ColorSpaces, that browsers are unable to decode natively. Hence, determining if a JPEG image is possible to decode natively in the browser require a non-trivial amount of parsing. In particular, we're parsing (part of) the raw JPEG data to extract certain marker data and we also need to parse the ColorSpace for the JPEG image. - While some JPEG images may, for all intents and purposes, appear to be natively supported there's still cases where the browser may fail to decode some JPEG images. In order to support those cases, we've had to implement a fallback to the PDF.js JPEG decoder if there's any issues during the native decoding. This also means that it's no longer possible to simply send the JPEG image to the main-thread and continue parsing, but you now need to actually wait for the main-thread to indicate success/failure first. In practice this means that there's a code-path where the worker-thread is forced to wait for the main-thread, while the reverse should *always* be the case. - The native decoding, for anything except the *simplest* of JPEG images, result in increased peak memory usage because there's a handful of short-lived copies of the JPEG data (see PR 11707). Furthermore this also leads to data being *parsed* on the main-thread, rather than the worker-thread, which you usually want to avoid for e.g. performance and UI-reponsiveness reasons. - Not all environments, e.g. Node.js, fully support native JPEG decoding. This has, historically, lead to some issues and support requests. - Different browsers may use different JPEG decoders, possibly leading to images being rendered slightly differently depending on the platform/browser where the PDF.js library is used. Originally the implementation in `src/core/jpg.js` were unable to handle all of the JPEG images in the test-suite, but over the last couple of years I've fixed (hopefully) all of those issues. At this point in time, there's two kinds of failure with this patch: - Changes which are basically imperceivable to the naked eye, where some pixels in the images are essentially off-by-one (in all components), which could probably be attributed to things such as different rounding behaviour in the browser/PDF.js JPEG decoder. This type of "failure" accounts for the *vast* majority of the total number of changes in the reference tests. - Changes where the JPEG images now looks *ever so slightly* blurrier than with the native browser decoder. For quite some time I've just assumed that this pointed to a general deficiency in the `src/core/jpg.js` implementation, however I've discovered when comparing two viewers side-by-side that the differences vanish at higher zoom levels (usually around 200% is enough). Basically if you disable [this downscaling in canvas.js](https://github.com/mozilla/pdf.js/blob/8fb82e939cf0c8618a4e775ff17fc96f726872b5/src/display/canvas.js#L2356-L2395), which is what happens when zooming in, the differences simply vanish! Hence I'm pretty satisfied that there's no significant problems with the `src/core/jpg.js` implementation, and the problems are rather tied to the general quality of the downscaling algorithm used. It could even be seen as a positive that *all* images now share the same downscaling behaviour, since this actually fixes one old bug; see issue 7041.
2020-01-20 20:10:16 +09:00
if (isInline && !softMask && !mask && w + h < SMALL_IMAGE_DIMENSIONS) {
Enable the ESLint `prefer-const` rule globally (PR 11450 follow-up) Please find additional details about the ESLint rule at https://eslint.org/docs/rules/prefer-const With the recent introduction of Prettier this sort of mass enabling of ESLint rules becomes a lot easier, since the code will be automatically reformatted as necessary to account for e.g. changed line lengths. Note that this patch is generated automatically, by using the ESLint `--fix` argument, and will thus require some additional clean-up (which is done separately).
2020-01-24 17:48:21 +09:00
const imageObj = new PDFImage({
Remove the unused `inline` parameter from various methods/functions in `PDFImage`, and change a couple of methods to use Objects rather than plain parameters The `inline` parameter is passed to a number of methods/functions in `PDFImage`, despite not actually being used. Its value is never checked, nor is it ever assigned to the current `PDFImage` instance (i.e. no `this.inline = inline` exists). Looking briefly at the history of this code, I was also unable to find a point in time where `inline` was being used. As far as I'm concerned, `inline` does nothing more than add clutter to already very unwieldy method/function signatures, hence why I'm proposing that we just remove it. To further simplify call-sites using `PDFImage`/`NativeImageDecoder`, a number of methods/functions are changed to take Objects rather than a bunch of (somewhat) randomly ordered parameters.
2017-09-21 19:14:05 +09:00
xref: this.xref,
res: resources,
image,
Change the signature of `PartialEvaluator.buildPaintImageXObject` to take a parameter object This method currently requires a fair number of parameters, which creates quite unwieldy call-sites. When invoking `buildPaintImageXObject`, you have to remember not only which arguments to supply, but also the correct order, to prevent run-time errors.
2018-02-01 23:44:49 +09:00
isInline,
Split the existing `PDFFunction` in two classes, a private `PDFFunction` and a public `PDFFunctionFactory``, and utilize the latter in `PDFDocument` to allow various code to access the methods of `PDFFunction` *Follow-up to PR 8909.* This requires us to pass around `pdfFunctionFactory` to quite a lot of existing code, however I don't see another way of handling this while still guaranteeing that we can access `PDFFunction` as freely as in the old code. Please note that the patch passes all tests locally (unit, font, reference), and I *very* much hope that we have sufficient test-coverage for the code in question to catch any typos/mistakes in the re-factoring.
2017-09-19 20:49:30 +09:00
pdfFunctionFactory: this.pdfFunctionFactory,
Remove the unused `inline` parameter from various methods/functions in `PDFImage`, and change a couple of methods to use Objects rather than plain parameters The `inline` parameter is passed to a number of methods/functions in `PDFImage`, despite not actually being used. Its value is never checked, nor is it ever assigned to the current `PDFImage` instance (i.e. no `this.inline = inline` exists). Looking briefly at the history of this code, I was also unable to find a point in time where `inline` was being used. As far as I'm concerned, `inline` does nothing more than add clutter to already very unwieldy method/function signatures, hence why I'm proposing that we just remove it. To further simplify call-sites using `PDFImage`/`NativeImageDecoder`, a number of methods/functions are changed to take Objects rather than a bunch of (somewhat) randomly ordered parameters.
2017-09-21 19:14:05 +09:00
});
Introduce ImageKind constants.
2014-02-26 08:11:15 +09:00
// We force the use of RGBA_32BPP images here, because we can't handle
// any other kind.
Fixes lint warning W004 in src/core
2014-04-08 06:42:54 +09:00
imgData = imageObj.createImageData(/* forceRGBA = */ true);
Reduce the memory usage of the operator list.
2013-11-14 04:43:38 +09:00
operatorList.addOp(OPS.paintInlineImageXObject, [imgData]);
Enable the `consistent-return` ESLint rule This rule is already enabled in mozilla-central, and helps ensure more consistent functions/methods, see https://searchfox.org/mozilla-central/rev/b9da45f63cb567244933c77b2c7e827a057d3f9b/tools/lint/eslint/eslint-plugin-mozilla/lib/configs/recommended.js#119-120 Please see https://eslint.org/docs/rules/consistent-return for additional information.
2019-05-10 19:54:06 +09:00
return undefined;
Splitting files
2011-10-25 08:55:23 +09:00
}
Make getOperatorList() calls independent and merge queues at end
2013-04-09 07:14:56 +09:00
// If there is no imageMask, create the PDFImage and a lot
// of image processing can be done here.
Attempt to cache repeated images at the document, rather than the page, level (issue 11878) Currently image resources, as opposed to e.g. font resources, are handled exclusively on a page-specific basis. Generally speaking this makes sense, since pages are separate from each other, however there's PDF documents where many (or even all) pages actually references exactly the same image resources (through the XRef table). Hence, in some cases, we're decoding the *same* images over and over for every page which is obviously slow and wasting both CPU and memory resources better used elsewhere.[1] Obviously we cannot simply treat all image resources as-if they're used throughout the entire PDF document, since that would end up increasing memory usage too much.[2] However, by introducing a `GlobalImageCache` in the worker we can track image resources that appear on more than one page. Hence we can switch image resources from being page-specific to being document-specific, once the image resource has been seen on more than a certain number of pages. In many cases, such as e.g. the referenced issue, this patch will thus lead to reduced memory usage for image resources. Scrolling through all pages of the document, there's now only a few main-thread copies of the same image data, as opposed to one for each rendered page (i.e. there could theoretically be *twenty* copies of the image data). While this obviously benefit both CPU and memory usage in this case, for *very* large image data this patch *may* possibly increase persistent main-thread memory usage a tiny bit. Thus to avoid negatively affecting memory usage too much in general, particularly on the main-thread, the `GlobalImageCache` will *only* cache a certain number of image resources at the document level and simply fallback to the default behaviour. Unfortunately the asynchronous nature of the code, with ranged/streamed loading of data, actually makes all of this much more complicated than if all data could be assumed to be immediately available.[3] *Please note:* The patch will lead to *small* movement in some existing test-cases, since we're now using the built-in PDF.js JPEG decoder more. This was done in order to simplify the overall implementation, especially on the main-thread, by limiting it to only the `OPS.paintImageXObject` operator. --- [1] There's e.g. PDF documents that use the same image as background on all pages. [2] Given that data stored in the `commonObjs`, on the main-thread, are only cleared manually through `PDFDocumentProxy.cleanup`. This as opposed to data stored in the `objs` of each page, which is automatically removed when the page is cleaned-up e.g. by being evicted from the cache in the default viewer. [3] If the latter case were true, we could simply check for repeat images *before* parsing started and thus avoid handling *any* duplicate image resources.
2020-05-18 21:17:56 +09:00
let objId = `img_${this.idFactory.createObjId()}`,
cacheGlobally = false;
Support (rare) Type3 fonts which contains image resources (issue 10717) The Type3 font type is not commonly used in PDF documents, as can be seen from telemetry data such as: https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0&end_date=2019-04-09&include_spill=0&keys=__none__!__none__!__none__&max_channel_version=nightly%252F68&measure=PDF_VIEWER_FONT_TYPES&min_channel_version=nightly%252F57&processType=*&product=Firefox&sanitize=1&sort_by_value=0&sort_keys=submissions&start_date=2019-03-18&table=0&trim=1&use_submission_date=0 (see also https://github.com/mozilla/pdf.js/wiki/Enumeration-Assignments-for-the-Telemetry-Histograms#pdf_viewer_font_types). Type3 fonts containing image resources are *very* rare in practice, usually they only contain path rendering operators, but as the issue shows they unfortunately do exist. Currently these Type3-related image resources are not handled in any special way, and given that fonts are document rather than page specific rendering breaks since the image resources are thus not available to the *entire* document. Fortunately fixing this isn't too difficult, but it does require adding a couple of Type3-specific code-paths to the `PartialEvaluator`. In order to keep the implementation simple, particularily on the main-thread, these Type3 image resources are completely decoded on the worker-thread to avoid adding too many special cases. This should not cause any issues, only marginally less efficient code, but given how rare this kind of Type3 font is adding premature optimizations didn't seem at all warranted at this point.
2019-04-11 19:26:15 +09:00
if (this.parsingType3Font) {
Add a `getDocId` method to the `idFactory`, in `Page` instances, to avoid passing around `PDFManager` instances unnecessarily (PR 7941 follow-up) This way we can avoid manually building a "document id" in multiple places in `evaluator.js`, and it also let's us avoid passing in an otherwise unnecessary `PDFManager` instance when creating a `PartialEvaluator`.
2019-04-20 19:36:49 +09:00
objId = `${this.idFactory.getDocId()}_type3res_${objId}`;
Attempt to cache repeated images at the document, rather than the page, level (issue 11878) Currently image resources, as opposed to e.g. font resources, are handled exclusively on a page-specific basis. Generally speaking this makes sense, since pages are separate from each other, however there's PDF documents where many (or even all) pages actually references exactly the same image resources (through the XRef table). Hence, in some cases, we're decoding the *same* images over and over for every page which is obviously slow and wasting both CPU and memory resources better used elsewhere.[1] Obviously we cannot simply treat all image resources as-if they're used throughout the entire PDF document, since that would end up increasing memory usage too much.[2] However, by introducing a `GlobalImageCache` in the worker we can track image resources that appear on more than one page. Hence we can switch image resources from being page-specific to being document-specific, once the image resource has been seen on more than a certain number of pages. In many cases, such as e.g. the referenced issue, this patch will thus lead to reduced memory usage for image resources. Scrolling through all pages of the document, there's now only a few main-thread copies of the same image data, as opposed to one for each rendered page (i.e. there could theoretically be *twenty* copies of the image data). While this obviously benefit both CPU and memory usage in this case, for *very* large image data this patch *may* possibly increase persistent main-thread memory usage a tiny bit. Thus to avoid negatively affecting memory usage too much in general, particularly on the main-thread, the `GlobalImageCache` will *only* cache a certain number of image resources at the document level and simply fallback to the default behaviour. Unfortunately the asynchronous nature of the code, with ranged/streamed loading of data, actually makes all of this much more complicated than if all data could be assumed to be immediately available.[3] *Please note:* The patch will lead to *small* movement in some existing test-cases, since we're now using the built-in PDF.js JPEG decoder more. This was done in order to simplify the overall implementation, especially on the main-thread, by limiting it to only the `OPS.paintImageXObject` operator. --- [1] There's e.g. PDF documents that use the same image as background on all pages. [2] Given that data stored in the `commonObjs`, on the main-thread, are only cleared manually through `PDFDocumentProxy.cleanup`. This as opposed to data stored in the `objs` of each page, which is automatically removed when the page is cleaned-up e.g. by being evicted from the cache in the default viewer. [3] If the latter case were true, we could simply check for repeat images *before* parsing started and thus avoid handling *any* duplicate image resources.
2020-05-18 21:17:56 +09:00
} else if (imageRef) {
cacheGlobally = this.globalImageCache.shouldCache(
imageRef,
this.pageIndex
);
if (cacheGlobally) {
objId = `${this.idFactory.getDocId()}_${objId}`;
}
Support (rare) Type3 fonts which contains image resources (issue 10717) The Type3 font type is not commonly used in PDF documents, as can be seen from telemetry data such as: https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0&end_date=2019-04-09&include_spill=0&keys=__none__!__none__!__none__&max_channel_version=nightly%252F68&measure=PDF_VIEWER_FONT_TYPES&min_channel_version=nightly%252F57&processType=*&product=Firefox&sanitize=1&sort_by_value=0&sort_keys=submissions&start_date=2019-03-18&table=0&trim=1&use_submission_date=0 (see also https://github.com/mozilla/pdf.js/wiki/Enumeration-Assignments-for-the-Telemetry-Histograms#pdf_viewer_font_types). Type3 fonts containing image resources are *very* rare in practice, usually they only contain path rendering operators, but as the issue shows they unfortunately do exist. Currently these Type3-related image resources are not handled in any special way, and given that fonts are document rather than page specific rendering breaks since the image resources are thus not available to the *entire* document. Fortunately fixing this isn't too difficult, but it does require adding a couple of Type3-specific code-paths to the `PartialEvaluator`. In order to keep the implementation simple, particularily on the main-thread, these Type3 image resources are completely decoded on the worker-thread to avoid adding too many special cases. This should not cause any issues, only marginally less efficient code, but given how rare this kind of Type3 font is adding premature optimizations didn't seem at all warranted at this point.
2019-04-11 19:26:15 +09:00
}
Make getOperatorList() calls independent and merge queues at end
2013-04-09 07:14:56 +09:00
Fallback to the built-in JPEG decoder if 'JpegStream', in `src/display/api.js`, fails to load the image This works by making `PartialEvaluator.buildPaintImageXObject` wait for the success/failure of `loadJpegStream` on the API side *before* parsing continues. Please note that in practice, it should be quite rare for the browser to fail loading/decoding of a JPEG image. In the general case, it should thus not be completely surprising if even `src/core/jpg.js` will fail to decode the image.
2018-02-02 00:43:10 +09:00
// Ensure that the dependency is added before the image is decoded.
operatorList.addDependency(objId);
args = [objId, w, h];
Support (rare) Type3 fonts which contains image resources (issue 10717) The Type3 font type is not commonly used in PDF documents, as can be seen from telemetry data such as: https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0&end_date=2019-04-09&include_spill=0&keys=__none__!__none__!__none__&max_channel_version=nightly%252F68&measure=PDF_VIEWER_FONT_TYPES&min_channel_version=nightly%252F57&processType=*&product=Firefox&sanitize=1&sort_by_value=0&sort_keys=submissions&start_date=2019-03-18&table=0&trim=1&use_submission_date=0 (see also https://github.com/mozilla/pdf.js/wiki/Enumeration-Assignments-for-the-Telemetry-Histograms#pdf_viewer_font_types). Type3 fonts containing image resources are *very* rare in practice, usually they only contain path rendering operators, but as the issue shows they unfortunately do exist. Currently these Type3-related image resources are not handled in any special way, and given that fonts are document rather than page specific rendering breaks since the image resources are thus not available to the *entire* document. Fortunately fixing this isn't too difficult, but it does require adding a couple of Type3-specific code-paths to the `PartialEvaluator`. In order to keep the implementation simple, particularily on the main-thread, these Type3 image resources are completely decoded on the worker-thread to avoid adding too many special cases. This should not cause any issues, only marginally less efficient code, but given how rare this kind of Type3 font is adding premature optimizations didn't seem at all warranted at this point.
2019-04-11 19:26:15 +09:00
const imgPromise = PDFImage.buildImage({
Remove the unused `inline` parameter from various methods/functions in `PDFImage`, and change a couple of methods to use Objects rather than plain parameters The `inline` parameter is passed to a number of methods/functions in `PDFImage`, despite not actually being used. Its value is never checked, nor is it ever assigned to the current `PDFImage` instance (i.e. no `this.inline = inline` exists). Looking briefly at the history of this code, I was also unable to find a point in time where `inline` was being used. As far as I'm concerned, `inline` does nothing more than add clutter to already very unwieldy method/function signatures, hence why I'm proposing that we just remove it. To further simplify call-sites using `PDFImage`/`NativeImageDecoder`, a number of methods/functions are changed to take Objects rather than a bunch of (somewhat) randomly ordered parameters.
2017-09-21 19:14:05 +09:00
xref: this.xref,
res: resources,
image,
Change the signature of `PartialEvaluator.buildPaintImageXObject` to take a parameter object This method currently requires a fair number of parameters, which creates quite unwieldy call-sites. When invoking `buildPaintImageXObject`, you have to remember not only which arguments to supply, but also the correct order, to prevent run-time errors.
2018-02-01 23:44:49 +09:00
isInline,
Split the existing `PDFFunction` in two classes, a private `PDFFunction` and a public `PDFFunctionFactory``, and utilize the latter in `PDFDocument` to allow various code to access the methods of `PDFFunction` *Follow-up to PR 8909.* This requires us to pass around `pdfFunctionFactory` to quite a lot of existing code, however I don't see another way of handling this while still guaranteeing that we can access `PDFFunction` as freely as in the old code. Please note that the patch passes all tests locally (unit, font, reference), and I *very* much hope that we have sufficient test-coverage for the code in question to catch any typos/mistakes in the re-factoring.
2017-09-19 20:49:30 +09:00
pdfFunctionFactory: this.pdfFunctionFactory,
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
})
.then(imageObj => {
Remove variable shadowing from the JavaScript files in the `src/core/` folder *This is part of a series of patches that will try to split PR 11566 into smaller chunks, to make reviewing more feasible.* Once all the code has been fixed, we'll be able to eventually enable the ESLint no-shadow rule; see https://eslint.org/docs/rules/no-shadow
2020-03-24 01:04:47 +09:00
imgData = imageObj.createImageData(/* forceRGBA = */ false);
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
Extract the actual sending of image data from the `PartialEvaluator.buildPaintImageXObject` method After PRs 10727 and 11912, the code responsible for sending the decoded image data to the main-thread has now become a fair bit more involved the previously. To reduce the amount of duplication here, the actual code responsible for sending the data is thus extracted into a new helper method instead.
2020-06-07 19:01:51 +09:00
return this._sendImgData(objId, imgData, cacheGlobally);
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
})
.catch(reason => {
Ensure that `PDFImage.buildImage` won't accidentally swallow errors, e.g. from ColorSpace parsing (issue 6707, PR 11601 follow-up) Because of a really stupid `Promise`-related mistake on my part, when re-factoring `PDFImage.buildImage` during the `NativeImageDecoder` removal, we're no longer re-throwing errors occuring during image parsing/decoding as intended. The result is that some (fairly) corrupt documents will never finish loading, and unfortunately there were apparently no sufficiently corrupt images in the test-suite to catch this.
2020-06-13 21:41:34 +09:00
warn(`Unable to decode image "${objId}": "${reason}".`);
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
Extract the actual sending of image data from the `PartialEvaluator.buildPaintImageXObject` method After PRs 10727 and 11912, the code responsible for sending the decoded image data to the main-thread has now become a fair bit more involved the previously. To reduce the amount of duplication here, the actual code responsible for sending the data is thus extracted into a new helper method instead.
2020-06-07 19:01:51 +09:00
return this._sendImgData(objId, /* imgData = */ null, cacheGlobally);
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
});
Making src/core/evaluator.js adhere to the style guide
2014-03-23 03:15:51 +09:00
Support (rare) Type3 fonts which contains image resources (issue 10717) The Type3 font type is not commonly used in PDF documents, as can be seen from telemetry data such as: https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0&end_date=2019-04-09&include_spill=0&keys=__none__!__none__!__none__&max_channel_version=nightly%252F68&measure=PDF_VIEWER_FONT_TYPES&min_channel_version=nightly%252F57&processType=*&product=Firefox&sanitize=1&sort_by_value=0&sort_keys=submissions&start_date=2019-03-18&table=0&trim=1&use_submission_date=0 (see also https://github.com/mozilla/pdf.js/wiki/Enumeration-Assignments-for-the-Telemetry-Histograms#pdf_viewer_font_types). Type3 fonts containing image resources are *very* rare in practice, usually they only contain path rendering operators, but as the issue shows they unfortunately do exist. Currently these Type3-related image resources are not handled in any special way, and given that fonts are document rather than page specific rendering breaks since the image resources are thus not available to the *entire* document. Fortunately fixing this isn't too difficult, but it does require adding a couple of Type3-specific code-paths to the `PartialEvaluator`. In order to keep the implementation simple, particularily on the main-thread, these Type3 image resources are completely decoded on the worker-thread to avoid adding too many special cases. This should not cause any issues, only marginally less efficient code, but given how rare this kind of Type3 font is adding premature optimizations didn't seem at all warranted at this point.
2019-04-11 19:26:15 +09:00
if (this.parsingType3Font) {
// In the very rare case where a Type3 image resource is being parsed,
// wait for the image to be both decoded *and* sent to simplify the
// rendering code on the main-thread (see issue10717.pdf).
await imgPromise;
}
Reduce the memory usage of the operator list.
2013-11-14 04:43:38 +09:00
operatorList.addOp(OPS.paintImageXObject, args);
Caches last parsed resource image, recornizes image repeats
2014-02-24 23:00:08 +09:00
if (cacheKey) {
Improve the *local* image caching in `PartialEvaluator.getOperatorList` Currently the local `imageCache`, as used in `PartialEvaluator.getOperatorList`, will miss certain cases of repeated images because the caching is *only* done by name (usually using a format such as e.g. "Im0", "Im1", ...). However, in some PDF documents the `/XObject` dictionaries many contain hundreds (or even thousands) of distinctly named images, despite them referring to only a handful of actual image objects (via the XRef table). With these changes we'll now cache *local* images using both name and (where applicable) reference, thus improving re-usage of images resources even further. This patch was tested using the PDF file from [bug 857031](https://bugzilla.mozilla.org/show_bug.cgi?id=857031), i.e. https://bug857031.bmoattachments.org/attachment.cgi?id=732270, with the following manifest file: ``` [ { "id": "bug857031", "file": "../web/pdfs/bug857031.pdf", "md5": "", "rounds": 250, "lastPage": 1, "type": "eq" } ] ``` which gave the following results when comparing this patch against the `master` branch: ``` -- Grouped By browser, page, stat -- browser | page | stat | Count | Baseline(ms) | Current(ms) | +/- | % | Result(P<.05) ------- | ---- | ------------ | ----- | ------------ | ----------- | --- | ----- | ------------- firefox | 0 | Overall | 250 | 2749 | 2656 | -93 | -3.38 | faster firefox | 0 | Page Request | 250 | 3 | 4 | 1 | 50.14 | slower firefox | 0 | Rendering | 250 | 2746 | 2652 | -94 | -3.44 | faster ``` While this is certainly an improvement, since we now avoid re-parsing ~1000 images on the first page, all of the image resources are small enough that the total rendering time doesn't improve that much in this particular case. In pathological cases, such as e.g. the PDF document in issue 4958, the improvements with this patch can be very significant. Looking for example at page 2, from issue 4958, the rendering time drops from ~60 seconds with `master` to ~30 seconds with this patch (obviously still slow, but it really showcases the potential of this patch nicely). Finally, note that there's also potential for additional improvements by re-using `LocalImageCache` instances for e.g. /XObject data of the `Form`-type. However, given that recent changes in this area I purposely didn't want to complicate *this* patch more than necessary.
2020-05-23 20:55:31 +09:00
localImageCache.set(cacheKey, imageRef, {
fixes caching of inline images during parsing. As described in #5444, the evaluator will perform identity checking of paintImageMaskXObjects to decide if it can use paintImageMaskXObjectRepeat instead of paintImageMaskXObjectGroup. This can only ever work if the entry is a cache hit. However the previous caching implementation was doing a lazy caching, which would only consider a image cache worthy if it is repeated. Only then the repeated instance would be cached. As a result of this the sequence of identical images A1 A2 A3 A4 would be seen as A1 A2 A2 A2 by the evaluator, which prevents using the "repeat" optimization. Also only the last encountered image is cached, so A1 B1 A2 B2, would stay A1 B1 A2 B2. The new implementation drops the "lazy" init of the cache. The threshold for enabling an image to be cached is rather small, so the potential waste in storage and adler32 calculation is rather low. It also caches any eligible image by its adler32. The two example from above would now be A1 A1 A1 A1 and A1 B1 A1 B1 which not only saves temporary storage, but also prevents computing identical masks over and over again (which is the main performance impact of #2618)
2014-10-27 01:03:44 +09:00
fn: OPS.paintImageXObject,
Enable the `object-shorthand` ESLint rule in `src/shared` Please see http://eslint.org/docs/rules/object-shorthand. For the most part, these changes are of the search-and-replace kind, and the previously enabled `no-undef` rule should complement the tests in helping ensure that no stupid errors crept into to the patch.
2017-04-27 19:58:44 +09:00
args,
Improve the *local* image caching in `PartialEvaluator.getOperatorList` Currently the local `imageCache`, as used in `PartialEvaluator.getOperatorList`, will miss certain cases of repeated images because the caching is *only* done by name (usually using a format such as e.g. "Im0", "Im1", ...). However, in some PDF documents the `/XObject` dictionaries many contain hundreds (or even thousands) of distinctly named images, despite them referring to only a handful of actual image objects (via the XRef table). With these changes we'll now cache *local* images using both name and (where applicable) reference, thus improving re-usage of images resources even further. This patch was tested using the PDF file from [bug 857031](https://bugzilla.mozilla.org/show_bug.cgi?id=857031), i.e. https://bug857031.bmoattachments.org/attachment.cgi?id=732270, with the following manifest file: ``` [ { "id": "bug857031", "file": "../web/pdfs/bug857031.pdf", "md5": "", "rounds": 250, "lastPage": 1, "type": "eq" } ] ``` which gave the following results when comparing this patch against the `master` branch: ``` -- Grouped By browser, page, stat -- browser | page | stat | Count | Baseline(ms) | Current(ms) | +/- | % | Result(P<.05) ------- | ---- | ------------ | ----- | ------------ | ----------- | --- | ----- | ------------- firefox | 0 | Overall | 250 | 2749 | 2656 | -93 | -3.38 | faster firefox | 0 | Page Request | 250 | 3 | 4 | 1 | 50.14 | slower firefox | 0 | Rendering | 250 | 2746 | 2652 | -94 | -3.44 | faster ``` While this is certainly an improvement, since we now avoid re-parsing ~1000 images on the first page, all of the image resources are small enough that the total rendering time doesn't improve that much in this particular case. In pathological cases, such as e.g. the PDF document in issue 4958, the improvements with this patch can be very significant. Looking for example at page 2, from issue 4958, the rendering time drops from ~60 seconds with `master` to ~30 seconds with this patch (obviously still slow, but it really showcases the potential of this patch nicely). Finally, note that there's also potential for additional improvements by re-using `LocalImageCache` instances for e.g. /XObject data of the `Form`-type. However, given that recent changes in this area I purposely didn't want to complicate *this* patch more than necessary.
2020-05-23 20:55:31 +09:00
});
Attempt to cache repeated images at the document, rather than the page, level (issue 11878) Currently image resources, as opposed to e.g. font resources, are handled exclusively on a page-specific basis. Generally speaking this makes sense, since pages are separate from each other, however there's PDF documents where many (or even all) pages actually references exactly the same image resources (through the XRef table). Hence, in some cases, we're decoding the *same* images over and over for every page which is obviously slow and wasting both CPU and memory resources better used elsewhere.[1] Obviously we cannot simply treat all image resources as-if they're used throughout the entire PDF document, since that would end up increasing memory usage too much.[2] However, by introducing a `GlobalImageCache` in the worker we can track image resources that appear on more than one page. Hence we can switch image resources from being page-specific to being document-specific, once the image resource has been seen on more than a certain number of pages. In many cases, such as e.g. the referenced issue, this patch will thus lead to reduced memory usage for image resources. Scrolling through all pages of the document, there's now only a few main-thread copies of the same image data, as opposed to one for each rendered page (i.e. there could theoretically be *twenty* copies of the image data). While this obviously benefit both CPU and memory usage in this case, for *very* large image data this patch *may* possibly increase persistent main-thread memory usage a tiny bit. Thus to avoid negatively affecting memory usage too much in general, particularly on the main-thread, the `GlobalImageCache` will *only* cache a certain number of image resources at the document level and simply fallback to the default behaviour. Unfortunately the asynchronous nature of the code, with ranged/streamed loading of data, actually makes all of this much more complicated than if all data could be assumed to be immediately available.[3] *Please note:* The patch will lead to *small* movement in some existing test-cases, since we're now using the built-in PDF.js JPEG decoder more. This was done in order to simplify the overall implementation, especially on the main-thread, by limiting it to only the `OPS.paintImageXObject` operator. --- [1] There's e.g. PDF documents that use the same image as background on all pages. [2] Given that data stored in the `commonObjs`, on the main-thread, are only cleared manually through `PDFDocumentProxy.cleanup`. This as opposed to data stored in the `objs` of each page, which is automatically removed when the page is cleaned-up e.g. by being evicted from the cache in the default viewer. [3] If the latter case were true, we could simply check for repeat images *before* parsing started and thus avoid handling *any* duplicate image resources.
2020-05-18 21:17:56 +09:00
if (imageRef) {
Ensure that that we don't attempt to cache *inline* images in the `GlobalImageCache` (PR 11912 follow-up) Since *inline* images, i.e. those defined inside of `/Contents` streams, are by their very definition page-specific it thus seem like a good idea to actually enforce that they won't accidentally end up in the `GlobalImageCache`.
2020-06-01 07:55:10 +09:00
assert(!isInline, "Cannot cache an inline image globally.");
Attempt to cache repeated images at the document, rather than the page, level (issue 11878) Currently image resources, as opposed to e.g. font resources, are handled exclusively on a page-specific basis. Generally speaking this makes sense, since pages are separate from each other, however there's PDF documents where many (or even all) pages actually references exactly the same image resources (through the XRef table). Hence, in some cases, we're decoding the *same* images over and over for every page which is obviously slow and wasting both CPU and memory resources better used elsewhere.[1] Obviously we cannot simply treat all image resources as-if they're used throughout the entire PDF document, since that would end up increasing memory usage too much.[2] However, by introducing a `GlobalImageCache` in the worker we can track image resources that appear on more than one page. Hence we can switch image resources from being page-specific to being document-specific, once the image resource has been seen on more than a certain number of pages. In many cases, such as e.g. the referenced issue, this patch will thus lead to reduced memory usage for image resources. Scrolling through all pages of the document, there's now only a few main-thread copies of the same image data, as opposed to one for each rendered page (i.e. there could theoretically be *twenty* copies of the image data). While this obviously benefit both CPU and memory usage in this case, for *very* large image data this patch *may* possibly increase persistent main-thread memory usage a tiny bit. Thus to avoid negatively affecting memory usage too much in general, particularly on the main-thread, the `GlobalImageCache` will *only* cache a certain number of image resources at the document level and simply fallback to the default behaviour. Unfortunately the asynchronous nature of the code, with ranged/streamed loading of data, actually makes all of this much more complicated than if all data could be assumed to be immediately available.[3] *Please note:* The patch will lead to *small* movement in some existing test-cases, since we're now using the built-in PDF.js JPEG decoder more. This was done in order to simplify the overall implementation, especially on the main-thread, by limiting it to only the `OPS.paintImageXObject` operator. --- [1] There's e.g. PDF documents that use the same image as background on all pages. [2] Given that data stored in the `commonObjs`, on the main-thread, are only cleared manually through `PDFDocumentProxy.cleanup`. This as opposed to data stored in the `objs` of each page, which is automatically removed when the page is cleaned-up e.g. by being evicted from the cache in the default viewer. [3] If the latter case were true, we could simply check for repeat images *before* parsing started and thus avoid handling *any* duplicate image resources.
2020-05-18 21:17:56 +09:00
this.globalImageCache.addPageIndex(imageRef, this.pageIndex);
if (cacheGlobally) {
this.globalImageCache.setData(imageRef, {
objId,
fn: OPS.paintImageXObject,
args,
});
}
}
Caches last parsed resource image, recornizes image repeats
2014-02-24 23:00:08 +09:00
}
Enable the `consistent-return` ESLint rule This rule is already enabled in mozilla-central, and helps ensure more consistent functions/methods, see https://searchfox.org/mozilla-central/rev/b9da45f63cb567244933c77b2c7e827a057d3f9b/tools/lint/eslint/eslint-plugin-mozilla/lib/configs/recommended.js#119-120 Please see https://eslint.org/docs/rules/consistent-return for additional information.
2019-05-10 19:54:06 +09:00
return undefined;
Make getOperatorList() calls independent and merge queues at end
2013-04-09 07:14:56 +09:00
},
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
handleSMask: function PartialEvaluator_handleSmask(
smask,
resources,
operatorList,
task,
Add local caching of `ColorSpace`s, by name, in `PartialEvaluator.getOperatorList` (issue 2504) By caching parsed `ColorSpace`s, we thus don't need to re-parse the same data over and over which saves CPU cycles *and* reduces peak memory usage. (Obviously persistent memory usage *may* increase a tiny bit, but since the caching is done per `PartialEvaluator.getOperatorList` invocation and given that `ColorSpace` instances generally hold very little data this shouldn't be much of an issue.) Furthermore, by caching `ColorSpace`s we can also lookup the already parsed ones *synchronously* during the `OperatorList` building, instead of having to defer to the event loop/microtask queue since the parsing is done asynchronously (such that error handling is easier). Possible future improvements: - Cache/lookup parsed `ColorSpaces` used in `Pattern`s and `Image`s. - Attempt to cache *local* `ColorSpace`s by reference as well, in addition to only by name, assuming that there's documents where that would be beneficial and that it's not too difficult to implement. - Assuming there's documents that would benefit from it, also cache repeated `ColorSpace`s *globally* as well. Given that we've never, until now, been doing *any* caching of parsed `ColorSpace`s and that even using a simple name-only *local* cache helps tremendously in pathological cases, I purposely decided against complicating the implementation too much initially. Also, compared to parsing of `Image`s, simply creating a `ColorSpace` instance isn't that expensive (hence I'd be somewhat surprised if adding a *global* cache would help much). --- This patch was tested using: - The default `tracemonkey` PDF file, which was included mostly to show that "normal" documents aren't negatively affected by these changes. - The PDF file from issue 2504, i.e. https://dl-ctlg.panasonic.com/jp/manual/sd/sd_rbm1000_0.pdf, where most pages will switch *thousands* of times between a handful of `ColorSpace`s. with the following manifest file: ``` [ { "id": "tracemonkey", "file": "pdfs/tracemonkey.pdf", "md5": "9a192d8b1a7dc652a19835f6f08098bd", "rounds": 100, "type": "eq" }, { "id": "issue2504", "file": "../web/pdfs/issue2504.pdf", "md5": "", "rounds": 20, "type": "eq" } ] ``` which gave the following results when comparing this patch against the `master` branch: - Overall ``` -- Grouped By browser, pdf, stat -- browser | pdf | stat | Count | Baseline(ms) | Current(ms) | +/- | % | Result(P<.05) ------- | ----------- | ------------ | ----- | ------------ | ----------- | ---- | ------ | ------------- firefox | issue2504 | Overall | 640 | 977 | 497 | -479 | -49.08 | faster firefox | issue2504 | Page Request | 640 | 3 | 4 | 1 | 59.18 | firefox | issue2504 | Rendering | 640 | 974 | 493 | -481 | -49.37 | faster firefox | tracemonkey | Overall | 1400 | 116 | 111 | -5 | -4.43 | firefox | tracemonkey | Page Request | 1400 | 2 | 2 | 0 | -2.86 | firefox | tracemonkey | Rendering | 1400 | 114 | 109 | -5 | -4.47 | ``` - Page-specific ``` -- Grouped By browser, pdf, page, stat -- browser | pdf | page | stat | Count | Baseline(ms) | Current(ms) | +/- | % | Result(P<.05) ------- | ----------- | ---- | ------------ | ----- | ------------ | ----------- | ----- | ------- | ------------- firefox | issue2504 | 0 | Overall | 20 | 2295 | 1268 | -1027 | -44.76 | faster firefox | issue2504 | 0 | Page Request | 20 | 6 | 7 | 1 | 15.32 | firefox | issue2504 | 0 | Rendering | 20 | 2288 | 1260 | -1028 | -44.93 | faster firefox | issue2504 | 1 | Overall | 20 | 3059 | 2806 | -252 | -8.25 | faster firefox | issue2504 | 1 | Page Request | 20 | 11 | 14 | 3 | 23.25 | slower firefox | issue2504 | 1 | Rendering | 20 | 3047 | 2792 | -255 | -8.37 | faster firefox | issue2504 | 2 | Overall | 20 | 411 | 295 | -116 | -28.20 | faster firefox | issue2504 | 2 | Page Request | 20 | 2 | 42 | 40 | 1897.62 | firefox | issue2504 | 2 | Rendering | 20 | 409 | 253 | -156 | -38.09 | faster firefox | issue2504 | 3 | Overall | 20 | 736 | 299 | -437 | -59.34 | faster firefox | issue2504 | 3 | Page Request | 20 | 2 | 2 | 0 | 0.00 | firefox | issue2504 | 3 | Rendering | 20 | 734 | 297 | -437 | -59.49 | faster firefox | issue2504 | 4 | Overall | 20 | 356 | 458 | 102 | 28.63 | firefox | issue2504 | 4 | Page Request | 20 | 1 | 2 | 1 | 57.14 | slower firefox | issue2504 | 4 | Rendering | 20 | 354 | 455 | 101 | 28.53 | firefox | issue2504 | 5 | Overall | 20 | 1381 | 765 | -616 | -44.59 | faster firefox | issue2504 | 5 | Page Request | 20 | 3 | 5 | 2 | 50.00 | slower firefox | issue2504 | 5 | Rendering | 20 | 1378 | 760 | -617 | -44.81 | faster firefox | issue2504 | 6 | Overall | 20 | 757 | 299 | -459 | -60.57 | faster firefox | issue2504 | 6 | Page Request | 20 | 2 | 5 | 3 | 150.00 | slower firefox | issue2504 | 6 | Rendering | 20 | 755 | 294 | -462 | -61.11 | faster firefox | issue2504 | 7 | Overall | 20 | 394 | 302 | -92 | -23.39 | faster firefox | issue2504 | 7 | Page Request | 20 | 2 | 1 | -1 | -34.88 | faster firefox | issue2504 | 7 | Rendering | 20 | 392 | 301 | -91 | -23.32 | faster firefox | issue2504 | 8 | Overall | 20 | 2875 | 979 | -1896 | -65.95 | faster firefox | issue2504 | 8 | Page Request | 20 | 1 | 2 | 0 | 11.11 | firefox | issue2504 | 8 | Rendering | 20 | 2874 | 978 | -1896 | -65.99 | faster firefox | issue2504 | 9 | Overall | 20 | 700 | 332 | -368 | -52.60 | faster firefox | issue2504 | 9 | Page Request | 20 | 3 | 2 | 0 | -4.00 | firefox | issue2504 | 9 | Rendering | 20 | 698 | 329 | -368 | -52.78 | faster firefox | issue2504 | 10 | Overall | 20 | 3296 | 926 | -2370 | -71.91 | faster firefox | issue2504 | 10 | Page Request | 20 | 2 | 2 | 0 | -18.75 | firefox | issue2504 | 10 | Rendering | 20 | 3293 | 924 | -2370 | -71.96 | faster firefox | issue2504 | 11 | Overall | 20 | 524 | 197 | -327 | -62.34 | faster firefox | issue2504 | 11 | Page Request | 20 | 2 | 3 | 1 | 58.54 | firefox | issue2504 | 11 | Rendering | 20 | 522 | 194 | -328 | -62.81 | faster firefox | issue2504 | 12 | Overall | 20 | 752 | 369 | -384 | -50.98 | faster firefox | issue2504 | 12 | Page Request | 20 | 3 | 2 | -1 | -36.51 | faster firefox | issue2504 | 12 | Rendering | 20 | 749 | 367 | -382 | -51.05 | faster firefox | issue2504 | 13 | Overall | 20 | 679 | 487 | -193 | -28.38 | faster firefox | issue2504 | 13 | Page Request | 20 | 4 | 2 | -2 | -48.68 | faster firefox | issue2504 | 13 | Rendering | 20 | 676 | 485 | -191 | -28.28 | faster firefox | issue2504 | 14 | Overall | 20 | 474 | 283 | -191 | -40.26 | faster firefox | issue2504 | 14 | Page Request | 20 | 2 | 4 | 2 | 78.57 | firefox | issue2504 | 14 | Rendering | 20 | 471 | 279 | -192 | -40.79 | faster firefox | issue2504 | 15 | Overall | 20 | 860 | 618 | -241 | -28.05 | faster firefox | issue2504 | 15 | Page Request | 20 | 2 | 3 | 0 | 10.87 | firefox | issue2504 | 15 | Rendering | 20 | 857 | 616 | -241 | -28.15 | faster firefox | issue2504 | 16 | Overall | 20 | 389 | 243 | -147 | -37.71 | faster firefox | issue2504 | 16 | Page Request | 20 | 2 | 2 | 0 | 2.33 | firefox | issue2504 | 16 | Rendering | 20 | 387 | 240 | -147 | -37.94 | faster firefox | issue2504 | 17 | Overall | 20 | 1484 | 672 | -812 | -54.70 | faster firefox | issue2504 | 17 | Page Request | 20 | 2 | 3 | 1 | 37.21 | firefox | issue2504 | 17 | Rendering | 20 | 1482 | 669 | -812 | -54.84 | faster firefox | issue2504 | 18 | Overall | 20 | 575 | 252 | -323 | -56.12 | faster firefox | issue2504 | 18 | Page Request | 20 | 2 | 2 | 0 | -16.22 | firefox | issue2504 | 18 | Rendering | 20 | 573 | 251 | -322 | -56.24 | faster firefox | issue2504 | 19 | Overall | 20 | 517 | 227 | -290 | -56.08 | faster firefox | issue2504 | 19 | Page Request | 20 | 2 | 2 | 0 | 21.62 | firefox | issue2504 | 19 | Rendering | 20 | 515 | 225 | -290 | -56.37 | faster firefox | issue2504 | 20 | Overall | 20 | 668 | 670 | 2 | 0.31 | firefox | issue2504 | 20 | Page Request | 20 | 4 | 2 | -1 | -34.29 | firefox | issue2504 | 20 | Rendering | 20 | 664 | 667 | 3 | 0.49 | firefox | issue2504 | 21 | Overall | 20 | 486 | 309 | -177 | -36.44 | faster firefox | issue2504 | 21 | Page Request | 20 | 2 | 2 | 0 | 16.13 | firefox | issue2504 | 21 | Rendering | 20 | 484 | 307 | -177 | -36.60 | faster firefox | issue2504 | 22 | Overall | 20 | 543 | 267 | -276 | -50.85 | faster firefox | issue2504 | 22 | Page Request | 20 | 2 | 2 | 0 | 10.26 | firefox | issue2504 | 22 | Rendering | 20 | 541 | 265 | -276 | -51.07 | faster firefox | issue2504 | 23 | Overall | 20 | 3246 | 871 | -2375 | -73.17 | faster firefox | issue2504 | 23 | Page Request | 20 | 2 | 3 | 1 | 37.21 | firefox | issue2504 | 23 | Rendering | 20 | 3243 | 868 | -2376 | -73.25 | faster firefox | issue2504 | 24 | Overall | 20 | 379 | 156 | -223 | -58.83 | faster firefox | issue2504 | 24 | Page Request | 20 | 2 | 2 | 0 | -2.86 | firefox | issue2504 | 24 | Rendering | 20 | 378 | 154 | -223 | -59.10 | faster firefox | issue2504 | 25 | Overall | 20 | 176 | 127 | -50 | -28.19 | faster firefox | issue2504 | 25 | Page Request | 20 | 2 | 1 | 0 | -15.63 | firefox | issue2504 | 25 | Rendering | 20 | 175 | 125 | -49 | -28.31 | faster firefox | issue2504 | 26 | Overall | 20 | 181 | 108 | -74 | -40.67 | faster firefox | issue2504 | 26 | Page Request | 20 | 3 | 2 | -1 | -39.13 | faster firefox | issue2504 | 26 | Rendering | 20 | 178 | 105 | -72 | -40.69 | faster firefox | issue2504 | 27 | Overall | 20 | 208 | 104 | -104 | -49.92 | faster firefox | issue2504 | 27 | Page Request | 20 | 2 | 2 | 1 | 48.39 | firefox | issue2504 | 27 | Rendering | 20 | 206 | 102 | -104 | -50.64 | faster firefox | issue2504 | 28 | Overall | 20 | 241 | 111 | -131 | -54.16 | faster firefox | issue2504 | 28 | Page Request | 20 | 2 | 2 | -1 | -33.33 | firefox | issue2504 | 28 | Rendering | 20 | 239 | 109 | -130 | -54.39 | faster firefox | issue2504 | 29 | Overall | 20 | 321 | 196 | -125 | -39.05 | faster firefox | issue2504 | 29 | Page Request | 20 | 1 | 2 | 0 | 17.86 | firefox | issue2504 | 29 | Rendering | 20 | 319 | 194 | -126 | -39.35 | faster firefox | issue2504 | 30 | Overall | 20 | 651 | 271 | -380 | -58.41 | faster firefox | issue2504 | 30 | Page Request | 20 | 1 | 2 | 1 | 50.00 | firefox | issue2504 | 30 | Rendering | 20 | 649 | 269 | -381 | -58.60 | faster firefox | issue2504 | 31 | Overall | 20 | 1635 | 647 | -988 | -60.42 | faster firefox | issue2504 | 31 | Page Request | 20 | 1 | 2 | 0 | 30.43 | firefox | issue2504 | 31 | Rendering | 20 | 1634 | 645 | -988 | -60.49 | faster firefox | tracemonkey | 0 | Overall | 100 | 51 | 51 | 0 | 0.02 | firefox | tracemonkey | 0 | Page Request | 100 | 1 | 1 | 0 | -4.76 | firefox | tracemonkey | 0 | Rendering | 100 | 50 | 50 | 0 | 0.12 | firefox | tracemonkey | 1 | Overall | 100 | 97 | 91 | -5 | -5.52 | faster firefox | tracemonkey | 1 | Page Request | 100 | 3 | 3 | 0 | -1.32 | firefox | tracemonkey | 1 | Rendering | 100 | 94 | 88 | -5 | -5.73 | faster firefox | tracemonkey | 2 | Overall | 100 | 40 | 40 | 0 | 0.50 | firefox | tracemonkey | 2 | Page Request | 100 | 1 | 1 | 0 | 3.16 | firefox | tracemonkey | 2 | Rendering | 100 | 39 | 39 | 0 | 0.54 | firefox | tracemonkey | 3 | Overall | 100 | 62 | 62 | -1 | -0.94 | firefox | tracemonkey | 3 | Page Request | 100 | 1 | 1 | 0 | 17.05 | firefox | tracemonkey | 3 | Rendering | 100 | 61 | 61 | -1 | -1.11 | firefox | tracemonkey | 4 | Overall | 100 | 56 | 58 | 2 | 3.41 | firefox | tracemonkey | 4 | Page Request | 100 | 1 | 1 | 0 | 15.31 | firefox | tracemonkey | 4 | Rendering | 100 | 55 | 57 | 2 | 3.23 | firefox | tracemonkey | 5 | Overall | 100 | 73 | 71 | -2 | -2.28 | firefox | tracemonkey | 5 | Page Request | 100 | 2 | 2 | 0 | 12.20 | firefox | tracemonkey | 5 | Rendering | 100 | 71 | 69 | -2 | -2.69 | firefox | tracemonkey | 6 | Overall | 100 | 85 | 69 | -16 | -18.73 | faster firefox | tracemonkey | 6 | Page Request | 100 | 2 | 2 | 0 | -9.90 | firefox | tracemonkey | 6 | Rendering | 100 | 83 | 67 | -16 | -18.97 | faster firefox | tracemonkey | 7 | Overall | 100 | 65 | 64 | 0 | -0.37 | firefox | tracemonkey | 7 | Page Request | 100 | 1 | 1 | 0 | -11.94 | firefox | tracemonkey | 7 | Rendering | 100 | 63 | 63 | 0 | -0.05 | firefox | tracemonkey | 8 | Overall | 100 | 53 | 54 | 1 | 2.04 | firefox | tracemonkey | 8 | Page Request | 100 | 1 | 1 | 0 | 17.02 | firefox | tracemonkey | 8 | Rendering | 100 | 52 | 53 | 1 | 1.82 | firefox | tracemonkey | 9 | Overall | 100 | 79 | 73 | -6 | -7.86 | faster firefox | tracemonkey | 9 | Page Request | 100 | 2 | 2 | 0 | -15.14 | firefox | tracemonkey | 9 | Rendering | 100 | 77 | 71 | -6 | -7.86 | faster firefox | tracemonkey | 10 | Overall | 100 | 545 | 519 | -27 | -4.86 | faster firefox | tracemonkey | 10 | Page Request | 100 | 14 | 13 | 0 | -3.56 | firefox | tracemonkey | 10 | Rendering | 100 | 532 | 506 | -26 | -4.90 | faster firefox | tracemonkey | 11 | Overall | 100 | 42 | 41 | -1 | -2.50 | firefox | tracemonkey | 11 | Page Request | 100 | 1 | 1 | 0 | -27.42 | faster firefox | tracemonkey | 11 | Rendering | 100 | 41 | 40 | -1 | -1.75 | firefox | tracemonkey | 12 | Overall | 100 | 350 | 332 | -18 | -5.16 | faster firefox | tracemonkey | 12 | Page Request | 100 | 3 | 3 | 0 | -5.17 | firefox | tracemonkey | 12 | Rendering | 100 | 347 | 329 | -18 | -5.15 | faster firefox | tracemonkey | 13 | Overall | 100 | 31 | 31 | 0 | 0.52 | firefox | tracemonkey | 13 | Page Request | 100 | 1 | 1 | 0 | 4.95 | firefox | tracemonkey | 13 | Rendering | 100 | 30 | 30 | 0 | 0.20 | ```
2020-06-13 21:12:40 +09:00
stateManager,
localColorSpaceCache
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
) {
var smaskContent = smask.get("G");
SMask emulation
2014-01-24 02:13:32 +09:00
var smaskOptions = {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
subtype: smask.get("S").name,
backdrop: smask.get("BC"),
SMask emulation
2014-01-24 02:13:32 +09:00
};
Adds transfer function support for SMask.
2015-12-05 03:52:45 +09:00
// The SMask might have a alpha/luminosity value transfer function --
// we will build a map of integer values in range 0..255 to be fast.
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
var transferObj = smask.get("TR");
Adds transfer function support for SMask.
2015-12-05 03:52:45 +09:00
if (isPDFFunction(transferObj)) {
Enable the ESLint `prefer-const` rule globally (PR 11450 follow-up) Please find additional details about the ESLint rule at https://eslint.org/docs/rules/prefer-const With the recent introduction of Prettier this sort of mass enabling of ESLint rules becomes a lot easier, since the code will be automatically reformatted as necessary to account for e.g. changed line lengths. Note that this patch is generated automatically, by using the ESLint `--fix` argument, and will thus require some additional clean-up (which is done separately).
2020-01-24 17:48:21 +09:00
const transferFn = this.pdfFunctionFactory.create(transferObj);
Adds transfer function support for SMask.
2015-12-05 03:52:45 +09:00
var transferMap = new Uint8Array(256);
var tmp = new Float32Array(1);
Correct the upper bound used when building the `transferMap` for SMasks (PR 6723 followup) Even though the currently known test-cases render correctly without this patch, that seems more like a lucky coincidence, given that there's no guarantee that `transferMap[255] === 0` for every possible transfer function.
2016-02-03 21:31:48 +09:00
for (var i = 0; i < 256; i++) {
Adds transfer function support for SMask.
2015-12-05 03:52:45 +09:00
tmp[0] = i / 255;
transferFn(tmp, 0, tmp, 0);
transferMap[i] = (tmp[0] * 255) | 0;
}
smaskOptions.transferMap = transferMap;
}
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
return this.buildFormXObject(
resources,
smaskContent,
smaskOptions,
operatorList,
task,
Add local caching of `ColorSpace`s, by name, in `PartialEvaluator.getOperatorList` (issue 2504) By caching parsed `ColorSpace`s, we thus don't need to re-parse the same data over and over which saves CPU cycles *and* reduces peak memory usage. (Obviously persistent memory usage *may* increase a tiny bit, but since the caching is done per `PartialEvaluator.getOperatorList` invocation and given that `ColorSpace` instances generally hold very little data this shouldn't be much of an issue.) Furthermore, by caching `ColorSpace`s we can also lookup the already parsed ones *synchronously* during the `OperatorList` building, instead of having to defer to the event loop/microtask queue since the parsing is done asynchronously (such that error handling is easier). Possible future improvements: - Cache/lookup parsed `ColorSpaces` used in `Pattern`s and `Image`s. - Attempt to cache *local* `ColorSpace`s by reference as well, in addition to only by name, assuming that there's documents where that would be beneficial and that it's not too difficult to implement. - Assuming there's documents that would benefit from it, also cache repeated `ColorSpace`s *globally* as well. Given that we've never, until now, been doing *any* caching of parsed `ColorSpace`s and that even using a simple name-only *local* cache helps tremendously in pathological cases, I purposely decided against complicating the implementation too much initially. Also, compared to parsing of `Image`s, simply creating a `ColorSpace` instance isn't that expensive (hence I'd be somewhat surprised if adding a *global* cache would help much). --- This patch was tested using: - The default `tracemonkey` PDF file, which was included mostly to show that "normal" documents aren't negatively affected by these changes. - The PDF file from issue 2504, i.e. https://dl-ctlg.panasonic.com/jp/manual/sd/sd_rbm1000_0.pdf, where most pages will switch *thousands* of times between a handful of `ColorSpace`s. with the following manifest file: ``` [ { "id": "tracemonkey", "file": "pdfs/tracemonkey.pdf", "md5": "9a192d8b1a7dc652a19835f6f08098bd", "rounds": 100, "type": "eq" }, { "id": "issue2504", "file": "../web/pdfs/issue2504.pdf", "md5": "", "rounds": 20, "type": "eq" } ] ``` which gave the following results when comparing this patch against the `master` branch: - Overall ``` -- Grouped By browser, pdf, stat -- browser | pdf | stat | Count | Baseline(ms) | Current(ms) | +/- | % | Result(P<.05) ------- | ----------- | ------------ | ----- | ------------ | ----------- | ---- | ------ | ------------- firefox | issue2504 | Overall | 640 | 977 | 497 | -479 | -49.08 | faster firefox | issue2504 | Page Request | 640 | 3 | 4 | 1 | 59.18 | firefox | issue2504 | Rendering | 640 | 974 | 493 | -481 | -49.37 | faster firefox | tracemonkey | Overall | 1400 | 116 | 111 | -5 | -4.43 | firefox | tracemonkey | Page Request | 1400 | 2 | 2 | 0 | -2.86 | firefox | tracemonkey | Rendering | 1400 | 114 | 109 | -5 | -4.47 | ``` - Page-specific ``` -- Grouped By browser, pdf, page, stat -- browser | pdf | page | stat | Count | Baseline(ms) | Current(ms) | +/- | % | Result(P<.05) ------- | ----------- | ---- | ------------ | ----- | ------------ | ----------- | ----- | ------- | ------------- firefox | issue2504 | 0 | Overall | 20 | 2295 | 1268 | -1027 | -44.76 | faster firefox | issue2504 | 0 | Page Request | 20 | 6 | 7 | 1 | 15.32 | firefox | issue2504 | 0 | Rendering | 20 | 2288 | 1260 | -1028 | -44.93 | faster firefox | issue2504 | 1 | Overall | 20 | 3059 | 2806 | -252 | -8.25 | faster firefox | issue2504 | 1 | Page Request | 20 | 11 | 14 | 3 | 23.25 | slower firefox | issue2504 | 1 | Rendering | 20 | 3047 | 2792 | -255 | -8.37 | faster firefox | issue2504 | 2 | Overall | 20 | 411 | 295 | -116 | -28.20 | faster firefox | issue2504 | 2 | Page Request | 20 | 2 | 42 | 40 | 1897.62 | firefox | issue2504 | 2 | Rendering | 20 | 409 | 253 | -156 | -38.09 | faster firefox | issue2504 | 3 | Overall | 20 | 736 | 299 | -437 | -59.34 | faster firefox | issue2504 | 3 | Page Request | 20 | 2 | 2 | 0 | 0.00 | firefox | issue2504 | 3 | Rendering | 20 | 734 | 297 | -437 | -59.49 | faster firefox | issue2504 | 4 | Overall | 20 | 356 | 458 | 102 | 28.63 | firefox | issue2504 | 4 | Page Request | 20 | 1 | 2 | 1 | 57.14 | slower firefox | issue2504 | 4 | Rendering | 20 | 354 | 455 | 101 | 28.53 | firefox | issue2504 | 5 | Overall | 20 | 1381 | 765 | -616 | -44.59 | faster firefox | issue2504 | 5 | Page Request | 20 | 3 | 5 | 2 | 50.00 | slower firefox | issue2504 | 5 | Rendering | 20 | 1378 | 760 | -617 | -44.81 | faster firefox | issue2504 | 6 | Overall | 20 | 757 | 299 | -459 | -60.57 | faster firefox | issue2504 | 6 | Page Request | 20 | 2 | 5 | 3 | 150.00 | slower firefox | issue2504 | 6 | Rendering | 20 | 755 | 294 | -462 | -61.11 | faster firefox | issue2504 | 7 | Overall | 20 | 394 | 302 | -92 | -23.39 | faster firefox | issue2504 | 7 | Page Request | 20 | 2 | 1 | -1 | -34.88 | faster firefox | issue2504 | 7 | Rendering | 20 | 392 | 301 | -91 | -23.32 | faster firefox | issue2504 | 8 | Overall | 20 | 2875 | 979 | -1896 | -65.95 | faster firefox | issue2504 | 8 | Page Request | 20 | 1 | 2 | 0 | 11.11 | firefox | issue2504 | 8 | Rendering | 20 | 2874 | 978 | -1896 | -65.99 | faster firefox | issue2504 | 9 | Overall | 20 | 700 | 332 | -368 | -52.60 | faster firefox | issue2504 | 9 | Page Request | 20 | 3 | 2 | 0 | -4.00 | firefox | issue2504 | 9 | Rendering | 20 | 698 | 329 | -368 | -52.78 | faster firefox | issue2504 | 10 | Overall | 20 | 3296 | 926 | -2370 | -71.91 | faster firefox | issue2504 | 10 | Page Request | 20 | 2 | 2 | 0 | -18.75 | firefox | issue2504 | 10 | Rendering | 20 | 3293 | 924 | -2370 | -71.96 | faster firefox | issue2504 | 11 | Overall | 20 | 524 | 197 | -327 | -62.34 | faster firefox | issue2504 | 11 | Page Request | 20 | 2 | 3 | 1 | 58.54 | firefox | issue2504 | 11 | Rendering | 20 | 522 | 194 | -328 | -62.81 | faster firefox | issue2504 | 12 | Overall | 20 | 752 | 369 | -384 | -50.98 | faster firefox | issue2504 | 12 | Page Request | 20 | 3 | 2 | -1 | -36.51 | faster firefox | issue2504 | 12 | Rendering | 20 | 749 | 367 | -382 | -51.05 | faster firefox | issue2504 | 13 | Overall | 20 | 679 | 487 | -193 | -28.38 | faster firefox | issue2504 | 13 | Page Request | 20 | 4 | 2 | -2 | -48.68 | faster firefox | issue2504 | 13 | Rendering | 20 | 676 | 485 | -191 | -28.28 | faster firefox | issue2504 | 14 | Overall | 20 | 474 | 283 | -191 | -40.26 | faster firefox | issue2504 | 14 | Page Request | 20 | 2 | 4 | 2 | 78.57 | firefox | issue2504 | 14 | Rendering | 20 | 471 | 279 | -192 | -40.79 | faster firefox | issue2504 | 15 | Overall | 20 | 860 | 618 | -241 | -28.05 | faster firefox | issue2504 | 15 | Page Request | 20 | 2 | 3 | 0 | 10.87 | firefox | issue2504 | 15 | Rendering | 20 | 857 | 616 | -241 | -28.15 | faster firefox | issue2504 | 16 | Overall | 20 | 389 | 243 | -147 | -37.71 | faster firefox | issue2504 | 16 | Page Request | 20 | 2 | 2 | 0 | 2.33 | firefox | issue2504 | 16 | Rendering | 20 | 387 | 240 | -147 | -37.94 | faster firefox | issue2504 | 17 | Overall | 20 | 1484 | 672 | -812 | -54.70 | faster firefox | issue2504 | 17 | Page Request | 20 | 2 | 3 | 1 | 37.21 | firefox | issue2504 | 17 | Rendering | 20 | 1482 | 669 | -812 | -54.84 | faster firefox | issue2504 | 18 | Overall | 20 | 575 | 252 | -323 | -56.12 | faster firefox | issue2504 | 18 | Page Request | 20 | 2 | 2 | 0 | -16.22 | firefox | issue2504 | 18 | Rendering | 20 | 573 | 251 | -322 | -56.24 | faster firefox | issue2504 | 19 | Overall | 20 | 517 | 227 | -290 | -56.08 | faster firefox | issue2504 | 19 | Page Request | 20 | 2 | 2 | 0 | 21.62 | firefox | issue2504 | 19 | Rendering | 20 | 515 | 225 | -290 | -56.37 | faster firefox | issue2504 | 20 | Overall | 20 | 668 | 670 | 2 | 0.31 | firefox | issue2504 | 20 | Page Request | 20 | 4 | 2 | -1 | -34.29 | firefox | issue2504 | 20 | Rendering | 20 | 664 | 667 | 3 | 0.49 | firefox | issue2504 | 21 | Overall | 20 | 486 | 309 | -177 | -36.44 | faster firefox | issue2504 | 21 | Page Request | 20 | 2 | 2 | 0 | 16.13 | firefox | issue2504 | 21 | Rendering | 20 | 484 | 307 | -177 | -36.60 | faster firefox | issue2504 | 22 | Overall | 20 | 543 | 267 | -276 | -50.85 | faster firefox | issue2504 | 22 | Page Request | 20 | 2 | 2 | 0 | 10.26 | firefox | issue2504 | 22 | Rendering | 20 | 541 | 265 | -276 | -51.07 | faster firefox | issue2504 | 23 | Overall | 20 | 3246 | 871 | -2375 | -73.17 | faster firefox | issue2504 | 23 | Page Request | 20 | 2 | 3 | 1 | 37.21 | firefox | issue2504 | 23 | Rendering | 20 | 3243 | 868 | -2376 | -73.25 | faster firefox | issue2504 | 24 | Overall | 20 | 379 | 156 | -223 | -58.83 | faster firefox | issue2504 | 24 | Page Request | 20 | 2 | 2 | 0 | -2.86 | firefox | issue2504 | 24 | Rendering | 20 | 378 | 154 | -223 | -59.10 | faster firefox | issue2504 | 25 | Overall | 20 | 176 | 127 | -50 | -28.19 | faster firefox | issue2504 | 25 | Page Request | 20 | 2 | 1 | 0 | -15.63 | firefox | issue2504 | 25 | Rendering | 20 | 175 | 125 | -49 | -28.31 | faster firefox | issue2504 | 26 | Overall | 20 | 181 | 108 | -74 | -40.67 | faster firefox | issue2504 | 26 | Page Request | 20 | 3 | 2 | -1 | -39.13 | faster firefox | issue2504 | 26 | Rendering | 20 | 178 | 105 | -72 | -40.69 | faster firefox | issue2504 | 27 | Overall | 20 | 208 | 104 | -104 | -49.92 | faster firefox | issue2504 | 27 | Page Request | 20 | 2 | 2 | 1 | 48.39 | firefox | issue2504 | 27 | Rendering | 20 | 206 | 102 | -104 | -50.64 | faster firefox | issue2504 | 28 | Overall | 20 | 241 | 111 | -131 | -54.16 | faster firefox | issue2504 | 28 | Page Request | 20 | 2 | 2 | -1 | -33.33 | firefox | issue2504 | 28 | Rendering | 20 | 239 | 109 | -130 | -54.39 | faster firefox | issue2504 | 29 | Overall | 20 | 321 | 196 | -125 | -39.05 | faster firefox | issue2504 | 29 | Page Request | 20 | 1 | 2 | 0 | 17.86 | firefox | issue2504 | 29 | Rendering | 20 | 319 | 194 | -126 | -39.35 | faster firefox | issue2504 | 30 | Overall | 20 | 651 | 271 | -380 | -58.41 | faster firefox | issue2504 | 30 | Page Request | 20 | 1 | 2 | 1 | 50.00 | firefox | issue2504 | 30 | Rendering | 20 | 649 | 269 | -381 | -58.60 | faster firefox | issue2504 | 31 | Overall | 20 | 1635 | 647 | -988 | -60.42 | faster firefox | issue2504 | 31 | Page Request | 20 | 1 | 2 | 0 | 30.43 | firefox | issue2504 | 31 | Rendering | 20 | 1634 | 645 | -988 | -60.49 | faster firefox | tracemonkey | 0 | Overall | 100 | 51 | 51 | 0 | 0.02 | firefox | tracemonkey | 0 | Page Request | 100 | 1 | 1 | 0 | -4.76 | firefox | tracemonkey | 0 | Rendering | 100 | 50 | 50 | 0 | 0.12 | firefox | tracemonkey | 1 | Overall | 100 | 97 | 91 | -5 | -5.52 | faster firefox | tracemonkey | 1 | Page Request | 100 | 3 | 3 | 0 | -1.32 | firefox | tracemonkey | 1 | Rendering | 100 | 94 | 88 | -5 | -5.73 | faster firefox | tracemonkey | 2 | Overall | 100 | 40 | 40 | 0 | 0.50 | firefox | tracemonkey | 2 | Page Request | 100 | 1 | 1 | 0 | 3.16 | firefox | tracemonkey | 2 | Rendering | 100 | 39 | 39 | 0 | 0.54 | firefox | tracemonkey | 3 | Overall | 100 | 62 | 62 | -1 | -0.94 | firefox | tracemonkey | 3 | Page Request | 100 | 1 | 1 | 0 | 17.05 | firefox | tracemonkey | 3 | Rendering | 100 | 61 | 61 | -1 | -1.11 | firefox | tracemonkey | 4 | Overall | 100 | 56 | 58 | 2 | 3.41 | firefox | tracemonkey | 4 | Page Request | 100 | 1 | 1 | 0 | 15.31 | firefox | tracemonkey | 4 | Rendering | 100 | 55 | 57 | 2 | 3.23 | firefox | tracemonkey | 5 | Overall | 100 | 73 | 71 | -2 | -2.28 | firefox | tracemonkey | 5 | Page Request | 100 | 2 | 2 | 0 | 12.20 | firefox | tracemonkey | 5 | Rendering | 100 | 71 | 69 | -2 | -2.69 | firefox | tracemonkey | 6 | Overall | 100 | 85 | 69 | -16 | -18.73 | faster firefox | tracemonkey | 6 | Page Request | 100 | 2 | 2 | 0 | -9.90 | firefox | tracemonkey | 6 | Rendering | 100 | 83 | 67 | -16 | -18.97 | faster firefox | tracemonkey | 7 | Overall | 100 | 65 | 64 | 0 | -0.37 | firefox | tracemonkey | 7 | Page Request | 100 | 1 | 1 | 0 | -11.94 | firefox | tracemonkey | 7 | Rendering | 100 | 63 | 63 | 0 | -0.05 | firefox | tracemonkey | 8 | Overall | 100 | 53 | 54 | 1 | 2.04 | firefox | tracemonkey | 8 | Page Request | 100 | 1 | 1 | 0 | 17.02 | firefox | tracemonkey | 8 | Rendering | 100 | 52 | 53 | 1 | 1.82 | firefox | tracemonkey | 9 | Overall | 100 | 79 | 73 | -6 | -7.86 | faster firefox | tracemonkey | 9 | Page Request | 100 | 2 | 2 | 0 | -15.14 | firefox | tracemonkey | 9 | Rendering | 100 | 77 | 71 | -6 | -7.86 | faster firefox | tracemonkey | 10 | Overall | 100 | 545 | 519 | -27 | -4.86 | faster firefox | tracemonkey | 10 | Page Request | 100 | 14 | 13 | 0 | -3.56 | firefox | tracemonkey | 10 | Rendering | 100 | 532 | 506 | -26 | -4.90 | faster firefox | tracemonkey | 11 | Overall | 100 | 42 | 41 | -1 | -2.50 | firefox | tracemonkey | 11 | Page Request | 100 | 1 | 1 | 0 | -27.42 | faster firefox | tracemonkey | 11 | Rendering | 100 | 41 | 40 | -1 | -1.75 | firefox | tracemonkey | 12 | Overall | 100 | 350 | 332 | -18 | -5.16 | faster firefox | tracemonkey | 12 | Page Request | 100 | 3 | 3 | 0 | -5.17 | firefox | tracemonkey | 12 | Rendering | 100 | 347 | 329 | -18 | -5.15 | faster firefox | tracemonkey | 13 | Overall | 100 | 31 | 31 | 0 | 0.52 | firefox | tracemonkey | 13 | Page Request | 100 | 1 | 1 | 0 | 4.95 | firefox | tracemonkey | 13 | Rendering | 100 | 30 | 30 | 0 | 0.20 | ```
2020-06-13 21:12:40 +09:00
stateManager.state.clone(),
localColorSpaceCache
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
);
SMask emulation
2014-01-24 02:13:32 +09:00
},
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
handleTilingType(
fn,
args,
resources,
pattern,
patternDict,
operatorList,
task
) {
Make getOperatorList() calls independent and merge queues at end
2013-04-09 07:14:56 +09:00
// Create an IR of the pattern code.
Enable the ESLint `prefer-const` rule globally (PR 11450 follow-up) Please find additional details about the ESLint rule at https://eslint.org/docs/rules/prefer-const With the recent introduction of Prettier this sort of mass enabling of ESLint rules becomes a lot easier, since the code will be automatically reformatted as necessary to account for e.g. changed line lengths. Note that this patch is generated automatically, by using the ESLint `--fix` argument, and will thus require some additional clean-up (which is done separately).
2020-01-24 17:48:21 +09:00
const tilingOpList = new OperatorList();
Prevent getOperatorList from failing to correctly parse OPS.paintXObject for TilingPatterns that are missing some /Resources entries (issue 6541) Fixes 6541.
2015-10-21 03:22:06 +09:00
// Merge the available resources, to prevent issues when the patternDict
// is missing some /Resources entries (fixes issue6541.pdf).
Enable the ESLint `prefer-const` rule globally (PR 11450 follow-up) Please find additional details about the ESLint rule at https://eslint.org/docs/rules/prefer-const With the recent introduction of Prettier this sort of mass enabling of ESLint rules becomes a lot easier, since the code will be automatically reformatted as necessary to account for e.g. changed line lengths. Note that this patch is generated automatically, by using the ESLint `--fix` argument, and will thus require some additional clean-up (which is done separately).
2020-01-24 17:48:21 +09:00
const resourcesArray = [patternDict.get("Resources"), resources];
const patternResources = Dict.merge(this.xref, resourcesArray);
Prevent getOperatorList from failing to correctly parse OPS.paintXObject for TilingPatterns that are missing some /Resources entries (issue 6541) Fixes 6541.
2015-10-21 03:22:06 +09:00
Change the signatures of the `PartialEvaluator` "constructor" and its `getOperatorList`/`getTextContent` methods to take parameter objects Currently these methods accept a large number of parameters, which creates quite unwieldy call-sites. When invoking them, you have to remember not only what arguments to supply, but also the correct order, to avoid runtime errors. Furthermore, since some of the parameters are optional, you also have to remember to pass e.g. `null` or `undefined` for those ones. Also, adding new parameters to these methods (which happens occasionally), often becomes unnecessarily tedious (based on personal experience). Please note that I do *not* think that we need/should convert *every* single method in `evaluator.js` (or elsewhere in `/core` files) to take parameter objects. However, in my opinion, once a method starts relying on approximately five parameter (or even more), passing them in individually becomes quite cumbersome. With these changes, I obviously needed to update the `evaluator_spec.js` unit-tests. The main change there, except the new method signatures[1], is that it's now re-using *one* `PartialEvalutor` instance, since I couldn't see any compelling reason for creating a new one in every single test. *Note:* If this patch is accepted, my intention is to (time permitting) see if it makes sense to convert additional methods in `evaluator.js` (and other `/core` files) in a similar fashion, but I figured that it'd be a good idea to limit the initial scope somewhat. --- [1] A fun fact here, note how the `PartialEvaluator` signature used in `evaluator_spec.js` wasn't even correct in the current `master`.
2017-04-30 06:13:51 +09:00
return this.getOperatorList({
stream: pattern,
task,
resources: patternResources,
operatorList: tilingOpList,
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
})
Update Prettier to version 2.0 Please note that these changes were done automatically, using `gulp lint --fix`. Given that the major version number was increased, there's a fair number of (primarily whitespace) changes; please see https://prettier.io/blog/2020/03/21/2.0.0.html In order to reduce the size of these changes somewhat, this patch maintains the old "arrowParens" style for now (once mozilla-central updates Prettier we can simply choose the same formatting, assuming it will differ here).
2020-04-14 19:28:14 +09:00
.then(function () {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
return getTilingPatternIR(
{
fnArray: tilingOpList.fnArray,
argsArray: tilingOpList.argsArray,
},
patternDict,
args
);
})
.then(
Update Prettier to version 2.0 Please note that these changes were done automatically, using `gulp lint --fix`. Given that the major version number was increased, there's a fair number of (primarily whitespace) changes; please see https://prettier.io/blog/2020/03/21/2.0.0.html In order to reduce the size of these changes somewhat, this patch maintains the old "arrowParens" style for now (once mozilla-central updates Prettier we can simply choose the same formatting, assuming it will differ here).
2020-04-14 19:28:14 +09:00
function (tilingPatternIR) {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
// Add the dependencies to the parent operator list so they are
// resolved before the sub operator list is executed synchronously.
operatorList.addDependencies(tilingOpList.dependencies);
operatorList.addOp(fn, tilingPatternIR);
},
reason => {
if (reason instanceof AbortException) {
return;
}
if (this.options.ignoreErrors) {
// Error(s) in the TilingPattern -- sending unsupported feature
// notification and allow rendering to continue.
this.handler.send("UnsupportedFeature", {
Add more categories of unsupported features. Fixes #11815
2020-05-01 07:27:37 +09:00
featureId: UNSUPPORTED_FEATURES.errorTilingPattern,
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
});
warn(`handleTilingType - ignoring pattern: "${reason}".`);
return;
}
throw reason;
}
);
Make getOperatorList() calls independent and merge queues at end
2013-04-09 07:14:56 +09:00
},
Refactor text extraction / font loading logic
2012-09-14 00:09:46 +09:00
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
handleSetFont: function PartialEvaluator_handleSetFont(
resources,
fontArgs,
fontRef,
operatorList,
task,
state
) {
Make getOperatorList() calls independent and merge queues at end
2013-04-09 07:14:56 +09:00
// TODO(mack): Not needed?
var fontName;
if (fontArgs) {
fontArgs = fontArgs.slice();
fontName = fontArgs[0].name;
}
Incrementally render by sending the operator list by chunks as they're ready.
2013-08-01 03:17:36 +09:00
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
return this.loadFont(fontName, fontRef, resources)
.then(translated => {
if (!translated.font.isType3Font) {
return translated;
}
return translated
.loadType3Data(this, resources, operatorList, task)
Update Prettier to version 2.0 Please note that these changes were done automatically, using `gulp lint --fix`. Given that the major version number was increased, there's a fair number of (primarily whitespace) changes; please see https://prettier.io/blog/2020/03/21/2.0.0.html In order to reduce the size of these changes somewhat, this patch maintains the old "arrowParens" style for now (once mozilla-central updates Prettier we can simply choose the same formatting, assuming it will differ here).
2020-04-14 19:28:14 +09:00
.then(function () {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
return translated;
})
.catch(reason => {
Fix the linting errors, from the Prettier auto-formatting, that ESLint `--fix` couldn't handle This patch makes the follow changes: - Remove no longer necessary inline `// eslint-disable-...` comments. - Fix `// eslint-disable-...` comments that Prettier moved down, thus causing new linting errors. - Concatenate strings which now fit on just one line. - Fix comments that are now too long. - Finally, and most importantly, adjust comments that Prettier moved down, since the new positions often is confusing or outright wrong.
2019-12-26 04:03:46 +09:00
// Error in the font data -- sending unsupported feature
// notification.
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
this.handler.send("UnsupportedFeature", {
Add more categories of unsupported features. Fixes #11815
2020-05-01 07:27:37 +09:00
featureId: UNSUPPORTED_FEATURES.errorFontLoadType3,
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
});
Change the signature of `TranslatedFont`, and convert it to a proper class In preparation for the next patch, this changes the signature of `TranslatedFont` to take an object rather than individual parameters. This also, in my opinion, makes the call-sites easier to read since it essentially provides a small bit of documentation of the arguments. Finally, since it was necessary to touch `TranslatedFont` anyway it seemed like a good idea to also convert it to a proper `class`.
2020-04-03 17:19:02 +09:00
return new TranslatedFont({
loadedName: "g_font_error",
font: new ErrorFont(`Type3 font load error: ${reason}`),
dict: translated.font,
[api-minor] Change `Font.exportData` to, by default, stop exporting properties which are completely unused on the main-thread and/or in the API (PR 11773 follow-up) For years now, the `Font.exportData` method has (because of its previous implementation) been exporting many properties despite them being completely unused on the main-thread and/or in the API. This is unfortunate, since among those properties there's a number of potentially very large data-structures, containing e.g. Arrays and Objects, which thus have to be first structured cloned and then stored on the main-thread. With the changes in this patch, we'll thus by default save memory for *every* `Font` instance created (there can be a lot in longer documents). The memory savings obviously depends a lot on the actual font data, but some approximate figures are: For non-embedded fonts it can save a couple of kilobytes, for simple embedded fonts a handful of kilobytes, and for composite fonts the size of this auxiliary can even be larger than the actual font program itself. All-in-all, there's no good reason to keep exporting these properties by default when they're unused. However, since we cannot be sure that every property is unused in custom implementations of the PDF.js library, this patch adds a new `getDocument` option (named `fontExtraProperties`) that still allows access to the following properties: - "cMap": An internal data structure, only used with composite fonts and never really intended to be exposed on the main-thread and/or in the API. Note also that the `CMap`/`IdentityCMap` classes are a lot more complex than simple Objects, but only their "internal" properties survive the structured cloning used to send data to the main-thread. Given that CMaps can often be *very* large, not exporting them can also save a fair bit of memory. - "defaultEncoding": An internal property used with simple fonts, and used when building the glyph mapping on the worker-thread. Considering how complex that topic is, and given that not all font types are handled identically, exposing this on the main-thread and/or in the API most likely isn't useful. - "differences": An internal property used with simple fonts, and used when building the glyph mapping on the worker-thread. Considering how complex that topic is, and given that not all font types are handled identically, exposing this on the main-thread and/or in the API most likely isn't useful. - "isSymbolicFont": An internal property, used during font parsing and building of the glyph mapping on the worker-thread. - "seacMap": An internal map, only potentially used with *some* Type1/CFF fonts and never intended to be exposed in the API. The existing `Font.{charToGlyph, charToGlyphs}` functionality already takes this data into account when handling text. - "toFontChar": The glyph map, necessary for mapping characters to glyphs in the font, which is built upon the various encoding information contained in the font dictionary and/or font program. This is not directly used on the main-thread and/or in the API. - "toUnicode": The unicode map, necessary for text-extraction to work correctly, which is built upon the ToUnicode/CMap information contained in the font dictionary, but not directly used on the main-thread and/or in the API. - "vmetrics": An array of width data used with fonts which are composite *and* vertical, but not directly used on the main-thread and/or in the API. - "widths": An array of width data used with most fonts, but not directly used on the main-thread and/or in the API.
2020-04-03 18:51:46 +09:00
extraProperties: this.options.fontExtraProperties,
Change the signature of `TranslatedFont`, and convert it to a proper class In preparation for the next patch, this changes the signature of `TranslatedFont` to take an object rather than individual parameters. This also, in my opinion, makes the call-sites easier to read since it essentially provides a small bit of documentation of the arguments. Finally, since it was necessary to touch `TranslatedFont` anyway it seemed like a good idea to also convert it to a proper `class`.
2020-04-03 17:19:02 +09:00
});
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
});
})
.then(translated => {
state.font = translated.font;
translated.send(this.handler);
return translated.loadedName;
Adds Promise to the getOperatorList
2014-05-10 10:21:15 +09:00
});
Make getOperatorList() calls independent and merge queues at end
2013-04-09 07:14:56 +09:00
},
Add basic support for transparency groups.
2013-03-13 09:20:38 +09:00
Fallback to the built-in font renderer when font loading fails After PR 9340 all glyphs are now re-mapped to a Private Use Area (PUA) which means that if a font fails to load, for whatever reason[1], all glyphs in the font will now render as Unicode glyph outlines. This obviously doesn't look good, to say the least, and might be seen as a "regression" since previously many glyphs were left in their original positions which provided a slightly better fallback[2]. Hence this patch, which implements a *general* fallback to the PDF.js built-in font renderer for fonts that fail to load (i.e. are rejected by the sanitizer). One caveat here is that this only works for the Font Loading API, since it's easy to handle errors in that case[3]. The solution implemented in this patch does *not* in any way delay the loading of valid fonts, which was the problem with my previous attempt at a solution, and will only require a bit of extra work/waiting for those fonts that actually fail to load. *Please note:* This patch doesn't fix any of the underlying PDF.js font conversion bugs that's responsible for creating corrupt font files, however it does *improve* rendering in a number of cases; refer to this possibly incomplete list: [Bug 1524888](https://bugzilla.mozilla.org/show_bug.cgi?id=1524888) Issue 10175 Issue 10232 --- [1] Usually because the PDF.js font conversion code wasn't able to parse the font file correctly. [2] Glyphs fell back to some default font, which while not accurate was more useful than the current state. [3] Furthermore I'm not sure how to implement this generally, assuming that's even possible, and don't really have time/interest to look into it either.
2019-02-11 08:47:56 +09:00
handleText(chars, state) {
const font = state.font;
const glyphs = font.charsToGlyphs(chars);
Build paths for glyph accents when drawing text as curves
2014-05-04 00:28:30 +09:00
Fallback to the built-in font renderer when font loading fails After PR 9340 all glyphs are now re-mapped to a Private Use Area (PUA) which means that if a font fails to load, for whatever reason[1], all glyphs in the font will now render as Unicode glyph outlines. This obviously doesn't look good, to say the least, and might be seen as a "regression" since previously many glyphs were left in their original positions which provided a slightly better fallback[2]. Hence this patch, which implements a *general* fallback to the PDF.js built-in font renderer for fonts that fail to load (i.e. are rejected by the sanitizer). One caveat here is that this only works for the Font Loading API, since it's easy to handle errors in that case[3]. The solution implemented in this patch does *not* in any way delay the loading of valid fonts, which was the problem with my previous attempt at a solution, and will only require a bit of extra work/waiting for those fonts that actually fail to load. *Please note:* This patch doesn't fix any of the underlying PDF.js font conversion bugs that's responsible for creating corrupt font files, however it does *improve* rendering in a number of cases; refer to this possibly incomplete list: [Bug 1524888](https://bugzilla.mozilla.org/show_bug.cgi?id=1524888) Issue 10175 Issue 10232 --- [1] Usually because the PDF.js font conversion code wasn't able to parse the font file correctly. [2] Glyphs fell back to some default font, which while not accurate was more useful than the current state. [3] Furthermore I'm not sure how to implement this generally, assuming that's even possible, and don't really have time/interest to look into it either.
2019-02-11 08:47:56 +09:00
if (font.data) {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
const isAddToPathSet = !!(
state.textRenderingMode & TextRenderingMode.ADD_TO_PATH_FLAG
);
if (
isAddToPathSet ||
state.fillColorSpace.name === "Pattern" ||
font.disableFontFace ||
this.options.disableFontFace
) {
Fallback to the built-in font renderer when font loading fails After PR 9340 all glyphs are now re-mapped to a Private Use Area (PUA) which means that if a font fails to load, for whatever reason[1], all glyphs in the font will now render as Unicode glyph outlines. This obviously doesn't look good, to say the least, and might be seen as a "regression" since previously many glyphs were left in their original positions which provided a slightly better fallback[2]. Hence this patch, which implements a *general* fallback to the PDF.js built-in font renderer for fonts that fail to load (i.e. are rejected by the sanitizer). One caveat here is that this only works for the Font Loading API, since it's easy to handle errors in that case[3]. The solution implemented in this patch does *not* in any way delay the loading of valid fonts, which was the problem with my previous attempt at a solution, and will only require a bit of extra work/waiting for those fonts that actually fail to load. *Please note:* This patch doesn't fix any of the underlying PDF.js font conversion bugs that's responsible for creating corrupt font files, however it does *improve* rendering in a number of cases; refer to this possibly incomplete list: [Bug 1524888](https://bugzilla.mozilla.org/show_bug.cgi?id=1524888) Issue 10175 Issue 10232 --- [1] Usually because the PDF.js font conversion code wasn't able to parse the font file correctly. [2] Glyphs fell back to some default font, which while not accurate was more useful than the current state. [3] Furthermore I'm not sure how to implement this generally, assuming that's even possible, and don't really have time/interest to look into it either.
2019-02-11 08:47:56 +09:00
PartialEvaluator.buildFontPaths(font, glyphs, this.handler);
Move the creation of canvas path fonts to the worker.
2013-08-20 08:33:20 +09:00
}
}
return glyphs;
},
Ensure that there's always a setFont (Tf) operator before text rendering operators (issue 11651) The PDF document in question is *corrupt*, since it contains multiple instances of incorrect operators. We obviously don't want to slow down parsing of *all* documents (since most are valid), just to accommodate a particular bad PDF generator, hence the reason for the inline check before calling the `ensureStateFont` method.
2020-03-02 23:34:00 +09:00
ensureStateFont(state) {
if (state.font) {
return;
}
const reason = new FormatError(
"Missing setFont (Tf) operator before text rendering operator."
);
if (this.options.ignoreErrors) {
// Missing setFont operator before text rendering operator -- sending
// unsupported feature notification and allow rendering to continue.
this.handler.send("UnsupportedFeature", {
Add more categories of unsupported features. Fixes #11815
2020-05-01 07:27:37 +09:00
featureId: UNSUPPORTED_FEATURES.errorFontState,
Ensure that there's always a setFont (Tf) operator before text rendering operators (issue 11651) The PDF document in question is *corrupt*, since it contains multiple instances of incorrect operators. We obviously don't want to slow down parsing of *all* documents (since most are valid), just to accommodate a particular bad PDF generator, hence the reason for the inline check before calling the `ensureStateFont` method.
2020-03-02 23:34:00 +09:00
});
warn(`ensureStateFont: "${reason}".`);
return;
}
throw reason;
},
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
setGState: function PartialEvaluator_setGState(
resources,
gState,
operatorList,
task,
Add local caching of `ColorSpace`s, by name, in `PartialEvaluator.getOperatorList` (issue 2504) By caching parsed `ColorSpace`s, we thus don't need to re-parse the same data over and over which saves CPU cycles *and* reduces peak memory usage. (Obviously persistent memory usage *may* increase a tiny bit, but since the caching is done per `PartialEvaluator.getOperatorList` invocation and given that `ColorSpace` instances generally hold very little data this shouldn't be much of an issue.) Furthermore, by caching `ColorSpace`s we can also lookup the already parsed ones *synchronously* during the `OperatorList` building, instead of having to defer to the event loop/microtask queue since the parsing is done asynchronously (such that error handling is easier). Possible future improvements: - Cache/lookup parsed `ColorSpaces` used in `Pattern`s and `Image`s. - Attempt to cache *local* `ColorSpace`s by reference as well, in addition to only by name, assuming that there's documents where that would be beneficial and that it's not too difficult to implement. - Assuming there's documents that would benefit from it, also cache repeated `ColorSpace`s *globally* as well. Given that we've never, until now, been doing *any* caching of parsed `ColorSpace`s and that even using a simple name-only *local* cache helps tremendously in pathological cases, I purposely decided against complicating the implementation too much initially. Also, compared to parsing of `Image`s, simply creating a `ColorSpace` instance isn't that expensive (hence I'd be somewhat surprised if adding a *global* cache would help much). --- This patch was tested using: - The default `tracemonkey` PDF file, which was included mostly to show that "normal" documents aren't negatively affected by these changes. - The PDF file from issue 2504, i.e. https://dl-ctlg.panasonic.com/jp/manual/sd/sd_rbm1000_0.pdf, where most pages will switch *thousands* of times between a handful of `ColorSpace`s. with the following manifest file: ``` [ { "id": "tracemonkey", "file": "pdfs/tracemonkey.pdf", "md5": "9a192d8b1a7dc652a19835f6f08098bd", "rounds": 100, "type": "eq" }, { "id": "issue2504", "file": "../web/pdfs/issue2504.pdf", "md5": "", "rounds": 20, "type": "eq" } ] ``` which gave the following results when comparing this patch against the `master` branch: - Overall ``` -- Grouped By browser, pdf, stat -- browser | pdf | stat | Count | Baseline(ms) | Current(ms) | +/- | % | Result(P<.05) ------- | ----------- | ------------ | ----- | ------------ | ----------- | ---- | ------ | ------------- firefox | issue2504 | Overall | 640 | 977 | 497 | -479 | -49.08 | faster firefox | issue2504 | Page Request | 640 | 3 | 4 | 1 | 59.18 | firefox | issue2504 | Rendering | 640 | 974 | 493 | -481 | -49.37 | faster firefox | tracemonkey | Overall | 1400 | 116 | 111 | -5 | -4.43 | firefox | tracemonkey | Page Request | 1400 | 2 | 2 | 0 | -2.86 | firefox | tracemonkey | Rendering | 1400 | 114 | 109 | -5 | -4.47 | ``` - Page-specific ``` -- Grouped By browser, pdf, page, stat -- browser | pdf | page | stat | Count | Baseline(ms) | Current(ms) | +/- | % | Result(P<.05) ------- | ----------- | ---- | ------------ | ----- | ------------ | ----------- | ----- | ------- | ------------- firefox | issue2504 | 0 | Overall | 20 | 2295 | 1268 | -1027 | -44.76 | faster firefox | issue2504 | 0 | Page Request | 20 | 6 | 7 | 1 | 15.32 | firefox | issue2504 | 0 | Rendering | 20 | 2288 | 1260 | -1028 | -44.93 | faster firefox | issue2504 | 1 | Overall | 20 | 3059 | 2806 | -252 | -8.25 | faster firefox | issue2504 | 1 | Page Request | 20 | 11 | 14 | 3 | 23.25 | slower firefox | issue2504 | 1 | Rendering | 20 | 3047 | 2792 | -255 | -8.37 | faster firefox | issue2504 | 2 | Overall | 20 | 411 | 295 | -116 | -28.20 | faster firefox | issue2504 | 2 | Page Request | 20 | 2 | 42 | 40 | 1897.62 | firefox | issue2504 | 2 | Rendering | 20 | 409 | 253 | -156 | -38.09 | faster firefox | issue2504 | 3 | Overall | 20 | 736 | 299 | -437 | -59.34 | faster firefox | issue2504 | 3 | Page Request | 20 | 2 | 2 | 0 | 0.00 | firefox | issue2504 | 3 | Rendering | 20 | 734 | 297 | -437 | -59.49 | faster firefox | issue2504 | 4 | Overall | 20 | 356 | 458 | 102 | 28.63 | firefox | issue2504 | 4 | Page Request | 20 | 1 | 2 | 1 | 57.14 | slower firefox | issue2504 | 4 | Rendering | 20 | 354 | 455 | 101 | 28.53 | firefox | issue2504 | 5 | Overall | 20 | 1381 | 765 | -616 | -44.59 | faster firefox | issue2504 | 5 | Page Request | 20 | 3 | 5 | 2 | 50.00 | slower firefox | issue2504 | 5 | Rendering | 20 | 1378 | 760 | -617 | -44.81 | faster firefox | issue2504 | 6 | Overall | 20 | 757 | 299 | -459 | -60.57 | faster firefox | issue2504 | 6 | Page Request | 20 | 2 | 5 | 3 | 150.00 | slower firefox | issue2504 | 6 | Rendering | 20 | 755 | 294 | -462 | -61.11 | faster firefox | issue2504 | 7 | Overall | 20 | 394 | 302 | -92 | -23.39 | faster firefox | issue2504 | 7 | Page Request | 20 | 2 | 1 | -1 | -34.88 | faster firefox | issue2504 | 7 | Rendering | 20 | 392 | 301 | -91 | -23.32 | faster firefox | issue2504 | 8 | Overall | 20 | 2875 | 979 | -1896 | -65.95 | faster firefox | issue2504 | 8 | Page Request | 20 | 1 | 2 | 0 | 11.11 | firefox | issue2504 | 8 | Rendering | 20 | 2874 | 978 | -1896 | -65.99 | faster firefox | issue2504 | 9 | Overall | 20 | 700 | 332 | -368 | -52.60 | faster firefox | issue2504 | 9 | Page Request | 20 | 3 | 2 | 0 | -4.00 | firefox | issue2504 | 9 | Rendering | 20 | 698 | 329 | -368 | -52.78 | faster firefox | issue2504 | 10 | Overall | 20 | 3296 | 926 | -2370 | -71.91 | faster firefox | issue2504 | 10 | Page Request | 20 | 2 | 2 | 0 | -18.75 | firefox | issue2504 | 10 | Rendering | 20 | 3293 | 924 | -2370 | -71.96 | faster firefox | issue2504 | 11 | Overall | 20 | 524 | 197 | -327 | -62.34 | faster firefox | issue2504 | 11 | Page Request | 20 | 2 | 3 | 1 | 58.54 | firefox | issue2504 | 11 | Rendering | 20 | 522 | 194 | -328 | -62.81 | faster firefox | issue2504 | 12 | Overall | 20 | 752 | 369 | -384 | -50.98 | faster firefox | issue2504 | 12 | Page Request | 20 | 3 | 2 | -1 | -36.51 | faster firefox | issue2504 | 12 | Rendering | 20 | 749 | 367 | -382 | -51.05 | faster firefox | issue2504 | 13 | Overall | 20 | 679 | 487 | -193 | -28.38 | faster firefox | issue2504 | 13 | Page Request | 20 | 4 | 2 | -2 | -48.68 | faster firefox | issue2504 | 13 | Rendering | 20 | 676 | 485 | -191 | -28.28 | faster firefox | issue2504 | 14 | Overall | 20 | 474 | 283 | -191 | -40.26 | faster firefox | issue2504 | 14 | Page Request | 20 | 2 | 4 | 2 | 78.57 | firefox | issue2504 | 14 | Rendering | 20 | 471 | 279 | -192 | -40.79 | faster firefox | issue2504 | 15 | Overall | 20 | 860 | 618 | -241 | -28.05 | faster firefox | issue2504 | 15 | Page Request | 20 | 2 | 3 | 0 | 10.87 | firefox | issue2504 | 15 | Rendering | 20 | 857 | 616 | -241 | -28.15 | faster firefox | issue2504 | 16 | Overall | 20 | 389 | 243 | -147 | -37.71 | faster firefox | issue2504 | 16 | Page Request | 20 | 2 | 2 | 0 | 2.33 | firefox | issue2504 | 16 | Rendering | 20 | 387 | 240 | -147 | -37.94 | faster firefox | issue2504 | 17 | Overall | 20 | 1484 | 672 | -812 | -54.70 | faster firefox | issue2504 | 17 | Page Request | 20 | 2 | 3 | 1 | 37.21 | firefox | issue2504 | 17 | Rendering | 20 | 1482 | 669 | -812 | -54.84 | faster firefox | issue2504 | 18 | Overall | 20 | 575 | 252 | -323 | -56.12 | faster firefox | issue2504 | 18 | Page Request | 20 | 2 | 2 | 0 | -16.22 | firefox | issue2504 | 18 | Rendering | 20 | 573 | 251 | -322 | -56.24 | faster firefox | issue2504 | 19 | Overall | 20 | 517 | 227 | -290 | -56.08 | faster firefox | issue2504 | 19 | Page Request | 20 | 2 | 2 | 0 | 21.62 | firefox | issue2504 | 19 | Rendering | 20 | 515 | 225 | -290 | -56.37 | faster firefox | issue2504 | 20 | Overall | 20 | 668 | 670 | 2 | 0.31 | firefox | issue2504 | 20 | Page Request | 20 | 4 | 2 | -1 | -34.29 | firefox | issue2504 | 20 | Rendering | 20 | 664 | 667 | 3 | 0.49 | firefox | issue2504 | 21 | Overall | 20 | 486 | 309 | -177 | -36.44 | faster firefox | issue2504 | 21 | Page Request | 20 | 2 | 2 | 0 | 16.13 | firefox | issue2504 | 21 | Rendering | 20 | 484 | 307 | -177 | -36.60 | faster firefox | issue2504 | 22 | Overall | 20 | 543 | 267 | -276 | -50.85 | faster firefox | issue2504 | 22 | Page Request | 20 | 2 | 2 | 0 | 10.26 | firefox | issue2504 | 22 | Rendering | 20 | 541 | 265 | -276 | -51.07 | faster firefox | issue2504 | 23 | Overall | 20 | 3246 | 871 | -2375 | -73.17 | faster firefox | issue2504 | 23 | Page Request | 20 | 2 | 3 | 1 | 37.21 | firefox | issue2504 | 23 | Rendering | 20 | 3243 | 868 | -2376 | -73.25 | faster firefox | issue2504 | 24 | Overall | 20 | 379 | 156 | -223 | -58.83 | faster firefox | issue2504 | 24 | Page Request | 20 | 2 | 2 | 0 | -2.86 | firefox | issue2504 | 24 | Rendering | 20 | 378 | 154 | -223 | -59.10 | faster firefox | issue2504 | 25 | Overall | 20 | 176 | 127 | -50 | -28.19 | faster firefox | issue2504 | 25 | Page Request | 20 | 2 | 1 | 0 | -15.63 | firefox | issue2504 | 25 | Rendering | 20 | 175 | 125 | -49 | -28.31 | faster firefox | issue2504 | 26 | Overall | 20 | 181 | 108 | -74 | -40.67 | faster firefox | issue2504 | 26 | Page Request | 20 | 3 | 2 | -1 | -39.13 | faster firefox | issue2504 | 26 | Rendering | 20 | 178 | 105 | -72 | -40.69 | faster firefox | issue2504 | 27 | Overall | 20 | 208 | 104 | -104 | -49.92 | faster firefox | issue2504 | 27 | Page Request | 20 | 2 | 2 | 1 | 48.39 | firefox | issue2504 | 27 | Rendering | 20 | 206 | 102 | -104 | -50.64 | faster firefox | issue2504 | 28 | Overall | 20 | 241 | 111 | -131 | -54.16 | faster firefox | issue2504 | 28 | Page Request | 20 | 2 | 2 | -1 | -33.33 | firefox | issue2504 | 28 | Rendering | 20 | 239 | 109 | -130 | -54.39 | faster firefox | issue2504 | 29 | Overall | 20 | 321 | 196 | -125 | -39.05 | faster firefox | issue2504 | 29 | Page Request | 20 | 1 | 2 | 0 | 17.86 | firefox | issue2504 | 29 | Rendering | 20 | 319 | 194 | -126 | -39.35 | faster firefox | issue2504 | 30 | Overall | 20 | 651 | 271 | -380 | -58.41 | faster firefox | issue2504 | 30 | Page Request | 20 | 1 | 2 | 1 | 50.00 | firefox | issue2504 | 30 | Rendering | 20 | 649 | 269 | -381 | -58.60 | faster firefox | issue2504 | 31 | Overall | 20 | 1635 | 647 | -988 | -60.42 | faster firefox | issue2504 | 31 | Page Request | 20 | 1 | 2 | 0 | 30.43 | firefox | issue2504 | 31 | Rendering | 20 | 1634 | 645 | -988 | -60.49 | faster firefox | tracemonkey | 0 | Overall | 100 | 51 | 51 | 0 | 0.02 | firefox | tracemonkey | 0 | Page Request | 100 | 1 | 1 | 0 | -4.76 | firefox | tracemonkey | 0 | Rendering | 100 | 50 | 50 | 0 | 0.12 | firefox | tracemonkey | 1 | Overall | 100 | 97 | 91 | -5 | -5.52 | faster firefox | tracemonkey | 1 | Page Request | 100 | 3 | 3 | 0 | -1.32 | firefox | tracemonkey | 1 | Rendering | 100 | 94 | 88 | -5 | -5.73 | faster firefox | tracemonkey | 2 | Overall | 100 | 40 | 40 | 0 | 0.50 | firefox | tracemonkey | 2 | Page Request | 100 | 1 | 1 | 0 | 3.16 | firefox | tracemonkey | 2 | Rendering | 100 | 39 | 39 | 0 | 0.54 | firefox | tracemonkey | 3 | Overall | 100 | 62 | 62 | -1 | -0.94 | firefox | tracemonkey | 3 | Page Request | 100 | 1 | 1 | 0 | 17.05 | firefox | tracemonkey | 3 | Rendering | 100 | 61 | 61 | -1 | -1.11 | firefox | tracemonkey | 4 | Overall | 100 | 56 | 58 | 2 | 3.41 | firefox | tracemonkey | 4 | Page Request | 100 | 1 | 1 | 0 | 15.31 | firefox | tracemonkey | 4 | Rendering | 100 | 55 | 57 | 2 | 3.23 | firefox | tracemonkey | 5 | Overall | 100 | 73 | 71 | -2 | -2.28 | firefox | tracemonkey | 5 | Page Request | 100 | 2 | 2 | 0 | 12.20 | firefox | tracemonkey | 5 | Rendering | 100 | 71 | 69 | -2 | -2.69 | firefox | tracemonkey | 6 | Overall | 100 | 85 | 69 | -16 | -18.73 | faster firefox | tracemonkey | 6 | Page Request | 100 | 2 | 2 | 0 | -9.90 | firefox | tracemonkey | 6 | Rendering | 100 | 83 | 67 | -16 | -18.97 | faster firefox | tracemonkey | 7 | Overall | 100 | 65 | 64 | 0 | -0.37 | firefox | tracemonkey | 7 | Page Request | 100 | 1 | 1 | 0 | -11.94 | firefox | tracemonkey | 7 | Rendering | 100 | 63 | 63 | 0 | -0.05 | firefox | tracemonkey | 8 | Overall | 100 | 53 | 54 | 1 | 2.04 | firefox | tracemonkey | 8 | Page Request | 100 | 1 | 1 | 0 | 17.02 | firefox | tracemonkey | 8 | Rendering | 100 | 52 | 53 | 1 | 1.82 | firefox | tracemonkey | 9 | Overall | 100 | 79 | 73 | -6 | -7.86 | faster firefox | tracemonkey | 9 | Page Request | 100 | 2 | 2 | 0 | -15.14 | firefox | tracemonkey | 9 | Rendering | 100 | 77 | 71 | -6 | -7.86 | faster firefox | tracemonkey | 10 | Overall | 100 | 545 | 519 | -27 | -4.86 | faster firefox | tracemonkey | 10 | Page Request | 100 | 14 | 13 | 0 | -3.56 | firefox | tracemonkey | 10 | Rendering | 100 | 532 | 506 | -26 | -4.90 | faster firefox | tracemonkey | 11 | Overall | 100 | 42 | 41 | -1 | -2.50 | firefox | tracemonkey | 11 | Page Request | 100 | 1 | 1 | 0 | -27.42 | faster firefox | tracemonkey | 11 | Rendering | 100 | 41 | 40 | -1 | -1.75 | firefox | tracemonkey | 12 | Overall | 100 | 350 | 332 | -18 | -5.16 | faster firefox | tracemonkey | 12 | Page Request | 100 | 3 | 3 | 0 | -5.17 | firefox | tracemonkey | 12 | Rendering | 100 | 347 | 329 | -18 | -5.15 | faster firefox | tracemonkey | 13 | Overall | 100 | 31 | 31 | 0 | 0.52 | firefox | tracemonkey | 13 | Page Request | 100 | 1 | 1 | 0 | 4.95 | firefox | tracemonkey | 13 | Rendering | 100 | 30 | 30 | 0 | 0.20 | ```
2020-06-13 21:12:40 +09:00
stateManager,
localColorSpaceCache
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
) {
Remove setGStateForKey() closure. setGStateForKey() is a closure that serves no particularly useful purpose. This change inlines it at the single call site. This avoids 1.7 MiB of allocations (because closures are objects) for the MTA map mentioned in https://bugzilla.mozilla.org/show_bug.cgi?id=835380#c17.
2014-08-18 14:21:45 +09:00
// This array holds the converted/processed state data.
var gStateObj = [];
Don't directly access the private `map` in `setGState`, and ensure that we avoid indirect objects *This patch is based on something I noticed while debugging some of the PDF files in issue 6931.* In a number of the cases in `setGState`, we're implicitly assuming that we're not dealing with indirect objects (i.e. `Ref`s). See e.g. the 'Font' case, or the various cases where we simply do `gStateObj.push([key, value]);` (since the code in `canvas.js` won't be able to deal with a `Ref` for those cases). The reason that I didn't use `Dict_forEach` instead, is that it would re-introduce the unncessary closures that PR 5205 removed.
2016-02-04 00:53:18 +09:00
var gStateKeys = gState.getKeys();
Remove setGStateForKey() closure. setGStateForKey() is a closure that serves no particularly useful purpose. This change inlines it at the single call site. This avoids 1.7 MiB of allocations (because closures are objects) for the MTA map mentioned in https://bugzilla.mozilla.org/show_bug.cgi?id=835380#c17.
2014-08-18 14:21:45 +09:00
var promise = Promise.resolve();
Don't directly access the private `map` in `setGState`, and ensure that we avoid indirect objects *This patch is based on something I noticed while debugging some of the PDF files in issue 6931.* In a number of the cases in `setGState`, we're implicitly assuming that we're not dealing with indirect objects (i.e. `Ref`s). See e.g. the 'Font' case, or the various cases where we simply do `gStateObj.push([key, value]);` (since the code in `canvas.js` won't be able to deal with a `Ref` for those cases). The reason that I didn't use `Dict_forEach` instead, is that it would re-introduce the unncessary closures that PR 5205 removed.
2016-02-04 00:53:18 +09:00
for (var i = 0, ii = gStateKeys.length; i < ii; i++) {
Enable the ESLint `prefer-const` rule globally (PR 11450 follow-up) Please find additional details about the ESLint rule at https://eslint.org/docs/rules/prefer-const With the recent introduction of Prettier this sort of mass enabling of ESLint rules becomes a lot easier, since the code will be automatically reformatted as necessary to account for e.g. changed line lengths. Note that this patch is generated automatically, by using the ESLint `--fix` argument, and will thus require some additional clean-up (which is done separately).
2020-01-24 17:48:21 +09:00
const key = gStateKeys[i];
const value = gState.get(key);
Make getOperatorList() calls independent and merge queues at end
2013-04-09 07:14:56 +09:00
switch (key) {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
case "Type":
Make getOperatorList() calls independent and merge queues at end
2013-04-09 07:14:56 +09:00
break;
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
case "LW":
case "LC":
case "LJ":
case "ML":
case "D":
case "RI":
case "FL":
case "CA":
case "ca":
Make getOperatorList() calls independent and merge queues at end
2013-04-09 07:14:56 +09:00
gStateObj.push([key, value]);
break;
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
case "Font":
Replace unnecessary `bind(this)` and `var self = this` statements with arrow functions in `src/core/evaluator.js` Note that by using `let` instead of `var` in `PartialEvaluator.setGState` and `TranslatedFont.loadType3Data`, we can get rid of further `bind` usages since `let` is block-scoped. Also, the fact that `bind` wasn't used in the `Font` case inside of `setGState` is actually a bug which has been present ever since PR 5205, where a closure was replaced by a standard loop.[1] --- [1] I'm not aware of any bugs caused by this, but that is probably more a happy accident than anything else, since e.g. just removing the `bind` from the `SMask` case without using block-scoped variables causes test failures.
2017-04-30 06:36:43 +09:00
promise = promise.then(() => {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
return this.handleSetFont(
resources,
null,
value[0],
operatorList,
task,
stateManager.state
Update Prettier to version 2.0 Please note that these changes were done automatically, using `gulp lint --fix`. Given that the major version number was increased, there's a fair number of (primarily whitespace) changes; please see https://prettier.io/blog/2020/03/21/2.0.0.html In order to reduce the size of these changes somewhat, this patch maintains the old "arrowParens" style for now (once mozilla-central updates Prettier we can simply choose the same formatting, assuming it will differ here).
2020-04-14 19:28:14 +09:00
).then(function (loadedName) {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
operatorList.addDependency(loadedName);
gStateObj.push([key, [loadedName, value[1]]]);
});
Adds Promise to the getOperatorList
2014-05-10 10:21:15 +09:00
});
Make getOperatorList() calls independent and merge queues at end
2013-04-09 07:14:56 +09:00
break;
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
case "BM":
Normalize blend mode names.
2017-04-11 03:58:02 +09:00
gStateObj.push([key, normalizeBlendMode(value)]);
Make getOperatorList() calls independent and merge queues at end
2013-04-09 07:14:56 +09:00
break;
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
case "SMask":
if (isName(value, "None")) {
SMask emulation
2014-01-24 02:13:32 +09:00
gStateObj.push([key, false]);
break;
}
Don't directly access the private `map` in `setGState`, and ensure that we avoid indirect objects *This patch is based on something I noticed while debugging some of the PDF files in issue 6931.* In a number of the cases in `setGState`, we're implicitly assuming that we're not dealing with indirect objects (i.e. `Ref`s). See e.g. the 'Font' case, or the various cases where we simply do `gStateObj.push([key, value]);` (since the code in `canvas.js` won't be able to deal with a `Ref` for those cases). The reason that I didn't use `Dict_forEach` instead, is that it would re-introduce the unncessary closures that PR 5205 removed.
2016-02-04 00:53:18 +09:00
if (isDict(value)) {
Replace unnecessary `bind(this)` and `var self = this` statements with arrow functions in `src/core/evaluator.js` Note that by using `let` instead of `var` in `PartialEvaluator.setGState` and `TranslatedFont.loadType3Data`, we can get rid of further `bind` usages since `let` is block-scoped. Also, the fact that `bind` wasn't used in the `Font` case inside of `setGState` is actually a bug which has been present ever since PR 5205, where a closure was replaced by a standard loop.[1] --- [1] I'm not aware of any bugs caused by this, but that is probably more a happy accident than anything else, since e.g. just removing the `bind` from the `SMask` case without using block-scoped variables causes test failures.
2017-04-30 06:36:43 +09:00
promise = promise.then(() => {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
return this.handleSMask(
value,
resources,
operatorList,
task,
Add local caching of `ColorSpace`s, by name, in `PartialEvaluator.getOperatorList` (issue 2504) By caching parsed `ColorSpace`s, we thus don't need to re-parse the same data over and over which saves CPU cycles *and* reduces peak memory usage. (Obviously persistent memory usage *may* increase a tiny bit, but since the caching is done per `PartialEvaluator.getOperatorList` invocation and given that `ColorSpace` instances generally hold very little data this shouldn't be much of an issue.) Furthermore, by caching `ColorSpace`s we can also lookup the already parsed ones *synchronously* during the `OperatorList` building, instead of having to defer to the event loop/microtask queue since the parsing is done asynchronously (such that error handling is easier). Possible future improvements: - Cache/lookup parsed `ColorSpaces` used in `Pattern`s and `Image`s. - Attempt to cache *local* `ColorSpace`s by reference as well, in addition to only by name, assuming that there's documents where that would be beneficial and that it's not too difficult to implement. - Assuming there's documents that would benefit from it, also cache repeated `ColorSpace`s *globally* as well. Given that we've never, until now, been doing *any* caching of parsed `ColorSpace`s and that even using a simple name-only *local* cache helps tremendously in pathological cases, I purposely decided against complicating the implementation too much initially. Also, compared to parsing of `Image`s, simply creating a `ColorSpace` instance isn't that expensive (hence I'd be somewhat surprised if adding a *global* cache would help much). --- This patch was tested using: - The default `tracemonkey` PDF file, which was included mostly to show that "normal" documents aren't negatively affected by these changes. - The PDF file from issue 2504, i.e. https://dl-ctlg.panasonic.com/jp/manual/sd/sd_rbm1000_0.pdf, where most pages will switch *thousands* of times between a handful of `ColorSpace`s. with the following manifest file: ``` [ { "id": "tracemonkey", "file": "pdfs/tracemonkey.pdf", "md5": "9a192d8b1a7dc652a19835f6f08098bd", "rounds": 100, "type": "eq" }, { "id": "issue2504", "file": "../web/pdfs/issue2504.pdf", "md5": "", "rounds": 20, "type": "eq" } ] ``` which gave the following results when comparing this patch against the `master` branch: - Overall ``` -- Grouped By browser, pdf, stat -- browser | pdf | stat | Count | Baseline(ms) | Current(ms) | +/- | % | Result(P<.05) ------- | ----------- | ------------ | ----- | ------------ | ----------- | ---- | ------ | ------------- firefox | issue2504 | Overall | 640 | 977 | 497 | -479 | -49.08 | faster firefox | issue2504 | Page Request | 640 | 3 | 4 | 1 | 59.18 | firefox | issue2504 | Rendering | 640 | 974 | 493 | -481 | -49.37 | faster firefox | tracemonkey | Overall | 1400 | 116 | 111 | -5 | -4.43 | firefox | tracemonkey | Page Request | 1400 | 2 | 2 | 0 | -2.86 | firefox | tracemonkey | Rendering | 1400 | 114 | 109 | -5 | -4.47 | ``` - Page-specific ``` -- Grouped By browser, pdf, page, stat -- browser | pdf | page | stat | Count | Baseline(ms) | Current(ms) | +/- | % | Result(P<.05) ------- | ----------- | ---- | ------------ | ----- | ------------ | ----------- | ----- | ------- | ------------- firefox | issue2504 | 0 | Overall | 20 | 2295 | 1268 | -1027 | -44.76 | faster firefox | issue2504 | 0 | Page Request | 20 | 6 | 7 | 1 | 15.32 | firefox | issue2504 | 0 | Rendering | 20 | 2288 | 1260 | -1028 | -44.93 | faster firefox | issue2504 | 1 | Overall | 20 | 3059 | 2806 | -252 | -8.25 | faster firefox | issue2504 | 1 | Page Request | 20 | 11 | 14 | 3 | 23.25 | slower firefox | issue2504 | 1 | Rendering | 20 | 3047 | 2792 | -255 | -8.37 | faster firefox | issue2504 | 2 | Overall | 20 | 411 | 295 | -116 | -28.20 | faster firefox | issue2504 | 2 | Page Request | 20 | 2 | 42 | 40 | 1897.62 | firefox | issue2504 | 2 | Rendering | 20 | 409 | 253 | -156 | -38.09 | faster firefox | issue2504 | 3 | Overall | 20 | 736 | 299 | -437 | -59.34 | faster firefox | issue2504 | 3 | Page Request | 20 | 2 | 2 | 0 | 0.00 | firefox | issue2504 | 3 | Rendering | 20 | 734 | 297 | -437 | -59.49 | faster firefox | issue2504 | 4 | Overall | 20 | 356 | 458 | 102 | 28.63 | firefox | issue2504 | 4 | Page Request | 20 | 1 | 2 | 1 | 57.14 | slower firefox | issue2504 | 4 | Rendering | 20 | 354 | 455 | 101 | 28.53 | firefox | issue2504 | 5 | Overall | 20 | 1381 | 765 | -616 | -44.59 | faster firefox | issue2504 | 5 | Page Request | 20 | 3 | 5 | 2 | 50.00 | slower firefox | issue2504 | 5 | Rendering | 20 | 1378 | 760 | -617 | -44.81 | faster firefox | issue2504 | 6 | Overall | 20 | 757 | 299 | -459 | -60.57 | faster firefox | issue2504 | 6 | Page Request | 20 | 2 | 5 | 3 | 150.00 | slower firefox | issue2504 | 6 | Rendering | 20 | 755 | 294 | -462 | -61.11 | faster firefox | issue2504 | 7 | Overall | 20 | 394 | 302 | -92 | -23.39 | faster firefox | issue2504 | 7 | Page Request | 20 | 2 | 1 | -1 | -34.88 | faster firefox | issue2504 | 7 | Rendering | 20 | 392 | 301 | -91 | -23.32 | faster firefox | issue2504 | 8 | Overall | 20 | 2875 | 979 | -1896 | -65.95 | faster firefox | issue2504 | 8 | Page Request | 20 | 1 | 2 | 0 | 11.11 | firefox | issue2504 | 8 | Rendering | 20 | 2874 | 978 | -1896 | -65.99 | faster firefox | issue2504 | 9 | Overall | 20 | 700 | 332 | -368 | -52.60 | faster firefox | issue2504 | 9 | Page Request | 20 | 3 | 2 | 0 | -4.00 | firefox | issue2504 | 9 | Rendering | 20 | 698 | 329 | -368 | -52.78 | faster firefox | issue2504 | 10 | Overall | 20 | 3296 | 926 | -2370 | -71.91 | faster firefox | issue2504 | 10 | Page Request | 20 | 2 | 2 | 0 | -18.75 | firefox | issue2504 | 10 | Rendering | 20 | 3293 | 924 | -2370 | -71.96 | faster firefox | issue2504 | 11 | Overall | 20 | 524 | 197 | -327 | -62.34 | faster firefox | issue2504 | 11 | Page Request | 20 | 2 | 3 | 1 | 58.54 | firefox | issue2504 | 11 | Rendering | 20 | 522 | 194 | -328 | -62.81 | faster firefox | issue2504 | 12 | Overall | 20 | 752 | 369 | -384 | -50.98 | faster firefox | issue2504 | 12 | Page Request | 20 | 3 | 2 | -1 | -36.51 | faster firefox | issue2504 | 12 | Rendering | 20 | 749 | 367 | -382 | -51.05 | faster firefox | issue2504 | 13 | Overall | 20 | 679 | 487 | -193 | -28.38 | faster firefox | issue2504 | 13 | Page Request | 20 | 4 | 2 | -2 | -48.68 | faster firefox | issue2504 | 13 | Rendering | 20 | 676 | 485 | -191 | -28.28 | faster firefox | issue2504 | 14 | Overall | 20 | 474 | 283 | -191 | -40.26 | faster firefox | issue2504 | 14 | Page Request | 20 | 2 | 4 | 2 | 78.57 | firefox | issue2504 | 14 | Rendering | 20 | 471 | 279 | -192 | -40.79 | faster firefox | issue2504 | 15 | Overall | 20 | 860 | 618 | -241 | -28.05 | faster firefox | issue2504 | 15 | Page Request | 20 | 2 | 3 | 0 | 10.87 | firefox | issue2504 | 15 | Rendering | 20 | 857 | 616 | -241 | -28.15 | faster firefox | issue2504 | 16 | Overall | 20 | 389 | 243 | -147 | -37.71 | faster firefox | issue2504 | 16 | Page Request | 20 | 2 | 2 | 0 | 2.33 | firefox | issue2504 | 16 | Rendering | 20 | 387 | 240 | -147 | -37.94 | faster firefox | issue2504 | 17 | Overall | 20 | 1484 | 672 | -812 | -54.70 | faster firefox | issue2504 | 17 | Page Request | 20 | 2 | 3 | 1 | 37.21 | firefox | issue2504 | 17 | Rendering | 20 | 1482 | 669 | -812 | -54.84 | faster firefox | issue2504 | 18 | Overall | 20 | 575 | 252 | -323 | -56.12 | faster firefox | issue2504 | 18 | Page Request | 20 | 2 | 2 | 0 | -16.22 | firefox | issue2504 | 18 | Rendering | 20 | 573 | 251 | -322 | -56.24 | faster firefox | issue2504 | 19 | Overall | 20 | 517 | 227 | -290 | -56.08 | faster firefox | issue2504 | 19 | Page Request | 20 | 2 | 2 | 0 | 21.62 | firefox | issue2504 | 19 | Rendering | 20 | 515 | 225 | -290 | -56.37 | faster firefox | issue2504 | 20 | Overall | 20 | 668 | 670 | 2 | 0.31 | firefox | issue2504 | 20 | Page Request | 20 | 4 | 2 | -1 | -34.29 | firefox | issue2504 | 20 | Rendering | 20 | 664 | 667 | 3 | 0.49 | firefox | issue2504 | 21 | Overall | 20 | 486 | 309 | -177 | -36.44 | faster firefox | issue2504 | 21 | Page Request | 20 | 2 | 2 | 0 | 16.13 | firefox | issue2504 | 21 | Rendering | 20 | 484 | 307 | -177 | -36.60 | faster firefox | issue2504 | 22 | Overall | 20 | 543 | 267 | -276 | -50.85 | faster firefox | issue2504 | 22 | Page Request | 20 | 2 | 2 | 0 | 10.26 | firefox | issue2504 | 22 | Rendering | 20 | 541 | 265 | -276 | -51.07 | faster firefox | issue2504 | 23 | Overall | 20 | 3246 | 871 | -2375 | -73.17 | faster firefox | issue2504 | 23 | Page Request | 20 | 2 | 3 | 1 | 37.21 | firefox | issue2504 | 23 | Rendering | 20 | 3243 | 868 | -2376 | -73.25 | faster firefox | issue2504 | 24 | Overall | 20 | 379 | 156 | -223 | -58.83 | faster firefox | issue2504 | 24 | Page Request | 20 | 2 | 2 | 0 | -2.86 | firefox | issue2504 | 24 | Rendering | 20 | 378 | 154 | -223 | -59.10 | faster firefox | issue2504 | 25 | Overall | 20 | 176 | 127 | -50 | -28.19 | faster firefox | issue2504 | 25 | Page Request | 20 | 2 | 1 | 0 | -15.63 | firefox | issue2504 | 25 | Rendering | 20 | 175 | 125 | -49 | -28.31 | faster firefox | issue2504 | 26 | Overall | 20 | 181 | 108 | -74 | -40.67 | faster firefox | issue2504 | 26 | Page Request | 20 | 3 | 2 | -1 | -39.13 | faster firefox | issue2504 | 26 | Rendering | 20 | 178 | 105 | -72 | -40.69 | faster firefox | issue2504 | 27 | Overall | 20 | 208 | 104 | -104 | -49.92 | faster firefox | issue2504 | 27 | Page Request | 20 | 2 | 2 | 1 | 48.39 | firefox | issue2504 | 27 | Rendering | 20 | 206 | 102 | -104 | -50.64 | faster firefox | issue2504 | 28 | Overall | 20 | 241 | 111 | -131 | -54.16 | faster firefox | issue2504 | 28 | Page Request | 20 | 2 | 2 | -1 | -33.33 | firefox | issue2504 | 28 | Rendering | 20 | 239 | 109 | -130 | -54.39 | faster firefox | issue2504 | 29 | Overall | 20 | 321 | 196 | -125 | -39.05 | faster firefox | issue2504 | 29 | Page Request | 20 | 1 | 2 | 0 | 17.86 | firefox | issue2504 | 29 | Rendering | 20 | 319 | 194 | -126 | -39.35 | faster firefox | issue2504 | 30 | Overall | 20 | 651 | 271 | -380 | -58.41 | faster firefox | issue2504 | 30 | Page Request | 20 | 1 | 2 | 1 | 50.00 | firefox | issue2504 | 30 | Rendering | 20 | 649 | 269 | -381 | -58.60 | faster firefox | issue2504 | 31 | Overall | 20 | 1635 | 647 | -988 | -60.42 | faster firefox | issue2504 | 31 | Page Request | 20 | 1 | 2 | 0 | 30.43 | firefox | issue2504 | 31 | Rendering | 20 | 1634 | 645 | -988 | -60.49 | faster firefox | tracemonkey | 0 | Overall | 100 | 51 | 51 | 0 | 0.02 | firefox | tracemonkey | 0 | Page Request | 100 | 1 | 1 | 0 | -4.76 | firefox | tracemonkey | 0 | Rendering | 100 | 50 | 50 | 0 | 0.12 | firefox | tracemonkey | 1 | Overall | 100 | 97 | 91 | -5 | -5.52 | faster firefox | tracemonkey | 1 | Page Request | 100 | 3 | 3 | 0 | -1.32 | firefox | tracemonkey | 1 | Rendering | 100 | 94 | 88 | -5 | -5.73 | faster firefox | tracemonkey | 2 | Overall | 100 | 40 | 40 | 0 | 0.50 | firefox | tracemonkey | 2 | Page Request | 100 | 1 | 1 | 0 | 3.16 | firefox | tracemonkey | 2 | Rendering | 100 | 39 | 39 | 0 | 0.54 | firefox | tracemonkey | 3 | Overall | 100 | 62 | 62 | -1 | -0.94 | firefox | tracemonkey | 3 | Page Request | 100 | 1 | 1 | 0 | 17.05 | firefox | tracemonkey | 3 | Rendering | 100 | 61 | 61 | -1 | -1.11 | firefox | tracemonkey | 4 | Overall | 100 | 56 | 58 | 2 | 3.41 | firefox | tracemonkey | 4 | Page Request | 100 | 1 | 1 | 0 | 15.31 | firefox | tracemonkey | 4 | Rendering | 100 | 55 | 57 | 2 | 3.23 | firefox | tracemonkey | 5 | Overall | 100 | 73 | 71 | -2 | -2.28 | firefox | tracemonkey | 5 | Page Request | 100 | 2 | 2 | 0 | 12.20 | firefox | tracemonkey | 5 | Rendering | 100 | 71 | 69 | -2 | -2.69 | firefox | tracemonkey | 6 | Overall | 100 | 85 | 69 | -16 | -18.73 | faster firefox | tracemonkey | 6 | Page Request | 100 | 2 | 2 | 0 | -9.90 | firefox | tracemonkey | 6 | Rendering | 100 | 83 | 67 | -16 | -18.97 | faster firefox | tracemonkey | 7 | Overall | 100 | 65 | 64 | 0 | -0.37 | firefox | tracemonkey | 7 | Page Request | 100 | 1 | 1 | 0 | -11.94 | firefox | tracemonkey | 7 | Rendering | 100 | 63 | 63 | 0 | -0.05 | firefox | tracemonkey | 8 | Overall | 100 | 53 | 54 | 1 | 2.04 | firefox | tracemonkey | 8 | Page Request | 100 | 1 | 1 | 0 | 17.02 | firefox | tracemonkey | 8 | Rendering | 100 | 52 | 53 | 1 | 1.82 | firefox | tracemonkey | 9 | Overall | 100 | 79 | 73 | -6 | -7.86 | faster firefox | tracemonkey | 9 | Page Request | 100 | 2 | 2 | 0 | -15.14 | firefox | tracemonkey | 9 | Rendering | 100 | 77 | 71 | -6 | -7.86 | faster firefox | tracemonkey | 10 | Overall | 100 | 545 | 519 | -27 | -4.86 | faster firefox | tracemonkey | 10 | Page Request | 100 | 14 | 13 | 0 | -3.56 | firefox | tracemonkey | 10 | Rendering | 100 | 532 | 506 | -26 | -4.90 | faster firefox | tracemonkey | 11 | Overall | 100 | 42 | 41 | -1 | -2.50 | firefox | tracemonkey | 11 | Page Request | 100 | 1 | 1 | 0 | -27.42 | faster firefox | tracemonkey | 11 | Rendering | 100 | 41 | 40 | -1 | -1.75 | firefox | tracemonkey | 12 | Overall | 100 | 350 | 332 | -18 | -5.16 | faster firefox | tracemonkey | 12 | Page Request | 100 | 3 | 3 | 0 | -5.17 | firefox | tracemonkey | 12 | Rendering | 100 | 347 | 329 | -18 | -5.15 | faster firefox | tracemonkey | 13 | Overall | 100 | 31 | 31 | 0 | 0.52 | firefox | tracemonkey | 13 | Page Request | 100 | 1 | 1 | 0 | 4.95 | firefox | tracemonkey | 13 | Rendering | 100 | 30 | 30 | 0 | 0.20 | ```
2020-06-13 21:12:40 +09:00
stateManager,
localColorSpaceCache
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
);
Replace unnecessary `bind(this)` and `var self = this` statements with arrow functions in `src/core/evaluator.js` Note that by using `let` instead of `var` in `PartialEvaluator.setGState` and `TranslatedFont.loadType3Data`, we can get rid of further `bind` usages since `let` is block-scoped. Also, the fact that `bind` wasn't used in the `Font` case inside of `setGState` is actually a bug which has been present ever since PR 5205, where a closure was replaced by a standard loop.[1] --- [1] I'm not aware of any bugs caused by this, but that is probably more a happy accident than anything else, since e.g. just removing the `bind` from the `SMask` case without using block-scoped variables causes test failures.
2017-04-30 06:36:43 +09:00
});
SMask emulation
2014-01-24 02:13:32 +09:00
gStateObj.push([key, true]);
} else {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
warn("Unsupported SMask type");
SMask emulation
2014-01-24 02:13:32 +09:00
}
Make getOperatorList() calls independent and merge queues at end
2013-04-09 07:14:56 +09:00
break;
// Only generate info log messages for the following since
Ignore setGState no-ops. For the document in #2504, 11% of the ops are `setGState` with a `gStateObj` that is an empty array, which is a no-op. This is possible because we ignore various setGState keys (OP, OPM, BG, etc). This change prevents these ops from being inserted into the operator list.
2014-08-15 12:34:53 +09:00
// they are unlikely to have a big impact on the rendering.
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
case "OP":
case "op":
case "OPM":
case "BG":
case "BG2":
case "UCR":
case "UCR2":
case "TR":
case "TR2":
case "HT":
case "SM":
case "SA":
case "AIS":
case "TK":
Make getOperatorList() calls independent and merge queues at end
2013-04-09 07:14:56 +09:00
// TODO implement these operators.
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
info("graphic state operator " + key);
Make getOperatorList() calls independent and merge queues at end
2013-04-09 07:14:56 +09:00
break;
default:
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
info("Unknown graphic state operator " + key);
Make getOperatorList() calls independent and merge queues at end
2013-04-09 07:14:56 +09:00
break;
}
}
Update Prettier to version 2.0 Please note that these changes were done automatically, using `gulp lint --fix`. Given that the major version number was increased, there's a fair number of (primarily whitespace) changes; please see https://prettier.io/blog/2020/03/21/2.0.0.html In order to reduce the size of these changes somewhat, this patch maintains the old "arrowParens" style for now (once mozilla-central updates Prettier we can simply choose the same formatting, assuming it will differ here).
2020-04-14 19:28:14 +09:00
return promise.then(function () {
Actually ignore no-op `setGState` (PR 5192 followup) The intention of PR 5192 was to avoid adding empty `setGState` ops to the operatorList. But the patch accidentally used `>=`, which means that it's not actually working as intended, since empty arrays always have `length === 0`.
2016-02-03 22:29:20 +09:00
if (gStateObj.length > 0) {
Ignore setGState no-ops. For the document in #2504, 11% of the ops are `setGState` with a `gStateObj` that is an empty array, which is a no-op. This is possible because we ignore various setGState keys (OP, OPM, BG, etc). This change prevents these ops from being inserted into the operator list.
2014-08-15 12:34:53 +09:00
operatorList.addOp(OPS.setGState, [gStateObj]);
}
Adds Promise to the getOperatorList
2014-05-10 10:21:15 +09:00
});
Make getOperatorList() calls independent and merge queues at end
2013-04-09 07:14:56 +09:00
},
Removes "too many inline images" limit
2012-12-08 03:19:43 +09:00
Remove unnecessary `xref` parameters from various method signatures in `PartialEvaluator`, since `this.xref` is already available in the relevant scope For reasons I don't pretend to understand, we're passing around `xref` arguments to a bunch of methods despite `this.xref` being available in `PartialEvaluator`. This patch is a small first small step towards cleaning up the, often unwieldy, signatures of methods in `PartialEvaluator`.
2017-03-26 21:12:53 +09:00
loadFont: function PartialEvaluator_loadFont(fontName, font, resources) {
[api-minor] Change `Font.exportData` to, by default, stop exporting properties which are completely unused on the main-thread and/or in the API (PR 11773 follow-up) For years now, the `Font.exportData` method has (because of its previous implementation) been exporting many properties despite them being completely unused on the main-thread and/or in the API. This is unfortunate, since among those properties there's a number of potentially very large data-structures, containing e.g. Arrays and Objects, which thus have to be first structured cloned and then stored on the main-thread. With the changes in this patch, we'll thus by default save memory for *every* `Font` instance created (there can be a lot in longer documents). The memory savings obviously depends a lot on the actual font data, but some approximate figures are: For non-embedded fonts it can save a couple of kilobytes, for simple embedded fonts a handful of kilobytes, and for composite fonts the size of this auxiliary can even be larger than the actual font program itself. All-in-all, there's no good reason to keep exporting these properties by default when they're unused. However, since we cannot be sure that every property is unused in custom implementations of the PDF.js library, this patch adds a new `getDocument` option (named `fontExtraProperties`) that still allows access to the following properties: - "cMap": An internal data structure, only used with composite fonts and never really intended to be exposed on the main-thread and/or in the API. Note also that the `CMap`/`IdentityCMap` classes are a lot more complex than simple Objects, but only their "internal" properties survive the structured cloning used to send data to the main-thread. Given that CMaps can often be *very* large, not exporting them can also save a fair bit of memory. - "defaultEncoding": An internal property used with simple fonts, and used when building the glyph mapping on the worker-thread. Considering how complex that topic is, and given that not all font types are handled identically, exposing this on the main-thread and/or in the API most likely isn't useful. - "differences": An internal property used with simple fonts, and used when building the glyph mapping on the worker-thread. Considering how complex that topic is, and given that not all font types are handled identically, exposing this on the main-thread and/or in the API most likely isn't useful. - "isSymbolicFont": An internal property, used during font parsing and building of the glyph mapping on the worker-thread. - "seacMap": An internal map, only potentially used with *some* Type1/CFF fonts and never intended to be exposed in the API. The existing `Font.{charToGlyph, charToGlyphs}` functionality already takes this data into account when handling text. - "toFontChar": The glyph map, necessary for mapping characters to glyphs in the font, which is built upon the various encoding information contained in the font dictionary and/or font program. This is not directly used on the main-thread and/or in the API. - "toUnicode": The unicode map, necessary for text-extraction to work correctly, which is built upon the ToUnicode/CMap information contained in the font dictionary, but not directly used on the main-thread and/or in the API. - "vmetrics": An array of width data used with fonts which are composite *and* vertical, but not directly used on the main-thread and/or in the API. - "widths": An array of width data used with most fonts, but not directly used on the main-thread and/or in the API.
2020-04-03 18:51:46 +09:00
const errorFont = () => {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
return Promise.resolve(
Change the signature of `TranslatedFont`, and convert it to a proper class In preparation for the next patch, this changes the signature of `TranslatedFont` to take an object rather than individual parameters. This also, in my opinion, makes the call-sites easier to read since it essentially provides a small bit of documentation of the arguments. Finally, since it was necessary to touch `TranslatedFont` anyway it seemed like a good idea to also convert it to a proper `class`.
2020-04-03 17:19:02 +09:00
new TranslatedFont({
loadedName: "g_font_error",
font: new ErrorFont(`Font "${fontName}" is not available.`),
dict: font,
[api-minor] Change `Font.exportData` to, by default, stop exporting properties which are completely unused on the main-thread and/or in the API (PR 11773 follow-up) For years now, the `Font.exportData` method has (because of its previous implementation) been exporting many properties despite them being completely unused on the main-thread and/or in the API. This is unfortunate, since among those properties there's a number of potentially very large data-structures, containing e.g. Arrays and Objects, which thus have to be first structured cloned and then stored on the main-thread. With the changes in this patch, we'll thus by default save memory for *every* `Font` instance created (there can be a lot in longer documents). The memory savings obviously depends a lot on the actual font data, but some approximate figures are: For non-embedded fonts it can save a couple of kilobytes, for simple embedded fonts a handful of kilobytes, and for composite fonts the size of this auxiliary can even be larger than the actual font program itself. All-in-all, there's no good reason to keep exporting these properties by default when they're unused. However, since we cannot be sure that every property is unused in custom implementations of the PDF.js library, this patch adds a new `getDocument` option (named `fontExtraProperties`) that still allows access to the following properties: - "cMap": An internal data structure, only used with composite fonts and never really intended to be exposed on the main-thread and/or in the API. Note also that the `CMap`/`IdentityCMap` classes are a lot more complex than simple Objects, but only their "internal" properties survive the structured cloning used to send data to the main-thread. Given that CMaps can often be *very* large, not exporting them can also save a fair bit of memory. - "defaultEncoding": An internal property used with simple fonts, and used when building the glyph mapping on the worker-thread. Considering how complex that topic is, and given that not all font types are handled identically, exposing this on the main-thread and/or in the API most likely isn't useful. - "differences": An internal property used with simple fonts, and used when building the glyph mapping on the worker-thread. Considering how complex that topic is, and given that not all font types are handled identically, exposing this on the main-thread and/or in the API most likely isn't useful. - "isSymbolicFont": An internal property, used during font parsing and building of the glyph mapping on the worker-thread. - "seacMap": An internal map, only potentially used with *some* Type1/CFF fonts and never intended to be exposed in the API. The existing `Font.{charToGlyph, charToGlyphs}` functionality already takes this data into account when handling text. - "toFontChar": The glyph map, necessary for mapping characters to glyphs in the font, which is built upon the various encoding information contained in the font dictionary and/or font program. This is not directly used on the main-thread and/or in the API. - "toUnicode": The unicode map, necessary for text-extraction to work correctly, which is built upon the ToUnicode/CMap information contained in the font dictionary, but not directly used on the main-thread and/or in the API. - "vmetrics": An array of width data used with fonts which are composite *and* vertical, but not directly used on the main-thread and/or in the API. - "widths": An array of width data used with most fonts, but not directly used on the main-thread and/or in the API.
2020-04-03 18:51:46 +09:00
extraProperties: this.options.fontExtraProperties,
Change the signature of `TranslatedFont`, and convert it to a proper class In preparation for the next patch, this changes the signature of `TranslatedFont` to take an object rather than individual parameters. This also, in my opinion, makes the call-sites easier to read since it essentially provides a small bit of documentation of the arguments. Finally, since it was necessary to touch `TranslatedFont` anyway it seemed like a good idea to also convert it to a proper `class`.
2020-04-03 17:19:02 +09:00
})
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
);
[api-minor] Change `Font.exportData` to, by default, stop exporting properties which are completely unused on the main-thread and/or in the API (PR 11773 follow-up) For years now, the `Font.exportData` method has (because of its previous implementation) been exporting many properties despite them being completely unused on the main-thread and/or in the API. This is unfortunate, since among those properties there's a number of potentially very large data-structures, containing e.g. Arrays and Objects, which thus have to be first structured cloned and then stored on the main-thread. With the changes in this patch, we'll thus by default save memory for *every* `Font` instance created (there can be a lot in longer documents). The memory savings obviously depends a lot on the actual font data, but some approximate figures are: For non-embedded fonts it can save a couple of kilobytes, for simple embedded fonts a handful of kilobytes, and for composite fonts the size of this auxiliary can even be larger than the actual font program itself. All-in-all, there's no good reason to keep exporting these properties by default when they're unused. However, since we cannot be sure that every property is unused in custom implementations of the PDF.js library, this patch adds a new `getDocument` option (named `fontExtraProperties`) that still allows access to the following properties: - "cMap": An internal data structure, only used with composite fonts and never really intended to be exposed on the main-thread and/or in the API. Note also that the `CMap`/`IdentityCMap` classes are a lot more complex than simple Objects, but only their "internal" properties survive the structured cloning used to send data to the main-thread. Given that CMaps can often be *very* large, not exporting them can also save a fair bit of memory. - "defaultEncoding": An internal property used with simple fonts, and used when building the glyph mapping on the worker-thread. Considering how complex that topic is, and given that not all font types are handled identically, exposing this on the main-thread and/or in the API most likely isn't useful. - "differences": An internal property used with simple fonts, and used when building the glyph mapping on the worker-thread. Considering how complex that topic is, and given that not all font types are handled identically, exposing this on the main-thread and/or in the API most likely isn't useful. - "isSymbolicFont": An internal property, used during font parsing and building of the glyph mapping on the worker-thread. - "seacMap": An internal map, only potentially used with *some* Type1/CFF fonts and never intended to be exposed in the API. The existing `Font.{charToGlyph, charToGlyphs}` functionality already takes this data into account when handling text. - "toFontChar": The glyph map, necessary for mapping characters to glyphs in the font, which is built upon the various encoding information contained in the font dictionary and/or font program. This is not directly used on the main-thread and/or in the API. - "toUnicode": The unicode map, necessary for text-extraction to work correctly, which is built upon the ToUnicode/CMap information contained in the font dictionary, but not directly used on the main-thread and/or in the API. - "vmetrics": An array of width data used with fonts which are composite *and* vertical, but not directly used on the main-thread and/or in the API. - "widths": An array of width data used with most fonts, but not directly used on the main-thread and/or in the API.
2020-04-03 18:51:46 +09:00
};
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
var fontRef,
xref = this.xref;
if (font) {
// Loading by ref.
Remove most `assert()` calls (issue 8506) This replaces `assert` calls with `throw new FormatError()`/`throw new Error()`. In a few places, throwing an `Error` (which is what `assert` meant) isn't correct since the enclosing function is supposed to return a `Promise`, hence some cases were changed to `Promise.reject(...)` and similarily for `createPromiseCapability` instances.
2017-07-20 21:04:54 +09:00
if (!isRef(font)) {
Attempt to fallback to a default font, for non-available ones, in `PartialEvaluator.loadFont` This handles the two different ways that fonts can be loaded, either by Name (which is the common case) or by Reference. Furthermore, this also takes the `ignoreErrors` option into account when deciding whether to fallback or Error. Finally, by creating a minimal but valid Font dictionary, there's no special-cases necessary in any of the font parsing code. Co-authored-by: huzjakd <huzjakd@gmail.com> Co-Authored-By: Jonas Jenwald <jonas.jenwald@gmail.com>
2019-10-02 21:13:49 +09:00
throw new FormatError('The "font" object should be a reference.');
Remove most `assert()` calls (issue 8506) This replaces `assert` calls with `throw new FormatError()`/`throw new Error()`. In a few places, throwing an `Error` (which is what `assert` meant) isn't correct since the enclosing function is supposed to return a `Promise`, hence some cases were changed to `Promise.reject(...)` and similarily for `createPromiseCapability` instances.
2017-07-20 21:04:54 +09:00
}
Cache fonts by reference.
2013-06-26 02:33:53 +09:00
fontRef = font;
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
} else {
// Loading by name.
var fontRes = resources.get("Font");
Cache fonts by reference.
2013-06-26 02:33:53 +09:00
if (fontRes) {
fontRef = fontRes.getRaw(fontName);
}
}
Return ErrorFont in loadFont when the fontRef is undefined
2014-06-12 19:46:39 +09:00
if (!fontRef) {
Update Prettier to version 2.0 Please note that these changes were done automatically, using `gulp lint --fix`. Given that the major version number was increased, there's a fair number of (primarily whitespace) changes; please see https://prettier.io/blog/2020/03/21/2.0.0.html In order to reduce the size of these changes somewhat, this patch maintains the old "arrowParens" style for now (once mozilla-central updates Prettier we can simply choose the same formatting, assuming it will differ here).
2020-04-14 19:28:14 +09:00
const partialMsg = `Font "${
fontName || (font && font.toString())
}" is not available`;
Attempt to fallback to a default font, for non-available ones, in `PartialEvaluator.loadFont` This handles the two different ways that fonts can be loaded, either by Name (which is the common case) or by Reference. Furthermore, this also takes the `ignoreErrors` option into account when deciding whether to fallback or Error. Finally, by creating a minimal but valid Font dictionary, there's no special-cases necessary in any of the font parsing code. Co-authored-by: huzjakd <huzjakd@gmail.com> Co-Authored-By: Jonas Jenwald <jonas.jenwald@gmail.com>
2019-10-02 21:13:49 +09:00
if (!this.options.ignoreErrors && !this.parsingType3Font) {
warn(`${partialMsg}.`);
return errorFont();
}
// Font not found -- sending unsupported feature notification.
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
this.handler.send("UnsupportedFeature", {
Add more categories of unsupported features. Fixes #11815
2020-05-01 07:27:37 +09:00
featureId: UNSUPPORTED_FEATURES.errorFontMissing,
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
});
Attempt to fallback to a default font, for non-available ones, in `PartialEvaluator.loadFont` This handles the two different ways that fonts can be loaded, either by Name (which is the common case) or by Reference. Furthermore, this also takes the `ignoreErrors` option into account when deciding whether to fallback or Error. Finally, by creating a minimal but valid Font dictionary, there's no special-cases necessary in any of the font parsing code. Co-authored-by: huzjakd <huzjakd@gmail.com> Co-Authored-By: Jonas Jenwald <jonas.jenwald@gmail.com>
2019-10-02 21:13:49 +09:00
warn(`${partialMsg} -- attempting to fallback to a default font.`);
// Falling back to a default font to avoid completely broken rendering,
// but note that there're no guarantees that things will look "correct".
Cache the fallback font dictionary on the `PartialEvaluator` (PR 11218 follow-up) This way we'll benefit from the existing font caching, and can thus avoid re-creating a fallback font over and over again during parsing. (Thece changes necessitated the previous patch, since otherwise breakage could occur e.g. with fake workers.)
2020-01-16 23:08:25 +09:00
fontRef = PartialEvaluator.getFallbackFontDict();
Return ErrorFont in loadFont when the fontRef is undefined
2014-06-12 19:46:39 +09:00
}
Cache fonts by reference.
2013-06-26 02:33:53 +09:00
if (this.fontCache.has(fontRef)) {
return this.fontCache.get(fontRef);
}
font = xref.fetchIfRef(fontRef);
if (!isDict(font)) {
Incrementally render by sending the operator list by chunks as they're ready.
2013-08-01 03:17:36 +09:00
return errorFont();
Fix type3 font loading regression.
2013-05-04 03:13:45 +09:00
}
Treat fonts with the same font descriptor, encoding and unicode map as aliases Different fonts can point to the same font descriptor (see https://github.com/mozilla/pdf.js/issues/4339 for details). With this commit such fonts are treated as aliases if they have also the same encoding and the same toUnicode map. The according info is stored on the font descriptor. This change must also ensure that aliases use always the same font name because translated fonts can get cleared depending on the CLEANUP_TIMEOUT setting.
2014-03-04 02:44:45 +09:00
Slightly refactor the `fontRef` handling in `PartialEvaluator_loadFont` (issue 7403 and issue 7402) Originally, I was just going to change this code to use `Ref_toString` in a couple more places. When I started reading the code, I figured that it wouldn't hurt to clean up a couple of comments. While doing this, I noticed that the logic for the (rare) `isDict(fontRef)` case could do with a few improvements. There should be no functional changes with this patch, but given the added reference checks, we will now avoid bogus `Ref`s when resolving font aliases. In practice, as issue 7403 shows, the current code can break certain PDF files even if it's very rare. Note that the only thing that this patch will change, is the `font.loadedName` in the case where a `fontRef` is a reference *and* the font doesn't have a descriptor. Previously for `fontRef = Ref(4, 0)` we'd get `font.loadedName = 'g_d0_f4_0'`, and with this patch `font.loadedName = g_d0_f4R`, which is actually one character shorted in most cases. (Given that `Ref_toString` contains an optimization for the `gen === 0` case, which is by far the most common `gen` value.) In the already existing fallback case, where the `fontName` is used to when creating the `font.loadedName`, we allow any alphanumeric character. Hence I don't see how (as mentioned above) e.g. `font.loadedName = g_d0_f4R` would be an issue here.
2016-05-23 22:32:04 +09:00
// We are holding `font.translated` references just for `fontRef`s that
// are not actually `Ref`s, but rather `Dict`s. See explanation below.
Refactors loadFont for translateFont be async; fixes type3 dup data
2014-05-20 06:27:54 +09:00
if (font.translated) {
return font.translated;
}
Adds Promise to the getOperatorList
2014-05-10 10:21:15 +09:00
var fontCapability = createPromiseCapability();
Remove unnecessary `xref` parameters from various method signatures in `PartialEvaluator`, since `this.xref` is already available in the relevant scope For reasons I don't pretend to understand, we're passing around `xref` arguments to a bunch of methods despite `this.xref` being available in `PartialEvaluator`. This patch is a small first small step towards cleaning up the, often unwieldy, signatures of methods in `PartialEvaluator`.
2017-03-26 21:12:53 +09:00
var preEvaluatedFont = this.preEvaluateFont(font);
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
const { descriptor, hash } = preEvaluatedFont;
Slightly refactor the `fontRef` handling in `PartialEvaluator_loadFont` (issue 7403 and issue 7402) Originally, I was just going to change this code to use `Ref_toString` in a couple more places. When I started reading the code, I figured that it wouldn't hurt to clean up a couple of comments. While doing this, I noticed that the logic for the (rare) `isDict(fontRef)` case could do with a few improvements. There should be no functional changes with this patch, but given the added reference checks, we will now avoid bogus `Ref`s when resolving font aliases. In practice, as issue 7403 shows, the current code can break certain PDF files even if it's very rare. Note that the only thing that this patch will change, is the `font.loadedName` in the case where a `fontRef` is a reference *and* the font doesn't have a descriptor. Previously for `fontRef = Ref(4, 0)` we'd get `font.loadedName = 'g_d0_f4_0'`, and with this patch `font.loadedName = g_d0_f4R`, which is actually one character shorted in most cases. (Given that `Ref_toString` contains an optimization for the `gen === 0` case, which is by far the most common `gen` value.) In the already existing fallback case, where the `fontName` is used to when creating the `font.loadedName`, we allow any alphanumeric character. Hence I don't see how (as mentioned above) e.g. `font.loadedName = g_d0_f4R` would be an issue here.
2016-05-23 22:32:04 +09:00
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
var fontRefIsRef = isRef(fontRef),
fontID;
Slightly refactor the `fontRef` handling in `PartialEvaluator_loadFont` (issue 7403 and issue 7402) Originally, I was just going to change this code to use `Ref_toString` in a couple more places. When I started reading the code, I figured that it wouldn't hurt to clean up a couple of comments. While doing this, I noticed that the logic for the (rare) `isDict(fontRef)` case could do with a few improvements. There should be no functional changes with this patch, but given the added reference checks, we will now avoid bogus `Ref`s when resolving font aliases. In practice, as issue 7403 shows, the current code can break certain PDF files even if it's very rare. Note that the only thing that this patch will change, is the `font.loadedName` in the case where a `fontRef` is a reference *and* the font doesn't have a descriptor. Previously for `fontRef = Ref(4, 0)` we'd get `font.loadedName = 'g_d0_f4_0'`, and with this patch `font.loadedName = g_d0_f4R`, which is actually one character shorted in most cases. (Given that `Ref_toString` contains an optimization for the `gen === 0` case, which is by far the most common `gen` value.) In the already existing fallback case, where the `fontName` is used to when creating the `font.loadedName`, we allow any alphanumeric character. Hence I don't see how (as mentioned above) e.g. `font.loadedName = g_d0_f4R` would be an issue here.
2016-05-23 22:32:04 +09:00
if (fontRefIsRef) {
fontID = fontRef.toString();
}
Don't accidentally use an empty `hash` value when comparing `preEvaluatedFonts` in `PartialEvaluator.loadFont` Note that `PartialEvaluator.preEvaluateFont` will return an empty string when no hash was computed. This will complete short-circuit the `fontAlias` comparison in `PartialEvaluator.loadFont`, since fonts which are totally different will then match if their `hash`es are empty.
2019-03-27 08:00:13 +09:00
if (hash && isDict(descriptor)) {
Treat fonts with the same font descriptor, encoding and unicode map as aliases Different fonts can point to the same font descriptor (see https://github.com/mozilla/pdf.js/issues/4339 for details). With this commit such fonts are treated as aliases if they have also the same encoding and the same toUnicode map. The according info is stored on the font descriptor. This change must also ensure that aliases use always the same font name because translated fonts can get cleared depending on the CLEANUP_TIMEOUT setting.
2014-03-04 02:44:45 +09:00
if (!descriptor.fontAliases) {
descriptor.fontAliases = Object.create(null);
}
var fontAliases = descriptor.fontAliases;
Don't accidentally use an empty `hash` value when comparing `preEvaluatedFonts` in `PartialEvaluator.loadFont` Note that `PartialEvaluator.preEvaluateFont` will return an empty string when no hash was computed. This will complete short-circuit the `fontAlias` comparison in `PartialEvaluator.loadFont`, since fonts which are totally different will then match if their `hash`es are empty.
2019-03-27 08:00:13 +09:00
Treat fonts with the same font descriptor, encoding and unicode map as aliases Different fonts can point to the same font descriptor (see https://github.com/mozilla/pdf.js/issues/4339 for details). With this commit such fonts are treated as aliases if they have also the same encoding and the same toUnicode map. The according info is stored on the font descriptor. This change must also ensure that aliases use always the same font name because translated fonts can get cleared depending on the CLEANUP_TIMEOUT setting.
2014-03-04 02:44:45 +09:00
if (fontAliases[hash]) {
var aliasFontRef = fontAliases[hash].aliasRef;
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
if (
fontRefIsRef &&
aliasFontRef &&
this.fontCache.has(aliasFontRef)
) {
Treat fonts with the same font descriptor, encoding and unicode map as aliases Different fonts can point to the same font descriptor (see https://github.com/mozilla/pdf.js/issues/4339 for details). With this commit such fonts are treated as aliases if they have also the same encoding and the same toUnicode map. The according info is stored on the font descriptor. This change must also ensure that aliases use always the same font name because translated fonts can get cleared depending on the CLEANUP_TIMEOUT setting.
2014-03-04 02:44:45 +09:00
this.fontCache.putAlias(fontRef, aliasFontRef);
Refactors loadFont for translateFont be async; fixes type3 dup data
2014-05-20 06:27:54 +09:00
return this.fontCache.get(fontRef);
Treat fonts with the same font descriptor, encoding and unicode map as aliases Different fonts can point to the same font descriptor (see https://github.com/mozilla/pdf.js/issues/4339 for details). With this commit such fonts are treated as aliases if they have also the same encoding and the same toUnicode map. The according info is stored on the font descriptor. This change must also ensure that aliases use always the same font name because translated fonts can get cleared depending on the CLEANUP_TIMEOUT setting.
2014-03-04 02:44:45 +09:00
}
Slightly refactor the `fontRef` handling in `PartialEvaluator_loadFont` (issue 7403 and issue 7402) Originally, I was just going to change this code to use `Ref_toString` in a couple more places. When I started reading the code, I figured that it wouldn't hurt to clean up a couple of comments. While doing this, I noticed that the logic for the (rare) `isDict(fontRef)` case could do with a few improvements. There should be no functional changes with this patch, but given the added reference checks, we will now avoid bogus `Ref`s when resolving font aliases. In practice, as issue 7403 shows, the current code can break certain PDF files even if it's very rare. Note that the only thing that this patch will change, is the `font.loadedName` in the case where a `fontRef` is a reference *and* the font doesn't have a descriptor. Previously for `fontRef = Ref(4, 0)` we'd get `font.loadedName = 'g_d0_f4_0'`, and with this patch `font.loadedName = g_d0_f4R`, which is actually one character shorted in most cases. (Given that `Ref_toString` contains an optimization for the `gen === 0` case, which is by far the most common `gen` value.) In the already existing fallback case, where the `fontName` is used to when creating the `font.loadedName`, we allow any alphanumeric character. Hence I don't see how (as mentioned above) e.g. `font.loadedName = g_d0_f4R` would be an issue here.
2016-05-23 22:32:04 +09:00
} else {
Treat fonts with the same font descriptor, encoding and unicode map as aliases Different fonts can point to the same font descriptor (see https://github.com/mozilla/pdf.js/issues/4339 for details). With this commit such fonts are treated as aliases if they have also the same encoding and the same toUnicode map. The according info is stored on the font descriptor. This change must also ensure that aliases use always the same font name because translated fonts can get cleared depending on the CLEANUP_TIMEOUT setting.
2014-03-04 02:44:45 +09:00
fontAliases[hash] = {
Fix inconsistent spacing and trailing commas in objects in `src/core/` files, so we can enable the `comma-dangle` and `object-curly-spacing` ESLint rules later on *Unfortunately this patch is fairly big, even though it only covers the `src/core` folder, but splitting it even further seemed difficult.* http://eslint.org/docs/rules/comma-dangle http://eslint.org/docs/rules/object-curly-spacing Given that we currently have quite inconsistent object formatting, fixing this in *one* big patch probably wouldn't be feasible (since I cannot imagine anyone wanting to review that); hence I've opted to try and do this piecewise instead. Please note: This patch was created automatically, using the ESLint --fix command line option. In a couple of places this caused lines to become too long, and I've fixed those manually; please refer to the interdiff below for the only hand-edits in this patch. ```diff diff --git a/src/core/evaluator.js b/src/core/evaluator.js index abab9027..dcd3594b 100644 --- a/src/core/evaluator.js +++ b/src/core/evaluator.js @@ -2785,7 +2785,8 @@ var EvaluatorPreprocessor = (function EvaluatorPreprocessorClosure() { t['Tz'] = { id: OPS.setHScale, numArgs: 1, variableArgs: false, }; t['TL'] = { id: OPS.setLeading, numArgs: 1, variableArgs: false, }; t['Tf'] = { id: OPS.setFont, numArgs: 2, variableArgs: false, }; - t['Tr'] = { id: OPS.setTextRenderingMode, numArgs: 1, variableArgs: false, }; + t['Tr'] = { id: OPS.setTextRenderingMode, numArgs: 1, + variableArgs: false, }; t['Ts'] = { id: OPS.setTextRise, numArgs: 1, variableArgs: false, }; t['Td'] = { id: OPS.moveText, numArgs: 2, variableArgs: false, }; t['TD'] = { id: OPS.setLeadingMoveText, numArgs: 2, variableArgs: false, }; diff --git a/src/core/jbig2.js b/src/core/jbig2.js index 5a17d482..71671541 100644 --- a/src/core/jbig2.js +++ b/src/core/jbig2.js @@ -123,19 +123,22 @@ var Jbig2Image = (function Jbig2ImageClosure() { { x: -1, y: -1, }, { x: 0, y: -1, }, { x: 1, y: -1, }, { x: -2, y: 0, }, { x: -1, y: 0, }], [{ x: -3, y: -1, }, { x: -2, y: -1, }, { x: -1, y: -1, }, { x: 0, y: -1, }, - { x: 1, y: -1, }, { x: -4, y: 0, }, { x: -3, y: 0, }, { x: -2, y: 0, }, { x: -1, y: 0, }] + { x: 1, y: -1, }, { x: -4, y: 0, }, { x: -3, y: 0, }, { x: -2, y: 0, }, + { x: -1, y: 0, }] ]; var RefinementTemplates = [ { coding: [{ x: 0, y: -1, }, { x: 1, y: -1, }, { x: -1, y: 0, }], - reference: [{ x: 0, y: -1, }, { x: 1, y: -1, }, { x: -1, y: 0, }, { x: 0, y: 0, }, - { x: 1, y: 0, }, { x: -1, y: 1, }, { x: 0, y: 1, }, { x: 1, y: 1, }], + reference: [{ x: 0, y: -1, }, { x: 1, y: -1, }, { x: -1, y: 0, }, + { x: 0, y: 0, }, { x: 1, y: 0, }, { x: -1, y: 1, }, + { x: 0, y: 1, }, { x: 1, y: 1, }], }, { - coding: [{ x: -1, y: -1, }, { x: 0, y: -1, }, { x: 1, y: -1, }, { x: -1, y: 0, }], - reference: [{ x: 0, y: -1, }, { x: -1, y: 0, }, { x: 0, y: 0, }, { x: 1, y: 0, }, - { x: 0, y: 1, }, { x: 1, y: 1, }], + coding: [{ x: -1, y: -1, }, { x: 0, y: -1, }, { x: 1, y: -1, }, + { x: -1, y: 0, }], + reference: [{ x: 0, y: -1, }, { x: -1, y: 0, }, { x: 0, y: 0, }, + { x: 1, y: 0, }, { x: 0, y: 1, }, { x: 1, y: 1, }], } ]; ```
2017-06-02 18:16:24 +09:00
fontID: Font.getFontID(),
Treat fonts with the same font descriptor, encoding and unicode map as aliases Different fonts can point to the same font descriptor (see https://github.com/mozilla/pdf.js/issues/4339 for details). With this commit such fonts are treated as aliases if they have also the same encoding and the same toUnicode map. The according info is stored on the font descriptor. This change must also ensure that aliases use always the same font name because translated fonts can get cleared depending on the CLEANUP_TIMEOUT setting.
2014-03-04 02:44:45 +09:00
};
}
Slightly refactor the `fontRef` handling in `PartialEvaluator_loadFont` (issue 7403 and issue 7402) Originally, I was just going to change this code to use `Ref_toString` in a couple more places. When I started reading the code, I figured that it wouldn't hurt to clean up a couple of comments. While doing this, I noticed that the logic for the (rare) `isDict(fontRef)` case could do with a few improvements. There should be no functional changes with this patch, but given the added reference checks, we will now avoid bogus `Ref`s when resolving font aliases. In practice, as issue 7403 shows, the current code can break certain PDF files even if it's very rare. Note that the only thing that this patch will change, is the `font.loadedName` in the case where a `fontRef` is a reference *and* the font doesn't have a descriptor. Previously for `fontRef = Ref(4, 0)` we'd get `font.loadedName = 'g_d0_f4_0'`, and with this patch `font.loadedName = g_d0_f4R`, which is actually one character shorted in most cases. (Given that `Ref_toString` contains an optimization for the `gen === 0` case, which is by far the most common `gen` value.) In the already existing fallback case, where the `fontName` is used to when creating the `font.loadedName`, we allow any alphanumeric character. Hence I don't see how (as mentioned above) e.g. `font.loadedName = g_d0_f4R` would be an issue here.
2016-05-23 22:32:04 +09:00
if (fontRefIsRef) {
fontAliases[hash].aliasRef = fontRef;
}
Treat fonts with the same font descriptor, encoding and unicode map as aliases Different fonts can point to the same font descriptor (see https://github.com/mozilla/pdf.js/issues/4339 for details). With this commit such fonts are treated as aliases if they have also the same encoding and the same toUnicode map. The according info is stored on the font descriptor. This change must also ensure that aliases use always the same font name because translated fonts can get cleared depending on the CLEANUP_TIMEOUT setting.
2014-03-04 02:44:45 +09:00
fontID = fontAliases[hash].fontID;
}
Slightly refactor the `fontRef` handling in `PartialEvaluator_loadFont` (issue 7403 and issue 7402) Originally, I was just going to change this code to use `Ref_toString` in a couple more places. When I started reading the code, I figured that it wouldn't hurt to clean up a couple of comments. While doing this, I noticed that the logic for the (rare) `isDict(fontRef)` case could do with a few improvements. There should be no functional changes with this patch, but given the added reference checks, we will now avoid bogus `Ref`s when resolving font aliases. In practice, as issue 7403 shows, the current code can break certain PDF files even if it's very rare. Note that the only thing that this patch will change, is the `font.loadedName` in the case where a `fontRef` is a reference *and* the font doesn't have a descriptor. Previously for `fontRef = Ref(4, 0)` we'd get `font.loadedName = 'g_d0_f4_0'`, and with this patch `font.loadedName = g_d0_f4R`, which is actually one character shorted in most cases. (Given that `Ref_toString` contains an optimization for the `gen === 0` case, which is by far the most common `gen` value.) In the already existing fallback case, where the `fontName` is used to when creating the `font.loadedName`, we allow any alphanumeric character. Hence I don't see how (as mentioned above) e.g. `font.loadedName = g_d0_f4R` would be an issue here.
2016-05-23 22:32:04 +09:00
// Workaround for bad PDF generators that reference fonts incorrectly,
// where `fontRef` is a `Dict` rather than a `Ref` (fixes bug946506.pdf).
Attempt to cache fonts that are direct objects (i.e. `Dict`s), as opposed to `Ref`s, to prevent re-rendering after `cleanup` from breaking (issue 7403 and issue 7402) Fonts that are not referenced by `Ref`s are very uncommon in practice, but it can unfortunately happen. In this case, we're currently not caching them in the usual way, i.e. by `Ref`, which leads to failures when a page is rendered after `cleanup` has run. The simplest solution would have been to remove the `font.translated` workaround, but since this would have meant loading these kind of fonts over and over, the patch attempts to be a bit clever about this situation. Note that if we instead loaded fonts per *page*, instead of per document, this issue wouldn't have existed.
2016-06-11 21:28:59 +09:00
// In this case we should not put the font into `this.fontCache` (which is
// a `RefSetCache`), since it's not meaningful to use a `Dict` as a key.
//
// However, if we don't cache the font it's not possible to remove it
// when `cleanup` is triggered from the API, which causes issues on
// subsequent rendering operations (see issue7403.pdf).
// A simple workaround would be to just not hold `font.translated`
// references in this case, but this would force us to unnecessarily load
// the same fonts over and over.
//
// Instead, we cheat a bit by attempting to use a modified `fontID` as a
// key in `this.fontCache`, to allow the font to be cached.
// NOTE: This works because `RefSetCache` calls `toString()` on provided
// keys. Also, since `fontRef` is used when getting cached fonts,
// we'll not accidentally match fonts cached with the `fontID`.
Slightly refactor the `fontRef` handling in `PartialEvaluator_loadFont` (issue 7403 and issue 7402) Originally, I was just going to change this code to use `Ref_toString` in a couple more places. When I started reading the code, I figured that it wouldn't hurt to clean up a couple of comments. While doing this, I noticed that the logic for the (rare) `isDict(fontRef)` case could do with a few improvements. There should be no functional changes with this patch, but given the added reference checks, we will now avoid bogus `Ref`s when resolving font aliases. In practice, as issue 7403 shows, the current code can break certain PDF files even if it's very rare. Note that the only thing that this patch will change, is the `font.loadedName` in the case where a `fontRef` is a reference *and* the font doesn't have a descriptor. Previously for `fontRef = Ref(4, 0)` we'd get `font.loadedName = 'g_d0_f4_0'`, and with this patch `font.loadedName = g_d0_f4R`, which is actually one character shorted in most cases. (Given that `Ref_toString` contains an optimization for the `gen === 0` case, which is by far the most common `gen` value.) In the already existing fallback case, where the `fontName` is used to when creating the `font.loadedName`, we allow any alphanumeric character. Hence I don't see how (as mentioned above) e.g. `font.loadedName = g_d0_f4R` would be an issue here.
2016-05-23 22:32:04 +09:00
if (fontRefIsRef) {
Adds Promise to the getOperatorList
2014-05-10 10:21:15 +09:00
this.fontCache.put(fontRef, fontCapability.promise);
Slightly refactor the `fontRef` handling in `PartialEvaluator_loadFont` (issue 7403 and issue 7402) Originally, I was just going to change this code to use `Ref_toString` in a couple more places. When I started reading the code, I figured that it wouldn't hurt to clean up a couple of comments. While doing this, I noticed that the logic for the (rare) `isDict(fontRef)` case could do with a few improvements. There should be no functional changes with this patch, but given the added reference checks, we will now avoid bogus `Ref`s when resolving font aliases. In practice, as issue 7403 shows, the current code can break certain PDF files even if it's very rare. Note that the only thing that this patch will change, is the `font.loadedName` in the case where a `fontRef` is a reference *and* the font doesn't have a descriptor. Previously for `fontRef = Ref(4, 0)` we'd get `font.loadedName = 'g_d0_f4_0'`, and with this patch `font.loadedName = g_d0_f4R`, which is actually one character shorted in most cases. (Given that `Ref_toString` contains an optimization for the `gen === 0` case, which is by far the most common `gen` value.) In the already existing fallback case, where the `fontName` is used to when creating the `font.loadedName`, we allow any alphanumeric character. Hence I don't see how (as mentioned above) e.g. `font.loadedName = g_d0_f4R` would be an issue here.
2016-05-23 22:32:04 +09:00
} else {
if (!fontID) {
Replace direct lookup of `uniquePrefix`/`idCounters`, in `Page` instances, with an `idFactory` containing an `createObjId` method instead We're currently making use of `uniquePrefix`/`idCounters` in multiple files, to create unique object id's, and adding a new occurrence of them requires some care to ensure that an object id isn't accidentally reused. Furthermore, having to pass around multiple parameters as we currently do seem like something you want to avoid. Instead, this patch adds a factory which means that there's only *one* thing that needs to be passed around. And since it's now only necessary to call a method in order to obtain a unique object id, the details are thus abstracted away at the call-sites which avoids accidental reuse of object id's. To test that this works as expected a very simple `Page` unit-test is added, and the existing `Annotation layer` tests are also adjusted slightly.
2017-01-09 00:51:30 +09:00
fontID = this.idFactory.createObjId();
Slightly refactor the `fontRef` handling in `PartialEvaluator_loadFont` (issue 7403 and issue 7402) Originally, I was just going to change this code to use `Ref_toString` in a couple more places. When I started reading the code, I figured that it wouldn't hurt to clean up a couple of comments. While doing this, I noticed that the logic for the (rare) `isDict(fontRef)` case could do with a few improvements. There should be no functional changes with this patch, but given the added reference checks, we will now avoid bogus `Ref`s when resolving font aliases. In practice, as issue 7403 shows, the current code can break certain PDF files even if it's very rare. Note that the only thing that this patch will change, is the `font.loadedName` in the case where a `fontRef` is a reference *and* the font doesn't have a descriptor. Previously for `fontRef = Ref(4, 0)` we'd get `font.loadedName = 'g_d0_f4_0'`, and with this patch `font.loadedName = g_d0_f4R`, which is actually one character shorted in most cases. (Given that `Ref_toString` contains an optimization for the `gen === 0` case, which is by far the most common `gen` value.) In the already existing fallback case, where the `fontName` is used to when creating the `font.loadedName`, we allow any alphanumeric character. Hence I don't see how (as mentioned above) e.g. `font.loadedName = g_d0_f4R` would be an issue here.
2016-05-23 22:32:04 +09:00
}
Add a `getDocId` method to the `idFactory`, in `Page` instances, to avoid passing around `PDFManager` instances unnecessarily (PR 7941 follow-up) This way we can avoid manually building a "document id" in multiple places in `evaluator.js`, and it also let's us avoid passing in an otherwise unnecessary `PDFManager` instance when creating a `PartialEvaluator`.
2019-04-20 19:36:49 +09:00
this.fontCache.put(`id_${fontID}`, fontCapability.promise);
Fix loading of fonts that are not referenced by an object identifier
2013-12-17 08:19:31 +09:00
}
Attempt to cache fonts that are direct objects (i.e. `Dict`s), as opposed to `Ref`s, to prevent re-rendering after `cleanup` from breaking (issue 7403 and issue 7402) Fonts that are not referenced by `Ref`s are very uncommon in practice, but it can unfortunately happen. In this case, we're currently not caching them in the usual way, i.e. by `Ref`, which leads to failures when a page is rendered after `cleanup` has run. The simplest solution would have been to remove the `font.translated` workaround, but since this would have meant loading these kind of fonts over and over, the patch attempts to be a bit clever about this situation. Note that if we instead loaded fonts per *page*, instead of per document, this issue wouldn't have existed.
2016-06-11 21:28:59 +09:00
assert(fontID, 'The "fontID" must be defined.');
Fix type3 font loading regression.
2013-05-04 03:13:45 +09:00
Making src/core/evaluator.js adhere to the style guide
2014-03-23 03:15:51 +09:00
// Keep track of each font we translated so the caller can
// load them asynchronously before calling display on a page.
Add a `getDocId` method to the `idFactory`, in `Page` instances, to avoid passing around `PDFManager` instances unnecessarily (PR 7941 follow-up) This way we can avoid manually building a "document id" in multiple places in `evaluator.js`, and it also let's us avoid passing in an otherwise unnecessary `PDFManager` instance when creating a `PartialEvaluator`.
2019-04-20 19:36:49 +09:00
font.loadedName = `${this.idFactory.getDocId()}_f${fontID}`;
Cleanup the way getIRQueue is called (no need to pass in a queue object in most cases anymore)
2012-02-21 22:28:42 +09:00
Refactors loadFont for translateFont be async; fixes type3 dup data
2014-05-20 06:27:54 +09:00
font.translated = fontCapability.promise;
Make getOperatorList() calls independent and merge queues at end
2013-04-09 07:14:56 +09:00
Refactors loadFont for translateFont be async; fixes type3 dup data
2014-05-20 06:27:54 +09:00
// TODO move promises into translate font
var translatedPromise;
try {
Remove unnecessary `xref` parameters from various method signatures in `PartialEvaluator`, since `this.xref` is already available in the relevant scope For reasons I don't pretend to understand, we're passing around `xref` arguments to a bunch of methods despite `this.xref` being available in `PartialEvaluator`. This patch is a small first small step towards cleaning up the, often unwieldy, signatures of methods in `PartialEvaluator`.
2017-03-26 21:12:53 +09:00
translatedPromise = this.translateFont(preEvaluatedFont);
Refactors loadFont for translateFont be async; fixes type3 dup data
2014-05-20 06:27:54 +09:00
} catch (e) {
translatedPromise = Promise.reject(e);
Splitting files
2011-10-25 08:55:23 +09:00
}
Refactors loadFont for translateFont be async; fixes type3 dup data
2014-05-20 06:27:54 +09:00
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
translatedPromise
[api-minor] Change `Font.exportData` to, by default, stop exporting properties which are completely unused on the main-thread and/or in the API (PR 11773 follow-up) For years now, the `Font.exportData` method has (because of its previous implementation) been exporting many properties despite them being completely unused on the main-thread and/or in the API. This is unfortunate, since among those properties there's a number of potentially very large data-structures, containing e.g. Arrays and Objects, which thus have to be first structured cloned and then stored on the main-thread. With the changes in this patch, we'll thus by default save memory for *every* `Font` instance created (there can be a lot in longer documents). The memory savings obviously depends a lot on the actual font data, but some approximate figures are: For non-embedded fonts it can save a couple of kilobytes, for simple embedded fonts a handful of kilobytes, and for composite fonts the size of this auxiliary can even be larger than the actual font program itself. All-in-all, there's no good reason to keep exporting these properties by default when they're unused. However, since we cannot be sure that every property is unused in custom implementations of the PDF.js library, this patch adds a new `getDocument` option (named `fontExtraProperties`) that still allows access to the following properties: - "cMap": An internal data structure, only used with composite fonts and never really intended to be exposed on the main-thread and/or in the API. Note also that the `CMap`/`IdentityCMap` classes are a lot more complex than simple Objects, but only their "internal" properties survive the structured cloning used to send data to the main-thread. Given that CMaps can often be *very* large, not exporting them can also save a fair bit of memory. - "defaultEncoding": An internal property used with simple fonts, and used when building the glyph mapping on the worker-thread. Considering how complex that topic is, and given that not all font types are handled identically, exposing this on the main-thread and/or in the API most likely isn't useful. - "differences": An internal property used with simple fonts, and used when building the glyph mapping on the worker-thread. Considering how complex that topic is, and given that not all font types are handled identically, exposing this on the main-thread and/or in the API most likely isn't useful. - "isSymbolicFont": An internal property, used during font parsing and building of the glyph mapping on the worker-thread. - "seacMap": An internal map, only potentially used with *some* Type1/CFF fonts and never intended to be exposed in the API. The existing `Font.{charToGlyph, charToGlyphs}` functionality already takes this data into account when handling text. - "toFontChar": The glyph map, necessary for mapping characters to glyphs in the font, which is built upon the various encoding information contained in the font dictionary and/or font program. This is not directly used on the main-thread and/or in the API. - "toUnicode": The unicode map, necessary for text-extraction to work correctly, which is built upon the ToUnicode/CMap information contained in the font dictionary, but not directly used on the main-thread and/or in the API. - "vmetrics": An array of width data used with fonts which are composite *and* vertical, but not directly used on the main-thread and/or in the API. - "widths": An array of width data used with most fonts, but not directly used on the main-thread and/or in the API.
2020-04-03 18:51:46 +09:00
.then(translatedFont => {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
if (translatedFont.fontType !== undefined) {
var xrefFontStats = xref.stats.fontTypes;
xrefFontStats[translatedFont.fontType] = true;
}
fontCapability.resolve(
Change the signature of `TranslatedFont`, and convert it to a proper class In preparation for the next patch, this changes the signature of `TranslatedFont` to take an object rather than individual parameters. This also, in my opinion, makes the call-sites easier to read since it essentially provides a small bit of documentation of the arguments. Finally, since it was necessary to touch `TranslatedFont` anyway it seemed like a good idea to also convert it to a proper `class`.
2020-04-03 17:19:02 +09:00
new TranslatedFont({
loadedName: font.loadedName,
font: translatedFont,
dict: font,
[api-minor] Change `Font.exportData` to, by default, stop exporting properties which are completely unused on the main-thread and/or in the API (PR 11773 follow-up) For years now, the `Font.exportData` method has (because of its previous implementation) been exporting many properties despite them being completely unused on the main-thread and/or in the API. This is unfortunate, since among those properties there's a number of potentially very large data-structures, containing e.g. Arrays and Objects, which thus have to be first structured cloned and then stored on the main-thread. With the changes in this patch, we'll thus by default save memory for *every* `Font` instance created (there can be a lot in longer documents). The memory savings obviously depends a lot on the actual font data, but some approximate figures are: For non-embedded fonts it can save a couple of kilobytes, for simple embedded fonts a handful of kilobytes, and for composite fonts the size of this auxiliary can even be larger than the actual font program itself. All-in-all, there's no good reason to keep exporting these properties by default when they're unused. However, since we cannot be sure that every property is unused in custom implementations of the PDF.js library, this patch adds a new `getDocument` option (named `fontExtraProperties`) that still allows access to the following properties: - "cMap": An internal data structure, only used with composite fonts and never really intended to be exposed on the main-thread and/or in the API. Note also that the `CMap`/`IdentityCMap` classes are a lot more complex than simple Objects, but only their "internal" properties survive the structured cloning used to send data to the main-thread. Given that CMaps can often be *very* large, not exporting them can also save a fair bit of memory. - "defaultEncoding": An internal property used with simple fonts, and used when building the glyph mapping on the worker-thread. Considering how complex that topic is, and given that not all font types are handled identically, exposing this on the main-thread and/or in the API most likely isn't useful. - "differences": An internal property used with simple fonts, and used when building the glyph mapping on the worker-thread. Considering how complex that topic is, and given that not all font types are handled identically, exposing this on the main-thread and/or in the API most likely isn't useful. - "isSymbolicFont": An internal property, used during font parsing and building of the glyph mapping on the worker-thread. - "seacMap": An internal map, only potentially used with *some* Type1/CFF fonts and never intended to be exposed in the API. The existing `Font.{charToGlyph, charToGlyphs}` functionality already takes this data into account when handling text. - "toFontChar": The glyph map, necessary for mapping characters to glyphs in the font, which is built upon the various encoding information contained in the font dictionary and/or font program. This is not directly used on the main-thread and/or in the API. - "toUnicode": The unicode map, necessary for text-extraction to work correctly, which is built upon the ToUnicode/CMap information contained in the font dictionary, but not directly used on the main-thread and/or in the API. - "vmetrics": An array of width data used with fonts which are composite *and* vertical, but not directly used on the main-thread and/or in the API. - "widths": An array of width data used with most fonts, but not directly used on the main-thread and/or in the API.
2020-04-03 18:51:46 +09:00
extraProperties: this.options.fontExtraProperties,
Change the signature of `TranslatedFont`, and convert it to a proper class In preparation for the next patch, this changes the signature of `TranslatedFont` to take an object rather than individual parameters. This also, in my opinion, makes the call-sites easier to read since it essentially provides a small bit of documentation of the arguments. Finally, since it was necessary to touch `TranslatedFont` anyway it seemed like a good idea to also convert it to a proper `class`.
2020-04-03 17:19:02 +09:00
})
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
);
})
.catch(reason => {
// TODO fontCapability.reject?
// Error in the font data -- sending unsupported feature notification.
this.handler.send("UnsupportedFeature", {
Add more categories of unsupported features. Fixes #11815
2020-05-01 07:27:37 +09:00
featureId: UNSUPPORTED_FEATURES.errorFontTranslate,
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
});
try {
// error, but it's still nice to have font type reported
var fontFile3 = descriptor && descriptor.get("FontFile3");
var subtype = fontFile3 && fontFile3.get("Subtype");
var fontType = getFontType(
preEvaluatedFont.type,
subtype && subtype.name
);
var xrefFontStats = xref.stats.fontTypes;
xrefFontStats[fontType] = true;
} catch (ex) {}
fontCapability.resolve(
Change the signature of `TranslatedFont`, and convert it to a proper class In preparation for the next patch, this changes the signature of `TranslatedFont` to take an object rather than individual parameters. This also, in my opinion, makes the call-sites easier to read since it essentially provides a small bit of documentation of the arguments. Finally, since it was necessary to touch `TranslatedFont` anyway it seemed like a good idea to also convert it to a proper `class`.
2020-04-03 17:19:02 +09:00
new TranslatedFont({
loadedName: font.loadedName,
font: new ErrorFont(
reason instanceof Error ? reason.message : reason
),
dict: font,
[api-minor] Change `Font.exportData` to, by default, stop exporting properties which are completely unused on the main-thread and/or in the API (PR 11773 follow-up) For years now, the `Font.exportData` method has (because of its previous implementation) been exporting many properties despite them being completely unused on the main-thread and/or in the API. This is unfortunate, since among those properties there's a number of potentially very large data-structures, containing e.g. Arrays and Objects, which thus have to be first structured cloned and then stored on the main-thread. With the changes in this patch, we'll thus by default save memory for *every* `Font` instance created (there can be a lot in longer documents). The memory savings obviously depends a lot on the actual font data, but some approximate figures are: For non-embedded fonts it can save a couple of kilobytes, for simple embedded fonts a handful of kilobytes, and for composite fonts the size of this auxiliary can even be larger than the actual font program itself. All-in-all, there's no good reason to keep exporting these properties by default when they're unused. However, since we cannot be sure that every property is unused in custom implementations of the PDF.js library, this patch adds a new `getDocument` option (named `fontExtraProperties`) that still allows access to the following properties: - "cMap": An internal data structure, only used with composite fonts and never really intended to be exposed on the main-thread and/or in the API. Note also that the `CMap`/`IdentityCMap` classes are a lot more complex than simple Objects, but only their "internal" properties survive the structured cloning used to send data to the main-thread. Given that CMaps can often be *very* large, not exporting them can also save a fair bit of memory. - "defaultEncoding": An internal property used with simple fonts, and used when building the glyph mapping on the worker-thread. Considering how complex that topic is, and given that not all font types are handled identically, exposing this on the main-thread and/or in the API most likely isn't useful. - "differences": An internal property used with simple fonts, and used when building the glyph mapping on the worker-thread. Considering how complex that topic is, and given that not all font types are handled identically, exposing this on the main-thread and/or in the API most likely isn't useful. - "isSymbolicFont": An internal property, used during font parsing and building of the glyph mapping on the worker-thread. - "seacMap": An internal map, only potentially used with *some* Type1/CFF fonts and never intended to be exposed in the API. The existing `Font.{charToGlyph, charToGlyphs}` functionality already takes this data into account when handling text. - "toFontChar": The glyph map, necessary for mapping characters to glyphs in the font, which is built upon the various encoding information contained in the font dictionary and/or font program. This is not directly used on the main-thread and/or in the API. - "toUnicode": The unicode map, necessary for text-extraction to work correctly, which is built upon the ToUnicode/CMap information contained in the font dictionary, but not directly used on the main-thread and/or in the API. - "vmetrics": An array of width data used with fonts which are composite *and* vertical, but not directly used on the main-thread and/or in the API. - "widths": An array of width data used with most fonts, but not directly used on the main-thread and/or in the API.
2020-04-03 18:51:46 +09:00
extraProperties: this.options.fontExtraProperties,
Change the signature of `TranslatedFont`, and convert it to a proper class In preparation for the next patch, this changes the signature of `TranslatedFont` to take an object rather than individual parameters. This also, in my opinion, makes the call-sites easier to read since it essentially provides a small bit of documentation of the arguments. Finally, since it was necessary to touch `TranslatedFont` anyway it seemed like a good idea to also convert it to a proper `class`.
2020-04-03 17:19:02 +09:00
})
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
);
});
Refactors loadFont for translateFont be async; fixes type3 dup data
2014-05-20 06:27:54 +09:00
return fontCapability.promise;
Make getOperatorList() calls independent and merge queues at end
2013-04-09 07:14:56 +09:00
},
Attempt to handle corrupt PDF documents that contains path operators inside of text object (issue 10542) First of all, while this simple approach appears to work OK in practice I'm not sure if it's the best way of addressing the problem (assuming that you even want to). Second of all, while the solution implemented here only requires tracking/checking one new boolean in order for this to work, I'm nonetheless not entirely happy about this since it will add additional overhead (albeit *very* small) to the parsing of path operators in PDF documents just for a handful of *corrupt* ones.
2019-04-22 00:03:38 +09:00
buildPath(operatorList, fn, args, parsingText = false) {
Groups path commands into single command
2014-04-30 23:09:04 +09:00
var lastIndex = operatorList.length - 1;
Fixes a regression from PR 4982 After PR 4982, the rendering of the first two pages of http://www.openmagazin.cz/pdf/2011/openMagazin-2011-04.pdf (from issue 215) no longer completes. The issue is that we cannot have `args === null` in `PartialEvaluator_buildPath`, but *must* use an empty array instead. In this patch I've also moved the `argsLength` variable definition in `EvaluatorPreprocessor_read`, to make sure that it's always defined.
2014-08-08 19:50:54 +09:00
if (!args) {
args = [];
}
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
if (
lastIndex < 0 ||
operatorList.fnArray[lastIndex] !== OPS.constructPath
) {
Attempt to handle corrupt PDF documents that contains path operators inside of text object (issue 10542) First of all, while this simple approach appears to work OK in practice I'm not sure if it's the best way of addressing the problem (assuming that you even want to). Second of all, while the solution implemented here only requires tracking/checking one new boolean in order for this to work, I'm nonetheless not entirely happy about this since it will add additional overhead (albeit *very* small) to the parsing of path operators in PDF documents just for a handful of *corrupt* ones.
2019-04-22 00:03:38 +09:00
// Handle corrupt PDF documents that contains path operators inside of
// text objects, which may shift subsequent text, by enclosing the path
// operator in save/restore operators (fixes issue10542_reduced.pdf).
//
// Note that this will effectively disable the optimization in the
// `else` branch below, but given that this type of corruption is
// *extremely* rare that shouldn't really matter much in practice.
if (parsingText) {
warn(`Encountered path operator "${fn}" inside of a text object.`);
operatorList.addOp(OPS.save, null);
}
Groups path commands into single command
2014-04-30 23:09:04 +09:00
operatorList.addOp(OPS.constructPath, [[fn], args]);
Attempt to handle corrupt PDF documents that contains path operators inside of text object (issue 10542) First of all, while this simple approach appears to work OK in practice I'm not sure if it's the best way of addressing the problem (assuming that you even want to). Second of all, while the solution implemented here only requires tracking/checking one new boolean in order for this to work, I'm nonetheless not entirely happy about this since it will add additional overhead (albeit *very* small) to the parsing of path operators in PDF documents just for a handful of *corrupt* ones.
2019-04-22 00:03:38 +09:00
if (parsingText) {
operatorList.addOp(OPS.restore, null);
}
Groups path commands into single command
2014-04-30 23:09:04 +09:00
} else {
var opArgs = operatorList.argsArray[lastIndex];
opArgs[0].push(fn);
Array.prototype.push.apply(opArgs[1], args);
}
},
Add local caching of `ColorSpace`s, by name, in `PartialEvaluator.getOperatorList` (issue 2504) By caching parsed `ColorSpace`s, we thus don't need to re-parse the same data over and over which saves CPU cycles *and* reduces peak memory usage. (Obviously persistent memory usage *may* increase a tiny bit, but since the caching is done per `PartialEvaluator.getOperatorList` invocation and given that `ColorSpace` instances generally hold very little data this shouldn't be much of an issue.) Furthermore, by caching `ColorSpace`s we can also lookup the already parsed ones *synchronously* during the `OperatorList` building, instead of having to defer to the event loop/microtask queue since the parsing is done asynchronously (such that error handling is easier). Possible future improvements: - Cache/lookup parsed `ColorSpaces` used in `Pattern`s and `Image`s. - Attempt to cache *local* `ColorSpace`s by reference as well, in addition to only by name, assuming that there's documents where that would be beneficial and that it's not too difficult to implement. - Assuming there's documents that would benefit from it, also cache repeated `ColorSpace`s *globally* as well. Given that we've never, until now, been doing *any* caching of parsed `ColorSpace`s and that even using a simple name-only *local* cache helps tremendously in pathological cases, I purposely decided against complicating the implementation too much initially. Also, compared to parsing of `Image`s, simply creating a `ColorSpace` instance isn't that expensive (hence I'd be somewhat surprised if adding a *global* cache would help much). --- This patch was tested using: - The default `tracemonkey` PDF file, which was included mostly to show that "normal" documents aren't negatively affected by these changes. - The PDF file from issue 2504, i.e. https://dl-ctlg.panasonic.com/jp/manual/sd/sd_rbm1000_0.pdf, where most pages will switch *thousands* of times between a handful of `ColorSpace`s. with the following manifest file: ``` [ { "id": "tracemonkey", "file": "pdfs/tracemonkey.pdf", "md5": "9a192d8b1a7dc652a19835f6f08098bd", "rounds": 100, "type": "eq" }, { "id": "issue2504", "file": "../web/pdfs/issue2504.pdf", "md5": "", "rounds": 20, "type": "eq" } ] ``` which gave the following results when comparing this patch against the `master` branch: - Overall ``` -- Grouped By browser, pdf, stat -- browser | pdf | stat | Count | Baseline(ms) | Current(ms) | +/- | % | Result(P<.05) ------- | ----------- | ------------ | ----- | ------------ | ----------- | ---- | ------ | ------------- firefox | issue2504 | Overall | 640 | 977 | 497 | -479 | -49.08 | faster firefox | issue2504 | Page Request | 640 | 3 | 4 | 1 | 59.18 | firefox | issue2504 | Rendering | 640 | 974 | 493 | -481 | -49.37 | faster firefox | tracemonkey | Overall | 1400 | 116 | 111 | -5 | -4.43 | firefox | tracemonkey | Page Request | 1400 | 2 | 2 | 0 | -2.86 | firefox | tracemonkey | Rendering | 1400 | 114 | 109 | -5 | -4.47 | ``` - Page-specific ``` -- Grouped By browser, pdf, page, stat -- browser | pdf | page | stat | Count | Baseline(ms) | Current(ms) | +/- | % | Result(P<.05) ------- | ----------- | ---- | ------------ | ----- | ------------ | ----------- | ----- | ------- | ------------- firefox | issue2504 | 0 | Overall | 20 | 2295 | 1268 | -1027 | -44.76 | faster firefox | issue2504 | 0 | Page Request | 20 | 6 | 7 | 1 | 15.32 | firefox | issue2504 | 0 | Rendering | 20 | 2288 | 1260 | -1028 | -44.93 | faster firefox | issue2504 | 1 | Overall | 20 | 3059 | 2806 | -252 | -8.25 | faster firefox | issue2504 | 1 | Page Request | 20 | 11 | 14 | 3 | 23.25 | slower firefox | issue2504 | 1 | Rendering | 20 | 3047 | 2792 | -255 | -8.37 | faster firefox | issue2504 | 2 | Overall | 20 | 411 | 295 | -116 | -28.20 | faster firefox | issue2504 | 2 | Page Request | 20 | 2 | 42 | 40 | 1897.62 | firefox | issue2504 | 2 | Rendering | 20 | 409 | 253 | -156 | -38.09 | faster firefox | issue2504 | 3 | Overall | 20 | 736 | 299 | -437 | -59.34 | faster firefox | issue2504 | 3 | Page Request | 20 | 2 | 2 | 0 | 0.00 | firefox | issue2504 | 3 | Rendering | 20 | 734 | 297 | -437 | -59.49 | faster firefox | issue2504 | 4 | Overall | 20 | 356 | 458 | 102 | 28.63 | firefox | issue2504 | 4 | Page Request | 20 | 1 | 2 | 1 | 57.14 | slower firefox | issue2504 | 4 | Rendering | 20 | 354 | 455 | 101 | 28.53 | firefox | issue2504 | 5 | Overall | 20 | 1381 | 765 | -616 | -44.59 | faster firefox | issue2504 | 5 | Page Request | 20 | 3 | 5 | 2 | 50.00 | slower firefox | issue2504 | 5 | Rendering | 20 | 1378 | 760 | -617 | -44.81 | faster firefox | issue2504 | 6 | Overall | 20 | 757 | 299 | -459 | -60.57 | faster firefox | issue2504 | 6 | Page Request | 20 | 2 | 5 | 3 | 150.00 | slower firefox | issue2504 | 6 | Rendering | 20 | 755 | 294 | -462 | -61.11 | faster firefox | issue2504 | 7 | Overall | 20 | 394 | 302 | -92 | -23.39 | faster firefox | issue2504 | 7 | Page Request | 20 | 2 | 1 | -1 | -34.88 | faster firefox | issue2504 | 7 | Rendering | 20 | 392 | 301 | -91 | -23.32 | faster firefox | issue2504 | 8 | Overall | 20 | 2875 | 979 | -1896 | -65.95 | faster firefox | issue2504 | 8 | Page Request | 20 | 1 | 2 | 0 | 11.11 | firefox | issue2504 | 8 | Rendering | 20 | 2874 | 978 | -1896 | -65.99 | faster firefox | issue2504 | 9 | Overall | 20 | 700 | 332 | -368 | -52.60 | faster firefox | issue2504 | 9 | Page Request | 20 | 3 | 2 | 0 | -4.00 | firefox | issue2504 | 9 | Rendering | 20 | 698 | 329 | -368 | -52.78 | faster firefox | issue2504 | 10 | Overall | 20 | 3296 | 926 | -2370 | -71.91 | faster firefox | issue2504 | 10 | Page Request | 20 | 2 | 2 | 0 | -18.75 | firefox | issue2504 | 10 | Rendering | 20 | 3293 | 924 | -2370 | -71.96 | faster firefox | issue2504 | 11 | Overall | 20 | 524 | 197 | -327 | -62.34 | faster firefox | issue2504 | 11 | Page Request | 20 | 2 | 3 | 1 | 58.54 | firefox | issue2504 | 11 | Rendering | 20 | 522 | 194 | -328 | -62.81 | faster firefox | issue2504 | 12 | Overall | 20 | 752 | 369 | -384 | -50.98 | faster firefox | issue2504 | 12 | Page Request | 20 | 3 | 2 | -1 | -36.51 | faster firefox | issue2504 | 12 | Rendering | 20 | 749 | 367 | -382 | -51.05 | faster firefox | issue2504 | 13 | Overall | 20 | 679 | 487 | -193 | -28.38 | faster firefox | issue2504 | 13 | Page Request | 20 | 4 | 2 | -2 | -48.68 | faster firefox | issue2504 | 13 | Rendering | 20 | 676 | 485 | -191 | -28.28 | faster firefox | issue2504 | 14 | Overall | 20 | 474 | 283 | -191 | -40.26 | faster firefox | issue2504 | 14 | Page Request | 20 | 2 | 4 | 2 | 78.57 | firefox | issue2504 | 14 | Rendering | 20 | 471 | 279 | -192 | -40.79 | faster firefox | issue2504 | 15 | Overall | 20 | 860 | 618 | -241 | -28.05 | faster firefox | issue2504 | 15 | Page Request | 20 | 2 | 3 | 0 | 10.87 | firefox | issue2504 | 15 | Rendering | 20 | 857 | 616 | -241 | -28.15 | faster firefox | issue2504 | 16 | Overall | 20 | 389 | 243 | -147 | -37.71 | faster firefox | issue2504 | 16 | Page Request | 20 | 2 | 2 | 0 | 2.33 | firefox | issue2504 | 16 | Rendering | 20 | 387 | 240 | -147 | -37.94 | faster firefox | issue2504 | 17 | Overall | 20 | 1484 | 672 | -812 | -54.70 | faster firefox | issue2504 | 17 | Page Request | 20 | 2 | 3 | 1 | 37.21 | firefox | issue2504 | 17 | Rendering | 20 | 1482 | 669 | -812 | -54.84 | faster firefox | issue2504 | 18 | Overall | 20 | 575 | 252 | -323 | -56.12 | faster firefox | issue2504 | 18 | Page Request | 20 | 2 | 2 | 0 | -16.22 | firefox | issue2504 | 18 | Rendering | 20 | 573 | 251 | -322 | -56.24 | faster firefox | issue2504 | 19 | Overall | 20 | 517 | 227 | -290 | -56.08 | faster firefox | issue2504 | 19 | Page Request | 20 | 2 | 2 | 0 | 21.62 | firefox | issue2504 | 19 | Rendering | 20 | 515 | 225 | -290 | -56.37 | faster firefox | issue2504 | 20 | Overall | 20 | 668 | 670 | 2 | 0.31 | firefox | issue2504 | 20 | Page Request | 20 | 4 | 2 | -1 | -34.29 | firefox | issue2504 | 20 | Rendering | 20 | 664 | 667 | 3 | 0.49 | firefox | issue2504 | 21 | Overall | 20 | 486 | 309 | -177 | -36.44 | faster firefox | issue2504 | 21 | Page Request | 20 | 2 | 2 | 0 | 16.13 | firefox | issue2504 | 21 | Rendering | 20 | 484 | 307 | -177 | -36.60 | faster firefox | issue2504 | 22 | Overall | 20 | 543 | 267 | -276 | -50.85 | faster firefox | issue2504 | 22 | Page Request | 20 | 2 | 2 | 0 | 10.26 | firefox | issue2504 | 22 | Rendering | 20 | 541 | 265 | -276 | -51.07 | faster firefox | issue2504 | 23 | Overall | 20 | 3246 | 871 | -2375 | -73.17 | faster firefox | issue2504 | 23 | Page Request | 20 | 2 | 3 | 1 | 37.21 | firefox | issue2504 | 23 | Rendering | 20 | 3243 | 868 | -2376 | -73.25 | faster firefox | issue2504 | 24 | Overall | 20 | 379 | 156 | -223 | -58.83 | faster firefox | issue2504 | 24 | Page Request | 20 | 2 | 2 | 0 | -2.86 | firefox | issue2504 | 24 | Rendering | 20 | 378 | 154 | -223 | -59.10 | faster firefox | issue2504 | 25 | Overall | 20 | 176 | 127 | -50 | -28.19 | faster firefox | issue2504 | 25 | Page Request | 20 | 2 | 1 | 0 | -15.63 | firefox | issue2504 | 25 | Rendering | 20 | 175 | 125 | -49 | -28.31 | faster firefox | issue2504 | 26 | Overall | 20 | 181 | 108 | -74 | -40.67 | faster firefox | issue2504 | 26 | Page Request | 20 | 3 | 2 | -1 | -39.13 | faster firefox | issue2504 | 26 | Rendering | 20 | 178 | 105 | -72 | -40.69 | faster firefox | issue2504 | 27 | Overall | 20 | 208 | 104 | -104 | -49.92 | faster firefox | issue2504 | 27 | Page Request | 20 | 2 | 2 | 1 | 48.39 | firefox | issue2504 | 27 | Rendering | 20 | 206 | 102 | -104 | -50.64 | faster firefox | issue2504 | 28 | Overall | 20 | 241 | 111 | -131 | -54.16 | faster firefox | issue2504 | 28 | Page Request | 20 | 2 | 2 | -1 | -33.33 | firefox | issue2504 | 28 | Rendering | 20 | 239 | 109 | -130 | -54.39 | faster firefox | issue2504 | 29 | Overall | 20 | 321 | 196 | -125 | -39.05 | faster firefox | issue2504 | 29 | Page Request | 20 | 1 | 2 | 0 | 17.86 | firefox | issue2504 | 29 | Rendering | 20 | 319 | 194 | -126 | -39.35 | faster firefox | issue2504 | 30 | Overall | 20 | 651 | 271 | -380 | -58.41 | faster firefox | issue2504 | 30 | Page Request | 20 | 1 | 2 | 1 | 50.00 | firefox | issue2504 | 30 | Rendering | 20 | 649 | 269 | -381 | -58.60 | faster firefox | issue2504 | 31 | Overall | 20 | 1635 | 647 | -988 | -60.42 | faster firefox | issue2504 | 31 | Page Request | 20 | 1 | 2 | 0 | 30.43 | firefox | issue2504 | 31 | Rendering | 20 | 1634 | 645 | -988 | -60.49 | faster firefox | tracemonkey | 0 | Overall | 100 | 51 | 51 | 0 | 0.02 | firefox | tracemonkey | 0 | Page Request | 100 | 1 | 1 | 0 | -4.76 | firefox | tracemonkey | 0 | Rendering | 100 | 50 | 50 | 0 | 0.12 | firefox | tracemonkey | 1 | Overall | 100 | 97 | 91 | -5 | -5.52 | faster firefox | tracemonkey | 1 | Page Request | 100 | 3 | 3 | 0 | -1.32 | firefox | tracemonkey | 1 | Rendering | 100 | 94 | 88 | -5 | -5.73 | faster firefox | tracemonkey | 2 | Overall | 100 | 40 | 40 | 0 | 0.50 | firefox | tracemonkey | 2 | Page Request | 100 | 1 | 1 | 0 | 3.16 | firefox | tracemonkey | 2 | Rendering | 100 | 39 | 39 | 0 | 0.54 | firefox | tracemonkey | 3 | Overall | 100 | 62 | 62 | -1 | -0.94 | firefox | tracemonkey | 3 | Page Request | 100 | 1 | 1 | 0 | 17.05 | firefox | tracemonkey | 3 | Rendering | 100 | 61 | 61 | -1 | -1.11 | firefox | tracemonkey | 4 | Overall | 100 | 56 | 58 | 2 | 3.41 | firefox | tracemonkey | 4 | Page Request | 100 | 1 | 1 | 0 | 15.31 | firefox | tracemonkey | 4 | Rendering | 100 | 55 | 57 | 2 | 3.23 | firefox | tracemonkey | 5 | Overall | 100 | 73 | 71 | -2 | -2.28 | firefox | tracemonkey | 5 | Page Request | 100 | 2 | 2 | 0 | 12.20 | firefox | tracemonkey | 5 | Rendering | 100 | 71 | 69 | -2 | -2.69 | firefox | tracemonkey | 6 | Overall | 100 | 85 | 69 | -16 | -18.73 | faster firefox | tracemonkey | 6 | Page Request | 100 | 2 | 2 | 0 | -9.90 | firefox | tracemonkey | 6 | Rendering | 100 | 83 | 67 | -16 | -18.97 | faster firefox | tracemonkey | 7 | Overall | 100 | 65 | 64 | 0 | -0.37 | firefox | tracemonkey | 7 | Page Request | 100 | 1 | 1 | 0 | -11.94 | firefox | tracemonkey | 7 | Rendering | 100 | 63 | 63 | 0 | -0.05 | firefox | tracemonkey | 8 | Overall | 100 | 53 | 54 | 1 | 2.04 | firefox | tracemonkey | 8 | Page Request | 100 | 1 | 1 | 0 | 17.02 | firefox | tracemonkey | 8 | Rendering | 100 | 52 | 53 | 1 | 1.82 | firefox | tracemonkey | 9 | Overall | 100 | 79 | 73 | -6 | -7.86 | faster firefox | tracemonkey | 9 | Page Request | 100 | 2 | 2 | 0 | -15.14 | firefox | tracemonkey | 9 | Rendering | 100 | 77 | 71 | -6 | -7.86 | faster firefox | tracemonkey | 10 | Overall | 100 | 545 | 519 | -27 | -4.86 | faster firefox | tracemonkey | 10 | Page Request | 100 | 14 | 13 | 0 | -3.56 | firefox | tracemonkey | 10 | Rendering | 100 | 532 | 506 | -26 | -4.90 | faster firefox | tracemonkey | 11 | Overall | 100 | 42 | 41 | -1 | -2.50 | firefox | tracemonkey | 11 | Page Request | 100 | 1 | 1 | 0 | -27.42 | faster firefox | tracemonkey | 11 | Rendering | 100 | 41 | 40 | -1 | -1.75 | firefox | tracemonkey | 12 | Overall | 100 | 350 | 332 | -18 | -5.16 | faster firefox | tracemonkey | 12 | Page Request | 100 | 3 | 3 | 0 | -5.17 | firefox | tracemonkey | 12 | Rendering | 100 | 347 | 329 | -18 | -5.15 | faster firefox | tracemonkey | 13 | Overall | 100 | 31 | 31 | 0 | 0.52 | firefox | tracemonkey | 13 | Page Request | 100 | 1 | 1 | 0 | 4.95 | firefox | tracemonkey | 13 | Rendering | 100 | 30 | 30 | 0 | 0.20 | ```
2020-06-13 21:12:40 +09:00
parseColorSpace({ cs, resources, localColorSpaceCache }) {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
return new Promise(resolve => {
Add local caching of `ColorSpace`s, by name, in `PartialEvaluator.getOperatorList` (issue 2504) By caching parsed `ColorSpace`s, we thus don't need to re-parse the same data over and over which saves CPU cycles *and* reduces peak memory usage. (Obviously persistent memory usage *may* increase a tiny bit, but since the caching is done per `PartialEvaluator.getOperatorList` invocation and given that `ColorSpace` instances generally hold very little data this shouldn't be much of an issue.) Furthermore, by caching `ColorSpace`s we can also lookup the already parsed ones *synchronously* during the `OperatorList` building, instead of having to defer to the event loop/microtask queue since the parsing is done asynchronously (such that error handling is easier). Possible future improvements: - Cache/lookup parsed `ColorSpaces` used in `Pattern`s and `Image`s. - Attempt to cache *local* `ColorSpace`s by reference as well, in addition to only by name, assuming that there's documents where that would be beneficial and that it's not too difficult to implement. - Assuming there's documents that would benefit from it, also cache repeated `ColorSpace`s *globally* as well. Given that we've never, until now, been doing *any* caching of parsed `ColorSpace`s and that even using a simple name-only *local* cache helps tremendously in pathological cases, I purposely decided against complicating the implementation too much initially. Also, compared to parsing of `Image`s, simply creating a `ColorSpace` instance isn't that expensive (hence I'd be somewhat surprised if adding a *global* cache would help much). --- This patch was tested using: - The default `tracemonkey` PDF file, which was included mostly to show that "normal" documents aren't negatively affected by these changes. - The PDF file from issue 2504, i.e. https://dl-ctlg.panasonic.com/jp/manual/sd/sd_rbm1000_0.pdf, where most pages will switch *thousands* of times between a handful of `ColorSpace`s. with the following manifest file: ``` [ { "id": "tracemonkey", "file": "pdfs/tracemonkey.pdf", "md5": "9a192d8b1a7dc652a19835f6f08098bd", "rounds": 100, "type": "eq" }, { "id": "issue2504", "file": "../web/pdfs/issue2504.pdf", "md5": "", "rounds": 20, "type": "eq" } ] ``` which gave the following results when comparing this patch against the `master` branch: - Overall ``` -- Grouped By browser, pdf, stat -- browser | pdf | stat | Count | Baseline(ms) | Current(ms) | +/- | % | Result(P<.05) ------- | ----------- | ------------ | ----- | ------------ | ----------- | ---- | ------ | ------------- firefox | issue2504 | Overall | 640 | 977 | 497 | -479 | -49.08 | faster firefox | issue2504 | Page Request | 640 | 3 | 4 | 1 | 59.18 | firefox | issue2504 | Rendering | 640 | 974 | 493 | -481 | -49.37 | faster firefox | tracemonkey | Overall | 1400 | 116 | 111 | -5 | -4.43 | firefox | tracemonkey | Page Request | 1400 | 2 | 2 | 0 | -2.86 | firefox | tracemonkey | Rendering | 1400 | 114 | 109 | -5 | -4.47 | ``` - Page-specific ``` -- Grouped By browser, pdf, page, stat -- browser | pdf | page | stat | Count | Baseline(ms) | Current(ms) | +/- | % | Result(P<.05) ------- | ----------- | ---- | ------------ | ----- | ------------ | ----------- | ----- | ------- | ------------- firefox | issue2504 | 0 | Overall | 20 | 2295 | 1268 | -1027 | -44.76 | faster firefox | issue2504 | 0 | Page Request | 20 | 6 | 7 | 1 | 15.32 | firefox | issue2504 | 0 | Rendering | 20 | 2288 | 1260 | -1028 | -44.93 | faster firefox | issue2504 | 1 | Overall | 20 | 3059 | 2806 | -252 | -8.25 | faster firefox | issue2504 | 1 | Page Request | 20 | 11 | 14 | 3 | 23.25 | slower firefox | issue2504 | 1 | Rendering | 20 | 3047 | 2792 | -255 | -8.37 | faster firefox | issue2504 | 2 | Overall | 20 | 411 | 295 | -116 | -28.20 | faster firefox | issue2504 | 2 | Page Request | 20 | 2 | 42 | 40 | 1897.62 | firefox | issue2504 | 2 | Rendering | 20 | 409 | 253 | -156 | -38.09 | faster firefox | issue2504 | 3 | Overall | 20 | 736 | 299 | -437 | -59.34 | faster firefox | issue2504 | 3 | Page Request | 20 | 2 | 2 | 0 | 0.00 | firefox | issue2504 | 3 | Rendering | 20 | 734 | 297 | -437 | -59.49 | faster firefox | issue2504 | 4 | Overall | 20 | 356 | 458 | 102 | 28.63 | firefox | issue2504 | 4 | Page Request | 20 | 1 | 2 | 1 | 57.14 | slower firefox | issue2504 | 4 | Rendering | 20 | 354 | 455 | 101 | 28.53 | firefox | issue2504 | 5 | Overall | 20 | 1381 | 765 | -616 | -44.59 | faster firefox | issue2504 | 5 | Page Request | 20 | 3 | 5 | 2 | 50.00 | slower firefox | issue2504 | 5 | Rendering | 20 | 1378 | 760 | -617 | -44.81 | faster firefox | issue2504 | 6 | Overall | 20 | 757 | 299 | -459 | -60.57 | faster firefox | issue2504 | 6 | Page Request | 20 | 2 | 5 | 3 | 150.00 | slower firefox | issue2504 | 6 | Rendering | 20 | 755 | 294 | -462 | -61.11 | faster firefox | issue2504 | 7 | Overall | 20 | 394 | 302 | -92 | -23.39 | faster firefox | issue2504 | 7 | Page Request | 20 | 2 | 1 | -1 | -34.88 | faster firefox | issue2504 | 7 | Rendering | 20 | 392 | 301 | -91 | -23.32 | faster firefox | issue2504 | 8 | Overall | 20 | 2875 | 979 | -1896 | -65.95 | faster firefox | issue2504 | 8 | Page Request | 20 | 1 | 2 | 0 | 11.11 | firefox | issue2504 | 8 | Rendering | 20 | 2874 | 978 | -1896 | -65.99 | faster firefox | issue2504 | 9 | Overall | 20 | 700 | 332 | -368 | -52.60 | faster firefox | issue2504 | 9 | Page Request | 20 | 3 | 2 | 0 | -4.00 | firefox | issue2504 | 9 | Rendering | 20 | 698 | 329 | -368 | -52.78 | faster firefox | issue2504 | 10 | Overall | 20 | 3296 | 926 | -2370 | -71.91 | faster firefox | issue2504 | 10 | Page Request | 20 | 2 | 2 | 0 | -18.75 | firefox | issue2504 | 10 | Rendering | 20 | 3293 | 924 | -2370 | -71.96 | faster firefox | issue2504 | 11 | Overall | 20 | 524 | 197 | -327 | -62.34 | faster firefox | issue2504 | 11 | Page Request | 20 | 2 | 3 | 1 | 58.54 | firefox | issue2504 | 11 | Rendering | 20 | 522 | 194 | -328 | -62.81 | faster firefox | issue2504 | 12 | Overall | 20 | 752 | 369 | -384 | -50.98 | faster firefox | issue2504 | 12 | Page Request | 20 | 3 | 2 | -1 | -36.51 | faster firefox | issue2504 | 12 | Rendering | 20 | 749 | 367 | -382 | -51.05 | faster firefox | issue2504 | 13 | Overall | 20 | 679 | 487 | -193 | -28.38 | faster firefox | issue2504 | 13 | Page Request | 20 | 4 | 2 | -2 | -48.68 | faster firefox | issue2504 | 13 | Rendering | 20 | 676 | 485 | -191 | -28.28 | faster firefox | issue2504 | 14 | Overall | 20 | 474 | 283 | -191 | -40.26 | faster firefox | issue2504 | 14 | Page Request | 20 | 2 | 4 | 2 | 78.57 | firefox | issue2504 | 14 | Rendering | 20 | 471 | 279 | -192 | -40.79 | faster firefox | issue2504 | 15 | Overall | 20 | 860 | 618 | -241 | -28.05 | faster firefox | issue2504 | 15 | Page Request | 20 | 2 | 3 | 0 | 10.87 | firefox | issue2504 | 15 | Rendering | 20 | 857 | 616 | -241 | -28.15 | faster firefox | issue2504 | 16 | Overall | 20 | 389 | 243 | -147 | -37.71 | faster firefox | issue2504 | 16 | Page Request | 20 | 2 | 2 | 0 | 2.33 | firefox | issue2504 | 16 | Rendering | 20 | 387 | 240 | -147 | -37.94 | faster firefox | issue2504 | 17 | Overall | 20 | 1484 | 672 | -812 | -54.70 | faster firefox | issue2504 | 17 | Page Request | 20 | 2 | 3 | 1 | 37.21 | firefox | issue2504 | 17 | Rendering | 20 | 1482 | 669 | -812 | -54.84 | faster firefox | issue2504 | 18 | Overall | 20 | 575 | 252 | -323 | -56.12 | faster firefox | issue2504 | 18 | Page Request | 20 | 2 | 2 | 0 | -16.22 | firefox | issue2504 | 18 | Rendering | 20 | 573 | 251 | -322 | -56.24 | faster firefox | issue2504 | 19 | Overall | 20 | 517 | 227 | -290 | -56.08 | faster firefox | issue2504 | 19 | Page Request | 20 | 2 | 2 | 0 | 21.62 | firefox | issue2504 | 19 | Rendering | 20 | 515 | 225 | -290 | -56.37 | faster firefox | issue2504 | 20 | Overall | 20 | 668 | 670 | 2 | 0.31 | firefox | issue2504 | 20 | Page Request | 20 | 4 | 2 | -1 | -34.29 | firefox | issue2504 | 20 | Rendering | 20 | 664 | 667 | 3 | 0.49 | firefox | issue2504 | 21 | Overall | 20 | 486 | 309 | -177 | -36.44 | faster firefox | issue2504 | 21 | Page Request | 20 | 2 | 2 | 0 | 16.13 | firefox | issue2504 | 21 | Rendering | 20 | 484 | 307 | -177 | -36.60 | faster firefox | issue2504 | 22 | Overall | 20 | 543 | 267 | -276 | -50.85 | faster firefox | issue2504 | 22 | Page Request | 20 | 2 | 2 | 0 | 10.26 | firefox | issue2504 | 22 | Rendering | 20 | 541 | 265 | -276 | -51.07 | faster firefox | issue2504 | 23 | Overall | 20 | 3246 | 871 | -2375 | -73.17 | faster firefox | issue2504 | 23 | Page Request | 20 | 2 | 3 | 1 | 37.21 | firefox | issue2504 | 23 | Rendering | 20 | 3243 | 868 | -2376 | -73.25 | faster firefox | issue2504 | 24 | Overall | 20 | 379 | 156 | -223 | -58.83 | faster firefox | issue2504 | 24 | Page Request | 20 | 2 | 2 | 0 | -2.86 | firefox | issue2504 | 24 | Rendering | 20 | 378 | 154 | -223 | -59.10 | faster firefox | issue2504 | 25 | Overall | 20 | 176 | 127 | -50 | -28.19 | faster firefox | issue2504 | 25 | Page Request | 20 | 2 | 1 | 0 | -15.63 | firefox | issue2504 | 25 | Rendering | 20 | 175 | 125 | -49 | -28.31 | faster firefox | issue2504 | 26 | Overall | 20 | 181 | 108 | -74 | -40.67 | faster firefox | issue2504 | 26 | Page Request | 20 | 3 | 2 | -1 | -39.13 | faster firefox | issue2504 | 26 | Rendering | 20 | 178 | 105 | -72 | -40.69 | faster firefox | issue2504 | 27 | Overall | 20 | 208 | 104 | -104 | -49.92 | faster firefox | issue2504 | 27 | Page Request | 20 | 2 | 2 | 1 | 48.39 | firefox | issue2504 | 27 | Rendering | 20 | 206 | 102 | -104 | -50.64 | faster firefox | issue2504 | 28 | Overall | 20 | 241 | 111 | -131 | -54.16 | faster firefox | issue2504 | 28 | Page Request | 20 | 2 | 2 | -1 | -33.33 | firefox | issue2504 | 28 | Rendering | 20 | 239 | 109 | -130 | -54.39 | faster firefox | issue2504 | 29 | Overall | 20 | 321 | 196 | -125 | -39.05 | faster firefox | issue2504 | 29 | Page Request | 20 | 1 | 2 | 0 | 17.86 | firefox | issue2504 | 29 | Rendering | 20 | 319 | 194 | -126 | -39.35 | faster firefox | issue2504 | 30 | Overall | 20 | 651 | 271 | -380 | -58.41 | faster firefox | issue2504 | 30 | Page Request | 20 | 1 | 2 | 1 | 50.00 | firefox | issue2504 | 30 | Rendering | 20 | 649 | 269 | -381 | -58.60 | faster firefox | issue2504 | 31 | Overall | 20 | 1635 | 647 | -988 | -60.42 | faster firefox | issue2504 | 31 | Page Request | 20 | 1 | 2 | 0 | 30.43 | firefox | issue2504 | 31 | Rendering | 20 | 1634 | 645 | -988 | -60.49 | faster firefox | tracemonkey | 0 | Overall | 100 | 51 | 51 | 0 | 0.02 | firefox | tracemonkey | 0 | Page Request | 100 | 1 | 1 | 0 | -4.76 | firefox | tracemonkey | 0 | Rendering | 100 | 50 | 50 | 0 | 0.12 | firefox | tracemonkey | 1 | Overall | 100 | 97 | 91 | -5 | -5.52 | faster firefox | tracemonkey | 1 | Page Request | 100 | 3 | 3 | 0 | -1.32 | firefox | tracemonkey | 1 | Rendering | 100 | 94 | 88 | -5 | -5.73 | faster firefox | tracemonkey | 2 | Overall | 100 | 40 | 40 | 0 | 0.50 | firefox | tracemonkey | 2 | Page Request | 100 | 1 | 1 | 0 | 3.16 | firefox | tracemonkey | 2 | Rendering | 100 | 39 | 39 | 0 | 0.54 | firefox | tracemonkey | 3 | Overall | 100 | 62 | 62 | -1 | -0.94 | firefox | tracemonkey | 3 | Page Request | 100 | 1 | 1 | 0 | 17.05 | firefox | tracemonkey | 3 | Rendering | 100 | 61 | 61 | -1 | -1.11 | firefox | tracemonkey | 4 | Overall | 100 | 56 | 58 | 2 | 3.41 | firefox | tracemonkey | 4 | Page Request | 100 | 1 | 1 | 0 | 15.31 | firefox | tracemonkey | 4 | Rendering | 100 | 55 | 57 | 2 | 3.23 | firefox | tracemonkey | 5 | Overall | 100 | 73 | 71 | -2 | -2.28 | firefox | tracemonkey | 5 | Page Request | 100 | 2 | 2 | 0 | 12.20 | firefox | tracemonkey | 5 | Rendering | 100 | 71 | 69 | -2 | -2.69 | firefox | tracemonkey | 6 | Overall | 100 | 85 | 69 | -16 | -18.73 | faster firefox | tracemonkey | 6 | Page Request | 100 | 2 | 2 | 0 | -9.90 | firefox | tracemonkey | 6 | Rendering | 100 | 83 | 67 | -16 | -18.97 | faster firefox | tracemonkey | 7 | Overall | 100 | 65 | 64 | 0 | -0.37 | firefox | tracemonkey | 7 | Page Request | 100 | 1 | 1 | 0 | -11.94 | firefox | tracemonkey | 7 | Rendering | 100 | 63 | 63 | 0 | -0.05 | firefox | tracemonkey | 8 | Overall | 100 | 53 | 54 | 1 | 2.04 | firefox | tracemonkey | 8 | Page Request | 100 | 1 | 1 | 0 | 17.02 | firefox | tracemonkey | 8 | Rendering | 100 | 52 | 53 | 1 | 1.82 | firefox | tracemonkey | 9 | Overall | 100 | 79 | 73 | -6 | -7.86 | faster firefox | tracemonkey | 9 | Page Request | 100 | 2 | 2 | 0 | -15.14 | firefox | tracemonkey | 9 | Rendering | 100 | 77 | 71 | -6 | -7.86 | faster firefox | tracemonkey | 10 | Overall | 100 | 545 | 519 | -27 | -4.86 | faster firefox | tracemonkey | 10 | Page Request | 100 | 14 | 13 | 0 | -3.56 | firefox | tracemonkey | 10 | Rendering | 100 | 532 | 506 | -26 | -4.90 | faster firefox | tracemonkey | 11 | Overall | 100 | 42 | 41 | -1 | -2.50 | firefox | tracemonkey | 11 | Page Request | 100 | 1 | 1 | 0 | -27.42 | faster firefox | tracemonkey | 11 | Rendering | 100 | 41 | 40 | -1 | -1.75 | firefox | tracemonkey | 12 | Overall | 100 | 350 | 332 | -18 | -5.16 | faster firefox | tracemonkey | 12 | Page Request | 100 | 3 | 3 | 0 | -5.17 | firefox | tracemonkey | 12 | Rendering | 100 | 347 | 329 | -18 | -5.15 | faster firefox | tracemonkey | 13 | Overall | 100 | 31 | 31 | 0 | 0.52 | firefox | tracemonkey | 13 | Page Request | 100 | 1 | 1 | 0 | 4.95 | firefox | tracemonkey | 13 | Rendering | 100 | 30 | 30 | 0 | 0.20 | ```
2020-06-13 21:12:40 +09:00
const parsedColorSpace = ColorSpace.parse(
cs,
this.xref,
resources,
this.pdfFunctionFactory
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
);
Add local caching of `ColorSpace`s, by name, in `PartialEvaluator.getOperatorList` (issue 2504) By caching parsed `ColorSpace`s, we thus don't need to re-parse the same data over and over which saves CPU cycles *and* reduces peak memory usage. (Obviously persistent memory usage *may* increase a tiny bit, but since the caching is done per `PartialEvaluator.getOperatorList` invocation and given that `ColorSpace` instances generally hold very little data this shouldn't be much of an issue.) Furthermore, by caching `ColorSpace`s we can also lookup the already parsed ones *synchronously* during the `OperatorList` building, instead of having to defer to the event loop/microtask queue since the parsing is done asynchronously (such that error handling is easier). Possible future improvements: - Cache/lookup parsed `ColorSpaces` used in `Pattern`s and `Image`s. - Attempt to cache *local* `ColorSpace`s by reference as well, in addition to only by name, assuming that there's documents where that would be beneficial and that it's not too difficult to implement. - Assuming there's documents that would benefit from it, also cache repeated `ColorSpace`s *globally* as well. Given that we've never, until now, been doing *any* caching of parsed `ColorSpace`s and that even using a simple name-only *local* cache helps tremendously in pathological cases, I purposely decided against complicating the implementation too much initially. Also, compared to parsing of `Image`s, simply creating a `ColorSpace` instance isn't that expensive (hence I'd be somewhat surprised if adding a *global* cache would help much). --- This patch was tested using: - The default `tracemonkey` PDF file, which was included mostly to show that "normal" documents aren't negatively affected by these changes. - The PDF file from issue 2504, i.e. https://dl-ctlg.panasonic.com/jp/manual/sd/sd_rbm1000_0.pdf, where most pages will switch *thousands* of times between a handful of `ColorSpace`s. with the following manifest file: ``` [ { "id": "tracemonkey", "file": "pdfs/tracemonkey.pdf", "md5": "9a192d8b1a7dc652a19835f6f08098bd", "rounds": 100, "type": "eq" }, { "id": "issue2504", "file": "../web/pdfs/issue2504.pdf", "md5": "", "rounds": 20, "type": "eq" } ] ``` which gave the following results when comparing this patch against the `master` branch: - Overall ``` -- Grouped By browser, pdf, stat -- browser | pdf | stat | Count | Baseline(ms) | Current(ms) | +/- | % | Result(P<.05) ------- | ----------- | ------------ | ----- | ------------ | ----------- | ---- | ------ | ------------- firefox | issue2504 | Overall | 640 | 977 | 497 | -479 | -49.08 | faster firefox | issue2504 | Page Request | 640 | 3 | 4 | 1 | 59.18 | firefox | issue2504 | Rendering | 640 | 974 | 493 | -481 | -49.37 | faster firefox | tracemonkey | Overall | 1400 | 116 | 111 | -5 | -4.43 | firefox | tracemonkey | Page Request | 1400 | 2 | 2 | 0 | -2.86 | firefox | tracemonkey | Rendering | 1400 | 114 | 109 | -5 | -4.47 | ``` - Page-specific ``` -- Grouped By browser, pdf, page, stat -- browser | pdf | page | stat | Count | Baseline(ms) | Current(ms) | +/- | % | Result(P<.05) ------- | ----------- | ---- | ------------ | ----- | ------------ | ----------- | ----- | ------- | ------------- firefox | issue2504 | 0 | Overall | 20 | 2295 | 1268 | -1027 | -44.76 | faster firefox | issue2504 | 0 | Page Request | 20 | 6 | 7 | 1 | 15.32 | firefox | issue2504 | 0 | Rendering | 20 | 2288 | 1260 | -1028 | -44.93 | faster firefox | issue2504 | 1 | Overall | 20 | 3059 | 2806 | -252 | -8.25 | faster firefox | issue2504 | 1 | Page Request | 20 | 11 | 14 | 3 | 23.25 | slower firefox | issue2504 | 1 | Rendering | 20 | 3047 | 2792 | -255 | -8.37 | faster firefox | issue2504 | 2 | Overall | 20 | 411 | 295 | -116 | -28.20 | faster firefox | issue2504 | 2 | Page Request | 20 | 2 | 42 | 40 | 1897.62 | firefox | issue2504 | 2 | Rendering | 20 | 409 | 253 | -156 | -38.09 | faster firefox | issue2504 | 3 | Overall | 20 | 736 | 299 | -437 | -59.34 | faster firefox | issue2504 | 3 | Page Request | 20 | 2 | 2 | 0 | 0.00 | firefox | issue2504 | 3 | Rendering | 20 | 734 | 297 | -437 | -59.49 | faster firefox | issue2504 | 4 | Overall | 20 | 356 | 458 | 102 | 28.63 | firefox | issue2504 | 4 | Page Request | 20 | 1 | 2 | 1 | 57.14 | slower firefox | issue2504 | 4 | Rendering | 20 | 354 | 455 | 101 | 28.53 | firefox | issue2504 | 5 | Overall | 20 | 1381 | 765 | -616 | -44.59 | faster firefox | issue2504 | 5 | Page Request | 20 | 3 | 5 | 2 | 50.00 | slower firefox | issue2504 | 5 | Rendering | 20 | 1378 | 760 | -617 | -44.81 | faster firefox | issue2504 | 6 | Overall | 20 | 757 | 299 | -459 | -60.57 | faster firefox | issue2504 | 6 | Page Request | 20 | 2 | 5 | 3 | 150.00 | slower firefox | issue2504 | 6 | Rendering | 20 | 755 | 294 | -462 | -61.11 | faster firefox | issue2504 | 7 | Overall | 20 | 394 | 302 | -92 | -23.39 | faster firefox | issue2504 | 7 | Page Request | 20 | 2 | 1 | -1 | -34.88 | faster firefox | issue2504 | 7 | Rendering | 20 | 392 | 301 | -91 | -23.32 | faster firefox | issue2504 | 8 | Overall | 20 | 2875 | 979 | -1896 | -65.95 | faster firefox | issue2504 | 8 | Page Request | 20 | 1 | 2 | 0 | 11.11 | firefox | issue2504 | 8 | Rendering | 20 | 2874 | 978 | -1896 | -65.99 | faster firefox | issue2504 | 9 | Overall | 20 | 700 | 332 | -368 | -52.60 | faster firefox | issue2504 | 9 | Page Request | 20 | 3 | 2 | 0 | -4.00 | firefox | issue2504 | 9 | Rendering | 20 | 698 | 329 | -368 | -52.78 | faster firefox | issue2504 | 10 | Overall | 20 | 3296 | 926 | -2370 | -71.91 | faster firefox | issue2504 | 10 | Page Request | 20 | 2 | 2 | 0 | -18.75 | firefox | issue2504 | 10 | Rendering | 20 | 3293 | 924 | -2370 | -71.96 | faster firefox | issue2504 | 11 | Overall | 20 | 524 | 197 | -327 | -62.34 | faster firefox | issue2504 | 11 | Page Request | 20 | 2 | 3 | 1 | 58.54 | firefox | issue2504 | 11 | Rendering | 20 | 522 | 194 | -328 | -62.81 | faster firefox | issue2504 | 12 | Overall | 20 | 752 | 369 | -384 | -50.98 | faster firefox | issue2504 | 12 | Page Request | 20 | 3 | 2 | -1 | -36.51 | faster firefox | issue2504 | 12 | Rendering | 20 | 749 | 367 | -382 | -51.05 | faster firefox | issue2504 | 13 | Overall | 20 | 679 | 487 | -193 | -28.38 | faster firefox | issue2504 | 13 | Page Request | 20 | 4 | 2 | -2 | -48.68 | faster firefox | issue2504 | 13 | Rendering | 20 | 676 | 485 | -191 | -28.28 | faster firefox | issue2504 | 14 | Overall | 20 | 474 | 283 | -191 | -40.26 | faster firefox | issue2504 | 14 | Page Request | 20 | 2 | 4 | 2 | 78.57 | firefox | issue2504 | 14 | Rendering | 20 | 471 | 279 | -192 | -40.79 | faster firefox | issue2504 | 15 | Overall | 20 | 860 | 618 | -241 | -28.05 | faster firefox | issue2504 | 15 | Page Request | 20 | 2 | 3 | 0 | 10.87 | firefox | issue2504 | 15 | Rendering | 20 | 857 | 616 | -241 | -28.15 | faster firefox | issue2504 | 16 | Overall | 20 | 389 | 243 | -147 | -37.71 | faster firefox | issue2504 | 16 | Page Request | 20 | 2 | 2 | 0 | 2.33 | firefox | issue2504 | 16 | Rendering | 20 | 387 | 240 | -147 | -37.94 | faster firefox | issue2504 | 17 | Overall | 20 | 1484 | 672 | -812 | -54.70 | faster firefox | issue2504 | 17 | Page Request | 20 | 2 | 3 | 1 | 37.21 | firefox | issue2504 | 17 | Rendering | 20 | 1482 | 669 | -812 | -54.84 | faster firefox | issue2504 | 18 | Overall | 20 | 575 | 252 | -323 | -56.12 | faster firefox | issue2504 | 18 | Page Request | 20 | 2 | 2 | 0 | -16.22 | firefox | issue2504 | 18 | Rendering | 20 | 573 | 251 | -322 | -56.24 | faster firefox | issue2504 | 19 | Overall | 20 | 517 | 227 | -290 | -56.08 | faster firefox | issue2504 | 19 | Page Request | 20 | 2 | 2 | 0 | 21.62 | firefox | issue2504 | 19 | Rendering | 20 | 515 | 225 | -290 | -56.37 | faster firefox | issue2504 | 20 | Overall | 20 | 668 | 670 | 2 | 0.31 | firefox | issue2504 | 20 | Page Request | 20 | 4 | 2 | -1 | -34.29 | firefox | issue2504 | 20 | Rendering | 20 | 664 | 667 | 3 | 0.49 | firefox | issue2504 | 21 | Overall | 20 | 486 | 309 | -177 | -36.44 | faster firefox | issue2504 | 21 | Page Request | 20 | 2 | 2 | 0 | 16.13 | firefox | issue2504 | 21 | Rendering | 20 | 484 | 307 | -177 | -36.60 | faster firefox | issue2504 | 22 | Overall | 20 | 543 | 267 | -276 | -50.85 | faster firefox | issue2504 | 22 | Page Request | 20 | 2 | 2 | 0 | 10.26 | firefox | issue2504 | 22 | Rendering | 20 | 541 | 265 | -276 | -51.07 | faster firefox | issue2504 | 23 | Overall | 20 | 3246 | 871 | -2375 | -73.17 | faster firefox | issue2504 | 23 | Page Request | 20 | 2 | 3 | 1 | 37.21 | firefox | issue2504 | 23 | Rendering | 20 | 3243 | 868 | -2376 | -73.25 | faster firefox | issue2504 | 24 | Overall | 20 | 379 | 156 | -223 | -58.83 | faster firefox | issue2504 | 24 | Page Request | 20 | 2 | 2 | 0 | -2.86 | firefox | issue2504 | 24 | Rendering | 20 | 378 | 154 | -223 | -59.10 | faster firefox | issue2504 | 25 | Overall | 20 | 176 | 127 | -50 | -28.19 | faster firefox | issue2504 | 25 | Page Request | 20 | 2 | 1 | 0 | -15.63 | firefox | issue2504 | 25 | Rendering | 20 | 175 | 125 | -49 | -28.31 | faster firefox | issue2504 | 26 | Overall | 20 | 181 | 108 | -74 | -40.67 | faster firefox | issue2504 | 26 | Page Request | 20 | 3 | 2 | -1 | -39.13 | faster firefox | issue2504 | 26 | Rendering | 20 | 178 | 105 | -72 | -40.69 | faster firefox | issue2504 | 27 | Overall | 20 | 208 | 104 | -104 | -49.92 | faster firefox | issue2504 | 27 | Page Request | 20 | 2 | 2 | 1 | 48.39 | firefox | issue2504 | 27 | Rendering | 20 | 206 | 102 | -104 | -50.64 | faster firefox | issue2504 | 28 | Overall | 20 | 241 | 111 | -131 | -54.16 | faster firefox | issue2504 | 28 | Page Request | 20 | 2 | 2 | -1 | -33.33 | firefox | issue2504 | 28 | Rendering | 20 | 239 | 109 | -130 | -54.39 | faster firefox | issue2504 | 29 | Overall | 20 | 321 | 196 | -125 | -39.05 | faster firefox | issue2504 | 29 | Page Request | 20 | 1 | 2 | 0 | 17.86 | firefox | issue2504 | 29 | Rendering | 20 | 319 | 194 | -126 | -39.35 | faster firefox | issue2504 | 30 | Overall | 20 | 651 | 271 | -380 | -58.41 | faster firefox | issue2504 | 30 | Page Request | 20 | 1 | 2 | 1 | 50.00 | firefox | issue2504 | 30 | Rendering | 20 | 649 | 269 | -381 | -58.60 | faster firefox | issue2504 | 31 | Overall | 20 | 1635 | 647 | -988 | -60.42 | faster firefox | issue2504 | 31 | Page Request | 20 | 1 | 2 | 0 | 30.43 | firefox | issue2504 | 31 | Rendering | 20 | 1634 | 645 | -988 | -60.49 | faster firefox | tracemonkey | 0 | Overall | 100 | 51 | 51 | 0 | 0.02 | firefox | tracemonkey | 0 | Page Request | 100 | 1 | 1 | 0 | -4.76 | firefox | tracemonkey | 0 | Rendering | 100 | 50 | 50 | 0 | 0.12 | firefox | tracemonkey | 1 | Overall | 100 | 97 | 91 | -5 | -5.52 | faster firefox | tracemonkey | 1 | Page Request | 100 | 3 | 3 | 0 | -1.32 | firefox | tracemonkey | 1 | Rendering | 100 | 94 | 88 | -5 | -5.73 | faster firefox | tracemonkey | 2 | Overall | 100 | 40 | 40 | 0 | 0.50 | firefox | tracemonkey | 2 | Page Request | 100 | 1 | 1 | 0 | 3.16 | firefox | tracemonkey | 2 | Rendering | 100 | 39 | 39 | 0 | 0.54 | firefox | tracemonkey | 3 | Overall | 100 | 62 | 62 | -1 | -0.94 | firefox | tracemonkey | 3 | Page Request | 100 | 1 | 1 | 0 | 17.05 | firefox | tracemonkey | 3 | Rendering | 100 | 61 | 61 | -1 | -1.11 | firefox | tracemonkey | 4 | Overall | 100 | 56 | 58 | 2 | 3.41 | firefox | tracemonkey | 4 | Page Request | 100 | 1 | 1 | 0 | 15.31 | firefox | tracemonkey | 4 | Rendering | 100 | 55 | 57 | 2 | 3.23 | firefox | tracemonkey | 5 | Overall | 100 | 73 | 71 | -2 | -2.28 | firefox | tracemonkey | 5 | Page Request | 100 | 2 | 2 | 0 | 12.20 | firefox | tracemonkey | 5 | Rendering | 100 | 71 | 69 | -2 | -2.69 | firefox | tracemonkey | 6 | Overall | 100 | 85 | 69 | -16 | -18.73 | faster firefox | tracemonkey | 6 | Page Request | 100 | 2 | 2 | 0 | -9.90 | firefox | tracemonkey | 6 | Rendering | 100 | 83 | 67 | -16 | -18.97 | faster firefox | tracemonkey | 7 | Overall | 100 | 65 | 64 | 0 | -0.37 | firefox | tracemonkey | 7 | Page Request | 100 | 1 | 1 | 0 | -11.94 | firefox | tracemonkey | 7 | Rendering | 100 | 63 | 63 | 0 | -0.05 | firefox | tracemonkey | 8 | Overall | 100 | 53 | 54 | 1 | 2.04 | firefox | tracemonkey | 8 | Page Request | 100 | 1 | 1 | 0 | 17.02 | firefox | tracemonkey | 8 | Rendering | 100 | 52 | 53 | 1 | 1.82 | firefox | tracemonkey | 9 | Overall | 100 | 79 | 73 | -6 | -7.86 | faster firefox | tracemonkey | 9 | Page Request | 100 | 2 | 2 | 0 | -15.14 | firefox | tracemonkey | 9 | Rendering | 100 | 77 | 71 | -6 | -7.86 | faster firefox | tracemonkey | 10 | Overall | 100 | 545 | 519 | -27 | -4.86 | faster firefox | tracemonkey | 10 | Page Request | 100 | 14 | 13 | 0 | -3.56 | firefox | tracemonkey | 10 | Rendering | 100 | 532 | 506 | -26 | -4.90 | faster firefox | tracemonkey | 11 | Overall | 100 | 42 | 41 | -1 | -2.50 | firefox | tracemonkey | 11 | Page Request | 100 | 1 | 1 | 0 | -27.42 | faster firefox | tracemonkey | 11 | Rendering | 100 | 41 | 40 | -1 | -1.75 | firefox | tracemonkey | 12 | Overall | 100 | 350 | 332 | -18 | -5.16 | faster firefox | tracemonkey | 12 | Page Request | 100 | 3 | 3 | 0 | -5.17 | firefox | tracemonkey | 12 | Rendering | 100 | 347 | 329 | -18 | -5.15 | faster firefox | tracemonkey | 13 | Overall | 100 | 31 | 31 | 0 | 0.52 | firefox | tracemonkey | 13 | Page Request | 100 | 1 | 1 | 0 | 4.95 | firefox | tracemonkey | 13 | Rendering | 100 | 30 | 30 | 0 | 0.20 | ```
2020-06-13 21:12:40 +09:00
const csName = cs instanceof Name ? cs.name : null;
if (csName) {
localColorSpaceCache.set(csName, /* ref = */ null, parsedColorSpace);
}
resolve(parsedColorSpace);
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
}).catch(reason => {
Allow skipping of errors when parsing broken/unsupported ColorSpaces (issue 6707, issue 11287) This will allow us to attempt to recover as much as possible of a page, rather than immediately failing, when a broken/unsupported ColorSpace is encountered. This patch thus extends the framework added in PRs such as e.g. 8240 and 8922, to also cover parsing of ColorSpaces.
2019-10-31 23:53:51 +09:00
if (reason instanceof AbortException) {
return null;
}
if (this.options.ignoreErrors) {
// Error(s) in the ColorSpace -- sending unsupported feature
// notification and allow rendering to continue.
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
this.handler.send("UnsupportedFeature", {
Add more categories of unsupported features. Fixes #11815
2020-05-01 07:27:37 +09:00
featureId: UNSUPPORTED_FEATURES.errorColorSpace,
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
});
Allow skipping of errors when parsing broken/unsupported ColorSpaces (issue 6707, issue 11287) This will allow us to attempt to recover as much as possible of a page, rather than immediately failing, when a broken/unsupported ColorSpace is encountered. This patch thus extends the framework added in PRs such as e.g. 8240 and 8922, to also cover parsing of ColorSpaces.
2019-10-31 23:53:51 +09:00
warn(`parseColorSpace - ignoring ColorSpace: "${reason}".`);
return null;
}
throw reason;
});
},
Change `PartialEvaluator.handleColorN` to throw when no valid pattern is found Currently `handleColorN` will fallback to add a completely unparsed/unvalidated operator when no valid pattern was found. This is unfortunate, since it could very easily lead to a couple of different errors: - `DataCloneError`s when attempting to send the data to the main-thread, e.g. when `args` is `Dict`/`Stream`. - Errors in `getShadingPatternFromIR` on the main-thread, unless `args` just happens to have the expected format. - Errors when actually attempting to render the pattern on the main-thread, since the `args` will most likely not have the expected format. Hence it probably makes sense to error in `PartialEvaluator.handleColorN`, and having invalid patterns fail gracefully via the existing `ignoreErrors` code-paths instead.
2019-05-04 19:39:58 +09:00
async handleColorN(operatorList, fn, args, cs, patterns, resources, task) {
Moves ColorSpace logic into evaluator
2014-05-22 02:47:42 +09:00
// compile tiling patterns
var patternName = args[args.length - 1];
// SCN/scn applies patterns along with normal colors
var pattern;
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
if (isName(patternName) && (pattern = patterns.get(patternName.name))) {
var dict = isStream(pattern) ? pattern.dict : pattern;
var typeNum = dict.get("PatternType");
Moves ColorSpace logic into evaluator
2014-05-22 02:47:42 +09:00
evaluator.js minor optimizations
2014-06-02 19:43:20 +09:00
if (typeNum === TILING_PATTERN) {
Moves ColorSpace logic into evaluator
2014-05-22 02:47:42 +09:00
var color = cs.base ? cs.base.getRgb(args, 0) : null;
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
return this.handleTilingType(
fn,
color,
resources,
pattern,
dict,
operatorList,
task
);
evaluator.js minor optimizations
2014-06-02 19:43:20 +09:00
} else if (typeNum === SHADING_PATTERN) {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
var shading = dict.get("Shading");
var matrix = dict.getArray("Matrix");
pattern = Pattern.parseShading(
shading,
matrix,
this.xref,
resources,
this.handler,
this.pdfFunctionFactory
);
Moves ColorSpace logic into evaluator
2014-05-22 02:47:42 +09:00
operatorList.addOp(fn, pattern.getIR());
Change `PartialEvaluator.handleColorN` to throw when no valid pattern is found Currently `handleColorN` will fallback to add a completely unparsed/unvalidated operator when no valid pattern was found. This is unfortunate, since it could very easily lead to a couple of different errors: - `DataCloneError`s when attempting to send the data to the main-thread, e.g. when `args` is `Dict`/`Stream`. - Errors in `getShadingPatternFromIR` on the main-thread, unless `args` just happens to have the expected format. - Errors when actually attempting to render the pattern on the main-thread, since the `args` will most likely not have the expected format. Hence it probably makes sense to error in `PartialEvaluator.handleColorN`, and having invalid patterns fail gracefully via the existing `ignoreErrors` code-paths instead.
2019-05-04 19:39:58 +09:00
return undefined;
Moves ColorSpace logic into evaluator
2014-05-22 02:47:42 +09:00
}
Change `PartialEvaluator.handleColorN` to throw when no valid pattern is found Currently `handleColorN` will fallback to add a completely unparsed/unvalidated operator when no valid pattern was found. This is unfortunate, since it could very easily lead to a couple of different errors: - `DataCloneError`s when attempting to send the data to the main-thread, e.g. when `args` is `Dict`/`Stream`. - Errors in `getShadingPatternFromIR` on the main-thread, unless `args` just happens to have the expected format. - Errors when actually attempting to render the pattern on the main-thread, since the `args` will most likely not have the expected format. Hence it probably makes sense to error in `PartialEvaluator.handleColorN`, and having invalid patterns fail gracefully via the existing `ignoreErrors` code-paths instead.
2019-05-04 19:39:58 +09:00
throw new FormatError(`Unknown PatternType: ${typeNum}`);
Moves ColorSpace logic into evaluator
2014-05-22 02:47:42 +09:00
}
Change `PartialEvaluator.handleColorN` to throw when no valid pattern is found Currently `handleColorN` will fallback to add a completely unparsed/unvalidated operator when no valid pattern was found. This is unfortunate, since it could very easily lead to a couple of different errors: - `DataCloneError`s when attempting to send the data to the main-thread, e.g. when `args` is `Dict`/`Stream`. - Errors in `getShadingPatternFromIR` on the main-thread, unless `args` just happens to have the expected format. - Errors when actually attempting to render the pattern on the main-thread, since the `args` will most likely not have the expected format. Hence it probably makes sense to error in `PartialEvaluator.handleColorN`, and having invalid patterns fail gracefully via the existing `ignoreErrors` code-paths instead.
2019-05-04 19:39:58 +09:00
throw new FormatError(`Unknown PatternName: ${patternName}`);
Moves ColorSpace logic into evaluator
2014-05-22 02:47:42 +09:00
},
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
getOperatorList({
stream,
task,
resources,
operatorList,
initialState = null,
}) {
Change the signatures of the `PartialEvaluator` "constructor" and its `getOperatorList`/`getTextContent` methods to take parameter objects Currently these methods accept a large number of parameters, which creates quite unwieldy call-sites. When invoking them, you have to remember not only what arguments to supply, but also the correct order, to avoid runtime errors. Furthermore, since some of the parameters are optional, you also have to remember to pass e.g. `null` or `undefined` for those ones. Also, adding new parameters to these methods (which happens occasionally), often becomes unnecessarily tedious (based on personal experience). Please note that I do *not* think that we need/should convert *every* single method in `evaluator.js` (or elsewhere in `/core` files) to take parameter objects. However, in my opinion, once a method starts relying on approximately five parameter (or even more), passing them in individually becomes quite cumbersome. With these changes, I obviously needed to update the `evaluator_spec.js` unit-tests. The main change there, except the new method signatures[1], is that it's now re-using *one* `PartialEvalutor` instance, since I couldn't see any compelling reason for creating a new one in every single test. *Note:* If this patch is accepted, my intention is to (time permitting) see if it makes sense to convert additional methods in `evaluator.js` (and other `/core` files) in a similar fashion, but I figured that it'd be a good idea to limit the initial scope somewhat. --- [1] A fun fact here, note how the `PartialEvaluator` signature used in `evaluator_spec.js` wasn't even correct in the current `master`.
2017-04-30 06:13:51 +09:00
// Ensure that `resources`/`initialState` is correctly initialized,
// even if the provided parameter is e.g. `null`.
resources = resources || Dict.empty;
initialState = initialState || new EvalState();
Remove most `assert()` calls (issue 8506) This replaces `assert` calls with `throw new FormatError()`/`throw new Error()`. In a few places, throwing an `Error` (which is what `assert` meant) isn't correct since the enclosing function is supposed to return a `Promise`, hence some cases were changed to `Promise.reject(...)` and similarily for `createPromiseCapability` instances.
2017-07-20 21:04:54 +09:00
if (!operatorList) {
throw new Error('getOperatorList: missing "operatorList" parameter');
}
Change the signatures of the `PartialEvaluator` "constructor" and its `getOperatorList`/`getTextContent` methods to take parameter objects Currently these methods accept a large number of parameters, which creates quite unwieldy call-sites. When invoking them, you have to remember not only what arguments to supply, but also the correct order, to avoid runtime errors. Furthermore, since some of the parameters are optional, you also have to remember to pass e.g. `null` or `undefined` for those ones. Also, adding new parameters to these methods (which happens occasionally), often becomes unnecessarily tedious (based on personal experience). Please note that I do *not* think that we need/should convert *every* single method in `evaluator.js` (or elsewhere in `/core` files) to take parameter objects. However, in my opinion, once a method starts relying on approximately five parameter (or even more), passing them in individually becomes quite cumbersome. With these changes, I obviously needed to update the `evaluator_spec.js` unit-tests. The main change there, except the new method signatures[1], is that it's now re-using *one* `PartialEvalutor` instance, since I couldn't see any compelling reason for creating a new one in every single test. *Note:* If this patch is accepted, my intention is to (time permitting) see if it makes sense to convert additional methods in `evaluator.js` (and other `/core` files) in a similar fashion, but I figured that it'd be a good idea to limit the initial scope somewhat. --- [1] A fun fact here, note how the `PartialEvaluator` signature used in `evaluator_spec.js` wasn't even correct in the current `master`.
2017-04-30 06:13:51 +09:00
Make getOperatorList() calls independent and merge queues at end
2013-04-09 07:14:56 +09:00
var self = this;
var xref = this.xref;
Attempt to handle corrupt PDF documents that contains path operators inside of text object (issue 10542) First of all, while this simple approach appears to work OK in practice I'm not sure if it's the best way of addressing the problem (assuming that you even want to). Second of all, while the solution implemented here only requires tracking/checking one new boolean in order for this to work, I'm nonetheless not entirely happy about this since it will add additional overhead (albeit *very* small) to the parsing of path operators in PDF documents just for a handful of *corrupt* ones.
2019-04-22 00:03:38 +09:00
let parsingText = false;
Improve the *local* image caching in `PartialEvaluator.getOperatorList` Currently the local `imageCache`, as used in `PartialEvaluator.getOperatorList`, will miss certain cases of repeated images because the caching is *only* done by name (usually using a format such as e.g. "Im0", "Im1", ...). However, in some PDF documents the `/XObject` dictionaries many contain hundreds (or even thousands) of distinctly named images, despite them referring to only a handful of actual image objects (via the XRef table). With these changes we'll now cache *local* images using both name and (where applicable) reference, thus improving re-usage of images resources even further. This patch was tested using the PDF file from [bug 857031](https://bugzilla.mozilla.org/show_bug.cgi?id=857031), i.e. https://bug857031.bmoattachments.org/attachment.cgi?id=732270, with the following manifest file: ``` [ { "id": "bug857031", "file": "../web/pdfs/bug857031.pdf", "md5": "", "rounds": 250, "lastPage": 1, "type": "eq" } ] ``` which gave the following results when comparing this patch against the `master` branch: ``` -- Grouped By browser, page, stat -- browser | page | stat | Count | Baseline(ms) | Current(ms) | +/- | % | Result(P<.05) ------- | ---- | ------------ | ----- | ------------ | ----------- | --- | ----- | ------------- firefox | 0 | Overall | 250 | 2749 | 2656 | -93 | -3.38 | faster firefox | 0 | Page Request | 250 | 3 | 4 | 1 | 50.14 | slower firefox | 0 | Rendering | 250 | 2746 | 2652 | -94 | -3.44 | faster ``` While this is certainly an improvement, since we now avoid re-parsing ~1000 images on the first page, all of the image resources are small enough that the total rendering time doesn't improve that much in this particular case. In pathological cases, such as e.g. the PDF document in issue 4958, the improvements with this patch can be very significant. Looking for example at page 2, from issue 4958, the rendering time drops from ~60 seconds with `master` to ~30 seconds with this patch (obviously still slow, but it really showcases the potential of this patch nicely). Finally, note that there's also potential for additional improvements by re-using `LocalImageCache` instances for e.g. /XObject data of the `Form`-type. However, given that recent changes in this area I purposely didn't want to complicate *this* patch more than necessary.
2020-05-23 20:55:31 +09:00
const localImageCache = new LocalImageCache();
Add local caching of `ColorSpace`s, by name, in `PartialEvaluator.getOperatorList` (issue 2504) By caching parsed `ColorSpace`s, we thus don't need to re-parse the same data over and over which saves CPU cycles *and* reduces peak memory usage. (Obviously persistent memory usage *may* increase a tiny bit, but since the caching is done per `PartialEvaluator.getOperatorList` invocation and given that `ColorSpace` instances generally hold very little data this shouldn't be much of an issue.) Furthermore, by caching `ColorSpace`s we can also lookup the already parsed ones *synchronously* during the `OperatorList` building, instead of having to defer to the event loop/microtask queue since the parsing is done asynchronously (such that error handling is easier). Possible future improvements: - Cache/lookup parsed `ColorSpaces` used in `Pattern`s and `Image`s. - Attempt to cache *local* `ColorSpace`s by reference as well, in addition to only by name, assuming that there's documents where that would be beneficial and that it's not too difficult to implement. - Assuming there's documents that would benefit from it, also cache repeated `ColorSpace`s *globally* as well. Given that we've never, until now, been doing *any* caching of parsed `ColorSpace`s and that even using a simple name-only *local* cache helps tremendously in pathological cases, I purposely decided against complicating the implementation too much initially. Also, compared to parsing of `Image`s, simply creating a `ColorSpace` instance isn't that expensive (hence I'd be somewhat surprised if adding a *global* cache would help much). --- This patch was tested using: - The default `tracemonkey` PDF file, which was included mostly to show that "normal" documents aren't negatively affected by these changes. - The PDF file from issue 2504, i.e. https://dl-ctlg.panasonic.com/jp/manual/sd/sd_rbm1000_0.pdf, where most pages will switch *thousands* of times between a handful of `ColorSpace`s. with the following manifest file: ``` [ { "id": "tracemonkey", "file": "pdfs/tracemonkey.pdf", "md5": "9a192d8b1a7dc652a19835f6f08098bd", "rounds": 100, "type": "eq" }, { "id": "issue2504", "file": "../web/pdfs/issue2504.pdf", "md5": "", "rounds": 20, "type": "eq" } ] ``` which gave the following results when comparing this patch against the `master` branch: - Overall ``` -- Grouped By browser, pdf, stat -- browser | pdf | stat | Count | Baseline(ms) | Current(ms) | +/- | % | Result(P<.05) ------- | ----------- | ------------ | ----- | ------------ | ----------- | ---- | ------ | ------------- firefox | issue2504 | Overall | 640 | 977 | 497 | -479 | -49.08 | faster firefox | issue2504 | Page Request | 640 | 3 | 4 | 1 | 59.18 | firefox | issue2504 | Rendering | 640 | 974 | 493 | -481 | -49.37 | faster firefox | tracemonkey | Overall | 1400 | 116 | 111 | -5 | -4.43 | firefox | tracemonkey | Page Request | 1400 | 2 | 2 | 0 | -2.86 | firefox | tracemonkey | Rendering | 1400 | 114 | 109 | -5 | -4.47 | ``` - Page-specific ``` -- Grouped By browser, pdf, page, stat -- browser | pdf | page | stat | Count | Baseline(ms) | Current(ms) | +/- | % | Result(P<.05) ------- | ----------- | ---- | ------------ | ----- | ------------ | ----------- | ----- | ------- | ------------- firefox | issue2504 | 0 | Overall | 20 | 2295 | 1268 | -1027 | -44.76 | faster firefox | issue2504 | 0 | Page Request | 20 | 6 | 7 | 1 | 15.32 | firefox | issue2504 | 0 | Rendering | 20 | 2288 | 1260 | -1028 | -44.93 | faster firefox | issue2504 | 1 | Overall | 20 | 3059 | 2806 | -252 | -8.25 | faster firefox | issue2504 | 1 | Page Request | 20 | 11 | 14 | 3 | 23.25 | slower firefox | issue2504 | 1 | Rendering | 20 | 3047 | 2792 | -255 | -8.37 | faster firefox | issue2504 | 2 | Overall | 20 | 411 | 295 | -116 | -28.20 | faster firefox | issue2504 | 2 | Page Request | 20 | 2 | 42 | 40 | 1897.62 | firefox | issue2504 | 2 | Rendering | 20 | 409 | 253 | -156 | -38.09 | faster firefox | issue2504 | 3 | Overall | 20 | 736 | 299 | -437 | -59.34 | faster firefox | issue2504 | 3 | Page Request | 20 | 2 | 2 | 0 | 0.00 | firefox | issue2504 | 3 | Rendering | 20 | 734 | 297 | -437 | -59.49 | faster firefox | issue2504 | 4 | Overall | 20 | 356 | 458 | 102 | 28.63 | firefox | issue2504 | 4 | Page Request | 20 | 1 | 2 | 1 | 57.14 | slower firefox | issue2504 | 4 | Rendering | 20 | 354 | 455 | 101 | 28.53 | firefox | issue2504 | 5 | Overall | 20 | 1381 | 765 | -616 | -44.59 | faster firefox | issue2504 | 5 | Page Request | 20 | 3 | 5 | 2 | 50.00 | slower firefox | issue2504 | 5 | Rendering | 20 | 1378 | 760 | -617 | -44.81 | faster firefox | issue2504 | 6 | Overall | 20 | 757 | 299 | -459 | -60.57 | faster firefox | issue2504 | 6 | Page Request | 20 | 2 | 5 | 3 | 150.00 | slower firefox | issue2504 | 6 | Rendering | 20 | 755 | 294 | -462 | -61.11 | faster firefox | issue2504 | 7 | Overall | 20 | 394 | 302 | -92 | -23.39 | faster firefox | issue2504 | 7 | Page Request | 20 | 2 | 1 | -1 | -34.88 | faster firefox | issue2504 | 7 | Rendering | 20 | 392 | 301 | -91 | -23.32 | faster firefox | issue2504 | 8 | Overall | 20 | 2875 | 979 | -1896 | -65.95 | faster firefox | issue2504 | 8 | Page Request | 20 | 1 | 2 | 0 | 11.11 | firefox | issue2504 | 8 | Rendering | 20 | 2874 | 978 | -1896 | -65.99 | faster firefox | issue2504 | 9 | Overall | 20 | 700 | 332 | -368 | -52.60 | faster firefox | issue2504 | 9 | Page Request | 20 | 3 | 2 | 0 | -4.00 | firefox | issue2504 | 9 | Rendering | 20 | 698 | 329 | -368 | -52.78 | faster firefox | issue2504 | 10 | Overall | 20 | 3296 | 926 | -2370 | -71.91 | faster firefox | issue2504 | 10 | Page Request | 20 | 2 | 2 | 0 | -18.75 | firefox | issue2504 | 10 | Rendering | 20 | 3293 | 924 | -2370 | -71.96 | faster firefox | issue2504 | 11 | Overall | 20 | 524 | 197 | -327 | -62.34 | faster firefox | issue2504 | 11 | Page Request | 20 | 2 | 3 | 1 | 58.54 | firefox | issue2504 | 11 | Rendering | 20 | 522 | 194 | -328 | -62.81 | faster firefox | issue2504 | 12 | Overall | 20 | 752 | 369 | -384 | -50.98 | faster firefox | issue2504 | 12 | Page Request | 20 | 3 | 2 | -1 | -36.51 | faster firefox | issue2504 | 12 | Rendering | 20 | 749 | 367 | -382 | -51.05 | faster firefox | issue2504 | 13 | Overall | 20 | 679 | 487 | -193 | -28.38 | faster firefox | issue2504 | 13 | Page Request | 20 | 4 | 2 | -2 | -48.68 | faster firefox | issue2504 | 13 | Rendering | 20 | 676 | 485 | -191 | -28.28 | faster firefox | issue2504 | 14 | Overall | 20 | 474 | 283 | -191 | -40.26 | faster firefox | issue2504 | 14 | Page Request | 20 | 2 | 4 | 2 | 78.57 | firefox | issue2504 | 14 | Rendering | 20 | 471 | 279 | -192 | -40.79 | faster firefox | issue2504 | 15 | Overall | 20 | 860 | 618 | -241 | -28.05 | faster firefox | issue2504 | 15 | Page Request | 20 | 2 | 3 | 0 | 10.87 | firefox | issue2504 | 15 | Rendering | 20 | 857 | 616 | -241 | -28.15 | faster firefox | issue2504 | 16 | Overall | 20 | 389 | 243 | -147 | -37.71 | faster firefox | issue2504 | 16 | Page Request | 20 | 2 | 2 | 0 | 2.33 | firefox | issue2504 | 16 | Rendering | 20 | 387 | 240 | -147 | -37.94 | faster firefox | issue2504 | 17 | Overall | 20 | 1484 | 672 | -812 | -54.70 | faster firefox | issue2504 | 17 | Page Request | 20 | 2 | 3 | 1 | 37.21 | firefox | issue2504 | 17 | Rendering | 20 | 1482 | 669 | -812 | -54.84 | faster firefox | issue2504 | 18 | Overall | 20 | 575 | 252 | -323 | -56.12 | faster firefox | issue2504 | 18 | Page Request | 20 | 2 | 2 | 0 | -16.22 | firefox | issue2504 | 18 | Rendering | 20 | 573 | 251 | -322 | -56.24 | faster firefox | issue2504 | 19 | Overall | 20 | 517 | 227 | -290 | -56.08 | faster firefox | issue2504 | 19 | Page Request | 20 | 2 | 2 | 0 | 21.62 | firefox | issue2504 | 19 | Rendering | 20 | 515 | 225 | -290 | -56.37 | faster firefox | issue2504 | 20 | Overall | 20 | 668 | 670 | 2 | 0.31 | firefox | issue2504 | 20 | Page Request | 20 | 4 | 2 | -1 | -34.29 | firefox | issue2504 | 20 | Rendering | 20 | 664 | 667 | 3 | 0.49 | firefox | issue2504 | 21 | Overall | 20 | 486 | 309 | -177 | -36.44 | faster firefox | issue2504 | 21 | Page Request | 20 | 2 | 2 | 0 | 16.13 | firefox | issue2504 | 21 | Rendering | 20 | 484 | 307 | -177 | -36.60 | faster firefox | issue2504 | 22 | Overall | 20 | 543 | 267 | -276 | -50.85 | faster firefox | issue2504 | 22 | Page Request | 20 | 2 | 2 | 0 | 10.26 | firefox | issue2504 | 22 | Rendering | 20 | 541 | 265 | -276 | -51.07 | faster firefox | issue2504 | 23 | Overall | 20 | 3246 | 871 | -2375 | -73.17 | faster firefox | issue2504 | 23 | Page Request | 20 | 2 | 3 | 1 | 37.21 | firefox | issue2504 | 23 | Rendering | 20 | 3243 | 868 | -2376 | -73.25 | faster firefox | issue2504 | 24 | Overall | 20 | 379 | 156 | -223 | -58.83 | faster firefox | issue2504 | 24 | Page Request | 20 | 2 | 2 | 0 | -2.86 | firefox | issue2504 | 24 | Rendering | 20 | 378 | 154 | -223 | -59.10 | faster firefox | issue2504 | 25 | Overall | 20 | 176 | 127 | -50 | -28.19 | faster firefox | issue2504 | 25 | Page Request | 20 | 2 | 1 | 0 | -15.63 | firefox | issue2504 | 25 | Rendering | 20 | 175 | 125 | -49 | -28.31 | faster firefox | issue2504 | 26 | Overall | 20 | 181 | 108 | -74 | -40.67 | faster firefox | issue2504 | 26 | Page Request | 20 | 3 | 2 | -1 | -39.13 | faster firefox | issue2504 | 26 | Rendering | 20 | 178 | 105 | -72 | -40.69 | faster firefox | issue2504 | 27 | Overall | 20 | 208 | 104 | -104 | -49.92 | faster firefox | issue2504 | 27 | Page Request | 20 | 2 | 2 | 1 | 48.39 | firefox | issue2504 | 27 | Rendering | 20 | 206 | 102 | -104 | -50.64 | faster firefox | issue2504 | 28 | Overall | 20 | 241 | 111 | -131 | -54.16 | faster firefox | issue2504 | 28 | Page Request | 20 | 2 | 2 | -1 | -33.33 | firefox | issue2504 | 28 | Rendering | 20 | 239 | 109 | -130 | -54.39 | faster firefox | issue2504 | 29 | Overall | 20 | 321 | 196 | -125 | -39.05 | faster firefox | issue2504 | 29 | Page Request | 20 | 1 | 2 | 0 | 17.86 | firefox | issue2504 | 29 | Rendering | 20 | 319 | 194 | -126 | -39.35 | faster firefox | issue2504 | 30 | Overall | 20 | 651 | 271 | -380 | -58.41 | faster firefox | issue2504 | 30 | Page Request | 20 | 1 | 2 | 1 | 50.00 | firefox | issue2504 | 30 | Rendering | 20 | 649 | 269 | -381 | -58.60 | faster firefox | issue2504 | 31 | Overall | 20 | 1635 | 647 | -988 | -60.42 | faster firefox | issue2504 | 31 | Page Request | 20 | 1 | 2 | 0 | 30.43 | firefox | issue2504 | 31 | Rendering | 20 | 1634 | 645 | -988 | -60.49 | faster firefox | tracemonkey | 0 | Overall | 100 | 51 | 51 | 0 | 0.02 | firefox | tracemonkey | 0 | Page Request | 100 | 1 | 1 | 0 | -4.76 | firefox | tracemonkey | 0 | Rendering | 100 | 50 | 50 | 0 | 0.12 | firefox | tracemonkey | 1 | Overall | 100 | 97 | 91 | -5 | -5.52 | faster firefox | tracemonkey | 1 | Page Request | 100 | 3 | 3 | 0 | -1.32 | firefox | tracemonkey | 1 | Rendering | 100 | 94 | 88 | -5 | -5.73 | faster firefox | tracemonkey | 2 | Overall | 100 | 40 | 40 | 0 | 0.50 | firefox | tracemonkey | 2 | Page Request | 100 | 1 | 1 | 0 | 3.16 | firefox | tracemonkey | 2 | Rendering | 100 | 39 | 39 | 0 | 0.54 | firefox | tracemonkey | 3 | Overall | 100 | 62 | 62 | -1 | -0.94 | firefox | tracemonkey | 3 | Page Request | 100 | 1 | 1 | 0 | 17.05 | firefox | tracemonkey | 3 | Rendering | 100 | 61 | 61 | -1 | -1.11 | firefox | tracemonkey | 4 | Overall | 100 | 56 | 58 | 2 | 3.41 | firefox | tracemonkey | 4 | Page Request | 100 | 1 | 1 | 0 | 15.31 | firefox | tracemonkey | 4 | Rendering | 100 | 55 | 57 | 2 | 3.23 | firefox | tracemonkey | 5 | Overall | 100 | 73 | 71 | -2 | -2.28 | firefox | tracemonkey | 5 | Page Request | 100 | 2 | 2 | 0 | 12.20 | firefox | tracemonkey | 5 | Rendering | 100 | 71 | 69 | -2 | -2.69 | firefox | tracemonkey | 6 | Overall | 100 | 85 | 69 | -16 | -18.73 | faster firefox | tracemonkey | 6 | Page Request | 100 | 2 | 2 | 0 | -9.90 | firefox | tracemonkey | 6 | Rendering | 100 | 83 | 67 | -16 | -18.97 | faster firefox | tracemonkey | 7 | Overall | 100 | 65 | 64 | 0 | -0.37 | firefox | tracemonkey | 7 | Page Request | 100 | 1 | 1 | 0 | -11.94 | firefox | tracemonkey | 7 | Rendering | 100 | 63 | 63 | 0 | -0.05 | firefox | tracemonkey | 8 | Overall | 100 | 53 | 54 | 1 | 2.04 | firefox | tracemonkey | 8 | Page Request | 100 | 1 | 1 | 0 | 17.02 | firefox | tracemonkey | 8 | Rendering | 100 | 52 | 53 | 1 | 1.82 | firefox | tracemonkey | 9 | Overall | 100 | 79 | 73 | -6 | -7.86 | faster firefox | tracemonkey | 9 | Page Request | 100 | 2 | 2 | 0 | -15.14 | firefox | tracemonkey | 9 | Rendering | 100 | 77 | 71 | -6 | -7.86 | faster firefox | tracemonkey | 10 | Overall | 100 | 545 | 519 | -27 | -4.86 | faster firefox | tracemonkey | 10 | Page Request | 100 | 14 | 13 | 0 | -3.56 | firefox | tracemonkey | 10 | Rendering | 100 | 532 | 506 | -26 | -4.90 | faster firefox | tracemonkey | 11 | Overall | 100 | 42 | 41 | -1 | -2.50 | firefox | tracemonkey | 11 | Page Request | 100 | 1 | 1 | 0 | -27.42 | faster firefox | tracemonkey | 11 | Rendering | 100 | 41 | 40 | -1 | -1.75 | firefox | tracemonkey | 12 | Overall | 100 | 350 | 332 | -18 | -5.16 | faster firefox | tracemonkey | 12 | Page Request | 100 | 3 | 3 | 0 | -5.17 | firefox | tracemonkey | 12 | Rendering | 100 | 347 | 329 | -18 | -5.15 | faster firefox | tracemonkey | 13 | Overall | 100 | 31 | 31 | 0 | 0.52 | firefox | tracemonkey | 13 | Page Request | 100 | 1 | 1 | 0 | 4.95 | firefox | tracemonkey | 13 | Rendering | 100 | 30 | 30 | 0 | 0.20 | ```
2020-06-13 21:12:40 +09:00
const localColorSpaceCache = new LocalImageCache();
Splitting files
2011-10-25 08:55:23 +09:00
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
var xobjs = resources.get("XObject") || Dict.empty;
var patterns = resources.get("Pattern") || Dict.empty;
Change the signatures of the `PartialEvaluator` "constructor" and its `getOperatorList`/`getTextContent` methods to take parameter objects Currently these methods accept a large number of parameters, which creates quite unwieldy call-sites. When invoking them, you have to remember not only what arguments to supply, but also the correct order, to avoid runtime errors. Furthermore, since some of the parameters are optional, you also have to remember to pass e.g. `null` or `undefined` for those ones. Also, adding new parameters to these methods (which happens occasionally), often becomes unnecessarily tedious (based on personal experience). Please note that I do *not* think that we need/should convert *every* single method in `evaluator.js` (or elsewhere in `/core` files) to take parameter objects. However, in my opinion, once a method starts relying on approximately five parameter (or even more), passing them in individually becomes quite cumbersome. With these changes, I obviously needed to update the `evaluator_spec.js` unit-tests. The main change there, except the new method signatures[1], is that it's now re-using *one* `PartialEvalutor` instance, since I couldn't see any compelling reason for creating a new one in every single test. *Note:* If this patch is accepted, my intention is to (time permitting) see if it makes sense to convert additional methods in `evaluator.js` (and other `/core` files) in a similar fashion, but I figured that it'd be a good idea to limit the initial scope somewhat. --- [1] A fun fact here, note how the `PartialEvaluator` signature used in `evaluator_spec.js` wasn't even correct in the current `master`.
2017-04-30 06:13:51 +09:00
var stateManager = new StateManager(initialState);
Build the text layer geometry on the worker.
2014-04-10 08:44:07 +09:00
var preprocessor = new EvaluatorPreprocessor(stream, xref, stateManager);
Terminate getOperationList and getTextContent every 20 ms
2014-05-10 10:41:03 +09:00
var timeSlotManager = new TimeSlotManager();
Adds Promise to the getOperatorList
2014-05-10 10:21:15 +09:00
[api-minor] Always allow e.g. rendering to continue even if there are errors, and add a `stopAtErrors` parameter to `getDocument` to opt-out of this behaviour (issue 6342, issue 3795, bug 1130815) Other PDF readers, e.g. Adobe Reader and PDFium (in Chrome), will attempt to render as much of a page as possible even if there are errors present. Currently we just bail as soon the first error is hit, which means that we'll usually not render anything in these cases and just display a blank page instead. NOTE: This patch changes the default behaviour of the PDF.js API to always attempt to recover as much data as possible, even when encountering errors during e.g. `getOperatorList`/`getTextContent`, which thus improve our handling of corrupt PDF files and allow the default viewer to handle errors slightly more gracefully. In the event that an API consumer wishes to use the old behaviour, where we stop parsing as soon as an error is encountered, the `stopAtErrors` parameter can be set at `getDocument`. Fixes, inasmuch it's possible since the PDF files are corrupt, e.g. issue 6342, issue 3795, and [bug 1130815](https://bugzilla.mozilla.org/show_bug.cgi?id=1130815) (and probably others too).
2017-02-19 22:03:08 +09:00
function closePendingRestoreOPS(argument) {
for (var i = 0, ii = preprocessor.savedStatesDepth; i < ii; i++) {
operatorList.addOp(OPS.restore, []);
}
}
Better errors capturing at the core and stop rendering on error.
2016-03-11 22:59:09 +09:00
return new Promise(function promiseBody(resolve, reject) {
Update Prettier to version 2.0 Please note that these changes were done automatically, using `gulp lint --fix`. Given that the major version number was increased, there's a fair number of (primarily whitespace) changes; please see https://prettier.io/blog/2020/03/21/2.0.0.html In order to reduce the size of these changes somewhat, this patch maintains the old "arrowParens" style for now (once mozilla-central updates Prettier we can simply choose the same formatting, assuming it will differ here).
2020-04-14 19:28:14 +09:00
const next = function (promise) {
Promise.all([promise, operatorList.ready]).then(function () {
Better errors capturing at the core and stop rendering on error.
2016-03-11 22:59:09 +09:00
try {
promiseBody(resolve, reject);
} catch (ex) {
reject(ex);
}
}, reject);
};
Adds thread abort capabilities.
2015-10-21 10:50:32 +09:00
task.ensureNotTerminated();
Terminate getOperationList and getTextContent every 20 ms
2014-05-10 10:41:03 +09:00
timeSlotManager.reset();
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
var stop,
operation = {},
i,
ii,
cs;
Avoid unnecessary array allocations in EvaluatorPreprocessor_read(). EvaluatorPreprocessor_read() is called in two cases. For the normal layer, the args array it produces is used beyond the bounds of the loop in which EvaluatorPreprocessor_read() is called. But for the text layer, the args array is used in a very short-term fashion. This change reworks things so that a single array is repeatedly used for the text layer. This reduces total JS allocations for the Spoorkaart map by 11%, and has similar effects on many other PDFs.
2014-08-11 09:23:23 +09:00
while (!(stop = timeSlotManager.check())) {
// The arguments parsed by read() are used beyond this loop, so we
// cannot reuse the same array on each iteration. Therefore we pass
// in |null| as the initial value (see the comment on
// EvaluatorPreprocessor_read() for why).
operation.args = null;
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
if (!preprocessor.read(operation)) {
Avoid unnecessary array allocations in EvaluatorPreprocessor_read(). EvaluatorPreprocessor_read() is called in two cases. For the normal layer, the args array it produces is used beyond the bounds of the loop in which EvaluatorPreprocessor_read() is called. But for the text layer, the args array is used in a very short-term fashion. This change reworks things so that a single array is repeatedly used for the text layer. This reduces total JS allocations for the Spoorkaart map by 11%, and has similar effects on many other PDFs.
2014-08-11 09:23:23 +09:00
break;
}
Adds Promise to the getOperatorList
2014-05-10 10:21:15 +09:00
var args = operation.args;
var fn = operation.fn;
switch (fn | 0) {
case OPS.paintXObject:
// eagerly compile XForm objects
var name = args[0].name;
Improve the *local* image caching in `PartialEvaluator.getOperatorList` Currently the local `imageCache`, as used in `PartialEvaluator.getOperatorList`, will miss certain cases of repeated images because the caching is *only* done by name (usually using a format such as e.g. "Im0", "Im1", ...). However, in some PDF documents the `/XObject` dictionaries many contain hundreds (or even thousands) of distinctly named images, despite them referring to only a handful of actual image objects (via the XRef table). With these changes we'll now cache *local* images using both name and (where applicable) reference, thus improving re-usage of images resources even further. This patch was tested using the PDF file from [bug 857031](https://bugzilla.mozilla.org/show_bug.cgi?id=857031), i.e. https://bug857031.bmoattachments.org/attachment.cgi?id=732270, with the following manifest file: ``` [ { "id": "bug857031", "file": "../web/pdfs/bug857031.pdf", "md5": "", "rounds": 250, "lastPage": 1, "type": "eq" } ] ``` which gave the following results when comparing this patch against the `master` branch: ``` -- Grouped By browser, page, stat -- browser | page | stat | Count | Baseline(ms) | Current(ms) | +/- | % | Result(P<.05) ------- | ---- | ------------ | ----- | ------------ | ----------- | --- | ----- | ------------- firefox | 0 | Overall | 250 | 2749 | 2656 | -93 | -3.38 | faster firefox | 0 | Page Request | 250 | 3 | 4 | 1 | 50.14 | slower firefox | 0 | Rendering | 250 | 2746 | 2652 | -94 | -3.44 | faster ``` While this is certainly an improvement, since we now avoid re-parsing ~1000 images on the first page, all of the image resources are small enough that the total rendering time doesn't improve that much in this particular case. In pathological cases, such as e.g. the PDF document in issue 4958, the improvements with this patch can be very significant. Looking for example at page 2, from issue 4958, the rendering time drops from ~60 seconds with `master` to ~30 seconds with this patch (obviously still slow, but it really showcases the potential of this patch nicely). Finally, note that there's also potential for additional improvements by re-using `LocalImageCache` instances for e.g. /XObject data of the `Form`-type. However, given that recent changes in this area I purposely didn't want to complicate *this* patch more than necessary.
2020-05-23 20:55:31 +09:00
if (name) {
const localImage = localImageCache.getByName(name);
if (localImage) {
operatorList.addOp(localImage.fn, localImage.args);
args = null;
continue;
}
Caches last parsed resource image, recornizes image repeats
2014-02-24 23:00:08 +09:00
}
Making src/core/evaluator.js adhere to the style guide
2014-03-23 03:15:51 +09:00
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
next(
Update Prettier to version 2.0 Please note that these changes were done automatically, using `gulp lint --fix`. Given that the major version number was increased, there's a fair number of (primarily whitespace) changes; please see https://prettier.io/blog/2020/03/21/2.0.0.html In order to reduce the size of these changes somewhat, this patch maintains the old "arrowParens" style for now (once mozilla-central updates Prettier we can simply choose the same formatting, assuming it will differ here).
2020-04-14 19:28:14 +09:00
new Promise(function (resolveXObject, rejectXObject) {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
if (!name) {
throw new FormatError(
"XObject must be referred to by name."
);
}
Allow `getOperatorList`/`getTextContent` to skip errors when parsing broken XObjects (issue 8702, issue 8704) This patch makes use of the existing `ignoreErrors` property in `src/core/evaluator.js`, see PRs 8240 and 8441, thus allowing us to attempt to recovery as much as possible of a page even when it contains broken XObjects. Fixes 8702. Fixes 8704.
2017-09-17 20:35:18 +09:00
Attempt to cache repeated images at the document, rather than the page, level (issue 11878) Currently image resources, as opposed to e.g. font resources, are handled exclusively on a page-specific basis. Generally speaking this makes sense, since pages are separate from each other, however there's PDF documents where many (or even all) pages actually references exactly the same image resources (through the XRef table). Hence, in some cases, we're decoding the *same* images over and over for every page which is obviously slow and wasting both CPU and memory resources better used elsewhere.[1] Obviously we cannot simply treat all image resources as-if they're used throughout the entire PDF document, since that would end up increasing memory usage too much.[2] However, by introducing a `GlobalImageCache` in the worker we can track image resources that appear on more than one page. Hence we can switch image resources from being page-specific to being document-specific, once the image resource has been seen on more than a certain number of pages. In many cases, such as e.g. the referenced issue, this patch will thus lead to reduced memory usage for image resources. Scrolling through all pages of the document, there's now only a few main-thread copies of the same image data, as opposed to one for each rendered page (i.e. there could theoretically be *twenty* copies of the image data). While this obviously benefit both CPU and memory usage in this case, for *very* large image data this patch *may* possibly increase persistent main-thread memory usage a tiny bit. Thus to avoid negatively affecting memory usage too much in general, particularly on the main-thread, the `GlobalImageCache` will *only* cache a certain number of image resources at the document level and simply fallback to the default behaviour. Unfortunately the asynchronous nature of the code, with ranged/streamed loading of data, actually makes all of this much more complicated than if all data could be assumed to be immediately available.[3] *Please note:* The patch will lead to *small* movement in some existing test-cases, since we're now using the built-in PDF.js JPEG decoder more. This was done in order to simplify the overall implementation, especially on the main-thread, by limiting it to only the `OPS.paintImageXObject` operator. --- [1] There's e.g. PDF documents that use the same image as background on all pages. [2] Given that data stored in the `commonObjs`, on the main-thread, are only cleared manually through `PDFDocumentProxy.cleanup`. This as opposed to data stored in the `objs` of each page, which is automatically removed when the page is cleaned-up e.g. by being evicted from the cache in the default viewer. [3] If the latter case were true, we could simply check for repeat images *before* parsing started and thus avoid handling *any* duplicate image resources.
2020-05-18 21:17:56 +09:00
let xobj = xobjs.getRaw(name);
if (xobj instanceof Ref) {
Improve the *local* image caching in `PartialEvaluator.getOperatorList` Currently the local `imageCache`, as used in `PartialEvaluator.getOperatorList`, will miss certain cases of repeated images because the caching is *only* done by name (usually using a format such as e.g. "Im0", "Im1", ...). However, in some PDF documents the `/XObject` dictionaries many contain hundreds (or even thousands) of distinctly named images, despite them referring to only a handful of actual image objects (via the XRef table). With these changes we'll now cache *local* images using both name and (where applicable) reference, thus improving re-usage of images resources even further. This patch was tested using the PDF file from [bug 857031](https://bugzilla.mozilla.org/show_bug.cgi?id=857031), i.e. https://bug857031.bmoattachments.org/attachment.cgi?id=732270, with the following manifest file: ``` [ { "id": "bug857031", "file": "../web/pdfs/bug857031.pdf", "md5": "", "rounds": 250, "lastPage": 1, "type": "eq" } ] ``` which gave the following results when comparing this patch against the `master` branch: ``` -- Grouped By browser, page, stat -- browser | page | stat | Count | Baseline(ms) | Current(ms) | +/- | % | Result(P<.05) ------- | ---- | ------------ | ----- | ------------ | ----------- | --- | ----- | ------------- firefox | 0 | Overall | 250 | 2749 | 2656 | -93 | -3.38 | faster firefox | 0 | Page Request | 250 | 3 | 4 | 1 | 50.14 | slower firefox | 0 | Rendering | 250 | 2746 | 2652 | -94 | -3.44 | faster ``` While this is certainly an improvement, since we now avoid re-parsing ~1000 images on the first page, all of the image resources are small enough that the total rendering time doesn't improve that much in this particular case. In pathological cases, such as e.g. the PDF document in issue 4958, the improvements with this patch can be very significant. Looking for example at page 2, from issue 4958, the rendering time drops from ~60 seconds with `master` to ~30 seconds with this patch (obviously still slow, but it really showcases the potential of this patch nicely). Finally, note that there's also potential for additional improvements by re-using `LocalImageCache` instances for e.g. /XObject data of the `Form`-type. However, given that recent changes in this area I purposely didn't want to complicate *this* patch more than necessary.
2020-05-23 20:55:31 +09:00
const localImage = localImageCache.getByRef(xobj);
if (localImage) {
operatorList.addOp(localImage.fn, localImage.args);
resolveXObject();
return;
}
Attempt to cache repeated images at the document, rather than the page, level (issue 11878) Currently image resources, as opposed to e.g. font resources, are handled exclusively on a page-specific basis. Generally speaking this makes sense, since pages are separate from each other, however there's PDF documents where many (or even all) pages actually references exactly the same image resources (through the XRef table). Hence, in some cases, we're decoding the *same* images over and over for every page which is obviously slow and wasting both CPU and memory resources better used elsewhere.[1] Obviously we cannot simply treat all image resources as-if they're used throughout the entire PDF document, since that would end up increasing memory usage too much.[2] However, by introducing a `GlobalImageCache` in the worker we can track image resources that appear on more than one page. Hence we can switch image resources from being page-specific to being document-specific, once the image resource has been seen on more than a certain number of pages. In many cases, such as e.g. the referenced issue, this patch will thus lead to reduced memory usage for image resources. Scrolling through all pages of the document, there's now only a few main-thread copies of the same image data, as opposed to one for each rendered page (i.e. there could theoretically be *twenty* copies of the image data). While this obviously benefit both CPU and memory usage in this case, for *very* large image data this patch *may* possibly increase persistent main-thread memory usage a tiny bit. Thus to avoid negatively affecting memory usage too much in general, particularly on the main-thread, the `GlobalImageCache` will *only* cache a certain number of image resources at the document level and simply fallback to the default behaviour. Unfortunately the asynchronous nature of the code, with ranged/streamed loading of data, actually makes all of this much more complicated than if all data could be assumed to be immediately available.[3] *Please note:* The patch will lead to *small* movement in some existing test-cases, since we're now using the built-in PDF.js JPEG decoder more. This was done in order to simplify the overall implementation, especially on the main-thread, by limiting it to only the `OPS.paintImageXObject` operator. --- [1] There's e.g. PDF documents that use the same image as background on all pages. [2] Given that data stored in the `commonObjs`, on the main-thread, are only cleared manually through `PDFDocumentProxy.cleanup`. This as opposed to data stored in the `objs` of each page, which is automatically removed when the page is cleaned-up e.g. by being evicted from the cache in the default viewer. [3] If the latter case were true, we could simply check for repeat images *before* parsing started and thus avoid handling *any* duplicate image resources.
2020-05-18 21:17:56 +09:00
const globalImage = self.globalImageCache.getData(
xobj,
self.pageIndex
);
if (globalImage) {
operatorList.addDependency(globalImage.objId);
operatorList.addOp(globalImage.fn, globalImage.args);
resolveXObject();
return;
}
Improve the *local* image caching in `PartialEvaluator.getOperatorList` Currently the local `imageCache`, as used in `PartialEvaluator.getOperatorList`, will miss certain cases of repeated images because the caching is *only* done by name (usually using a format such as e.g. "Im0", "Im1", ...). However, in some PDF documents the `/XObject` dictionaries many contain hundreds (or even thousands) of distinctly named images, despite them referring to only a handful of actual image objects (via the XRef table). With these changes we'll now cache *local* images using both name and (where applicable) reference, thus improving re-usage of images resources even further. This patch was tested using the PDF file from [bug 857031](https://bugzilla.mozilla.org/show_bug.cgi?id=857031), i.e. https://bug857031.bmoattachments.org/attachment.cgi?id=732270, with the following manifest file: ``` [ { "id": "bug857031", "file": "../web/pdfs/bug857031.pdf", "md5": "", "rounds": 250, "lastPage": 1, "type": "eq" } ] ``` which gave the following results when comparing this patch against the `master` branch: ``` -- Grouped By browser, page, stat -- browser | page | stat | Count | Baseline(ms) | Current(ms) | +/- | % | Result(P<.05) ------- | ---- | ------------ | ----- | ------------ | ----------- | --- | ----- | ------------- firefox | 0 | Overall | 250 | 2749 | 2656 | -93 | -3.38 | faster firefox | 0 | Page Request | 250 | 3 | 4 | 1 | 50.14 | slower firefox | 0 | Rendering | 250 | 2746 | 2652 | -94 | -3.44 | faster ``` While this is certainly an improvement, since we now avoid re-parsing ~1000 images on the first page, all of the image resources are small enough that the total rendering time doesn't improve that much in this particular case. In pathological cases, such as e.g. the PDF document in issue 4958, the improvements with this patch can be very significant. Looking for example at page 2, from issue 4958, the rendering time drops from ~60 seconds with `master` to ~30 seconds with this patch (obviously still slow, but it really showcases the potential of this patch nicely). Finally, note that there's also potential for additional improvements by re-using `LocalImageCache` instances for e.g. /XObject data of the `Form`-type. However, given that recent changes in this area I purposely didn't want to complicate *this* patch more than necessary.
2020-05-23 20:55:31 +09:00
Attempt to cache repeated images at the document, rather than the page, level (issue 11878) Currently image resources, as opposed to e.g. font resources, are handled exclusively on a page-specific basis. Generally speaking this makes sense, since pages are separate from each other, however there's PDF documents where many (or even all) pages actually references exactly the same image resources (through the XRef table). Hence, in some cases, we're decoding the *same* images over and over for every page which is obviously slow and wasting both CPU and memory resources better used elsewhere.[1] Obviously we cannot simply treat all image resources as-if they're used throughout the entire PDF document, since that would end up increasing memory usage too much.[2] However, by introducing a `GlobalImageCache` in the worker we can track image resources that appear on more than one page. Hence we can switch image resources from being page-specific to being document-specific, once the image resource has been seen on more than a certain number of pages. In many cases, such as e.g. the referenced issue, this patch will thus lead to reduced memory usage for image resources. Scrolling through all pages of the document, there's now only a few main-thread copies of the same image data, as opposed to one for each rendered page (i.e. there could theoretically be *twenty* copies of the image data). While this obviously benefit both CPU and memory usage in this case, for *very* large image data this patch *may* possibly increase persistent main-thread memory usage a tiny bit. Thus to avoid negatively affecting memory usage too much in general, particularly on the main-thread, the `GlobalImageCache` will *only* cache a certain number of image resources at the document level and simply fallback to the default behaviour. Unfortunately the asynchronous nature of the code, with ranged/streamed loading of data, actually makes all of this much more complicated than if all data could be assumed to be immediately available.[3] *Please note:* The patch will lead to *small* movement in some existing test-cases, since we're now using the built-in PDF.js JPEG decoder more. This was done in order to simplify the overall implementation, especially on the main-thread, by limiting it to only the `OPS.paintImageXObject` operator. --- [1] There's e.g. PDF documents that use the same image as background on all pages. [2] Given that data stored in the `commonObjs`, on the main-thread, are only cleared manually through `PDFDocumentProxy.cleanup`. This as opposed to data stored in the `objs` of each page, which is automatically removed when the page is cleaned-up e.g. by being evicted from the cache in the default viewer. [3] If the latter case were true, we could simply check for repeat images *before* parsing started and thus avoid handling *any* duplicate image resources.
2020-05-18 21:17:56 +09:00
xobj = xref.fetch(xobj);
}
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
if (!xobj) {
operatorList.addOp(fn, args);
resolveXObject();
return;
}
if (!isStream(xobj)) {
throw new FormatError("XObject should be a stream");
}
Adds Promise to the getOperatorList
2014-05-10 10:21:15 +09:00
Enable the ESLint `prefer-const` rule globally (PR 11450 follow-up) Please find additional details about the ESLint rule at https://eslint.org/docs/rules/prefer-const With the recent introduction of Prettier this sort of mass enabling of ESLint rules becomes a lot easier, since the code will be automatically reformatted as necessary to account for e.g. changed line lengths. Note that this patch is generated automatically, by using the ESLint `--fix` argument, and will thus require some additional clean-up (which is done separately).
2020-01-24 17:48:21 +09:00
const type = xobj.dict.get("Subtype");
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
if (!isName(type)) {
throw new FormatError("XObject should have a Name subtype");
}
Adds Promise to the getOperatorList
2014-05-10 10:21:15 +09:00
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
if (type.name === "Form") {
stateManager.save();
self
.buildFormXObject(
resources,
xobj,
null,
operatorList,
task,
Add local caching of `ColorSpace`s, by name, in `PartialEvaluator.getOperatorList` (issue 2504) By caching parsed `ColorSpace`s, we thus don't need to re-parse the same data over and over which saves CPU cycles *and* reduces peak memory usage. (Obviously persistent memory usage *may* increase a tiny bit, but since the caching is done per `PartialEvaluator.getOperatorList` invocation and given that `ColorSpace` instances generally hold very little data this shouldn't be much of an issue.) Furthermore, by caching `ColorSpace`s we can also lookup the already parsed ones *synchronously* during the `OperatorList` building, instead of having to defer to the event loop/microtask queue since the parsing is done asynchronously (such that error handling is easier). Possible future improvements: - Cache/lookup parsed `ColorSpaces` used in `Pattern`s and `Image`s. - Attempt to cache *local* `ColorSpace`s by reference as well, in addition to only by name, assuming that there's documents where that would be beneficial and that it's not too difficult to implement. - Assuming there's documents that would benefit from it, also cache repeated `ColorSpace`s *globally* as well. Given that we've never, until now, been doing *any* caching of parsed `ColorSpace`s and that even using a simple name-only *local* cache helps tremendously in pathological cases, I purposely decided against complicating the implementation too much initially. Also, compared to parsing of `Image`s, simply creating a `ColorSpace` instance isn't that expensive (hence I'd be somewhat surprised if adding a *global* cache would help much). --- This patch was tested using: - The default `tracemonkey` PDF file, which was included mostly to show that "normal" documents aren't negatively affected by these changes. - The PDF file from issue 2504, i.e. https://dl-ctlg.panasonic.com/jp/manual/sd/sd_rbm1000_0.pdf, where most pages will switch *thousands* of times between a handful of `ColorSpace`s. with the following manifest file: ``` [ { "id": "tracemonkey", "file": "pdfs/tracemonkey.pdf", "md5": "9a192d8b1a7dc652a19835f6f08098bd", "rounds": 100, "type": "eq" }, { "id": "issue2504", "file": "../web/pdfs/issue2504.pdf", "md5": "", "rounds": 20, "type": "eq" } ] ``` which gave the following results when comparing this patch against the `master` branch: - Overall ``` -- Grouped By browser, pdf, stat -- browser | pdf | stat | Count | Baseline(ms) | Current(ms) | +/- | % | Result(P<.05) ------- | ----------- | ------------ | ----- | ------------ | ----------- | ---- | ------ | ------------- firefox | issue2504 | Overall | 640 | 977 | 497 | -479 | -49.08 | faster firefox | issue2504 | Page Request | 640 | 3 | 4 | 1 | 59.18 | firefox | issue2504 | Rendering | 640 | 974 | 493 | -481 | -49.37 | faster firefox | tracemonkey | Overall | 1400 | 116 | 111 | -5 | -4.43 | firefox | tracemonkey | Page Request | 1400 | 2 | 2 | 0 | -2.86 | firefox | tracemonkey | Rendering | 1400 | 114 | 109 | -5 | -4.47 | ``` - Page-specific ``` -- Grouped By browser, pdf, page, stat -- browser | pdf | page | stat | Count | Baseline(ms) | Current(ms) | +/- | % | Result(P<.05) ------- | ----------- | ---- | ------------ | ----- | ------------ | ----------- | ----- | ------- | ------------- firefox | issue2504 | 0 | Overall | 20 | 2295 | 1268 | -1027 | -44.76 | faster firefox | issue2504 | 0 | Page Request | 20 | 6 | 7 | 1 | 15.32 | firefox | issue2504 | 0 | Rendering | 20 | 2288 | 1260 | -1028 | -44.93 | faster firefox | issue2504 | 1 | Overall | 20 | 3059 | 2806 | -252 | -8.25 | faster firefox | issue2504 | 1 | Page Request | 20 | 11 | 14 | 3 | 23.25 | slower firefox | issue2504 | 1 | Rendering | 20 | 3047 | 2792 | -255 | -8.37 | faster firefox | issue2504 | 2 | Overall | 20 | 411 | 295 | -116 | -28.20 | faster firefox | issue2504 | 2 | Page Request | 20 | 2 | 42 | 40 | 1897.62 | firefox | issue2504 | 2 | Rendering | 20 | 409 | 253 | -156 | -38.09 | faster firefox | issue2504 | 3 | Overall | 20 | 736 | 299 | -437 | -59.34 | faster firefox | issue2504 | 3 | Page Request | 20 | 2 | 2 | 0 | 0.00 | firefox | issue2504 | 3 | Rendering | 20 | 734 | 297 | -437 | -59.49 | faster firefox | issue2504 | 4 | Overall | 20 | 356 | 458 | 102 | 28.63 | firefox | issue2504 | 4 | Page Request | 20 | 1 | 2 | 1 | 57.14 | slower firefox | issue2504 | 4 | Rendering | 20 | 354 | 455 | 101 | 28.53 | firefox | issue2504 | 5 | Overall | 20 | 1381 | 765 | -616 | -44.59 | faster firefox | issue2504 | 5 | Page Request | 20 | 3 | 5 | 2 | 50.00 | slower firefox | issue2504 | 5 | Rendering | 20 | 1378 | 760 | -617 | -44.81 | faster firefox | issue2504 | 6 | Overall | 20 | 757 | 299 | -459 | -60.57 | faster firefox | issue2504 | 6 | Page Request | 20 | 2 | 5 | 3 | 150.00 | slower firefox | issue2504 | 6 | Rendering | 20 | 755 | 294 | -462 | -61.11 | faster firefox | issue2504 | 7 | Overall | 20 | 394 | 302 | -92 | -23.39 | faster firefox | issue2504 | 7 | Page Request | 20 | 2 | 1 | -1 | -34.88 | faster firefox | issue2504 | 7 | Rendering | 20 | 392 | 301 | -91 | -23.32 | faster firefox | issue2504 | 8 | Overall | 20 | 2875 | 979 | -1896 | -65.95 | faster firefox | issue2504 | 8 | Page Request | 20 | 1 | 2 | 0 | 11.11 | firefox | issue2504 | 8 | Rendering | 20 | 2874 | 978 | -1896 | -65.99 | faster firefox | issue2504 | 9 | Overall | 20 | 700 | 332 | -368 | -52.60 | faster firefox | issue2504 | 9 | Page Request | 20 | 3 | 2 | 0 | -4.00 | firefox | issue2504 | 9 | Rendering | 20 | 698 | 329 | -368 | -52.78 | faster firefox | issue2504 | 10 | Overall | 20 | 3296 | 926 | -2370 | -71.91 | faster firefox | issue2504 | 10 | Page Request | 20 | 2 | 2 | 0 | -18.75 | firefox | issue2504 | 10 | Rendering | 20 | 3293 | 924 | -2370 | -71.96 | faster firefox | issue2504 | 11 | Overall | 20 | 524 | 197 | -327 | -62.34 | faster firefox | issue2504 | 11 | Page Request | 20 | 2 | 3 | 1 | 58.54 | firefox | issue2504 | 11 | Rendering | 20 | 522 | 194 | -328 | -62.81 | faster firefox | issue2504 | 12 | Overall | 20 | 752 | 369 | -384 | -50.98 | faster firefox | issue2504 | 12 | Page Request | 20 | 3 | 2 | -1 | -36.51 | faster firefox | issue2504 | 12 | Rendering | 20 | 749 | 367 | -382 | -51.05 | faster firefox | issue2504 | 13 | Overall | 20 | 679 | 487 | -193 | -28.38 | faster firefox | issue2504 | 13 | Page Request | 20 | 4 | 2 | -2 | -48.68 | faster firefox | issue2504 | 13 | Rendering | 20 | 676 | 485 | -191 | -28.28 | faster firefox | issue2504 | 14 | Overall | 20 | 474 | 283 | -191 | -40.26 | faster firefox | issue2504 | 14 | Page Request | 20 | 2 | 4 | 2 | 78.57 | firefox | issue2504 | 14 | Rendering | 20 | 471 | 279 | -192 | -40.79 | faster firefox | issue2504 | 15 | Overall | 20 | 860 | 618 | -241 | -28.05 | faster firefox | issue2504 | 15 | Page Request | 20 | 2 | 3 | 0 | 10.87 | firefox | issue2504 | 15 | Rendering | 20 | 857 | 616 | -241 | -28.15 | faster firefox | issue2504 | 16 | Overall | 20 | 389 | 243 | -147 | -37.71 | faster firefox | issue2504 | 16 | Page Request | 20 | 2 | 2 | 0 | 2.33 | firefox | issue2504 | 16 | Rendering | 20 | 387 | 240 | -147 | -37.94 | faster firefox | issue2504 | 17 | Overall | 20 | 1484 | 672 | -812 | -54.70 | faster firefox | issue2504 | 17 | Page Request | 20 | 2 | 3 | 1 | 37.21 | firefox | issue2504 | 17 | Rendering | 20 | 1482 | 669 | -812 | -54.84 | faster firefox | issue2504 | 18 | Overall | 20 | 575 | 252 | -323 | -56.12 | faster firefox | issue2504 | 18 | Page Request | 20 | 2 | 2 | 0 | -16.22 | firefox | issue2504 | 18 | Rendering | 20 | 573 | 251 | -322 | -56.24 | faster firefox | issue2504 | 19 | Overall | 20 | 517 | 227 | -290 | -56.08 | faster firefox | issue2504 | 19 | Page Request | 20 | 2 | 2 | 0 | 21.62 | firefox | issue2504 | 19 | Rendering | 20 | 515 | 225 | -290 | -56.37 | faster firefox | issue2504 | 20 | Overall | 20 | 668 | 670 | 2 | 0.31 | firefox | issue2504 | 20 | Page Request | 20 | 4 | 2 | -1 | -34.29 | firefox | issue2504 | 20 | Rendering | 20 | 664 | 667 | 3 | 0.49 | firefox | issue2504 | 21 | Overall | 20 | 486 | 309 | -177 | -36.44 | faster firefox | issue2504 | 21 | Page Request | 20 | 2 | 2 | 0 | 16.13 | firefox | issue2504 | 21 | Rendering | 20 | 484 | 307 | -177 | -36.60 | faster firefox | issue2504 | 22 | Overall | 20 | 543 | 267 | -276 | -50.85 | faster firefox | issue2504 | 22 | Page Request | 20 | 2 | 2 | 0 | 10.26 | firefox | issue2504 | 22 | Rendering | 20 | 541 | 265 | -276 | -51.07 | faster firefox | issue2504 | 23 | Overall | 20 | 3246 | 871 | -2375 | -73.17 | faster firefox | issue2504 | 23 | Page Request | 20 | 2 | 3 | 1 | 37.21 | firefox | issue2504 | 23 | Rendering | 20 | 3243 | 868 | -2376 | -73.25 | faster firefox | issue2504 | 24 | Overall | 20 | 379 | 156 | -223 | -58.83 | faster firefox | issue2504 | 24 | Page Request | 20 | 2 | 2 | 0 | -2.86 | firefox | issue2504 | 24 | Rendering | 20 | 378 | 154 | -223 | -59.10 | faster firefox | issue2504 | 25 | Overall | 20 | 176 | 127 | -50 | -28.19 | faster firefox | issue2504 | 25 | Page Request | 20 | 2 | 1 | 0 | -15.63 | firefox | issue2504 | 25 | Rendering | 20 | 175 | 125 | -49 | -28.31 | faster firefox | issue2504 | 26 | Overall | 20 | 181 | 108 | -74 | -40.67 | faster firefox | issue2504 | 26 | Page Request | 20 | 3 | 2 | -1 | -39.13 | faster firefox | issue2504 | 26 | Rendering | 20 | 178 | 105 | -72 | -40.69 | faster firefox | issue2504 | 27 | Overall | 20 | 208 | 104 | -104 | -49.92 | faster firefox | issue2504 | 27 | Page Request | 20 | 2 | 2 | 1 | 48.39 | firefox | issue2504 | 27 | Rendering | 20 | 206 | 102 | -104 | -50.64 | faster firefox | issue2504 | 28 | Overall | 20 | 241 | 111 | -131 | -54.16 | faster firefox | issue2504 | 28 | Page Request | 20 | 2 | 2 | -1 | -33.33 | firefox | issue2504 | 28 | Rendering | 20 | 239 | 109 | -130 | -54.39 | faster firefox | issue2504 | 29 | Overall | 20 | 321 | 196 | -125 | -39.05 | faster firefox | issue2504 | 29 | Page Request | 20 | 1 | 2 | 0 | 17.86 | firefox | issue2504 | 29 | Rendering | 20 | 319 | 194 | -126 | -39.35 | faster firefox | issue2504 | 30 | Overall | 20 | 651 | 271 | -380 | -58.41 | faster firefox | issue2504 | 30 | Page Request | 20 | 1 | 2 | 1 | 50.00 | firefox | issue2504 | 30 | Rendering | 20 | 649 | 269 | -381 | -58.60 | faster firefox | issue2504 | 31 | Overall | 20 | 1635 | 647 | -988 | -60.42 | faster firefox | issue2504 | 31 | Page Request | 20 | 1 | 2 | 0 | 30.43 | firefox | issue2504 | 31 | Rendering | 20 | 1634 | 645 | -988 | -60.49 | faster firefox | tracemonkey | 0 | Overall | 100 | 51 | 51 | 0 | 0.02 | firefox | tracemonkey | 0 | Page Request | 100 | 1 | 1 | 0 | -4.76 | firefox | tracemonkey | 0 | Rendering | 100 | 50 | 50 | 0 | 0.12 | firefox | tracemonkey | 1 | Overall | 100 | 97 | 91 | -5 | -5.52 | faster firefox | tracemonkey | 1 | Page Request | 100 | 3 | 3 | 0 | -1.32 | firefox | tracemonkey | 1 | Rendering | 100 | 94 | 88 | -5 | -5.73 | faster firefox | tracemonkey | 2 | Overall | 100 | 40 | 40 | 0 | 0.50 | firefox | tracemonkey | 2 | Page Request | 100 | 1 | 1 | 0 | 3.16 | firefox | tracemonkey | 2 | Rendering | 100 | 39 | 39 | 0 | 0.54 | firefox | tracemonkey | 3 | Overall | 100 | 62 | 62 | -1 | -0.94 | firefox | tracemonkey | 3 | Page Request | 100 | 1 | 1 | 0 | 17.05 | firefox | tracemonkey | 3 | Rendering | 100 | 61 | 61 | -1 | -1.11 | firefox | tracemonkey | 4 | Overall | 100 | 56 | 58 | 2 | 3.41 | firefox | tracemonkey | 4 | Page Request | 100 | 1 | 1 | 0 | 15.31 | firefox | tracemonkey | 4 | Rendering | 100 | 55 | 57 | 2 | 3.23 | firefox | tracemonkey | 5 | Overall | 100 | 73 | 71 | -2 | -2.28 | firefox | tracemonkey | 5 | Page Request | 100 | 2 | 2 | 0 | 12.20 | firefox | tracemonkey | 5 | Rendering | 100 | 71 | 69 | -2 | -2.69 | firefox | tracemonkey | 6 | Overall | 100 | 85 | 69 | -16 | -18.73 | faster firefox | tracemonkey | 6 | Page Request | 100 | 2 | 2 | 0 | -9.90 | firefox | tracemonkey | 6 | Rendering | 100 | 83 | 67 | -16 | -18.97 | faster firefox | tracemonkey | 7 | Overall | 100 | 65 | 64 | 0 | -0.37 | firefox | tracemonkey | 7 | Page Request | 100 | 1 | 1 | 0 | -11.94 | firefox | tracemonkey | 7 | Rendering | 100 | 63 | 63 | 0 | -0.05 | firefox | tracemonkey | 8 | Overall | 100 | 53 | 54 | 1 | 2.04 | firefox | tracemonkey | 8 | Page Request | 100 | 1 | 1 | 0 | 17.02 | firefox | tracemonkey | 8 | Rendering | 100 | 52 | 53 | 1 | 1.82 | firefox | tracemonkey | 9 | Overall | 100 | 79 | 73 | -6 | -7.86 | faster firefox | tracemonkey | 9 | Page Request | 100 | 2 | 2 | 0 | -15.14 | firefox | tracemonkey | 9 | Rendering | 100 | 77 | 71 | -6 | -7.86 | faster firefox | tracemonkey | 10 | Overall | 100 | 545 | 519 | -27 | -4.86 | faster firefox | tracemonkey | 10 | Page Request | 100 | 14 | 13 | 0 | -3.56 | firefox | tracemonkey | 10 | Rendering | 100 | 532 | 506 | -26 | -4.90 | faster firefox | tracemonkey | 11 | Overall | 100 | 42 | 41 | -1 | -2.50 | firefox | tracemonkey | 11 | Page Request | 100 | 1 | 1 | 0 | -27.42 | faster firefox | tracemonkey | 11 | Rendering | 100 | 41 | 40 | -1 | -1.75 | firefox | tracemonkey | 12 | Overall | 100 | 350 | 332 | -18 | -5.16 | faster firefox | tracemonkey | 12 | Page Request | 100 | 3 | 3 | 0 | -5.17 | firefox | tracemonkey | 12 | Rendering | 100 | 347 | 329 | -18 | -5.15 | faster firefox | tracemonkey | 13 | Overall | 100 | 31 | 31 | 0 | 0.52 | firefox | tracemonkey | 13 | Page Request | 100 | 1 | 1 | 0 | 4.95 | firefox | tracemonkey | 13 | Rendering | 100 | 30 | 30 | 0 | 0.20 | ```
2020-06-13 21:12:40 +09:00
stateManager.state.clone(),
localColorSpaceCache
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
)
Update Prettier to version 2.0 Please note that these changes were done automatically, using `gulp lint --fix`. Given that the major version number was increased, there's a fair number of (primarily whitespace) changes; please see https://prettier.io/blog/2020/03/21/2.0.0.html In order to reduce the size of these changes somewhat, this patch maintains the old "arrowParens" style for now (once mozilla-central updates Prettier we can simply choose the same formatting, assuming it will differ here).
2020-04-14 19:28:14 +09:00
.then(function () {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
stateManager.restore();
resolveXObject();
}, rejectXObject);
return;
} else if (type.name === "Image") {
self
.buildPaintImageXObject({
resources,
image: xobj,
operatorList,
cacheKey: name,
Improve the *local* image caching in `PartialEvaluator.getOperatorList` Currently the local `imageCache`, as used in `PartialEvaluator.getOperatorList`, will miss certain cases of repeated images because the caching is *only* done by name (usually using a format such as e.g. "Im0", "Im1", ...). However, in some PDF documents the `/XObject` dictionaries many contain hundreds (or even thousands) of distinctly named images, despite them referring to only a handful of actual image objects (via the XRef table). With these changes we'll now cache *local* images using both name and (where applicable) reference, thus improving re-usage of images resources even further. This patch was tested using the PDF file from [bug 857031](https://bugzilla.mozilla.org/show_bug.cgi?id=857031), i.e. https://bug857031.bmoattachments.org/attachment.cgi?id=732270, with the following manifest file: ``` [ { "id": "bug857031", "file": "../web/pdfs/bug857031.pdf", "md5": "", "rounds": 250, "lastPage": 1, "type": "eq" } ] ``` which gave the following results when comparing this patch against the `master` branch: ``` -- Grouped By browser, page, stat -- browser | page | stat | Count | Baseline(ms) | Current(ms) | +/- | % | Result(P<.05) ------- | ---- | ------------ | ----- | ------------ | ----------- | --- | ----- | ------------- firefox | 0 | Overall | 250 | 2749 | 2656 | -93 | -3.38 | faster firefox | 0 | Page Request | 250 | 3 | 4 | 1 | 50.14 | slower firefox | 0 | Rendering | 250 | 2746 | 2652 | -94 | -3.44 | faster ``` While this is certainly an improvement, since we now avoid re-parsing ~1000 images on the first page, all of the image resources are small enough that the total rendering time doesn't improve that much in this particular case. In pathological cases, such as e.g. the PDF document in issue 4958, the improvements with this patch can be very significant. Looking for example at page 2, from issue 4958, the rendering time drops from ~60 seconds with `master` to ~30 seconds with this patch (obviously still slow, but it really showcases the potential of this patch nicely). Finally, note that there's also potential for additional improvements by re-using `LocalImageCache` instances for e.g. /XObject data of the `Form`-type. However, given that recent changes in this area I purposely didn't want to complicate *this* patch more than necessary.
2020-05-23 20:55:31 +09:00
localImageCache,
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
})
.then(resolveXObject, rejectXObject);
return;
} else if (type.name === "PS") {
// PostScript XObjects are unused when viewing documents.
// See section 4.7.1 of Adobe's PDF reference.
info("Ignored XObject subtype PS");
} else {
throw new FormatError(
`Unhandled XObject subtype ${type.name}`
);
}
resolveXObject();
Update Prettier to version 2.0 Please note that these changes were done automatically, using `gulp lint --fix`. Given that the major version number was increased, there's a fair number of (primarily whitespace) changes; please see https://prettier.io/blog/2020/03/21/2.0.0.html In order to reduce the size of these changes somewhat, this patch maintains the old "arrowParens" style for now (once mozilla-central updates Prettier we can simply choose the same formatting, assuming it will differ here).
2020-04-14 19:28:14 +09:00
}).catch(function (reason) {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
if (reason instanceof AbortException) {
return;
}
if (self.options.ignoreErrors) {
// Error(s) in the XObject -- sending unsupported feature
// notification and allow rendering to continue.
self.handler.send("UnsupportedFeature", {
Add more categories of unsupported features. Fixes #11815
2020-05-01 07:27:37 +09:00
featureId: UNSUPPORTED_FEATURES.errorXObject,
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
});
warn(`getOperatorList - ignoring XObject: "${reason}".`);
return;
}
throw reason;
})
);
Allow `getOperatorList`/`getTextContent` to skip errors when parsing broken XObjects (issue 8702, issue 8704) This patch makes use of the existing `ignoreErrors` property in `src/core/evaluator.js`, see PRs 8240 and 8441, thus allowing us to attempt to recovery as much as possible of a page even when it contains broken XObjects. Fixes 8702. Fixes 8704.
2017-09-17 20:35:18 +09:00
return;
Adds Promise to the getOperatorList
2014-05-10 10:21:15 +09:00
case OPS.setFont:
var fontSize = args[1];
// eagerly collect all fonts
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
next(
self
.handleSetFont(
resources,
args,
null,
operatorList,
task,
stateManager.state
)
Update Prettier to version 2.0 Please note that these changes were done automatically, using `gulp lint --fix`. Given that the major version number was increased, there's a fair number of (primarily whitespace) changes; please see https://prettier.io/blog/2020/03/21/2.0.0.html In order to reduce the size of these changes somewhat, this patch maintains the old "arrowParens" style for now (once mozilla-central updates Prettier we can simply choose the same formatting, assuming it will differ here).
2020-04-14 19:28:14 +09:00
.then(function (loadedName) {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
operatorList.addDependency(loadedName);
operatorList.addOp(OPS.setFont, [loadedName, fontSize]);
})
);
Better errors capturing at the core and stop rendering on error.
2016-03-11 22:59:09 +09:00
return;
Attempt to handle corrupt PDF documents that contains path operators inside of text object (issue 10542) First of all, while this simple approach appears to work OK in practice I'm not sure if it's the best way of addressing the problem (assuming that you even want to). Second of all, while the solution implemented here only requires tracking/checking one new boolean in order for this to work, I'm nonetheless not entirely happy about this since it will add additional overhead (albeit *very* small) to the parsing of path operators in PDF documents just for a handful of *corrupt* ones.
2019-04-22 00:03:38 +09:00
case OPS.beginText:
parsingText = true;
break;
case OPS.endText:
parsingText = false;
break;
Adds Promise to the getOperatorList
2014-05-10 10:21:15 +09:00
case OPS.endInlineImage:
var cacheKey = args[0].cacheKey;
fixes caching of inline images during parsing. As described in #5444, the evaluator will perform identity checking of paintImageMaskXObjects to decide if it can use paintImageMaskXObjectRepeat instead of paintImageMaskXObjectGroup. This can only ever work if the entry is a cache hit. However the previous caching implementation was doing a lazy caching, which would only consider a image cache worthy if it is repeated. Only then the repeated instance would be cached. As a result of this the sequence of identical images A1 A2 A3 A4 would be seen as A1 A2 A2 A2 by the evaluator, which prevents using the "repeat" optimization. Also only the last encountered image is cached, so A1 B1 A2 B2, would stay A1 B1 A2 B2. The new implementation drops the "lazy" init of the cache. The threshold for enabling an image to be cached is rather small, so the potential waste in storage and adler32 calculation is rather low. It also caches any eligible image by its adler32. The two example from above would now be A1 A1 A1 A1 and A1 B1 A1 B1 which not only saves temporary storage, but also prevents computing identical masks over and over again (which is the main performance impact of #2618)
2014-10-27 01:03:44 +09:00
if (cacheKey) {
Improve the *local* image caching in `PartialEvaluator.getOperatorList` Currently the local `imageCache`, as used in `PartialEvaluator.getOperatorList`, will miss certain cases of repeated images because the caching is *only* done by name (usually using a format such as e.g. "Im0", "Im1", ...). However, in some PDF documents the `/XObject` dictionaries many contain hundreds (or even thousands) of distinctly named images, despite them referring to only a handful of actual image objects (via the XRef table). With these changes we'll now cache *local* images using both name and (where applicable) reference, thus improving re-usage of images resources even further. This patch was tested using the PDF file from [bug 857031](https://bugzilla.mozilla.org/show_bug.cgi?id=857031), i.e. https://bug857031.bmoattachments.org/attachment.cgi?id=732270, with the following manifest file: ``` [ { "id": "bug857031", "file": "../web/pdfs/bug857031.pdf", "md5": "", "rounds": 250, "lastPage": 1, "type": "eq" } ] ``` which gave the following results when comparing this patch against the `master` branch: ``` -- Grouped By browser, page, stat -- browser | page | stat | Count | Baseline(ms) | Current(ms) | +/- | % | Result(P<.05) ------- | ---- | ------------ | ----- | ------------ | ----------- | --- | ----- | ------------- firefox | 0 | Overall | 250 | 2749 | 2656 | -93 | -3.38 | faster firefox | 0 | Page Request | 250 | 3 | 4 | 1 | 50.14 | slower firefox | 0 | Rendering | 250 | 2746 | 2652 | -94 | -3.44 | faster ``` While this is certainly an improvement, since we now avoid re-parsing ~1000 images on the first page, all of the image resources are small enough that the total rendering time doesn't improve that much in this particular case. In pathological cases, such as e.g. the PDF document in issue 4958, the improvements with this patch can be very significant. Looking for example at page 2, from issue 4958, the rendering time drops from ~60 seconds with `master` to ~30 seconds with this patch (obviously still slow, but it really showcases the potential of this patch nicely). Finally, note that there's also potential for additional improvements by re-using `LocalImageCache` instances for e.g. /XObject data of the `Form`-type. However, given that recent changes in this area I purposely didn't want to complicate *this* patch more than necessary.
2020-05-23 20:55:31 +09:00
const localImage = localImageCache.getByName(cacheKey);
if (localImage) {
operatorList.addOp(localImage.fn, localImage.args);
fixes caching of inline images during parsing. As described in #5444, the evaluator will perform identity checking of paintImageMaskXObjects to decide if it can use paintImageMaskXObjectRepeat instead of paintImageMaskXObjectGroup. This can only ever work if the entry is a cache hit. However the previous caching implementation was doing a lazy caching, which would only consider a image cache worthy if it is repeated. Only then the repeated instance would be cached. As a result of this the sequence of identical images A1 A2 A3 A4 would be seen as A1 A2 A2 A2 by the evaluator, which prevents using the "repeat" optimization. Also only the last encountered image is cached, so A1 B1 A2 B2, would stay A1 B1 A2 B2. The new implementation drops the "lazy" init of the cache. The threshold for enabling an image to be cached is rather small, so the potential waste in storage and adler32 calculation is rather low. It also caches any eligible image by its adler32. The two example from above would now be A1 A1 A1 A1 and A1 B1 A1 B1 which not only saves temporary storage, but also prevents computing identical masks over and over again (which is the main performance impact of #2618)
2014-10-27 01:03:44 +09:00
args = null;
continue;
}
Caching inlined mask images
2014-02-25 00:59:02 +09:00
}
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
next(
self.buildPaintImageXObject({
resources,
image: args[0],
isInline: true,
operatorList,
cacheKey,
Improve the *local* image caching in `PartialEvaluator.getOperatorList` Currently the local `imageCache`, as used in `PartialEvaluator.getOperatorList`, will miss certain cases of repeated images because the caching is *only* done by name (usually using a format such as e.g. "Im0", "Im1", ...). However, in some PDF documents the `/XObject` dictionaries many contain hundreds (or even thousands) of distinctly named images, despite them referring to only a handful of actual image objects (via the XRef table). With these changes we'll now cache *local* images using both name and (where applicable) reference, thus improving re-usage of images resources even further. This patch was tested using the PDF file from [bug 857031](https://bugzilla.mozilla.org/show_bug.cgi?id=857031), i.e. https://bug857031.bmoattachments.org/attachment.cgi?id=732270, with the following manifest file: ``` [ { "id": "bug857031", "file": "../web/pdfs/bug857031.pdf", "md5": "", "rounds": 250, "lastPage": 1, "type": "eq" } ] ``` which gave the following results when comparing this patch against the `master` branch: ``` -- Grouped By browser, page, stat -- browser | page | stat | Count | Baseline(ms) | Current(ms) | +/- | % | Result(P<.05) ------- | ---- | ------------ | ----- | ------------ | ----------- | --- | ----- | ------------- firefox | 0 | Overall | 250 | 2749 | 2656 | -93 | -3.38 | faster firefox | 0 | Page Request | 250 | 3 | 4 | 1 | 50.14 | slower firefox | 0 | Rendering | 250 | 2746 | 2652 | -94 | -3.44 | faster ``` While this is certainly an improvement, since we now avoid re-parsing ~1000 images on the first page, all of the image resources are small enough that the total rendering time doesn't improve that much in this particular case. In pathological cases, such as e.g. the PDF document in issue 4958, the improvements with this patch can be very significant. Looking for example at page 2, from issue 4958, the rendering time drops from ~60 seconds with `master` to ~30 seconds with this patch (obviously still slow, but it really showcases the potential of this patch nicely). Finally, note that there's also potential for additional improvements by re-using `LocalImageCache` instances for e.g. /XObject data of the `Form`-type. However, given that recent changes in this area I purposely didn't want to complicate *this* patch more than necessary.
2020-05-23 20:55:31 +09:00
localImageCache,
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
})
);
Re-factor `PartialEvaluator.buildPaintImageXObject` to make it asynchronous This is necessary for upcoming changes, which will add fallback code-paths to allow graceful handling of native image decoding failures.
2018-02-01 23:53:37 +09:00
return;
Adds Promise to the getOperatorList
2014-05-10 10:21:15 +09:00
case OPS.showText:
Ensure that there's always a setFont (Tf) operator before text rendering operators (issue 11651) The PDF document in question is *corrupt*, since it contains multiple instances of incorrect operators. We obviously don't want to slow down parsing of *all* documents (since most are valid), just to accommodate a particular bad PDF generator, hence the reason for the inline check before calling the `ensureStateFont` method.
2020-03-02 23:34:00 +09:00
if (!stateManager.state.font) {
self.ensureStateFont(stateManager.state);
continue;
}
Adds Promise to the getOperatorList
2014-05-10 10:21:15 +09:00
args[0] = self.handleText(args[0], stateManager.state);
break;
case OPS.showSpacedText:
Ensure that there's always a setFont (Tf) operator before text rendering operators (issue 11651) The PDF document in question is *corrupt*, since it contains multiple instances of incorrect operators. We obviously don't want to slow down parsing of *all* documents (since most are valid), just to accommodate a particular bad PDF generator, hence the reason for the inline check before calling the `ensureStateFont` method.
2020-03-02 23:34:00 +09:00
if (!stateManager.state.font) {
self.ensureStateFont(stateManager.state);
continue;
}
Adds Promise to the getOperatorList
2014-05-10 10:21:15 +09:00
var arr = args[0];
Refactors showText: split type3, remove showSpacedText
2014-05-24 03:36:54 +09:00
var combinedGlyphs = [];
Adds Promise to the getOperatorList
2014-05-10 10:21:15 +09:00
var arrLength = arr.length;
Fix text spacing with vertical fonts (#6387) According to the PDF spec 5.3.2, a positive value means in horizontal, that the next glyph is further to the left (so narrower), and in vertical that it is further down (so wider). This change fixes the way PDF.js has interpreted the value.
2015-08-28 20:42:01 +09:00
var state = stateManager.state;
Adds Promise to the getOperatorList
2014-05-10 10:21:15 +09:00
for (i = 0; i < arrLength; ++i) {
Refactors showText: split type3, remove showSpacedText
2014-05-24 03:36:54 +09:00
var arrItem = arr[i];
if (isString(arrItem)) {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
Array.prototype.push.apply(
combinedGlyphs,
self.handleText(arrItem, state)
);
Refactors showText: split type3, remove showSpacedText
2014-05-24 03:36:54 +09:00
} else if (isNum(arrItem)) {
combinedGlyphs.push(arrItem);
Adds Promise to the getOperatorList
2014-05-10 10:21:15 +09:00
}
}
Refactors showText: split type3, remove showSpacedText
2014-05-24 03:36:54 +09:00
args[0] = combinedGlyphs;
fn = OPS.showText;
Adds Promise to the getOperatorList
2014-05-10 10:21:15 +09:00
break;
case OPS.nextLineShowText:
Ensure that there's always a setFont (Tf) operator before text rendering operators (issue 11651) The PDF document in question is *corrupt*, since it contains multiple instances of incorrect operators. We obviously don't want to slow down parsing of *all* documents (since most are valid), just to accommodate a particular bad PDF generator, hence the reason for the inline check before calling the `ensureStateFont` method.
2020-03-02 23:34:00 +09:00
if (!stateManager.state.font) {
self.ensureStateFont(stateManager.state);
continue;
}
Refactors showText: split type3, remove showSpacedText
2014-05-24 03:36:54 +09:00
operatorList.addOp(OPS.nextLine);
Adds Promise to the getOperatorList
2014-05-10 10:21:15 +09:00
args[0] = self.handleText(args[0], stateManager.state);
Refactors showText: split type3, remove showSpacedText
2014-05-24 03:36:54 +09:00
fn = OPS.showText;
Adds Promise to the getOperatorList
2014-05-10 10:21:15 +09:00
break;
case OPS.nextLineSetSpacingShowText:
Ensure that there's always a setFont (Tf) operator before text rendering operators (issue 11651) The PDF document in question is *corrupt*, since it contains multiple instances of incorrect operators. We obviously don't want to slow down parsing of *all* documents (since most are valid), just to accommodate a particular bad PDF generator, hence the reason for the inline check before calling the `ensureStateFont` method.
2020-03-02 23:34:00 +09:00
if (!stateManager.state.font) {
self.ensureStateFont(stateManager.state);
continue;
}
Refactors showText: split type3, remove showSpacedText
2014-05-24 03:36:54 +09:00
operatorList.addOp(OPS.nextLine);
operatorList.addOp(OPS.setWordSpacing, [args.shift()]);
operatorList.addOp(OPS.setCharSpacing, [args.shift()]);
args[0] = self.handleText(args[0], stateManager.state);
fn = OPS.showText;
Adds Promise to the getOperatorList
2014-05-10 10:21:15 +09:00
break;
case OPS.setTextRenderingMode:
stateManager.state.textRenderingMode = args[0];
break;
Moves ColorSpace logic into evaluator
2014-05-22 02:47:42 +09:00
Add local caching of `ColorSpace`s, by name, in `PartialEvaluator.getOperatorList` (issue 2504) By caching parsed `ColorSpace`s, we thus don't need to re-parse the same data over and over which saves CPU cycles *and* reduces peak memory usage. (Obviously persistent memory usage *may* increase a tiny bit, but since the caching is done per `PartialEvaluator.getOperatorList` invocation and given that `ColorSpace` instances generally hold very little data this shouldn't be much of an issue.) Furthermore, by caching `ColorSpace`s we can also lookup the already parsed ones *synchronously* during the `OperatorList` building, instead of having to defer to the event loop/microtask queue since the parsing is done asynchronously (such that error handling is easier). Possible future improvements: - Cache/lookup parsed `ColorSpaces` used in `Pattern`s and `Image`s. - Attempt to cache *local* `ColorSpace`s by reference as well, in addition to only by name, assuming that there's documents where that would be beneficial and that it's not too difficult to implement. - Assuming there's documents that would benefit from it, also cache repeated `ColorSpace`s *globally* as well. Given that we've never, until now, been doing *any* caching of parsed `ColorSpace`s and that even using a simple name-only *local* cache helps tremendously in pathological cases, I purposely decided against complicating the implementation too much initially. Also, compared to parsing of `Image`s, simply creating a `ColorSpace` instance isn't that expensive (hence I'd be somewhat surprised if adding a *global* cache would help much). --- This patch was tested using: - The default `tracemonkey` PDF file, which was included mostly to show that "normal" documents aren't negatively affected by these changes. - The PDF file from issue 2504, i.e. https://dl-ctlg.panasonic.com/jp/manual/sd/sd_rbm1000_0.pdf, where most pages will switch *thousands* of times between a handful of `ColorSpace`s. with the following manifest file: ``` [ { "id": "tracemonkey", "file": "pdfs/tracemonkey.pdf", "md5": "9a192d8b1a7dc652a19835f6f08098bd", "rounds": 100, "type": "eq" }, { "id": "issue2504", "file": "../web/pdfs/issue2504.pdf", "md5": "", "rounds": 20, "type": "eq" } ] ``` which gave the following results when comparing this patch against the `master` branch: - Overall ``` -- Grouped By browser, pdf, stat -- browser | pdf | stat | Count | Baseline(ms) | Current(ms) | +/- | % | Result(P<.05) ------- | ----------- | ------------ | ----- | ------------ | ----------- | ---- | ------ | ------------- firefox | issue2504 | Overall | 640 | 977 | 497 | -479 | -49.08 | faster firefox | issue2504 | Page Request | 640 | 3 | 4 | 1 | 59.18 | firefox | issue2504 | Rendering | 640 | 974 | 493 | -481 | -49.37 | faster firefox | tracemonkey | Overall | 1400 | 116 | 111 | -5 | -4.43 | firefox | tracemonkey | Page Request | 1400 | 2 | 2 | 0 | -2.86 | firefox | tracemonkey | Rendering | 1400 | 114 | 109 | -5 | -4.47 | ``` - Page-specific ``` -- Grouped By browser, pdf, page, stat -- browser | pdf | page | stat | Count | Baseline(ms) | Current(ms) | +/- | % | Result(P<.05) ------- | ----------- | ---- | ------------ | ----- | ------------ | ----------- | ----- | ------- | ------------- firefox | issue2504 | 0 | Overall | 20 | 2295 | 1268 | -1027 | -44.76 | faster firefox | issue2504 | 0 | Page Request | 20 | 6 | 7 | 1 | 15.32 | firefox | issue2504 | 0 | Rendering | 20 | 2288 | 1260 | -1028 | -44.93 | faster firefox | issue2504 | 1 | Overall | 20 | 3059 | 2806 | -252 | -8.25 | faster firefox | issue2504 | 1 | Page Request | 20 | 11 | 14 | 3 | 23.25 | slower firefox | issue2504 | 1 | Rendering | 20 | 3047 | 2792 | -255 | -8.37 | faster firefox | issue2504 | 2 | Overall | 20 | 411 | 295 | -116 | -28.20 | faster firefox | issue2504 | 2 | Page Request | 20 | 2 | 42 | 40 | 1897.62 | firefox | issue2504 | 2 | Rendering | 20 | 409 | 253 | -156 | -38.09 | faster firefox | issue2504 | 3 | Overall | 20 | 736 | 299 | -437 | -59.34 | faster firefox | issue2504 | 3 | Page Request | 20 | 2 | 2 | 0 | 0.00 | firefox | issue2504 | 3 | Rendering | 20 | 734 | 297 | -437 | -59.49 | faster firefox | issue2504 | 4 | Overall | 20 | 356 | 458 | 102 | 28.63 | firefox | issue2504 | 4 | Page Request | 20 | 1 | 2 | 1 | 57.14 | slower firefox | issue2504 | 4 | Rendering | 20 | 354 | 455 | 101 | 28.53 | firefox | issue2504 | 5 | Overall | 20 | 1381 | 765 | -616 | -44.59 | faster firefox | issue2504 | 5 | Page Request | 20 | 3 | 5 | 2 | 50.00 | slower firefox | issue2504 | 5 | Rendering | 20 | 1378 | 760 | -617 | -44.81 | faster firefox | issue2504 | 6 | Overall | 20 | 757 | 299 | -459 | -60.57 | faster firefox | issue2504 | 6 | Page Request | 20 | 2 | 5 | 3 | 150.00 | slower firefox | issue2504 | 6 | Rendering | 20 | 755 | 294 | -462 | -61.11 | faster firefox | issue2504 | 7 | Overall | 20 | 394 | 302 | -92 | -23.39 | faster firefox | issue2504 | 7 | Page Request | 20 | 2 | 1 | -1 | -34.88 | faster firefox | issue2504 | 7 | Rendering | 20 | 392 | 301 | -91 | -23.32 | faster firefox | issue2504 | 8 | Overall | 20 | 2875 | 979 | -1896 | -65.95 | faster firefox | issue2504 | 8 | Page Request | 20 | 1 | 2 | 0 | 11.11 | firefox | issue2504 | 8 | Rendering | 20 | 2874 | 978 | -1896 | -65.99 | faster firefox | issue2504 | 9 | Overall | 20 | 700 | 332 | -368 | -52.60 | faster firefox | issue2504 | 9 | Page Request | 20 | 3 | 2 | 0 | -4.00 | firefox | issue2504 | 9 | Rendering | 20 | 698 | 329 | -368 | -52.78 | faster firefox | issue2504 | 10 | Overall | 20 | 3296 | 926 | -2370 | -71.91 | faster firefox | issue2504 | 10 | Page Request | 20 | 2 | 2 | 0 | -18.75 | firefox | issue2504 | 10 | Rendering | 20 | 3293 | 924 | -2370 | -71.96 | faster firefox | issue2504 | 11 | Overall | 20 | 524 | 197 | -327 | -62.34 | faster firefox | issue2504 | 11 | Page Request | 20 | 2 | 3 | 1 | 58.54 | firefox | issue2504 | 11 | Rendering | 20 | 522 | 194 | -328 | -62.81 | faster firefox | issue2504 | 12 | Overall | 20 | 752 | 369 | -384 | -50.98 | faster firefox | issue2504 | 12 | Page Request | 20 | 3 | 2 | -1 | -36.51 | faster firefox | issue2504 | 12 | Rendering | 20 | 749 | 367 | -382 | -51.05 | faster firefox | issue2504 | 13 | Overall | 20 | 679 | 487 | -193 | -28.38 | faster firefox | issue2504 | 13 | Page Request | 20 | 4 | 2 | -2 | -48.68 | faster firefox | issue2504 | 13 | Rendering | 20 | 676 | 485 | -191 | -28.28 | faster firefox | issue2504 | 14 | Overall | 20 | 474 | 283 | -191 | -40.26 | faster firefox | issue2504 | 14 | Page Request | 20 | 2 | 4 | 2 | 78.57 | firefox | issue2504 | 14 | Rendering | 20 | 471 | 279 | -192 | -40.79 | faster firefox | issue2504 | 15 | Overall | 20 | 860 | 618 | -241 | -28.05 | faster firefox | issue2504 | 15 | Page Request | 20 | 2 | 3 | 0 | 10.87 | firefox | issue2504 | 15 | Rendering | 20 | 857 | 616 | -241 | -28.15 | faster firefox | issue2504 | 16 | Overall | 20 | 389 | 243 | -147 | -37.71 | faster firefox | issue2504 | 16 | Page Request | 20 | 2 | 2 | 0 | 2.33 | firefox | issue2504 | 16 | Rendering | 20 | 387 | 240 | -147 | -37.94 | faster firefox | issue2504 | 17 | Overall | 20 | 1484 | 672 | -812 | -54.70 | faster firefox | issue2504 | 17 | Page Request | 20 | 2 | 3 | 1 | 37.21 | firefox | issue2504 | 17 | Rendering | 20 | 1482 | 669 | -812 | -54.84 | faster firefox | issue2504 | 18 | Overall | 20 | 575 | 252 | -323 | -56.12 | faster firefox | issue2504 | 18 | Page Request | 20 | 2 | 2 | 0 | -16.22 | firefox | issue2504 | 18 | Rendering | 20 | 573 | 251 | -322 | -56.24 | faster firefox | issue2504 | 19 | Overall | 20 | 517 | 227 | -290 | -56.08 | faster firefox | issue2504 | 19 | Page Request | 20 | 2 | 2 | 0 | 21.62 | firefox | issue2504 | 19 | Rendering | 20 | 515 | 225 | -290 | -56.37 | faster firefox | issue2504 | 20 | Overall | 20 | 668 | 670 | 2 | 0.31 | firefox | issue2504 | 20 | Page Request | 20 | 4 | 2 | -1 | -34.29 | firefox | issue2504 | 20 | Rendering | 20 | 664 | 667 | 3 | 0.49 | firefox | issue2504 | 21 | Overall | 20 | 486 | 309 | -177 | -36.44 | faster firefox | issue2504 | 21 | Page Request | 20 | 2 | 2 | 0 | 16.13 | firefox | issue2504 | 21 | Rendering | 20 | 484 | 307 | -177 | -36.60 | faster firefox | issue2504 | 22 | Overall | 20 | 543 | 267 | -276 | -50.85 | faster firefox | issue2504 | 22 | Page Request | 20 | 2 | 2 | 0 | 10.26 | firefox | issue2504 | 22 | Rendering | 20 | 541 | 265 | -276 | -51.07 | faster firefox | issue2504 | 23 | Overall | 20 | 3246 | 871 | -2375 | -73.17 | faster firefox | issue2504 | 23 | Page Request | 20 | 2 | 3 | 1 | 37.21 | firefox | issue2504 | 23 | Rendering | 20 | 3243 | 868 | -2376 | -73.25 | faster firefox | issue2504 | 24 | Overall | 20 | 379 | 156 | -223 | -58.83 | faster firefox | issue2504 | 24 | Page Request | 20 | 2 | 2 | 0 | -2.86 | firefox | issue2504 | 24 | Rendering | 20 | 378 | 154 | -223 | -59.10 | faster firefox | issue2504 | 25 | Overall | 20 | 176 | 127 | -50 | -28.19 | faster firefox | issue2504 | 25 | Page Request | 20 | 2 | 1 | 0 | -15.63 | firefox | issue2504 | 25 | Rendering | 20 | 175 | 125 | -49 | -28.31 | faster firefox | issue2504 | 26 | Overall | 20 | 181 | 108 | -74 | -40.67 | faster firefox | issue2504 | 26 | Page Request | 20 | 3 | 2 | -1 | -39.13 | faster firefox | issue2504 | 26 | Rendering | 20 | 178 | 105 | -72 | -40.69 | faster firefox | issue2504 | 27 | Overall | 20 | 208 | 104 | -104 | -49.92 | faster firefox | issue2504 | 27 | Page Request | 20 | 2 | 2 | 1 | 48.39 | firefox | issue2504 | 27 | Rendering | 20 | 206 | 102 | -104 | -50.64 | faster firefox | issue2504 | 28 | Overall | 20 | 241 | 111 | -131 | -54.16 | faster firefox | issue2504 | 28 | Page Request | 20 | 2 | 2 | -1 | -33.33 | firefox | issue2504 | 28 | Rendering | 20 | 239 | 109 | -130 | -54.39 | faster firefox | issue2504 | 29 | Overall | 20 | 321 | 196 | -125 | -39.05 | faster firefox | issue2504 | 29 | Page Request | 20 | 1 | 2 | 0 | 17.86 | firefox | issue2504 | 29 | Rendering | 20 | 319 | 194 | -126 | -39.35 | faster firefox | issue2504 | 30 | Overall | 20 | 651 | 271 | -380 | -58.41 | faster firefox | issue2504 | 30 | Page Request | 20 | 1 | 2 | 1 | 50.00 | firefox | issue2504 | 30 | Rendering | 20 | 649 | 269 | -381 | -58.60 | faster firefox | issue2504 | 31 | Overall | 20 | 1635 | 647 | -988 | -60.42 | faster firefox | issue2504 | 31 | Page Request | 20 | 1 | 2 | 0 | 30.43 | firefox | issue2504 | 31 | Rendering | 20 | 1634 | 645 | -988 | -60.49 | faster firefox | tracemonkey | 0 | Overall | 100 | 51 | 51 | 0 | 0.02 | firefox | tracemonkey | 0 | Page Request | 100 | 1 | 1 | 0 | -4.76 | firefox | tracemonkey | 0 | Rendering | 100 | 50 | 50 | 0 | 0.12 | firefox | tracemonkey | 1 | Overall | 100 | 97 | 91 | -5 | -5.52 | faster firefox | tracemonkey | 1 | Page Request | 100 | 3 | 3 | 0 | -1.32 | firefox | tracemonkey | 1 | Rendering | 100 | 94 | 88 | -5 | -5.73 | faster firefox | tracemonkey | 2 | Overall | 100 | 40 | 40 | 0 | 0.50 | firefox | tracemonkey | 2 | Page Request | 100 | 1 | 1 | 0 | 3.16 | firefox | tracemonkey | 2 | Rendering | 100 | 39 | 39 | 0 | 0.54 | firefox | tracemonkey | 3 | Overall | 100 | 62 | 62 | -1 | -0.94 | firefox | tracemonkey | 3 | Page Request | 100 | 1 | 1 | 0 | 17.05 | firefox | tracemonkey | 3 | Rendering | 100 | 61 | 61 | -1 | -1.11 | firefox | tracemonkey | 4 | Overall | 100 | 56 | 58 | 2 | 3.41 | firefox | tracemonkey | 4 | Page Request | 100 | 1 | 1 | 0 | 15.31 | firefox | tracemonkey | 4 | Rendering | 100 | 55 | 57 | 2 | 3.23 | firefox | tracemonkey | 5 | Overall | 100 | 73 | 71 | -2 | -2.28 | firefox | tracemonkey | 5 | Page Request | 100 | 2 | 2 | 0 | 12.20 | firefox | tracemonkey | 5 | Rendering | 100 | 71 | 69 | -2 | -2.69 | firefox | tracemonkey | 6 | Overall | 100 | 85 | 69 | -16 | -18.73 | faster firefox | tracemonkey | 6 | Page Request | 100 | 2 | 2 | 0 | -9.90 | firefox | tracemonkey | 6 | Rendering | 100 | 83 | 67 | -16 | -18.97 | faster firefox | tracemonkey | 7 | Overall | 100 | 65 | 64 | 0 | -0.37 | firefox | tracemonkey | 7 | Page Request | 100 | 1 | 1 | 0 | -11.94 | firefox | tracemonkey | 7 | Rendering | 100 | 63 | 63 | 0 | -0.05 | firefox | tracemonkey | 8 | Overall | 100 | 53 | 54 | 1 | 2.04 | firefox | tracemonkey | 8 | Page Request | 100 | 1 | 1 | 0 | 17.02 | firefox | tracemonkey | 8 | Rendering | 100 | 52 | 53 | 1 | 1.82 | firefox | tracemonkey | 9 | Overall | 100 | 79 | 73 | -6 | -7.86 | faster firefox | tracemonkey | 9 | Page Request | 100 | 2 | 2 | 0 | -15.14 | firefox | tracemonkey | 9 | Rendering | 100 | 77 | 71 | -6 | -7.86 | faster firefox | tracemonkey | 10 | Overall | 100 | 545 | 519 | -27 | -4.86 | faster firefox | tracemonkey | 10 | Page Request | 100 | 14 | 13 | 0 | -3.56 | firefox | tracemonkey | 10 | Rendering | 100 | 532 | 506 | -26 | -4.90 | faster firefox | tracemonkey | 11 | Overall | 100 | 42 | 41 | -1 | -2.50 | firefox | tracemonkey | 11 | Page Request | 100 | 1 | 1 | 0 | -27.42 | faster firefox | tracemonkey | 11 | Rendering | 100 | 41 | 40 | -1 | -1.75 | firefox | tracemonkey | 12 | Overall | 100 | 350 | 332 | -18 | -5.16 | faster firefox | tracemonkey | 12 | Page Request | 100 | 3 | 3 | 0 | -5.17 | firefox | tracemonkey | 12 | Rendering | 100 | 347 | 329 | -18 | -5.15 | faster firefox | tracemonkey | 13 | Overall | 100 | 31 | 31 | 0 | 0.52 | firefox | tracemonkey | 13 | Page Request | 100 | 1 | 1 | 0 | 4.95 | firefox | tracemonkey | 13 | Rendering | 100 | 30 | 30 | 0 | 0.20 | ```
2020-06-13 21:12:40 +09:00
case OPS.setFillColorSpace: {
const localColorSpace =
args[0] instanceof Name &&
localColorSpaceCache.getByName(args[0].name);
if (localColorSpace) {
stateManager.state.fillColorSpace = localColorSpace;
continue;
}
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
next(
self
.parseColorSpace({
cs: args[0],
resources,
Add local caching of `ColorSpace`s, by name, in `PartialEvaluator.getOperatorList` (issue 2504) By caching parsed `ColorSpace`s, we thus don't need to re-parse the same data over and over which saves CPU cycles *and* reduces peak memory usage. (Obviously persistent memory usage *may* increase a tiny bit, but since the caching is done per `PartialEvaluator.getOperatorList` invocation and given that `ColorSpace` instances generally hold very little data this shouldn't be much of an issue.) Furthermore, by caching `ColorSpace`s we can also lookup the already parsed ones *synchronously* during the `OperatorList` building, instead of having to defer to the event loop/microtask queue since the parsing is done asynchronously (such that error handling is easier). Possible future improvements: - Cache/lookup parsed `ColorSpaces` used in `Pattern`s and `Image`s. - Attempt to cache *local* `ColorSpace`s by reference as well, in addition to only by name, assuming that there's documents where that would be beneficial and that it's not too difficult to implement. - Assuming there's documents that would benefit from it, also cache repeated `ColorSpace`s *globally* as well. Given that we've never, until now, been doing *any* caching of parsed `ColorSpace`s and that even using a simple name-only *local* cache helps tremendously in pathological cases, I purposely decided against complicating the implementation too much initially. Also, compared to parsing of `Image`s, simply creating a `ColorSpace` instance isn't that expensive (hence I'd be somewhat surprised if adding a *global* cache would help much). --- This patch was tested using: - The default `tracemonkey` PDF file, which was included mostly to show that "normal" documents aren't negatively affected by these changes. - The PDF file from issue 2504, i.e. https://dl-ctlg.panasonic.com/jp/manual/sd/sd_rbm1000_0.pdf, where most pages will switch *thousands* of times between a handful of `ColorSpace`s. with the following manifest file: ``` [ { "id": "tracemonkey", "file": "pdfs/tracemonkey.pdf", "md5": "9a192d8b1a7dc652a19835f6f08098bd", "rounds": 100, "type": "eq" }, { "id": "issue2504", "file": "../web/pdfs/issue2504.pdf", "md5": "", "rounds": 20, "type": "eq" } ] ``` which gave the following results when comparing this patch against the `master` branch: - Overall ``` -- Grouped By browser, pdf, stat -- browser | pdf | stat | Count | Baseline(ms) | Current(ms) | +/- | % | Result(P<.05) ------- | ----------- | ------------ | ----- | ------------ | ----------- | ---- | ------ | ------------- firefox | issue2504 | Overall | 640 | 977 | 497 | -479 | -49.08 | faster firefox | issue2504 | Page Request | 640 | 3 | 4 | 1 | 59.18 | firefox | issue2504 | Rendering | 640 | 974 | 493 | -481 | -49.37 | faster firefox | tracemonkey | Overall | 1400 | 116 | 111 | -5 | -4.43 | firefox | tracemonkey | Page Request | 1400 | 2 | 2 | 0 | -2.86 | firefox | tracemonkey | Rendering | 1400 | 114 | 109 | -5 | -4.47 | ``` - Page-specific ``` -- Grouped By browser, pdf, page, stat -- browser | pdf | page | stat | Count | Baseline(ms) | Current(ms) | +/- | % | Result(P<.05) ------- | ----------- | ---- | ------------ | ----- | ------------ | ----------- | ----- | ------- | ------------- firefox | issue2504 | 0 | Overall | 20 | 2295 | 1268 | -1027 | -44.76 | faster firefox | issue2504 | 0 | Page Request | 20 | 6 | 7 | 1 | 15.32 | firefox | issue2504 | 0 | Rendering | 20 | 2288 | 1260 | -1028 | -44.93 | faster firefox | issue2504 | 1 | Overall | 20 | 3059 | 2806 | -252 | -8.25 | faster firefox | issue2504 | 1 | Page Request | 20 | 11 | 14 | 3 | 23.25 | slower firefox | issue2504 | 1 | Rendering | 20 | 3047 | 2792 | -255 | -8.37 | faster firefox | issue2504 | 2 | Overall | 20 | 411 | 295 | -116 | -28.20 | faster firefox | issue2504 | 2 | Page Request | 20 | 2 | 42 | 40 | 1897.62 | firefox | issue2504 | 2 | Rendering | 20 | 409 | 253 | -156 | -38.09 | faster firefox | issue2504 | 3 | Overall | 20 | 736 | 299 | -437 | -59.34 | faster firefox | issue2504 | 3 | Page Request | 20 | 2 | 2 | 0 | 0.00 | firefox | issue2504 | 3 | Rendering | 20 | 734 | 297 | -437 | -59.49 | faster firefox | issue2504 | 4 | Overall | 20 | 356 | 458 | 102 | 28.63 | firefox | issue2504 | 4 | Page Request | 20 | 1 | 2 | 1 | 57.14 | slower firefox | issue2504 | 4 | Rendering | 20 | 354 | 455 | 101 | 28.53 | firefox | issue2504 | 5 | Overall | 20 | 1381 | 765 | -616 | -44.59 | faster firefox | issue2504 | 5 | Page Request | 20 | 3 | 5 | 2 | 50.00 | slower firefox | issue2504 | 5 | Rendering | 20 | 1378 | 760 | -617 | -44.81 | faster firefox | issue2504 | 6 | Overall | 20 | 757 | 299 | -459 | -60.57 | faster firefox | issue2504 | 6 | Page Request | 20 | 2 | 5 | 3 | 150.00 | slower firefox | issue2504 | 6 | Rendering | 20 | 755 | 294 | -462 | -61.11 | faster firefox | issue2504 | 7 | Overall | 20 | 394 | 302 | -92 | -23.39 | faster firefox | issue2504 | 7 | Page Request | 20 | 2 | 1 | -1 | -34.88 | faster firefox | issue2504 | 7 | Rendering | 20 | 392 | 301 | -91 | -23.32 | faster firefox | issue2504 | 8 | Overall | 20 | 2875 | 979 | -1896 | -65.95 | faster firefox | issue2504 | 8 | Page Request | 20 | 1 | 2 | 0 | 11.11 | firefox | issue2504 | 8 | Rendering | 20 | 2874 | 978 | -1896 | -65.99 | faster firefox | issue2504 | 9 | Overall | 20 | 700 | 332 | -368 | -52.60 | faster firefox | issue2504 | 9 | Page Request | 20 | 3 | 2 | 0 | -4.00 | firefox | issue2504 | 9 | Rendering | 20 | 698 | 329 | -368 | -52.78 | faster firefox | issue2504 | 10 | Overall | 20 | 3296 | 926 | -2370 | -71.91 | faster firefox | issue2504 | 10 | Page Request | 20 | 2 | 2 | 0 | -18.75 | firefox | issue2504 | 10 | Rendering | 20 | 3293 | 924 | -2370 | -71.96 | faster firefox | issue2504 | 11 | Overall | 20 | 524 | 197 | -327 | -62.34 | faster firefox | issue2504 | 11 | Page Request | 20 | 2 | 3 | 1 | 58.54 | firefox | issue2504 | 11 | Rendering | 20 | 522 | 194 | -328 | -62.81 | faster firefox | issue2504 | 12 | Overall | 20 | 752 | 369 | -384 | -50.98 | faster firefox | issue2504 | 12 | Page Request | 20 | 3 | 2 | -1 | -36.51 | faster firefox | issue2504 | 12 | Rendering | 20 | 749 | 367 | -382 | -51.05 | faster firefox | issue2504 | 13 | Overall | 20 | 679 | 487 | -193 | -28.38 | faster firefox | issue2504 | 13 | Page Request | 20 | 4 | 2 | -2 | -48.68 | faster firefox | issue2504 | 13 | Rendering | 20 | 676 | 485 | -191 | -28.28 | faster firefox | issue2504 | 14 | Overall | 20 | 474 | 283 | -191 | -40.26 | faster firefox | issue2504 | 14 | Page Request | 20 | 2 | 4 | 2 | 78.57 | firefox | issue2504 | 14 | Rendering | 20 | 471 | 279 | -192 | -40.79 | faster firefox | issue2504 | 15 | Overall | 20 | 860 | 618 | -241 | -28.05 | faster firefox | issue2504 | 15 | Page Request | 20 | 2 | 3 | 0 | 10.87 | firefox | issue2504 | 15 | Rendering | 20 | 857 | 616 | -241 | -28.15 | faster firefox | issue2504 | 16 | Overall | 20 | 389 | 243 | -147 | -37.71 | faster firefox | issue2504 | 16 | Page Request | 20 | 2 | 2 | 0 | 2.33 | firefox | issue2504 | 16 | Rendering | 20 | 387 | 240 | -147 | -37.94 | faster firefox | issue2504 | 17 | Overall | 20 | 1484 | 672 | -812 | -54.70 | faster firefox | issue2504 | 17 | Page Request | 20 | 2 | 3 | 1 | 37.21 | firefox | issue2504 | 17 | Rendering | 20 | 1482 | 669 | -812 | -54.84 | faster firefox | issue2504 | 18 | Overall | 20 | 575 | 252 | -323 | -56.12 | faster firefox | issue2504 | 18 | Page Request | 20 | 2 | 2 | 0 | -16.22 | firefox | issue2504 | 18 | Rendering | 20 | 573 | 251 | -322 | -56.24 | faster firefox | issue2504 | 19 | Overall | 20 | 517 | 227 | -290 | -56.08 | faster firefox | issue2504 | 19 | Page Request | 20 | 2 | 2 | 0 | 21.62 | firefox | issue2504 | 19 | Rendering | 20 | 515 | 225 | -290 | -56.37 | faster firefox | issue2504 | 20 | Overall | 20 | 668 | 670 | 2 | 0.31 | firefox | issue2504 | 20 | Page Request | 20 | 4 | 2 | -1 | -34.29 | firefox | issue2504 | 20 | Rendering | 20 | 664 | 667 | 3 | 0.49 | firefox | issue2504 | 21 | Overall | 20 | 486 | 309 | -177 | -36.44 | faster firefox | issue2504 | 21 | Page Request | 20 | 2 | 2 | 0 | 16.13 | firefox | issue2504 | 21 | Rendering | 20 | 484 | 307 | -177 | -36.60 | faster firefox | issue2504 | 22 | Overall | 20 | 543 | 267 | -276 | -50.85 | faster firefox | issue2504 | 22 | Page Request | 20 | 2 | 2 | 0 | 10.26 | firefox | issue2504 | 22 | Rendering | 20 | 541 | 265 | -276 | -51.07 | faster firefox | issue2504 | 23 | Overall | 20 | 3246 | 871 | -2375 | -73.17 | faster firefox | issue2504 | 23 | Page Request | 20 | 2 | 3 | 1 | 37.21 | firefox | issue2504 | 23 | Rendering | 20 | 3243 | 868 | -2376 | -73.25 | faster firefox | issue2504 | 24 | Overall | 20 | 379 | 156 | -223 | -58.83 | faster firefox | issue2504 | 24 | Page Request | 20 | 2 | 2 | 0 | -2.86 | firefox | issue2504 | 24 | Rendering | 20 | 378 | 154 | -223 | -59.10 | faster firefox | issue2504 | 25 | Overall | 20 | 176 | 127 | -50 | -28.19 | faster firefox | issue2504 | 25 | Page Request | 20 | 2 | 1 | 0 | -15.63 | firefox | issue2504 | 25 | Rendering | 20 | 175 | 125 | -49 | -28.31 | faster firefox | issue2504 | 26 | Overall | 20 | 181 | 108 | -74 | -40.67 | faster firefox | issue2504 | 26 | Page Request | 20 | 3 | 2 | -1 | -39.13 | faster firefox | issue2504 | 26 | Rendering | 20 | 178 | 105 | -72 | -40.69 | faster firefox | issue2504 | 27 | Overall | 20 | 208 | 104 | -104 | -49.92 | faster firefox | issue2504 | 27 | Page Request | 20 | 2 | 2 | 1 | 48.39 | firefox | issue2504 | 27 | Rendering | 20 | 206 | 102 | -104 | -50.64 | faster firefox | issue2504 | 28 | Overall | 20 | 241 | 111 | -131 | -54.16 | faster firefox | issue2504 | 28 | Page Request | 20 | 2 | 2 | -1 | -33.33 | firefox | issue2504 | 28 | Rendering | 20 | 239 | 109 | -130 | -54.39 | faster firefox | issue2504 | 29 | Overall | 20 | 321 | 196 | -125 | -39.05 | faster firefox | issue2504 | 29 | Page Request | 20 | 1 | 2 | 0 | 17.86 | firefox | issue2504 | 29 | Rendering | 20 | 319 | 194 | -126 | -39.35 | faster firefox | issue2504 | 30 | Overall | 20 | 651 | 271 | -380 | -58.41 | faster firefox | issue2504 | 30 | Page Request | 20 | 1 | 2 | 1 | 50.00 | firefox | issue2504 | 30 | Rendering | 20 | 649 | 269 | -381 | -58.60 | faster firefox | issue2504 | 31 | Overall | 20 | 1635 | 647 | -988 | -60.42 | faster firefox | issue2504 | 31 | Page Request | 20 | 1 | 2 | 0 | 30.43 | firefox | issue2504 | 31 | Rendering | 20 | 1634 | 645 | -988 | -60.49 | faster firefox | tracemonkey | 0 | Overall | 100 | 51 | 51 | 0 | 0.02 | firefox | tracemonkey | 0 | Page Request | 100 | 1 | 1 | 0 | -4.76 | firefox | tracemonkey | 0 | Rendering | 100 | 50 | 50 | 0 | 0.12 | firefox | tracemonkey | 1 | Overall | 100 | 97 | 91 | -5 | -5.52 | faster firefox | tracemonkey | 1 | Page Request | 100 | 3 | 3 | 0 | -1.32 | firefox | tracemonkey | 1 | Rendering | 100 | 94 | 88 | -5 | -5.73 | faster firefox | tracemonkey | 2 | Overall | 100 | 40 | 40 | 0 | 0.50 | firefox | tracemonkey | 2 | Page Request | 100 | 1 | 1 | 0 | 3.16 | firefox | tracemonkey | 2 | Rendering | 100 | 39 | 39 | 0 | 0.54 | firefox | tracemonkey | 3 | Overall | 100 | 62 | 62 | -1 | -0.94 | firefox | tracemonkey | 3 | Page Request | 100 | 1 | 1 | 0 | 17.05 | firefox | tracemonkey | 3 | Rendering | 100 | 61 | 61 | -1 | -1.11 | firefox | tracemonkey | 4 | Overall | 100 | 56 | 58 | 2 | 3.41 | firefox | tracemonkey | 4 | Page Request | 100 | 1 | 1 | 0 | 15.31 | firefox | tracemonkey | 4 | Rendering | 100 | 55 | 57 | 2 | 3.23 | firefox | tracemonkey | 5 | Overall | 100 | 73 | 71 | -2 | -2.28 | firefox | tracemonkey | 5 | Page Request | 100 | 2 | 2 | 0 | 12.20 | firefox | tracemonkey | 5 | Rendering | 100 | 71 | 69 | -2 | -2.69 | firefox | tracemonkey | 6 | Overall | 100 | 85 | 69 | -16 | -18.73 | faster firefox | tracemonkey | 6 | Page Request | 100 | 2 | 2 | 0 | -9.90 | firefox | tracemonkey | 6 | Rendering | 100 | 83 | 67 | -16 | -18.97 | faster firefox | tracemonkey | 7 | Overall | 100 | 65 | 64 | 0 | -0.37 | firefox | tracemonkey | 7 | Page Request | 100 | 1 | 1 | 0 | -11.94 | firefox | tracemonkey | 7 | Rendering | 100 | 63 | 63 | 0 | -0.05 | firefox | tracemonkey | 8 | Overall | 100 | 53 | 54 | 1 | 2.04 | firefox | tracemonkey | 8 | Page Request | 100 | 1 | 1 | 0 | 17.02 | firefox | tracemonkey | 8 | Rendering | 100 | 52 | 53 | 1 | 1.82 | firefox | tracemonkey | 9 | Overall | 100 | 79 | 73 | -6 | -7.86 | faster firefox | tracemonkey | 9 | Page Request | 100 | 2 | 2 | 0 | -15.14 | firefox | tracemonkey | 9 | Rendering | 100 | 77 | 71 | -6 | -7.86 | faster firefox | tracemonkey | 10 | Overall | 100 | 545 | 519 | -27 | -4.86 | faster firefox | tracemonkey | 10 | Page Request | 100 | 14 | 13 | 0 | -3.56 | firefox | tracemonkey | 10 | Rendering | 100 | 532 | 506 | -26 | -4.90 | faster firefox | tracemonkey | 11 | Overall | 100 | 42 | 41 | -1 | -2.50 | firefox | tracemonkey | 11 | Page Request | 100 | 1 | 1 | 0 | -27.42 | faster firefox | tracemonkey | 11 | Rendering | 100 | 41 | 40 | -1 | -1.75 | firefox | tracemonkey | 12 | Overall | 100 | 350 | 332 | -18 | -5.16 | faster firefox | tracemonkey | 12 | Page Request | 100 | 3 | 3 | 0 | -5.17 | firefox | tracemonkey | 12 | Rendering | 100 | 347 | 329 | -18 | -5.15 | faster firefox | tracemonkey | 13 | Overall | 100 | 31 | 31 | 0 | 0.52 | firefox | tracemonkey | 13 | Page Request | 100 | 1 | 1 | 0 | 4.95 | firefox | tracemonkey | 13 | Rendering | 100 | 30 | 30 | 0 | 0.20 | ```
2020-06-13 21:12:40 +09:00
localColorSpaceCache,
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
})
Update Prettier to version 2.0 Please note that these changes were done automatically, using `gulp lint --fix`. Given that the major version number was increased, there's a fair number of (primarily whitespace) changes; please see https://prettier.io/blog/2020/03/21/2.0.0.html In order to reduce the size of these changes somewhat, this patch maintains the old "arrowParens" style for now (once mozilla-central updates Prettier we can simply choose the same formatting, assuming it will differ here).
2020-04-14 19:28:14 +09:00
.then(function (colorSpace) {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
if (colorSpace) {
stateManager.state.fillColorSpace = colorSpace;
}
})
);
Allow skipping of errors when parsing broken/unsupported ColorSpaces (issue 6707, issue 11287) This will allow us to attempt to recover as much as possible of a page, rather than immediately failing, when a broken/unsupported ColorSpace is encountered. This patch thus extends the framework added in PRs such as e.g. 8240 and 8922, to also cover parsing of ColorSpaces.
2019-10-31 23:53:51 +09:00
return;
Add local caching of `ColorSpace`s, by name, in `PartialEvaluator.getOperatorList` (issue 2504) By caching parsed `ColorSpace`s, we thus don't need to re-parse the same data over and over which saves CPU cycles *and* reduces peak memory usage. (Obviously persistent memory usage *may* increase a tiny bit, but since the caching is done per `PartialEvaluator.getOperatorList` invocation and given that `ColorSpace` instances generally hold very little data this shouldn't be much of an issue.) Furthermore, by caching `ColorSpace`s we can also lookup the already parsed ones *synchronously* during the `OperatorList` building, instead of having to defer to the event loop/microtask queue since the parsing is done asynchronously (such that error handling is easier). Possible future improvements: - Cache/lookup parsed `ColorSpaces` used in `Pattern`s and `Image`s. - Attempt to cache *local* `ColorSpace`s by reference as well, in addition to only by name, assuming that there's documents where that would be beneficial and that it's not too difficult to implement. - Assuming there's documents that would benefit from it, also cache repeated `ColorSpace`s *globally* as well. Given that we've never, until now, been doing *any* caching of parsed `ColorSpace`s and that even using a simple name-only *local* cache helps tremendously in pathological cases, I purposely decided against complicating the implementation too much initially. Also, compared to parsing of `Image`s, simply creating a `ColorSpace` instance isn't that expensive (hence I'd be somewhat surprised if adding a *global* cache would help much). --- This patch was tested using: - The default `tracemonkey` PDF file, which was included mostly to show that "normal" documents aren't negatively affected by these changes. - The PDF file from issue 2504, i.e. https://dl-ctlg.panasonic.com/jp/manual/sd/sd_rbm1000_0.pdf, where most pages will switch *thousands* of times between a handful of `ColorSpace`s. with the following manifest file: ``` [ { "id": "tracemonkey", "file": "pdfs/tracemonkey.pdf", "md5": "9a192d8b1a7dc652a19835f6f08098bd", "rounds": 100, "type": "eq" }, { "id": "issue2504", "file": "../web/pdfs/issue2504.pdf", "md5": "", "rounds": 20, "type": "eq" } ] ``` which gave the following results when comparing this patch against the `master` branch: - Overall ``` -- Grouped By browser, pdf, stat -- browser | pdf | stat | Count | Baseline(ms) | Current(ms) | +/- | % | Result(P<.05) ------- | ----------- | ------------ | ----- | ------------ | ----------- | ---- | ------ | ------------- firefox | issue2504 | Overall | 640 | 977 | 497 | -479 | -49.08 | faster firefox | issue2504 | Page Request | 640 | 3 | 4 | 1 | 59.18 | firefox | issue2504 | Rendering | 640 | 974 | 493 | -481 | -49.37 | faster firefox | tracemonkey | Overall | 1400 | 116 | 111 | -5 | -4.43 | firefox | tracemonkey | Page Request | 1400 | 2 | 2 | 0 | -2.86 | firefox | tracemonkey | Rendering | 1400 | 114 | 109 | -5 | -4.47 | ``` - Page-specific ``` -- Grouped By browser, pdf, page, stat -- browser | pdf | page | stat | Count | Baseline(ms) | Current(ms) | +/- | % | Result(P<.05) ------- | ----------- | ---- | ------------ | ----- | ------------ | ----------- | ----- | ------- | ------------- firefox | issue2504 | 0 | Overall | 20 | 2295 | 1268 | -1027 | -44.76 | faster firefox | issue2504 | 0 | Page Request | 20 | 6 | 7 | 1 | 15.32 | firefox | issue2504 | 0 | Rendering | 20 | 2288 | 1260 | -1028 | -44.93 | faster firefox | issue2504 | 1 | Overall | 20 | 3059 | 2806 | -252 | -8.25 | faster firefox | issue2504 | 1 | Page Request | 20 | 11 | 14 | 3 | 23.25 | slower firefox | issue2504 | 1 | Rendering | 20 | 3047 | 2792 | -255 | -8.37 | faster firefox | issue2504 | 2 | Overall | 20 | 411 | 295 | -116 | -28.20 | faster firefox | issue2504 | 2 | Page Request | 20 | 2 | 42 | 40 | 1897.62 | firefox | issue2504 | 2 | Rendering | 20 | 409 | 253 | -156 | -38.09 | faster firefox | issue2504 | 3 | Overall | 20 | 736 | 299 | -437 | -59.34 | faster firefox | issue2504 | 3 | Page Request | 20 | 2 | 2 | 0 | 0.00 | firefox | issue2504 | 3 | Rendering | 20 | 734 | 297 | -437 | -59.49 | faster firefox | issue2504 | 4 | Overall | 20 | 356 | 458 | 102 | 28.63 | firefox | issue2504 | 4 | Page Request | 20 | 1 | 2 | 1 | 57.14 | slower firefox | issue2504 | 4 | Rendering | 20 | 354 | 455 | 101 | 28.53 | firefox | issue2504 | 5 | Overall | 20 | 1381 | 765 | -616 | -44.59 | faster firefox | issue2504 | 5 | Page Request | 20 | 3 | 5 | 2 | 50.00 | slower firefox | issue2504 | 5 | Rendering | 20 | 1378 | 760 | -617 | -44.81 | faster firefox | issue2504 | 6 | Overall | 20 | 757 | 299 | -459 | -60.57 | faster firefox | issue2504 | 6 | Page Request | 20 | 2 | 5 | 3 | 150.00 | slower firefox | issue2504 | 6 | Rendering | 20 | 755 | 294 | -462 | -61.11 | faster firefox | issue2504 | 7 | Overall | 20 | 394 | 302 | -92 | -23.39 | faster firefox | issue2504 | 7 | Page Request | 20 | 2 | 1 | -1 | -34.88 | faster firefox | issue2504 | 7 | Rendering | 20 | 392 | 301 | -91 | -23.32 | faster firefox | issue2504 | 8 | Overall | 20 | 2875 | 979 | -1896 | -65.95 | faster firefox | issue2504 | 8 | Page Request | 20 | 1 | 2 | 0 | 11.11 | firefox | issue2504 | 8 | Rendering | 20 | 2874 | 978 | -1896 | -65.99 | faster firefox | issue2504 | 9 | Overall | 20 | 700 | 332 | -368 | -52.60 | faster firefox | issue2504 | 9 | Page Request | 20 | 3 | 2 | 0 | -4.00 | firefox | issue2504 | 9 | Rendering | 20 | 698 | 329 | -368 | -52.78 | faster firefox | issue2504 | 10 | Overall | 20 | 3296 | 926 | -2370 | -71.91 | faster firefox | issue2504 | 10 | Page Request | 20 | 2 | 2 | 0 | -18.75 | firefox | issue2504 | 10 | Rendering | 20 | 3293 | 924 | -2370 | -71.96 | faster firefox | issue2504 | 11 | Overall | 20 | 524 | 197 | -327 | -62.34 | faster firefox | issue2504 | 11 | Page Request | 20 | 2 | 3 | 1 | 58.54 | firefox | issue2504 | 11 | Rendering | 20 | 522 | 194 | -328 | -62.81 | faster firefox | issue2504 | 12 | Overall | 20 | 752 | 369 | -384 | -50.98 | faster firefox | issue2504 | 12 | Page Request | 20 | 3 | 2 | -1 | -36.51 | faster firefox | issue2504 | 12 | Rendering | 20 | 749 | 367 | -382 | -51.05 | faster firefox | issue2504 | 13 | Overall | 20 | 679 | 487 | -193 | -28.38 | faster firefox | issue2504 | 13 | Page Request | 20 | 4 | 2 | -2 | -48.68 | faster firefox | issue2504 | 13 | Rendering | 20 | 676 | 485 | -191 | -28.28 | faster firefox | issue2504 | 14 | Overall | 20 | 474 | 283 | -191 | -40.26 | faster firefox | issue2504 | 14 | Page Request | 20 | 2 | 4 | 2 | 78.57 | firefox | issue2504 | 14 | Rendering | 20 | 471 | 279 | -192 | -40.79 | faster firefox | issue2504 | 15 | Overall | 20 | 860 | 618 | -241 | -28.05 | faster firefox | issue2504 | 15 | Page Request | 20 | 2 | 3 | 0 | 10.87 | firefox | issue2504 | 15 | Rendering | 20 | 857 | 616 | -241 | -28.15 | faster firefox | issue2504 | 16 | Overall | 20 | 389 | 243 | -147 | -37.71 | faster firefox | issue2504 | 16 | Page Request | 20 | 2 | 2 | 0 | 2.33 | firefox | issue2504 | 16 | Rendering | 20 | 387 | 240 | -147 | -37.94 | faster firefox | issue2504 | 17 | Overall | 20 | 1484 | 672 | -812 | -54.70 | faster firefox | issue2504 | 17 | Page Request | 20 | 2 | 3 | 1 | 37.21 | firefox | issue2504 | 17 | Rendering | 20 | 1482 | 669 | -812 | -54.84 | faster firefox | issue2504 | 18 | Overall | 20 | 575 | 252 | -323 | -56.12 | faster firefox | issue2504 | 18 | Page Request | 20 | 2 | 2 | 0 | -16.22 | firefox | issue2504 | 18 | Rendering | 20 | 573 | 251 | -322 | -56.24 | faster firefox | issue2504 | 19 | Overall | 20 | 517 | 227 | -290 | -56.08 | faster firefox | issue2504 | 19 | Page Request | 20 | 2 | 2 | 0 | 21.62 | firefox | issue2504 | 19 | Rendering | 20 | 515 | 225 | -290 | -56.37 | faster firefox | issue2504 | 20 | Overall | 20 | 668 | 670 | 2 | 0.31 | firefox | issue2504 | 20 | Page Request | 20 | 4 | 2 | -1 | -34.29 | firefox | issue2504 | 20 | Rendering | 20 | 664 | 667 | 3 | 0.49 | firefox | issue2504 | 21 | Overall | 20 | 486 | 309 | -177 | -36.44 | faster firefox | issue2504 | 21 | Page Request | 20 | 2 | 2 | 0 | 16.13 | firefox | issue2504 | 21 | Rendering | 20 | 484 | 307 | -177 | -36.60 | faster firefox | issue2504 | 22 | Overall | 20 | 543 | 267 | -276 | -50.85 | faster firefox | issue2504 | 22 | Page Request | 20 | 2 | 2 | 0 | 10.26 | firefox | issue2504 | 22 | Rendering | 20 | 541 | 265 | -276 | -51.07 | faster firefox | issue2504 | 23 | Overall | 20 | 3246 | 871 | -2375 | -73.17 | faster firefox | issue2504 | 23 | Page Request | 20 | 2 | 3 | 1 | 37.21 | firefox | issue2504 | 23 | Rendering | 20 | 3243 | 868 | -2376 | -73.25 | faster firefox | issue2504 | 24 | Overall | 20 | 379 | 156 | -223 | -58.83 | faster firefox | issue2504 | 24 | Page Request | 20 | 2 | 2 | 0 | -2.86 | firefox | issue2504 | 24 | Rendering | 20 | 378 | 154 | -223 | -59.10 | faster firefox | issue2504 | 25 | Overall | 20 | 176 | 127 | -50 | -28.19 | faster firefox | issue2504 | 25 | Page Request | 20 | 2 | 1 | 0 | -15.63 | firefox | issue2504 | 25 | Rendering | 20 | 175 | 125 | -49 | -28.31 | faster firefox | issue2504 | 26 | Overall | 20 | 181 | 108 | -74 | -40.67 | faster firefox | issue2504 | 26 | Page Request | 20 | 3 | 2 | -1 | -39.13 | faster firefox | issue2504 | 26 | Rendering | 20 | 178 | 105 | -72 | -40.69 | faster firefox | issue2504 | 27 | Overall | 20 | 208 | 104 | -104 | -49.92 | faster firefox | issue2504 | 27 | Page Request | 20 | 2 | 2 | 1 | 48.39 | firefox | issue2504 | 27 | Rendering | 20 | 206 | 102 | -104 | -50.64 | faster firefox | issue2504 | 28 | Overall | 20 | 241 | 111 | -131 | -54.16 | faster firefox | issue2504 | 28 | Page Request | 20 | 2 | 2 | -1 | -33.33 | firefox | issue2504 | 28 | Rendering | 20 | 239 | 109 | -130 | -54.39 | faster firefox | issue2504 | 29 | Overall | 20 | 321 | 196 | -125 | -39.05 | faster firefox | issue2504 | 29 | Page Request | 20 | 1 | 2 | 0 | 17.86 | firefox | issue2504 | 29 | Rendering | 20 | 319 | 194 | -126 | -39.35 | faster firefox | issue2504 | 30 | Overall | 20 | 651 | 271 | -380 | -58.41 | faster firefox | issue2504 | 30 | Page Request | 20 | 1 | 2 | 1 | 50.00 | firefox | issue2504 | 30 | Rendering | 20 | 649 | 269 | -381 | -58.60 | faster firefox | issue2504 | 31 | Overall | 20 | 1635 | 647 | -988 | -60.42 | faster firefox | issue2504 | 31 | Page Request | 20 | 1 | 2 | 0 | 30.43 | firefox | issue2504 | 31 | Rendering | 20 | 1634 | 645 | -988 | -60.49 | faster firefox | tracemonkey | 0 | Overall | 100 | 51 | 51 | 0 | 0.02 | firefox | tracemonkey | 0 | Page Request | 100 | 1 | 1 | 0 | -4.76 | firefox | tracemonkey | 0 | Rendering | 100 | 50 | 50 | 0 | 0.12 | firefox | tracemonkey | 1 | Overall | 100 | 97 | 91 | -5 | -5.52 | faster firefox | tracemonkey | 1 | Page Request | 100 | 3 | 3 | 0 | -1.32 | firefox | tracemonkey | 1 | Rendering | 100 | 94 | 88 | -5 | -5.73 | faster firefox | tracemonkey | 2 | Overall | 100 | 40 | 40 | 0 | 0.50 | firefox | tracemonkey | 2 | Page Request | 100 | 1 | 1 | 0 | 3.16 | firefox | tracemonkey | 2 | Rendering | 100 | 39 | 39 | 0 | 0.54 | firefox | tracemonkey | 3 | Overall | 100 | 62 | 62 | -1 | -0.94 | firefox | tracemonkey | 3 | Page Request | 100 | 1 | 1 | 0 | 17.05 | firefox | tracemonkey | 3 | Rendering | 100 | 61 | 61 | -1 | -1.11 | firefox | tracemonkey | 4 | Overall | 100 | 56 | 58 | 2 | 3.41 | firefox | tracemonkey | 4 | Page Request | 100 | 1 | 1 | 0 | 15.31 | firefox | tracemonkey | 4 | Rendering | 100 | 55 | 57 | 2 | 3.23 | firefox | tracemonkey | 5 | Overall | 100 | 73 | 71 | -2 | -2.28 | firefox | tracemonkey | 5 | Page Request | 100 | 2 | 2 | 0 | 12.20 | firefox | tracemonkey | 5 | Rendering | 100 | 71 | 69 | -2 | -2.69 | firefox | tracemonkey | 6 | Overall | 100 | 85 | 69 | -16 | -18.73 | faster firefox | tracemonkey | 6 | Page Request | 100 | 2 | 2 | 0 | -9.90 | firefox | tracemonkey | 6 | Rendering | 100 | 83 | 67 | -16 | -18.97 | faster firefox | tracemonkey | 7 | Overall | 100 | 65 | 64 | 0 | -0.37 | firefox | tracemonkey | 7 | Page Request | 100 | 1 | 1 | 0 | -11.94 | firefox | tracemonkey | 7 | Rendering | 100 | 63 | 63 | 0 | -0.05 | firefox | tracemonkey | 8 | Overall | 100 | 53 | 54 | 1 | 2.04 | firefox | tracemonkey | 8 | Page Request | 100 | 1 | 1 | 0 | 17.02 | firefox | tracemonkey | 8 | Rendering | 100 | 52 | 53 | 1 | 1.82 | firefox | tracemonkey | 9 | Overall | 100 | 79 | 73 | -6 | -7.86 | faster firefox | tracemonkey | 9 | Page Request | 100 | 2 | 2 | 0 | -15.14 | firefox | tracemonkey | 9 | Rendering | 100 | 77 | 71 | -6 | -7.86 | faster firefox | tracemonkey | 10 | Overall | 100 | 545 | 519 | -27 | -4.86 | faster firefox | tracemonkey | 10 | Page Request | 100 | 14 | 13 | 0 | -3.56 | firefox | tracemonkey | 10 | Rendering | 100 | 532 | 506 | -26 | -4.90 | faster firefox | tracemonkey | 11 | Overall | 100 | 42 | 41 | -1 | -2.50 | firefox | tracemonkey | 11 | Page Request | 100 | 1 | 1 | 0 | -27.42 | faster firefox | tracemonkey | 11 | Rendering | 100 | 41 | 40 | -1 | -1.75 | firefox | tracemonkey | 12 | Overall | 100 | 350 | 332 | -18 | -5.16 | faster firefox | tracemonkey | 12 | Page Request | 100 | 3 | 3 | 0 | -5.17 | firefox | tracemonkey | 12 | Rendering | 100 | 347 | 329 | -18 | -5.15 | faster firefox | tracemonkey | 13 | Overall | 100 | 31 | 31 | 0 | 0.52 | firefox | tracemonkey | 13 | Page Request | 100 | 1 | 1 | 0 | 4.95 | firefox | tracemonkey | 13 | Rendering | 100 | 30 | 30 | 0 | 0.20 | ```
2020-06-13 21:12:40 +09:00
}
case OPS.setStrokeColorSpace: {
const localColorSpace =
args[0] instanceof Name &&
localColorSpaceCache.getByName(args[0].name);
if (localColorSpace) {
stateManager.state.strokeColorSpace = localColorSpace;
continue;
}
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
next(
self
.parseColorSpace({
cs: args[0],
resources,
Add local caching of `ColorSpace`s, by name, in `PartialEvaluator.getOperatorList` (issue 2504) By caching parsed `ColorSpace`s, we thus don't need to re-parse the same data over and over which saves CPU cycles *and* reduces peak memory usage. (Obviously persistent memory usage *may* increase a tiny bit, but since the caching is done per `PartialEvaluator.getOperatorList` invocation and given that `ColorSpace` instances generally hold very little data this shouldn't be much of an issue.) Furthermore, by caching `ColorSpace`s we can also lookup the already parsed ones *synchronously* during the `OperatorList` building, instead of having to defer to the event loop/microtask queue since the parsing is done asynchronously (such that error handling is easier). Possible future improvements: - Cache/lookup parsed `ColorSpaces` used in `Pattern`s and `Image`s. - Attempt to cache *local* `ColorSpace`s by reference as well, in addition to only by name, assuming that there's documents where that would be beneficial and that it's not too difficult to implement. - Assuming there's documents that would benefit from it, also cache repeated `ColorSpace`s *globally* as well. Given that we've never, until now, been doing *any* caching of parsed `ColorSpace`s and that even using a simple name-only *local* cache helps tremendously in pathological cases, I purposely decided against complicating the implementation too much initially. Also, compared to parsing of `Image`s, simply creating a `ColorSpace` instance isn't that expensive (hence I'd be somewhat surprised if adding a *global* cache would help much). --- This patch was tested using: - The default `tracemonkey` PDF file, which was included mostly to show that "normal" documents aren't negatively affected by these changes. - The PDF file from issue 2504, i.e. https://dl-ctlg.panasonic.com/jp/manual/sd/sd_rbm1000_0.pdf, where most pages will switch *thousands* of times between a handful of `ColorSpace`s. with the following manifest file: ``` [ { "id": "tracemonkey", "file": "pdfs/tracemonkey.pdf", "md5": "9a192d8b1a7dc652a19835f6f08098bd", "rounds": 100, "type": "eq" }, { "id": "issue2504", "file": "../web/pdfs/issue2504.pdf", "md5": "", "rounds": 20, "type": "eq" } ] ``` which gave the following results when comparing this patch against the `master` branch: - Overall ``` -- Grouped By browser, pdf, stat -- browser | pdf | stat | Count | Baseline(ms) | Current(ms) | +/- | % | Result(P<.05) ------- | ----------- | ------------ | ----- | ------------ | ----------- | ---- | ------ | ------------- firefox | issue2504 | Overall | 640 | 977 | 497 | -479 | -49.08 | faster firefox | issue2504 | Page Request | 640 | 3 | 4 | 1 | 59.18 | firefox | issue2504 | Rendering | 640 | 974 | 493 | -481 | -49.37 | faster firefox | tracemonkey | Overall | 1400 | 116 | 111 | -5 | -4.43 | firefox | tracemonkey | Page Request | 1400 | 2 | 2 | 0 | -2.86 | firefox | tracemonkey | Rendering | 1400 | 114 | 109 | -5 | -4.47 | ``` - Page-specific ``` -- Grouped By browser, pdf, page, stat -- browser | pdf | page | stat | Count | Baseline(ms) | Current(ms) | +/- | % | Result(P<.05) ------- | ----------- | ---- | ------------ | ----- | ------------ | ----------- | ----- | ------- | ------------- firefox | issue2504 | 0 | Overall | 20 | 2295 | 1268 | -1027 | -44.76 | faster firefox | issue2504 | 0 | Page Request | 20 | 6 | 7 | 1 | 15.32 | firefox | issue2504 | 0 | Rendering | 20 | 2288 | 1260 | -1028 | -44.93 | faster firefox | issue2504 | 1 | Overall | 20 | 3059 | 2806 | -252 | -8.25 | faster firefox | issue2504 | 1 | Page Request | 20 | 11 | 14 | 3 | 23.25 | slower firefox | issue2504 | 1 | Rendering | 20 | 3047 | 2792 | -255 | -8.37 | faster firefox | issue2504 | 2 | Overall | 20 | 411 | 295 | -116 | -28.20 | faster firefox | issue2504 | 2 | Page Request | 20 | 2 | 42 | 40 | 1897.62 | firefox | issue2504 | 2 | Rendering | 20 | 409 | 253 | -156 | -38.09 | faster firefox | issue2504 | 3 | Overall | 20 | 736 | 299 | -437 | -59.34 | faster firefox | issue2504 | 3 | Page Request | 20 | 2 | 2 | 0 | 0.00 | firefox | issue2504 | 3 | Rendering | 20 | 734 | 297 | -437 | -59.49 | faster firefox | issue2504 | 4 | Overall | 20 | 356 | 458 | 102 | 28.63 | firefox | issue2504 | 4 | Page Request | 20 | 1 | 2 | 1 | 57.14 | slower firefox | issue2504 | 4 | Rendering | 20 | 354 | 455 | 101 | 28.53 | firefox | issue2504 | 5 | Overall | 20 | 1381 | 765 | -616 | -44.59 | faster firefox | issue2504 | 5 | Page Request | 20 | 3 | 5 | 2 | 50.00 | slower firefox | issue2504 | 5 | Rendering | 20 | 1378 | 760 | -617 | -44.81 | faster firefox | issue2504 | 6 | Overall | 20 | 757 | 299 | -459 | -60.57 | faster firefox | issue2504 | 6 | Page Request | 20 | 2 | 5 | 3 | 150.00 | slower firefox | issue2504 | 6 | Rendering | 20 | 755 | 294 | -462 | -61.11 | faster firefox | issue2504 | 7 | Overall | 20 | 394 | 302 | -92 | -23.39 | faster firefox | issue2504 | 7 | Page Request | 20 | 2 | 1 | -1 | -34.88 | faster firefox | issue2504 | 7 | Rendering | 20 | 392 | 301 | -91 | -23.32 | faster firefox | issue2504 | 8 | Overall | 20 | 2875 | 979 | -1896 | -65.95 | faster firefox | issue2504 | 8 | Page Request | 20 | 1 | 2 | 0 | 11.11 | firefox | issue2504 | 8 | Rendering | 20 | 2874 | 978 | -1896 | -65.99 | faster firefox | issue2504 | 9 | Overall | 20 | 700 | 332 | -368 | -52.60 | faster firefox | issue2504 | 9 | Page Request | 20 | 3 | 2 | 0 | -4.00 | firefox | issue2504 | 9 | Rendering | 20 | 698 | 329 | -368 | -52.78 | faster firefox | issue2504 | 10 | Overall | 20 | 3296 | 926 | -2370 | -71.91 | faster firefox | issue2504 | 10 | Page Request | 20 | 2 | 2 | 0 | -18.75 | firefox | issue2504 | 10 | Rendering | 20 | 3293 | 924 | -2370 | -71.96 | faster firefox | issue2504 | 11 | Overall | 20 | 524 | 197 | -327 | -62.34 | faster firefox | issue2504 | 11 | Page Request | 20 | 2 | 3 | 1 | 58.54 | firefox | issue2504 | 11 | Rendering | 20 | 522 | 194 | -328 | -62.81 | faster firefox | issue2504 | 12 | Overall | 20 | 752 | 369 | -384 | -50.98 | faster firefox | issue2504 | 12 | Page Request | 20 | 3 | 2 | -1 | -36.51 | faster firefox | issue2504 | 12 | Rendering | 20 | 749 | 367 | -382 | -51.05 | faster firefox | issue2504 | 13 | Overall | 20 | 679 | 487 | -193 | -28.38 | faster firefox | issue2504 | 13 | Page Request | 20 | 4 | 2 | -2 | -48.68 | faster firefox | issue2504 | 13 | Rendering | 20 | 676 | 485 | -191 | -28.28 | faster firefox | issue2504 | 14 | Overall | 20 | 474 | 283 | -191 | -40.26 | faster firefox | issue2504 | 14 | Page Request | 20 | 2 | 4 | 2 | 78.57 | firefox | issue2504 | 14 | Rendering | 20 | 471 | 279 | -192 | -40.79 | faster firefox | issue2504 | 15 | Overall | 20 | 860 | 618 | -241 | -28.05 | faster firefox | issue2504 | 15 | Page Request | 20 | 2 | 3 | 0 | 10.87 | firefox | issue2504 | 15 | Rendering | 20 | 857 | 616 | -241 | -28.15 | faster firefox | issue2504 | 16 | Overall | 20 | 389 | 243 | -147 | -37.71 | faster firefox | issue2504 | 16 | Page Request | 20 | 2 | 2 | 0 | 2.33 | firefox | issue2504 | 16 | Rendering | 20 | 387 | 240 | -147 | -37.94 | faster firefox | issue2504 | 17 | Overall | 20 | 1484 | 672 | -812 | -54.70 | faster firefox | issue2504 | 17 | Page Request | 20 | 2 | 3 | 1 | 37.21 | firefox | issue2504 | 17 | Rendering | 20 | 1482 | 669 | -812 | -54.84 | faster firefox | issue2504 | 18 | Overall | 20 | 575 | 252 | -323 | -56.12 | faster firefox | issue2504 | 18 | Page Request | 20 | 2 | 2 | 0 | -16.22 | firefox | issue2504 | 18 | Rendering | 20 | 573 | 251 | -322 | -56.24 | faster firefox | issue2504 | 19 | Overall | 20 | 517 | 227 | -290 | -56.08 | faster firefox | issue2504 | 19 | Page Request | 20 | 2 | 2 | 0 | 21.62 | firefox | issue2504 | 19 | Rendering | 20 | 515 | 225 | -290 | -56.37 | faster firefox | issue2504 | 20 | Overall | 20 | 668 | 670 | 2 | 0.31 | firefox | issue2504 | 20 | Page Request | 20 | 4 | 2 | -1 | -34.29 | firefox | issue2504 | 20 | Rendering | 20 | 664 | 667 | 3 | 0.49 | firefox | issue2504 | 21 | Overall | 20 | 486 | 309 | -177 | -36.44 | faster firefox | issue2504 | 21 | Page Request | 20 | 2 | 2 | 0 | 16.13 | firefox | issue2504 | 21 | Rendering | 20 | 484 | 307 | -177 | -36.60 | faster firefox | issue2504 | 22 | Overall | 20 | 543 | 267 | -276 | -50.85 | faster firefox | issue2504 | 22 | Page Request | 20 | 2 | 2 | 0 | 10.26 | firefox | issue2504 | 22 | Rendering | 20 | 541 | 265 | -276 | -51.07 | faster firefox | issue2504 | 23 | Overall | 20 | 3246 | 871 | -2375 | -73.17 | faster firefox | issue2504 | 23 | Page Request | 20 | 2 | 3 | 1 | 37.21 | firefox | issue2504 | 23 | Rendering | 20 | 3243 | 868 | -2376 | -73.25 | faster firefox | issue2504 | 24 | Overall | 20 | 379 | 156 | -223 | -58.83 | faster firefox | issue2504 | 24 | Page Request | 20 | 2 | 2 | 0 | -2.86 | firefox | issue2504 | 24 | Rendering | 20 | 378 | 154 | -223 | -59.10 | faster firefox | issue2504 | 25 | Overall | 20 | 176 | 127 | -50 | -28.19 | faster firefox | issue2504 | 25 | Page Request | 20 | 2 | 1 | 0 | -15.63 | firefox | issue2504 | 25 | Rendering | 20 | 175 | 125 | -49 | -28.31 | faster firefox | issue2504 | 26 | Overall | 20 | 181 | 108 | -74 | -40.67 | faster firefox | issue2504 | 26 | Page Request | 20 | 3 | 2 | -1 | -39.13 | faster firefox | issue2504 | 26 | Rendering | 20 | 178 | 105 | -72 | -40.69 | faster firefox | issue2504 | 27 | Overall | 20 | 208 | 104 | -104 | -49.92 | faster firefox | issue2504 | 27 | Page Request | 20 | 2 | 2 | 1 | 48.39 | firefox | issue2504 | 27 | Rendering | 20 | 206 | 102 | -104 | -50.64 | faster firefox | issue2504 | 28 | Overall | 20 | 241 | 111 | -131 | -54.16 | faster firefox | issue2504 | 28 | Page Request | 20 | 2 | 2 | -1 | -33.33 | firefox | issue2504 | 28 | Rendering | 20 | 239 | 109 | -130 | -54.39 | faster firefox | issue2504 | 29 | Overall | 20 | 321 | 196 | -125 | -39.05 | faster firefox | issue2504 | 29 | Page Request | 20 | 1 | 2 | 0 | 17.86 | firefox | issue2504 | 29 | Rendering | 20 | 319 | 194 | -126 | -39.35 | faster firefox | issue2504 | 30 | Overall | 20 | 651 | 271 | -380 | -58.41 | faster firefox | issue2504 | 30 | Page Request | 20 | 1 | 2 | 1 | 50.00 | firefox | issue2504 | 30 | Rendering | 20 | 649 | 269 | -381 | -58.60 | faster firefox | issue2504 | 31 | Overall | 20 | 1635 | 647 | -988 | -60.42 | faster firefox | issue2504 | 31 | Page Request | 20 | 1 | 2 | 0 | 30.43 | firefox | issue2504 | 31 | Rendering | 20 | 1634 | 645 | -988 | -60.49 | faster firefox | tracemonkey | 0 | Overall | 100 | 51 | 51 | 0 | 0.02 | firefox | tracemonkey | 0 | Page Request | 100 | 1 | 1 | 0 | -4.76 | firefox | tracemonkey | 0 | Rendering | 100 | 50 | 50 | 0 | 0.12 | firefox | tracemonkey | 1 | Overall | 100 | 97 | 91 | -5 | -5.52 | faster firefox | tracemonkey | 1 | Page Request | 100 | 3 | 3 | 0 | -1.32 | firefox | tracemonkey | 1 | Rendering | 100 | 94 | 88 | -5 | -5.73 | faster firefox | tracemonkey | 2 | Overall | 100 | 40 | 40 | 0 | 0.50 | firefox | tracemonkey | 2 | Page Request | 100 | 1 | 1 | 0 | 3.16 | firefox | tracemonkey | 2 | Rendering | 100 | 39 | 39 | 0 | 0.54 | firefox | tracemonkey | 3 | Overall | 100 | 62 | 62 | -1 | -0.94 | firefox | tracemonkey | 3 | Page Request | 100 | 1 | 1 | 0 | 17.05 | firefox | tracemonkey | 3 | Rendering | 100 | 61 | 61 | -1 | -1.11 | firefox | tracemonkey | 4 | Overall | 100 | 56 | 58 | 2 | 3.41 | firefox | tracemonkey | 4 | Page Request | 100 | 1 | 1 | 0 | 15.31 | firefox | tracemonkey | 4 | Rendering | 100 | 55 | 57 | 2 | 3.23 | firefox | tracemonkey | 5 | Overall | 100 | 73 | 71 | -2 | -2.28 | firefox | tracemonkey | 5 | Page Request | 100 | 2 | 2 | 0 | 12.20 | firefox | tracemonkey | 5 | Rendering | 100 | 71 | 69 | -2 | -2.69 | firefox | tracemonkey | 6 | Overall | 100 | 85 | 69 | -16 | -18.73 | faster firefox | tracemonkey | 6 | Page Request | 100 | 2 | 2 | 0 | -9.90 | firefox | tracemonkey | 6 | Rendering | 100 | 83 | 67 | -16 | -18.97 | faster firefox | tracemonkey | 7 | Overall | 100 | 65 | 64 | 0 | -0.37 | firefox | tracemonkey | 7 | Page Request | 100 | 1 | 1 | 0 | -11.94 | firefox | tracemonkey | 7 | Rendering | 100 | 63 | 63 | 0 | -0.05 | firefox | tracemonkey | 8 | Overall | 100 | 53 | 54 | 1 | 2.04 | firefox | tracemonkey | 8 | Page Request | 100 | 1 | 1 | 0 | 17.02 | firefox | tracemonkey | 8 | Rendering | 100 | 52 | 53 | 1 | 1.82 | firefox | tracemonkey | 9 | Overall | 100 | 79 | 73 | -6 | -7.86 | faster firefox | tracemonkey | 9 | Page Request | 100 | 2 | 2 | 0 | -15.14 | firefox | tracemonkey | 9 | Rendering | 100 | 77 | 71 | -6 | -7.86 | faster firefox | tracemonkey | 10 | Overall | 100 | 545 | 519 | -27 | -4.86 | faster firefox | tracemonkey | 10 | Page Request | 100 | 14 | 13 | 0 | -3.56 | firefox | tracemonkey | 10 | Rendering | 100 | 532 | 506 | -26 | -4.90 | faster firefox | tracemonkey | 11 | Overall | 100 | 42 | 41 | -1 | -2.50 | firefox | tracemonkey | 11 | Page Request | 100 | 1 | 1 | 0 | -27.42 | faster firefox | tracemonkey | 11 | Rendering | 100 | 41 | 40 | -1 | -1.75 | firefox | tracemonkey | 12 | Overall | 100 | 350 | 332 | -18 | -5.16 | faster firefox | tracemonkey | 12 | Page Request | 100 | 3 | 3 | 0 | -5.17 | firefox | tracemonkey | 12 | Rendering | 100 | 347 | 329 | -18 | -5.15 | faster firefox | tracemonkey | 13 | Overall | 100 | 31 | 31 | 0 | 0.52 | firefox | tracemonkey | 13 | Page Request | 100 | 1 | 1 | 0 | 4.95 | firefox | tracemonkey | 13 | Rendering | 100 | 30 | 30 | 0 | 0.20 | ```
2020-06-13 21:12:40 +09:00
localColorSpaceCache,
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
})
Update Prettier to version 2.0 Please note that these changes were done automatically, using `gulp lint --fix`. Given that the major version number was increased, there's a fair number of (primarily whitespace) changes; please see https://prettier.io/blog/2020/03/21/2.0.0.html In order to reduce the size of these changes somewhat, this patch maintains the old "arrowParens" style for now (once mozilla-central updates Prettier we can simply choose the same formatting, assuming it will differ here).
2020-04-14 19:28:14 +09:00
.then(function (colorSpace) {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
if (colorSpace) {
stateManager.state.strokeColorSpace = colorSpace;
}
})
);
Allow skipping of errors when parsing broken/unsupported ColorSpaces (issue 6707, issue 11287) This will allow us to attempt to recover as much as possible of a page, rather than immediately failing, when a broken/unsupported ColorSpace is encountered. This patch thus extends the framework added in PRs such as e.g. 8240 and 8922, to also cover parsing of ColorSpaces.
2019-10-31 23:53:51 +09:00
return;
Add local caching of `ColorSpace`s, by name, in `PartialEvaluator.getOperatorList` (issue 2504) By caching parsed `ColorSpace`s, we thus don't need to re-parse the same data over and over which saves CPU cycles *and* reduces peak memory usage. (Obviously persistent memory usage *may* increase a tiny bit, but since the caching is done per `PartialEvaluator.getOperatorList` invocation and given that `ColorSpace` instances generally hold very little data this shouldn't be much of an issue.) Furthermore, by caching `ColorSpace`s we can also lookup the already parsed ones *synchronously* during the `OperatorList` building, instead of having to defer to the event loop/microtask queue since the parsing is done asynchronously (such that error handling is easier). Possible future improvements: - Cache/lookup parsed `ColorSpaces` used in `Pattern`s and `Image`s. - Attempt to cache *local* `ColorSpace`s by reference as well, in addition to only by name, assuming that there's documents where that would be beneficial and that it's not too difficult to implement. - Assuming there's documents that would benefit from it, also cache repeated `ColorSpace`s *globally* as well. Given that we've never, until now, been doing *any* caching of parsed `ColorSpace`s and that even using a simple name-only *local* cache helps tremendously in pathological cases, I purposely decided against complicating the implementation too much initially. Also, compared to parsing of `Image`s, simply creating a `ColorSpace` instance isn't that expensive (hence I'd be somewhat surprised if adding a *global* cache would help much). --- This patch was tested using: - The default `tracemonkey` PDF file, which was included mostly to show that "normal" documents aren't negatively affected by these changes. - The PDF file from issue 2504, i.e. https://dl-ctlg.panasonic.com/jp/manual/sd/sd_rbm1000_0.pdf, where most pages will switch *thousands* of times between a handful of `ColorSpace`s. with the following manifest file: ``` [ { "id": "tracemonkey", "file": "pdfs/tracemonkey.pdf", "md5": "9a192d8b1a7dc652a19835f6f08098bd", "rounds": 100, "type": "eq" }, { "id": "issue2504", "file": "../web/pdfs/issue2504.pdf", "md5": "", "rounds": 20, "type": "eq" } ] ``` which gave the following results when comparing this patch against the `master` branch: - Overall ``` -- Grouped By browser, pdf, stat -- browser | pdf | stat | Count | Baseline(ms) | Current(ms) | +/- | % | Result(P<.05) ------- | ----------- | ------------ | ----- | ------------ | ----------- | ---- | ------ | ------------- firefox | issue2504 | Overall | 640 | 977 | 497 | -479 | -49.08 | faster firefox | issue2504 | Page Request | 640 | 3 | 4 | 1 | 59.18 | firefox | issue2504 | Rendering | 640 | 974 | 493 | -481 | -49.37 | faster firefox | tracemonkey | Overall | 1400 | 116 | 111 | -5 | -4.43 | firefox | tracemonkey | Page Request | 1400 | 2 | 2 | 0 | -2.86 | firefox | tracemonkey | Rendering | 1400 | 114 | 109 | -5 | -4.47 | ``` - Page-specific ``` -- Grouped By browser, pdf, page, stat -- browser | pdf | page | stat | Count | Baseline(ms) | Current(ms) | +/- | % | Result(P<.05) ------- | ----------- | ---- | ------------ | ----- | ------------ | ----------- | ----- | ------- | ------------- firefox | issue2504 | 0 | Overall | 20 | 2295 | 1268 | -1027 | -44.76 | faster firefox | issue2504 | 0 | Page Request | 20 | 6 | 7 | 1 | 15.32 | firefox | issue2504 | 0 | Rendering | 20 | 2288 | 1260 | -1028 | -44.93 | faster firefox | issue2504 | 1 | Overall | 20 | 3059 | 2806 | -252 | -8.25 | faster firefox | issue2504 | 1 | Page Request | 20 | 11 | 14 | 3 | 23.25 | slower firefox | issue2504 | 1 | Rendering | 20 | 3047 | 2792 | -255 | -8.37 | faster firefox | issue2504 | 2 | Overall | 20 | 411 | 295 | -116 | -28.20 | faster firefox | issue2504 | 2 | Page Request | 20 | 2 | 42 | 40 | 1897.62 | firefox | issue2504 | 2 | Rendering | 20 | 409 | 253 | -156 | -38.09 | faster firefox | issue2504 | 3 | Overall | 20 | 736 | 299 | -437 | -59.34 | faster firefox | issue2504 | 3 | Page Request | 20 | 2 | 2 | 0 | 0.00 | firefox | issue2504 | 3 | Rendering | 20 | 734 | 297 | -437 | -59.49 | faster firefox | issue2504 | 4 | Overall | 20 | 356 | 458 | 102 | 28.63 | firefox | issue2504 | 4 | Page Request | 20 | 1 | 2 | 1 | 57.14 | slower firefox | issue2504 | 4 | Rendering | 20 | 354 | 455 | 101 | 28.53 | firefox | issue2504 | 5 | Overall | 20 | 1381 | 765 | -616 | -44.59 | faster firefox | issue2504 | 5 | Page Request | 20 | 3 | 5 | 2 | 50.00 | slower firefox | issue2504 | 5 | Rendering | 20 | 1378 | 760 | -617 | -44.81 | faster firefox | issue2504 | 6 | Overall | 20 | 757 | 299 | -459 | -60.57 | faster firefox | issue2504 | 6 | Page Request | 20 | 2 | 5 | 3 | 150.00 | slower firefox | issue2504 | 6 | Rendering | 20 | 755 | 294 | -462 | -61.11 | faster firefox | issue2504 | 7 | Overall | 20 | 394 | 302 | -92 | -23.39 | faster firefox | issue2504 | 7 | Page Request | 20 | 2 | 1 | -1 | -34.88 | faster firefox | issue2504 | 7 | Rendering | 20 | 392 | 301 | -91 | -23.32 | faster firefox | issue2504 | 8 | Overall | 20 | 2875 | 979 | -1896 | -65.95 | faster firefox | issue2504 | 8 | Page Request | 20 | 1 | 2 | 0 | 11.11 | firefox | issue2504 | 8 | Rendering | 20 | 2874 | 978 | -1896 | -65.99 | faster firefox | issue2504 | 9 | Overall | 20 | 700 | 332 | -368 | -52.60 | faster firefox | issue2504 | 9 | Page Request | 20 | 3 | 2 | 0 | -4.00 | firefox | issue2504 | 9 | Rendering | 20 | 698 | 329 | -368 | -52.78 | faster firefox | issue2504 | 10 | Overall | 20 | 3296 | 926 | -2370 | -71.91 | faster firefox | issue2504 | 10 | Page Request | 20 | 2 | 2 | 0 | -18.75 | firefox | issue2504 | 10 | Rendering | 20 | 3293 | 924 | -2370 | -71.96 | faster firefox | issue2504 | 11 | Overall | 20 | 524 | 197 | -327 | -62.34 | faster firefox | issue2504 | 11 | Page Request | 20 | 2 | 3 | 1 | 58.54 | firefox | issue2504 | 11 | Rendering | 20 | 522 | 194 | -328 | -62.81 | faster firefox | issue2504 | 12 | Overall | 20 | 752 | 369 | -384 | -50.98 | faster firefox | issue2504 | 12 | Page Request | 20 | 3 | 2 | -1 | -36.51 | faster firefox | issue2504 | 12 | Rendering | 20 | 749 | 367 | -382 | -51.05 | faster firefox | issue2504 | 13 | Overall | 20 | 679 | 487 | -193 | -28.38 | faster firefox | issue2504 | 13 | Page Request | 20 | 4 | 2 | -2 | -48.68 | faster firefox | issue2504 | 13 | Rendering | 20 | 676 | 485 | -191 | -28.28 | faster firefox | issue2504 | 14 | Overall | 20 | 474 | 283 | -191 | -40.26 | faster firefox | issue2504 | 14 | Page Request | 20 | 2 | 4 | 2 | 78.57 | firefox | issue2504 | 14 | Rendering | 20 | 471 | 279 | -192 | -40.79 | faster firefox | issue2504 | 15 | Overall | 20 | 860 | 618 | -241 | -28.05 | faster firefox | issue2504 | 15 | Page Request | 20 | 2 | 3 | 0 | 10.87 | firefox | issue2504 | 15 | Rendering | 20 | 857 | 616 | -241 | -28.15 | faster firefox | issue2504 | 16 | Overall | 20 | 389 | 243 | -147 | -37.71 | faster firefox | issue2504 | 16 | Page Request | 20 | 2 | 2 | 0 | 2.33 | firefox | issue2504 | 16 | Rendering | 20 | 387 | 240 | -147 | -37.94 | faster firefox | issue2504 | 17 | Overall | 20 | 1484 | 672 | -812 | -54.70 | faster firefox | issue2504 | 17 | Page Request | 20 | 2 | 3 | 1 | 37.21 | firefox | issue2504 | 17 | Rendering | 20 | 1482 | 669 | -812 | -54.84 | faster firefox | issue2504 | 18 | Overall | 20 | 575 | 252 | -323 | -56.12 | faster firefox | issue2504 | 18 | Page Request | 20 | 2 | 2 | 0 | -16.22 | firefox | issue2504 | 18 | Rendering | 20 | 573 | 251 | -322 | -56.24 | faster firefox | issue2504 | 19 | Overall | 20 | 517 | 227 | -290 | -56.08 | faster firefox | issue2504 | 19 | Page Request | 20 | 2 | 2 | 0 | 21.62 | firefox | issue2504 | 19 | Rendering | 20 | 515 | 225 | -290 | -56.37 | faster firefox | issue2504 | 20 | Overall | 20 | 668 | 670 | 2 | 0.31 | firefox | issue2504 | 20 | Page Request | 20 | 4 | 2 | -1 | -34.29 | firefox | issue2504 | 20 | Rendering | 20 | 664 | 667 | 3 | 0.49 | firefox | issue2504 | 21 | Overall | 20 | 486 | 309 | -177 | -36.44 | faster firefox | issue2504 | 21 | Page Request | 20 | 2 | 2 | 0 | 16.13 | firefox | issue2504 | 21 | Rendering | 20 | 484 | 307 | -177 | -36.60 | faster firefox | issue2504 | 22 | Overall | 20 | 543 | 267 | -276 | -50.85 | faster firefox | issue2504 | 22 | Page Request | 20 | 2 | 2 | 0 | 10.26 | firefox | issue2504 | 22 | Rendering | 20 | 541 | 265 | -276 | -51.07 | faster firefox | issue2504 | 23 | Overall | 20 | 3246 | 871 | -2375 | -73.17 | faster firefox | issue2504 | 23 | Page Request | 20 | 2 | 3 | 1 | 37.21 | firefox | issue2504 | 23 | Rendering | 20 | 3243 | 868 | -2376 | -73.25 | faster firefox | issue2504 | 24 | Overall | 20 | 379 | 156 | -223 | -58.83 | faster firefox | issue2504 | 24 | Page Request | 20 | 2 | 2 | 0 | -2.86 | firefox | issue2504 | 24 | Rendering | 20 | 378 | 154 | -223 | -59.10 | faster firefox | issue2504 | 25 | Overall | 20 | 176 | 127 | -50 | -28.19 | faster firefox | issue2504 | 25 | Page Request | 20 | 2 | 1 | 0 | -15.63 | firefox | issue2504 | 25 | Rendering | 20 | 175 | 125 | -49 | -28.31 | faster firefox | issue2504 | 26 | Overall | 20 | 181 | 108 | -74 | -40.67 | faster firefox | issue2504 | 26 | Page Request | 20 | 3 | 2 | -1 | -39.13 | faster firefox | issue2504 | 26 | Rendering | 20 | 178 | 105 | -72 | -40.69 | faster firefox | issue2504 | 27 | Overall | 20 | 208 | 104 | -104 | -49.92 | faster firefox | issue2504 | 27 | Page Request | 20 | 2 | 2 | 1 | 48.39 | firefox | issue2504 | 27 | Rendering | 20 | 206 | 102 | -104 | -50.64 | faster firefox | issue2504 | 28 | Overall | 20 | 241 | 111 | -131 | -54.16 | faster firefox | issue2504 | 28 | Page Request | 20 | 2 | 2 | -1 | -33.33 | firefox | issue2504 | 28 | Rendering | 20 | 239 | 109 | -130 | -54.39 | faster firefox | issue2504 | 29 | Overall | 20 | 321 | 196 | -125 | -39.05 | faster firefox | issue2504 | 29 | Page Request | 20 | 1 | 2 | 0 | 17.86 | firefox | issue2504 | 29 | Rendering | 20 | 319 | 194 | -126 | -39.35 | faster firefox | issue2504 | 30 | Overall | 20 | 651 | 271 | -380 | -58.41 | faster firefox | issue2504 | 30 | Page Request | 20 | 1 | 2 | 1 | 50.00 | firefox | issue2504 | 30 | Rendering | 20 | 649 | 269 | -381 | -58.60 | faster firefox | issue2504 | 31 | Overall | 20 | 1635 | 647 | -988 | -60.42 | faster firefox | issue2504 | 31 | Page Request | 20 | 1 | 2 | 0 | 30.43 | firefox | issue2504 | 31 | Rendering | 20 | 1634 | 645 | -988 | -60.49 | faster firefox | tracemonkey | 0 | Overall | 100 | 51 | 51 | 0 | 0.02 | firefox | tracemonkey | 0 | Page Request | 100 | 1 | 1 | 0 | -4.76 | firefox | tracemonkey | 0 | Rendering | 100 | 50 | 50 | 0 | 0.12 | firefox | tracemonkey | 1 | Overall | 100 | 97 | 91 | -5 | -5.52 | faster firefox | tracemonkey | 1 | Page Request | 100 | 3 | 3 | 0 | -1.32 | firefox | tracemonkey | 1 | Rendering | 100 | 94 | 88 | -5 | -5.73 | faster firefox | tracemonkey | 2 | Overall | 100 | 40 | 40 | 0 | 0.50 | firefox | tracemonkey | 2 | Page Request | 100 | 1 | 1 | 0 | 3.16 | firefox | tracemonkey | 2 | Rendering | 100 | 39 | 39 | 0 | 0.54 | firefox | tracemonkey | 3 | Overall | 100 | 62 | 62 | -1 | -0.94 | firefox | tracemonkey | 3 | Page Request | 100 | 1 | 1 | 0 | 17.05 | firefox | tracemonkey | 3 | Rendering | 100 | 61 | 61 | -1 | -1.11 | firefox | tracemonkey | 4 | Overall | 100 | 56 | 58 | 2 | 3.41 | firefox | tracemonkey | 4 | Page Request | 100 | 1 | 1 | 0 | 15.31 | firefox | tracemonkey | 4 | Rendering | 100 | 55 | 57 | 2 | 3.23 | firefox | tracemonkey | 5 | Overall | 100 | 73 | 71 | -2 | -2.28 | firefox | tracemonkey | 5 | Page Request | 100 | 2 | 2 | 0 | 12.20 | firefox | tracemonkey | 5 | Rendering | 100 | 71 | 69 | -2 | -2.69 | firefox | tracemonkey | 6 | Overall | 100 | 85 | 69 | -16 | -18.73 | faster firefox | tracemonkey | 6 | Page Request | 100 | 2 | 2 | 0 | -9.90 | firefox | tracemonkey | 6 | Rendering | 100 | 83 | 67 | -16 | -18.97 | faster firefox | tracemonkey | 7 | Overall | 100 | 65 | 64 | 0 | -0.37 | firefox | tracemonkey | 7 | Page Request | 100 | 1 | 1 | 0 | -11.94 | firefox | tracemonkey | 7 | Rendering | 100 | 63 | 63 | 0 | -0.05 | firefox | tracemonkey | 8 | Overall | 100 | 53 | 54 | 1 | 2.04 | firefox | tracemonkey | 8 | Page Request | 100 | 1 | 1 | 0 | 17.02 | firefox | tracemonkey | 8 | Rendering | 100 | 52 | 53 | 1 | 1.82 | firefox | tracemonkey | 9 | Overall | 100 | 79 | 73 | -6 | -7.86 | faster firefox | tracemonkey | 9 | Page Request | 100 | 2 | 2 | 0 | -15.14 | firefox | tracemonkey | 9 | Rendering | 100 | 77 | 71 | -6 | -7.86 | faster firefox | tracemonkey | 10 | Overall | 100 | 545 | 519 | -27 | -4.86 | faster firefox | tracemonkey | 10 | Page Request | 100 | 14 | 13 | 0 | -3.56 | firefox | tracemonkey | 10 | Rendering | 100 | 532 | 506 | -26 | -4.90 | faster firefox | tracemonkey | 11 | Overall | 100 | 42 | 41 | -1 | -2.50 | firefox | tracemonkey | 11 | Page Request | 100 | 1 | 1 | 0 | -27.42 | faster firefox | tracemonkey | 11 | Rendering | 100 | 41 | 40 | -1 | -1.75 | firefox | tracemonkey | 12 | Overall | 100 | 350 | 332 | -18 | -5.16 | faster firefox | tracemonkey | 12 | Page Request | 100 | 3 | 3 | 0 | -5.17 | firefox | tracemonkey | 12 | Rendering | 100 | 347 | 329 | -18 | -5.15 | faster firefox | tracemonkey | 13 | Overall | 100 | 31 | 31 | 0 | 0.52 | firefox | tracemonkey | 13 | Page Request | 100 | 1 | 1 | 0 | 4.95 | firefox | tracemonkey | 13 | Rendering | 100 | 30 | 30 | 0 | 0.20 | ```
2020-06-13 21:12:40 +09:00
}
Moves ColorSpace logic into evaluator
2014-05-22 02:47:42 +09:00
case OPS.setFillColor:
cs = stateManager.state.fillColorSpace;
args = cs.getRgb(args, 0);
fn = OPS.setFillRGBColor;
break;
case OPS.setStrokeColor:
cs = stateManager.state.strokeColorSpace;
args = cs.getRgb(args, 0);
fn = OPS.setStrokeRGBColor;
break;
case OPS.setFillGray:
stateManager.state.fillColorSpace = ColorSpace.singletons.gray;
args = ColorSpace.singletons.gray.getRgb(args, 0);
fn = OPS.setFillRGBColor;
break;
case OPS.setStrokeGray:
stateManager.state.strokeColorSpace = ColorSpace.singletons.gray;
args = ColorSpace.singletons.gray.getRgb(args, 0);
fn = OPS.setStrokeRGBColor;
break;
case OPS.setFillCMYKColor:
stateManager.state.fillColorSpace = ColorSpace.singletons.cmyk;
args = ColorSpace.singletons.cmyk.getRgb(args, 0);
fn = OPS.setFillRGBColor;
break;
case OPS.setStrokeCMYKColor:
stateManager.state.strokeColorSpace = ColorSpace.singletons.cmyk;
args = ColorSpace.singletons.cmyk.getRgb(args, 0);
fn = OPS.setStrokeRGBColor;
break;
case OPS.setFillRGBColor:
stateManager.state.fillColorSpace = ColorSpace.singletons.rgb;
args = ColorSpace.singletons.rgb.getRgb(args, 0);
Adds Promise to the getOperatorList
2014-05-10 10:21:15 +09:00
break;
Moves ColorSpace logic into evaluator
2014-05-22 02:47:42 +09:00
case OPS.setStrokeRGBColor:
stateManager.state.strokeColorSpace = ColorSpace.singletons.rgb;
args = ColorSpace.singletons.rgb.getRgb(args, 0);
break;
case OPS.setFillColorN:
cs = stateManager.state.fillColorSpace;
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
if (cs.name === "Pattern") {
next(
self.handleColorN(
operatorList,
OPS.setFillColorN,
args,
cs,
patterns,
resources,
task
)
);
Better errors capturing at the core and stop rendering on error.
2016-03-11 22:59:09 +09:00
return;
Moves ColorSpace logic into evaluator
2014-05-22 02:47:42 +09:00
}
args = cs.getRgb(args, 0);
fn = OPS.setFillRGBColor;
break;
case OPS.setStrokeColorN:
cs = stateManager.state.strokeColorSpace;
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
if (cs.name === "Pattern") {
next(
self.handleColorN(
operatorList,
OPS.setStrokeColorN,
args,
cs,
patterns,
resources,
task
)
);
Better errors capturing at the core and stop rendering on error.
2016-03-11 22:59:09 +09:00
return;
Moves ColorSpace logic into evaluator
2014-05-22 02:47:42 +09:00
}
args = cs.getRgb(args, 0);
fn = OPS.setStrokeRGBColor;
break;
Adds Promise to the getOperatorList
2014-05-10 10:21:15 +09:00
case OPS.shadingFill:
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
var shadingRes = resources.get("Shading");
Remove most `assert()` calls (issue 8506) This replaces `assert` calls with `throw new FormatError()`/`throw new Error()`. In a few places, throwing an `Error` (which is what `assert` meant) isn't correct since the enclosing function is supposed to return a `Promise`, hence some cases were changed to `Promise.reject(...)` and similarily for `createPromiseCapability` instances.
2017-07-20 21:04:54 +09:00
if (!shadingRes) {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
throw new FormatError("No shading resource found");
Remove most `assert()` calls (issue 8506) This replaces `assert` calls with `throw new FormatError()`/`throw new Error()`. In a few places, throwing an `Error` (which is what `assert` meant) isn't correct since the enclosing function is supposed to return a `Promise`, hence some cases were changed to `Promise.reject(...)` and similarily for `createPromiseCapability` instances.
2017-07-20 21:04:54 +09:00
}
Load all resources before getOperatorList/getTextContent.
2013-06-05 09:57:52 +09:00
Moves ColorSpace logic into evaluator
2014-05-22 02:47:42 +09:00
var shading = shadingRes.get(args[0].name);
Remove most `assert()` calls (issue 8506) This replaces `assert` calls with `throw new FormatError()`/`throw new Error()`. In a few places, throwing an `Error` (which is what `assert` meant) isn't correct since the enclosing function is supposed to return a `Promise`, hence some cases were changed to `Promise.reject(...)` and similarily for `createPromiseCapability` instances.
2017-07-20 21:04:54 +09:00
if (!shading) {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
throw new FormatError("No shading object found");
Remove most `assert()` calls (issue 8506) This replaces `assert` calls with `throw new FormatError()`/`throw new Error()`. In a few places, throwing an `Error` (which is what `assert` meant) isn't correct since the enclosing function is supposed to return a `Promise`, hence some cases were changed to `Promise.reject(...)` and similarily for `createPromiseCapability` instances.
2017-07-20 21:04:54 +09:00
}
Load all resources before getOperatorList/getTextContent.
2013-06-05 09:57:52 +09:00
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
var shadingFill = Pattern.parseShading(
shading,
null,
xref,
resources,
self.handler,
self.pdfFunctionFactory
);
Adds Promise to the getOperatorList
2014-05-10 10:21:15 +09:00
var patternIR = shadingFill.getIR();
args = [patternIR];
fn = OPS.shadingFill;
Making src/core/evaluator.js adhere to the style guide
2014-03-23 03:15:51 +09:00
break;
Adds Promise to the getOperatorList
2014-05-10 10:21:15 +09:00
case OPS.setGState:
var dictName = args[0];
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
var extGState = resources.get("ExtGState");
Extracts evaluator preprocessor and refactor text extraction
2014-01-17 22:16:52 +09:00
Adds Promise to the getOperatorList
2014-05-10 10:21:15 +09:00
if (!isDict(extGState) || !extGState.has(dictName.name)) {
break;
}
Splitting files
2011-10-25 08:55:23 +09:00
Adds Promise to the getOperatorList
2014-05-10 10:21:15 +09:00
var gState = extGState.get(dictName.name);
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
next(
self.setGState(
resources,
gState,
operatorList,
task,
Add local caching of `ColorSpace`s, by name, in `PartialEvaluator.getOperatorList` (issue 2504) By caching parsed `ColorSpace`s, we thus don't need to re-parse the same data over and over which saves CPU cycles *and* reduces peak memory usage. (Obviously persistent memory usage *may* increase a tiny bit, but since the caching is done per `PartialEvaluator.getOperatorList` invocation and given that `ColorSpace` instances generally hold very little data this shouldn't be much of an issue.) Furthermore, by caching `ColorSpace`s we can also lookup the already parsed ones *synchronously* during the `OperatorList` building, instead of having to defer to the event loop/microtask queue since the parsing is done asynchronously (such that error handling is easier). Possible future improvements: - Cache/lookup parsed `ColorSpaces` used in `Pattern`s and `Image`s. - Attempt to cache *local* `ColorSpace`s by reference as well, in addition to only by name, assuming that there's documents where that would be beneficial and that it's not too difficult to implement. - Assuming there's documents that would benefit from it, also cache repeated `ColorSpace`s *globally* as well. Given that we've never, until now, been doing *any* caching of parsed `ColorSpace`s and that even using a simple name-only *local* cache helps tremendously in pathological cases, I purposely decided against complicating the implementation too much initially. Also, compared to parsing of `Image`s, simply creating a `ColorSpace` instance isn't that expensive (hence I'd be somewhat surprised if adding a *global* cache would help much). --- This patch was tested using: - The default `tracemonkey` PDF file, which was included mostly to show that "normal" documents aren't negatively affected by these changes. - The PDF file from issue 2504, i.e. https://dl-ctlg.panasonic.com/jp/manual/sd/sd_rbm1000_0.pdf, where most pages will switch *thousands* of times between a handful of `ColorSpace`s. with the following manifest file: ``` [ { "id": "tracemonkey", "file": "pdfs/tracemonkey.pdf", "md5": "9a192d8b1a7dc652a19835f6f08098bd", "rounds": 100, "type": "eq" }, { "id": "issue2504", "file": "../web/pdfs/issue2504.pdf", "md5": "", "rounds": 20, "type": "eq" } ] ``` which gave the following results when comparing this patch against the `master` branch: - Overall ``` -- Grouped By browser, pdf, stat -- browser | pdf | stat | Count | Baseline(ms) | Current(ms) | +/- | % | Result(P<.05) ------- | ----------- | ------------ | ----- | ------------ | ----------- | ---- | ------ | ------------- firefox | issue2504 | Overall | 640 | 977 | 497 | -479 | -49.08 | faster firefox | issue2504 | Page Request | 640 | 3 | 4 | 1 | 59.18 | firefox | issue2504 | Rendering | 640 | 974 | 493 | -481 | -49.37 | faster firefox | tracemonkey | Overall | 1400 | 116 | 111 | -5 | -4.43 | firefox | tracemonkey | Page Request | 1400 | 2 | 2 | 0 | -2.86 | firefox | tracemonkey | Rendering | 1400 | 114 | 109 | -5 | -4.47 | ``` - Page-specific ``` -- Grouped By browser, pdf, page, stat -- browser | pdf | page | stat | Count | Baseline(ms) | Current(ms) | +/- | % | Result(P<.05) ------- | ----------- | ---- | ------------ | ----- | ------------ | ----------- | ----- | ------- | ------------- firefox | issue2504 | 0 | Overall | 20 | 2295 | 1268 | -1027 | -44.76 | faster firefox | issue2504 | 0 | Page Request | 20 | 6 | 7 | 1 | 15.32 | firefox | issue2504 | 0 | Rendering | 20 | 2288 | 1260 | -1028 | -44.93 | faster firefox | issue2504 | 1 | Overall | 20 | 3059 | 2806 | -252 | -8.25 | faster firefox | issue2504 | 1 | Page Request | 20 | 11 | 14 | 3 | 23.25 | slower firefox | issue2504 | 1 | Rendering | 20 | 3047 | 2792 | -255 | -8.37 | faster firefox | issue2504 | 2 | Overall | 20 | 411 | 295 | -116 | -28.20 | faster firefox | issue2504 | 2 | Page Request | 20 | 2 | 42 | 40 | 1897.62 | firefox | issue2504 | 2 | Rendering | 20 | 409 | 253 | -156 | -38.09 | faster firefox | issue2504 | 3 | Overall | 20 | 736 | 299 | -437 | -59.34 | faster firefox | issue2504 | 3 | Page Request | 20 | 2 | 2 | 0 | 0.00 | firefox | issue2504 | 3 | Rendering | 20 | 734 | 297 | -437 | -59.49 | faster firefox | issue2504 | 4 | Overall | 20 | 356 | 458 | 102 | 28.63 | firefox | issue2504 | 4 | Page Request | 20 | 1 | 2 | 1 | 57.14 | slower firefox | issue2504 | 4 | Rendering | 20 | 354 | 455 | 101 | 28.53 | firefox | issue2504 | 5 | Overall | 20 | 1381 | 765 | -616 | -44.59 | faster firefox | issue2504 | 5 | Page Request | 20 | 3 | 5 | 2 | 50.00 | slower firefox | issue2504 | 5 | Rendering | 20 | 1378 | 760 | -617 | -44.81 | faster firefox | issue2504 | 6 | Overall | 20 | 757 | 299 | -459 | -60.57 | faster firefox | issue2504 | 6 | Page Request | 20 | 2 | 5 | 3 | 150.00 | slower firefox | issue2504 | 6 | Rendering | 20 | 755 | 294 | -462 | -61.11 | faster firefox | issue2504 | 7 | Overall | 20 | 394 | 302 | -92 | -23.39 | faster firefox | issue2504 | 7 | Page Request | 20 | 2 | 1 | -1 | -34.88 | faster firefox | issue2504 | 7 | Rendering | 20 | 392 | 301 | -91 | -23.32 | faster firefox | issue2504 | 8 | Overall | 20 | 2875 | 979 | -1896 | -65.95 | faster firefox | issue2504 | 8 | Page Request | 20 | 1 | 2 | 0 | 11.11 | firefox | issue2504 | 8 | Rendering | 20 | 2874 | 978 | -1896 | -65.99 | faster firefox | issue2504 | 9 | Overall | 20 | 700 | 332 | -368 | -52.60 | faster firefox | issue2504 | 9 | Page Request | 20 | 3 | 2 | 0 | -4.00 | firefox | issue2504 | 9 | Rendering | 20 | 698 | 329 | -368 | -52.78 | faster firefox | issue2504 | 10 | Overall | 20 | 3296 | 926 | -2370 | -71.91 | faster firefox | issue2504 | 10 | Page Request | 20 | 2 | 2 | 0 | -18.75 | firefox | issue2504 | 10 | Rendering | 20 | 3293 | 924 | -2370 | -71.96 | faster firefox | issue2504 | 11 | Overall | 20 | 524 | 197 | -327 | -62.34 | faster firefox | issue2504 | 11 | Page Request | 20 | 2 | 3 | 1 | 58.54 | firefox | issue2504 | 11 | Rendering | 20 | 522 | 194 | -328 | -62.81 | faster firefox | issue2504 | 12 | Overall | 20 | 752 | 369 | -384 | -50.98 | faster firefox | issue2504 | 12 | Page Request | 20 | 3 | 2 | -1 | -36.51 | faster firefox | issue2504 | 12 | Rendering | 20 | 749 | 367 | -382 | -51.05 | faster firefox | issue2504 | 13 | Overall | 20 | 679 | 487 | -193 | -28.38 | faster firefox | issue2504 | 13 | Page Request | 20 | 4 | 2 | -2 | -48.68 | faster firefox | issue2504 | 13 | Rendering | 20 | 676 | 485 | -191 | -28.28 | faster firefox | issue2504 | 14 | Overall | 20 | 474 | 283 | -191 | -40.26 | faster firefox | issue2504 | 14 | Page Request | 20 | 2 | 4 | 2 | 78.57 | firefox | issue2504 | 14 | Rendering | 20 | 471 | 279 | -192 | -40.79 | faster firefox | issue2504 | 15 | Overall | 20 | 860 | 618 | -241 | -28.05 | faster firefox | issue2504 | 15 | Page Request | 20 | 2 | 3 | 0 | 10.87 | firefox | issue2504 | 15 | Rendering | 20 | 857 | 616 | -241 | -28.15 | faster firefox | issue2504 | 16 | Overall | 20 | 389 | 243 | -147 | -37.71 | faster firefox | issue2504 | 16 | Page Request | 20 | 2 | 2 | 0 | 2.33 | firefox | issue2504 | 16 | Rendering | 20 | 387 | 240 | -147 | -37.94 | faster firefox | issue2504 | 17 | Overall | 20 | 1484 | 672 | -812 | -54.70 | faster firefox | issue2504 | 17 | Page Request | 20 | 2 | 3 | 1 | 37.21 | firefox | issue2504 | 17 | Rendering | 20 | 1482 | 669 | -812 | -54.84 | faster firefox | issue2504 | 18 | Overall | 20 | 575 | 252 | -323 | -56.12 | faster firefox | issue2504 | 18 | Page Request | 20 | 2 | 2 | 0 | -16.22 | firefox | issue2504 | 18 | Rendering | 20 | 573 | 251 | -322 | -56.24 | faster firefox | issue2504 | 19 | Overall | 20 | 517 | 227 | -290 | -56.08 | faster firefox | issue2504 | 19 | Page Request | 20 | 2 | 2 | 0 | 21.62 | firefox | issue2504 | 19 | Rendering | 20 | 515 | 225 | -290 | -56.37 | faster firefox | issue2504 | 20 | Overall | 20 | 668 | 670 | 2 | 0.31 | firefox | issue2504 | 20 | Page Request | 20 | 4 | 2 | -1 | -34.29 | firefox | issue2504 | 20 | Rendering | 20 | 664 | 667 | 3 | 0.49 | firefox | issue2504 | 21 | Overall | 20 | 486 | 309 | -177 | -36.44 | faster firefox | issue2504 | 21 | Page Request | 20 | 2 | 2 | 0 | 16.13 | firefox | issue2504 | 21 | Rendering | 20 | 484 | 307 | -177 | -36.60 | faster firefox | issue2504 | 22 | Overall | 20 | 543 | 267 | -276 | -50.85 | faster firefox | issue2504 | 22 | Page Request | 20 | 2 | 2 | 0 | 10.26 | firefox | issue2504 | 22 | Rendering | 20 | 541 | 265 | -276 | -51.07 | faster firefox | issue2504 | 23 | Overall | 20 | 3246 | 871 | -2375 | -73.17 | faster firefox | issue2504 | 23 | Page Request | 20 | 2 | 3 | 1 | 37.21 | firefox | issue2504 | 23 | Rendering | 20 | 3243 | 868 | -2376 | -73.25 | faster firefox | issue2504 | 24 | Overall | 20 | 379 | 156 | -223 | -58.83 | faster firefox | issue2504 | 24 | Page Request | 20 | 2 | 2 | 0 | -2.86 | firefox | issue2504 | 24 | Rendering | 20 | 378 | 154 | -223 | -59.10 | faster firefox | issue2504 | 25 | Overall | 20 | 176 | 127 | -50 | -28.19 | faster firefox | issue2504 | 25 | Page Request | 20 | 2 | 1 | 0 | -15.63 | firefox | issue2504 | 25 | Rendering | 20 | 175 | 125 | -49 | -28.31 | faster firefox | issue2504 | 26 | Overall | 20 | 181 | 108 | -74 | -40.67 | faster firefox | issue2504 | 26 | Page Request | 20 | 3 | 2 | -1 | -39.13 | faster firefox | issue2504 | 26 | Rendering | 20 | 178 | 105 | -72 | -40.69 | faster firefox | issue2504 | 27 | Overall | 20 | 208 | 104 | -104 | -49.92 | faster firefox | issue2504 | 27 | Page Request | 20 | 2 | 2 | 1 | 48.39 | firefox | issue2504 | 27 | Rendering | 20 | 206 | 102 | -104 | -50.64 | faster firefox | issue2504 | 28 | Overall | 20 | 241 | 111 | -131 | -54.16 | faster firefox | issue2504 | 28 | Page Request | 20 | 2 | 2 | -1 | -33.33 | firefox | issue2504 | 28 | Rendering | 20 | 239 | 109 | -130 | -54.39 | faster firefox | issue2504 | 29 | Overall | 20 | 321 | 196 | -125 | -39.05 | faster firefox | issue2504 | 29 | Page Request | 20 | 1 | 2 | 0 | 17.86 | firefox | issue2504 | 29 | Rendering | 20 | 319 | 194 | -126 | -39.35 | faster firefox | issue2504 | 30 | Overall | 20 | 651 | 271 | -380 | -58.41 | faster firefox | issue2504 | 30 | Page Request | 20 | 1 | 2 | 1 | 50.00 | firefox | issue2504 | 30 | Rendering | 20 | 649 | 269 | -381 | -58.60 | faster firefox | issue2504 | 31 | Overall | 20 | 1635 | 647 | -988 | -60.42 | faster firefox | issue2504 | 31 | Page Request | 20 | 1 | 2 | 0 | 30.43 | firefox | issue2504 | 31 | Rendering | 20 | 1634 | 645 | -988 | -60.49 | faster firefox | tracemonkey | 0 | Overall | 100 | 51 | 51 | 0 | 0.02 | firefox | tracemonkey | 0 | Page Request | 100 | 1 | 1 | 0 | -4.76 | firefox | tracemonkey | 0 | Rendering | 100 | 50 | 50 | 0 | 0.12 | firefox | tracemonkey | 1 | Overall | 100 | 97 | 91 | -5 | -5.52 | faster firefox | tracemonkey | 1 | Page Request | 100 | 3 | 3 | 0 | -1.32 | firefox | tracemonkey | 1 | Rendering | 100 | 94 | 88 | -5 | -5.73 | faster firefox | tracemonkey | 2 | Overall | 100 | 40 | 40 | 0 | 0.50 | firefox | tracemonkey | 2 | Page Request | 100 | 1 | 1 | 0 | 3.16 | firefox | tracemonkey | 2 | Rendering | 100 | 39 | 39 | 0 | 0.54 | firefox | tracemonkey | 3 | Overall | 100 | 62 | 62 | -1 | -0.94 | firefox | tracemonkey | 3 | Page Request | 100 | 1 | 1 | 0 | 17.05 | firefox | tracemonkey | 3 | Rendering | 100 | 61 | 61 | -1 | -1.11 | firefox | tracemonkey | 4 | Overall | 100 | 56 | 58 | 2 | 3.41 | firefox | tracemonkey | 4 | Page Request | 100 | 1 | 1 | 0 | 15.31 | firefox | tracemonkey | 4 | Rendering | 100 | 55 | 57 | 2 | 3.23 | firefox | tracemonkey | 5 | Overall | 100 | 73 | 71 | -2 | -2.28 | firefox | tracemonkey | 5 | Page Request | 100 | 2 | 2 | 0 | 12.20 | firefox | tracemonkey | 5 | Rendering | 100 | 71 | 69 | -2 | -2.69 | firefox | tracemonkey | 6 | Overall | 100 | 85 | 69 | -16 | -18.73 | faster firefox | tracemonkey | 6 | Page Request | 100 | 2 | 2 | 0 | -9.90 | firefox | tracemonkey | 6 | Rendering | 100 | 83 | 67 | -16 | -18.97 | faster firefox | tracemonkey | 7 | Overall | 100 | 65 | 64 | 0 | -0.37 | firefox | tracemonkey | 7 | Page Request | 100 | 1 | 1 | 0 | -11.94 | firefox | tracemonkey | 7 | Rendering | 100 | 63 | 63 | 0 | -0.05 | firefox | tracemonkey | 8 | Overall | 100 | 53 | 54 | 1 | 2.04 | firefox | tracemonkey | 8 | Page Request | 100 | 1 | 1 | 0 | 17.02 | firefox | tracemonkey | 8 | Rendering | 100 | 52 | 53 | 1 | 1.82 | firefox | tracemonkey | 9 | Overall | 100 | 79 | 73 | -6 | -7.86 | faster firefox | tracemonkey | 9 | Page Request | 100 | 2 | 2 | 0 | -15.14 | firefox | tracemonkey | 9 | Rendering | 100 | 77 | 71 | -6 | -7.86 | faster firefox | tracemonkey | 10 | Overall | 100 | 545 | 519 | -27 | -4.86 | faster firefox | tracemonkey | 10 | Page Request | 100 | 14 | 13 | 0 | -3.56 | firefox | tracemonkey | 10 | Rendering | 100 | 532 | 506 | -26 | -4.90 | faster firefox | tracemonkey | 11 | Overall | 100 | 42 | 41 | -1 | -2.50 | firefox | tracemonkey | 11 | Page Request | 100 | 1 | 1 | 0 | -27.42 | faster firefox | tracemonkey | 11 | Rendering | 100 | 41 | 40 | -1 | -1.75 | firefox | tracemonkey | 12 | Overall | 100 | 350 | 332 | -18 | -5.16 | faster firefox | tracemonkey | 12 | Page Request | 100 | 3 | 3 | 0 | -5.17 | firefox | tracemonkey | 12 | Rendering | 100 | 347 | 329 | -18 | -5.15 | faster firefox | tracemonkey | 13 | Overall | 100 | 31 | 31 | 0 | 0.52 | firefox | tracemonkey | 13 | Page Request | 100 | 1 | 1 | 0 | 4.95 | firefox | tracemonkey | 13 | Rendering | 100 | 30 | 30 | 0 | 0.20 | ```
2020-06-13 21:12:40 +09:00
stateManager,
localColorSpaceCache
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
)
);
Better errors capturing at the core and stop rendering on error.
2016-03-11 22:59:09 +09:00
return;
Adds Promise to the getOperatorList
2014-05-10 10:21:15 +09:00
case OPS.moveTo:
case OPS.lineTo:
case OPS.curveTo:
case OPS.curveTo2:
case OPS.curveTo3:
case OPS.closePath:
Combine re element into constructPath
2014-06-24 05:07:31 +09:00
case OPS.rectangle:
Attempt to handle corrupt PDF documents that contains path operators inside of text object (issue 10542) First of all, while this simple approach appears to work OK in practice I'm not sure if it's the best way of addressing the problem (assuming that you even want to). Second of all, while the solution implemented here only requires tracking/checking one new boolean in order for this to work, I'm nonetheless not entirely happy about this since it will add additional overhead (albeit *very* small) to the parsing of path operators in PDF documents just for a handful of *corrupt* ones.
2019-04-22 00:03:38 +09:00
self.buildPath(operatorList, fn, args, parsingText);
Combine re element into constructPath
2014-06-24 05:07:31 +09:00
continue;
Ignore operators that are known to be unsupported `operatorList.addOp` adds the arguments to the list which is then passed as-is by postMessage to the main thread. But since we don't parse these operations, they are raw PDF objects and may therefore cause a serialization error. This is a conservative patch, and only affects operators which are known to be unsupported. We should ignore all unknown operators, but I haven't really looked into the consequences of doing that. Fixes #6549
2015-10-21 22:39:25 +09:00
case OPS.markPoint:
case OPS.markPointProps:
case OPS.beginMarkedContent:
case OPS.beginMarkedContentProps:
case OPS.endMarkedContent:
case OPS.beginCompat:
case OPS.endCompat:
// Ignore operators where the corresponding handlers are known to
// be no-op in CanvasGraphics (display/canvas.js). This prevents
// serialization errors and is also a bit more efficient.
// We could also try to serialize all objects in a general way,
// e.g. as done in https://github.com/mozilla/pdf.js/pull/6266,
// but doing so is meaningless without knowing the semantics.
continue;
default:
Remove `getAll` from `EvaluatorPreprocessor_read` For the operators that we currently support, the arguments are not `Dict`s, which means that it's not really necessary to use `Dict_getAll` in `EvaluatorPreprocessor_read`. Also, I do think that if/when we support operators that use `Dict`s as arguments, that should be dealt with in the corresponding `case` in `PartialEvaluator_getOperatorList` which handles the operator. The only reason that I can find for using `Dict_getAll` like that, is that prior to PR 6550 we would just append certain (currently unsupported) operators without doing any further processing/checking. But as issue 6549 showed, that can lead to issues in practice, which is why it was changed. In an effort to prevent possible issue with unsupported operators, this patch simply ignores operators with `Dict` arguments in `PartialEvaluator_getOperatorList`.
2016-02-13 02:15:49 +09:00
// Note: Ignore the operator if it has `Dict` arguments, since
// those are non-serializable, otherwise postMessage will throw
Ignore operators that are known to be unsupported `operatorList.addOp` adds the arguments to the list which is then passed as-is by postMessage to the main thread. But since we don't parse these operations, they are raw PDF objects and may therefore cause a serialization error. This is a conservative patch, and only affects operators which are known to be unsupported. We should ignore all unknown operators, but I haven't really looked into the consequences of doing that. Fixes #6549
2015-10-21 22:39:25 +09:00
// "An object could not be cloned.".
Remove `getAll` from `EvaluatorPreprocessor_read` For the operators that we currently support, the arguments are not `Dict`s, which means that it's not really necessary to use `Dict_getAll` in `EvaluatorPreprocessor_read`. Also, I do think that if/when we support operators that use `Dict`s as arguments, that should be dealt with in the corresponding `case` in `PartialEvaluator_getOperatorList` which handles the operator. The only reason that I can find for using `Dict_getAll` like that, is that prior to PR 6550 we would just append certain (currently unsupported) operators without doing any further processing/checking. But as issue 6549 showed, that can lead to issues in practice, which is why it was changed. In an effort to prevent possible issue with unsupported operators, this patch simply ignores operators with `Dict` arguments in `PartialEvaluator_getOperatorList`.
2016-02-13 02:15:49 +09:00
if (args !== null) {
for (i = 0, ii = args.length; i < ii; i++) {
if (args[i] instanceof Dict) {
break;
}
}
if (i < ii) {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
warn("getOperatorList - ignoring operator: " + fn);
Remove `getAll` from `EvaluatorPreprocessor_read` For the operators that we currently support, the arguments are not `Dict`s, which means that it's not really necessary to use `Dict_getAll` in `EvaluatorPreprocessor_read`. Also, I do think that if/when we support operators that use `Dict`s as arguments, that should be dealt with in the corresponding `case` in `PartialEvaluator_getOperatorList` which handles the operator. The only reason that I can find for using `Dict_getAll` like that, is that prior to PR 6550 we would just append certain (currently unsupported) operators without doing any further processing/checking. But as issue 6549 showed, that can lead to issues in practice, which is why it was changed. In an effort to prevent possible issue with unsupported operators, this patch simply ignores operators with `Dict` arguments in `PartialEvaluator_getOperatorList`.
2016-02-13 02:15:49 +09:00
continue;
}
}
Adds Promise to the getOperatorList
2014-05-10 10:21:15 +09:00
}
operatorList.addOp(fn, args);
}
Terminate getOperationList and getTextContent every 20 ms
2014-05-10 10:41:03 +09:00
if (stop) {
Better errors capturing at the core and stop rendering on error.
2016-03-11 22:59:09 +09:00
next(deferred);
Terminate getOperationList and getTextContent every 20 ms
2014-05-10 10:41:03 +09:00
return;
}
Adds Promise to the getOperatorList
2014-05-10 10:21:15 +09:00
// Some PDFs don't close all restores inside object/form.
// Closing those for them.
[api-minor] Always allow e.g. rendering to continue even if there are errors, and add a `stopAtErrors` parameter to `getDocument` to opt-out of this behaviour (issue 6342, issue 3795, bug 1130815) Other PDF readers, e.g. Adobe Reader and PDFium (in Chrome), will attempt to render as much of a page as possible even if there are errors present. Currently we just bail as soon the first error is hit, which means that we'll usually not render anything in these cases and just display a blank page instead. NOTE: This patch changes the default behaviour of the PDF.js API to always attempt to recover as much data as possible, even when encountering errors during e.g. `getOperatorList`/`getTextContent`, which thus improve our handling of corrupt PDF files and allow the default viewer to handle errors slightly more gracefully. In the event that an API consumer wishes to use the old behaviour, where we stop parsing as soon as an error is encountered, the `stopAtErrors` parameter can be set at `getDocument`. Fixes, inasmuch it's possible since the PDF files are corrupt, e.g. issue 6342, issue 3795, and [bug 1130815](https://bugzilla.mozilla.org/show_bug.cgi?id=1130815) (and probably others too).
2017-02-19 22:03:08 +09:00
closePendingRestoreOPS();
Adds Promise to the getOperatorList
2014-05-10 10:21:15 +09:00
resolve();
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
}).catch(reason => {
Use streams for OperatorList chunking (issue 10023) *Please note:* The majority of this patch was written by Yury, and it's simply been rebased and slightly extended to prevent issues when dealing with `RenderingCancelledException`. By leveraging streams this (finally) provides a simple way in which parsing can be aborted on the worker-thread, which will ultimately help save resources. With this patch worker-thread parsing will *only* be aborted when the document is destroyed, and not when rendering is cancelled. There's a couple of reasons for this: - The API currently expects the *entire* OperatorList to be extracted, or an Error to occur, once it's been started. Hence additional re-factoring/re-writing of the API code will be necessary to properly support cancelling and re-starting of OperatorList parsing in cases where the `lastChunk` hasn't yet been seen. - Even with the above addressed, immediately cancelling when encountering a `RenderingCancelledException` will lead to worse performance in e.g. the default viewer. When zooming and/or rotation of the document occurs it's very likely that `cancel` will be (almost) immediately followed by a new `render` call. In that case you'd obviously *not* want to abort parsing on the worker-thread, since then you'd risk throwing away a partially parsed Page and thus be forced to re-parse it again which will regress perceived performance. - This patch is already *somewhat* risky, given that it touches fundamentally important/critical code, and trying to keep it somewhat small should hopefully reduce the risk of regressions (and simplify reviewing as well). Time permitting, once this has landed and been in Nightly for awhile, I'll try to work on the remaining points outlined above. Co-Authored-By: Yury Delendik <ydelendik@mozilla.com> Co-Authored-By: Jonas Jenwald <jonas.jenwald@gmail.com>
2017-11-10 10:58:43 +09:00
if (reason instanceof AbortException) {
return;
}
[api-minor] Always allow e.g. rendering to continue even if there are errors, and add a `stopAtErrors` parameter to `getDocument` to opt-out of this behaviour (issue 6342, issue 3795, bug 1130815) Other PDF readers, e.g. Adobe Reader and PDFium (in Chrome), will attempt to render as much of a page as possible even if there are errors present. Currently we just bail as soon the first error is hit, which means that we'll usually not render anything in these cases and just display a blank page instead. NOTE: This patch changes the default behaviour of the PDF.js API to always attempt to recover as much data as possible, even when encountering errors during e.g. `getOperatorList`/`getTextContent`, which thus improve our handling of corrupt PDF files and allow the default viewer to handle errors slightly more gracefully. In the event that an API consumer wishes to use the old behaviour, where we stop parsing as soon as an error is encountered, the `stopAtErrors` parameter can be set at `getDocument`. Fixes, inasmuch it's possible since the PDF files are corrupt, e.g. issue 6342, issue 3795, and [bug 1130815](https://bugzilla.mozilla.org/show_bug.cgi?id=1130815) (and probably others too).
2017-02-19 22:03:08 +09:00
if (this.options.ignoreErrors) {
// Error(s) in the OperatorList -- sending unsupported feature
// notification and allow rendering to continue.
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
this.handler.send("UnsupportedFeature", {
Add more categories of unsupported features. Fixes #11815
2020-05-01 07:27:37 +09:00
featureId: UNSUPPORTED_FEATURES.errorOperatorList,
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
});
warn(
`getOperatorList - ignoring errors during "${task.name}" ` +
`task: "${reason}".`
);
[api-minor] Always allow e.g. rendering to continue even if there are errors, and add a `stopAtErrors` parameter to `getDocument` to opt-out of this behaviour (issue 6342, issue 3795, bug 1130815) Other PDF readers, e.g. Adobe Reader and PDFium (in Chrome), will attempt to render as much of a page as possible even if there are errors present. Currently we just bail as soon the first error is hit, which means that we'll usually not render anything in these cases and just display a blank page instead. NOTE: This patch changes the default behaviour of the PDF.js API to always attempt to recover as much data as possible, even when encountering errors during e.g. `getOperatorList`/`getTextContent`, which thus improve our handling of corrupt PDF files and allow the default viewer to handle errors slightly more gracefully. In the event that an API consumer wishes to use the old behaviour, where we stop parsing as soon as an error is encountered, the `stopAtErrors` parameter can be set at `getDocument`. Fixes, inasmuch it's possible since the PDF files are corrupt, e.g. issue 6342, issue 3795, and [bug 1130815](https://bugzilla.mozilla.org/show_bug.cgi?id=1130815) (and probably others too).
2017-02-19 22:03:08 +09:00
closePendingRestoreOPS();
return;
}
throw reason;
Replace unnecessary `bind(this)` and `var self = this` statements with arrow functions in `src/core/evaluator.js` Note that by using `let` instead of `var` in `PartialEvaluator.setGState` and `TranslatedFont.loadType3Data`, we can get rid of further `bind` usages since `let` is block-scoped. Also, the fact that `bind` wasn't used in the `Font` case inside of `setGState` is actually a bug which has been present ever since PR 5205, where a closure was replaced by a standard loop.[1] --- [1] I'm not aware of any bugs caused by this, but that is probably more a happy accident than anything else, since e.g. just removing the `bind` from the `SMask` case without using block-scoped variables causes test failures.
2017-04-30 06:36:43 +09:00
});
Splitting files
2011-10-25 08:55:23 +09:00
},
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
getTextContent({
stream,
task,
resources,
stateManager = null,
normalizeWhitespace = false,
combineTextItems = false,
sink,
seenStyles = Object.create(null),
}) {
Change the signatures of the `PartialEvaluator` "constructor" and its `getOperatorList`/`getTextContent` methods to take parameter objects Currently these methods accept a large number of parameters, which creates quite unwieldy call-sites. When invoking them, you have to remember not only what arguments to supply, but also the correct order, to avoid runtime errors. Furthermore, since some of the parameters are optional, you also have to remember to pass e.g. `null` or `undefined` for those ones. Also, adding new parameters to these methods (which happens occasionally), often becomes unnecessarily tedious (based on personal experience). Please note that I do *not* think that we need/should convert *every* single method in `evaluator.js` (or elsewhere in `/core` files) to take parameter objects. However, in my opinion, once a method starts relying on approximately five parameter (or even more), passing them in individually becomes quite cumbersome. With these changes, I obviously needed to update the `evaluator_spec.js` unit-tests. The main change there, except the new method signatures[1], is that it's now re-using *one* `PartialEvalutor` instance, since I couldn't see any compelling reason for creating a new one in every single test. *Note:* If this patch is accepted, my intention is to (time permitting) see if it makes sense to convert additional methods in `evaluator.js` (and other `/core` files) in a similar fashion, but I figured that it'd be a good idea to limit the initial scope somewhat. --- [1] A fun fact here, note how the `PartialEvaluator` signature used in `evaluator_spec.js` wasn't even correct in the current `master`.
2017-04-30 06:13:51 +09:00
// Ensure that `resources`/`stateManager` is correctly initialized,
// even if the provided parameter is e.g. `null`.
resources = resources || Dict.empty;
stateManager = stateManager || new StateManager(new TextState());
Refactors getTextContent return value
2014-01-18 04:26:00 +09:00
[api-minor] Add a parameter to `PDFPageProxy_getTextContent` that enables replacing of all whitespace with standard spaces in the textLayer (issue 6612) This patch goes a bit further than issue 6612 requires, and replaces all kinds of whitespace with standard spaces. When testing this locally, it actually seemed to slightly improve two existing test-cases (`tracemonkey-text` and `taro-text`). Fixes 6612.
2015-11-24 00:57:43 +09:00
var WhitespaceRegexp = /\s/g;
Build the text layer geometry on the worker.
2014-04-10 08:44:07 +09:00
var textContent = {
items: [],
Fix inconsistent spacing and trailing commas in objects in `src/core/` files, so we can enable the `comma-dangle` and `object-curly-spacing` ESLint rules later on *Unfortunately this patch is fairly big, even though it only covers the `src/core` folder, but splitting it even further seemed difficult.* http://eslint.org/docs/rules/comma-dangle http://eslint.org/docs/rules/object-curly-spacing Given that we currently have quite inconsistent object formatting, fixing this in *one* big patch probably wouldn't be feasible (since I cannot imagine anyone wanting to review that); hence I've opted to try and do this piecewise instead. Please note: This patch was created automatically, using the ESLint --fix command line option. In a couple of places this caused lines to become too long, and I've fixed those manually; please refer to the interdiff below for the only hand-edits in this patch. ```diff diff --git a/src/core/evaluator.js b/src/core/evaluator.js index abab9027..dcd3594b 100644 --- a/src/core/evaluator.js +++ b/src/core/evaluator.js @@ -2785,7 +2785,8 @@ var EvaluatorPreprocessor = (function EvaluatorPreprocessorClosure() { t['Tz'] = { id: OPS.setHScale, numArgs: 1, variableArgs: false, }; t['TL'] = { id: OPS.setLeading, numArgs: 1, variableArgs: false, }; t['Tf'] = { id: OPS.setFont, numArgs: 2, variableArgs: false, }; - t['Tr'] = { id: OPS.setTextRenderingMode, numArgs: 1, variableArgs: false, }; + t['Tr'] = { id: OPS.setTextRenderingMode, numArgs: 1, + variableArgs: false, }; t['Ts'] = { id: OPS.setTextRise, numArgs: 1, variableArgs: false, }; t['Td'] = { id: OPS.moveText, numArgs: 2, variableArgs: false, }; t['TD'] = { id: OPS.setLeadingMoveText, numArgs: 2, variableArgs: false, }; diff --git a/src/core/jbig2.js b/src/core/jbig2.js index 5a17d482..71671541 100644 --- a/src/core/jbig2.js +++ b/src/core/jbig2.js @@ -123,19 +123,22 @@ var Jbig2Image = (function Jbig2ImageClosure() { { x: -1, y: -1, }, { x: 0, y: -1, }, { x: 1, y: -1, }, { x: -2, y: 0, }, { x: -1, y: 0, }], [{ x: -3, y: -1, }, { x: -2, y: -1, }, { x: -1, y: -1, }, { x: 0, y: -1, }, - { x: 1, y: -1, }, { x: -4, y: 0, }, { x: -3, y: 0, }, { x: -2, y: 0, }, { x: -1, y: 0, }] + { x: 1, y: -1, }, { x: -4, y: 0, }, { x: -3, y: 0, }, { x: -2, y: 0, }, + { x: -1, y: 0, }] ]; var RefinementTemplates = [ { coding: [{ x: 0, y: -1, }, { x: 1, y: -1, }, { x: -1, y: 0, }], - reference: [{ x: 0, y: -1, }, { x: 1, y: -1, }, { x: -1, y: 0, }, { x: 0, y: 0, }, - { x: 1, y: 0, }, { x: -1, y: 1, }, { x: 0, y: 1, }, { x: 1, y: 1, }], + reference: [{ x: 0, y: -1, }, { x: 1, y: -1, }, { x: -1, y: 0, }, + { x: 0, y: 0, }, { x: 1, y: 0, }, { x: -1, y: 1, }, + { x: 0, y: 1, }, { x: 1, y: 1, }], }, { - coding: [{ x: -1, y: -1, }, { x: 0, y: -1, }, { x: 1, y: -1, }, { x: -1, y: 0, }], - reference: [{ x: 0, y: -1, }, { x: -1, y: 0, }, { x: 0, y: 0, }, { x: 1, y: 0, }, - { x: 0, y: 1, }, { x: 1, y: 1, }], + coding: [{ x: -1, y: -1, }, { x: 0, y: -1, }, { x: 1, y: -1, }, + { x: -1, y: 0, }], + reference: [{ x: 0, y: -1, }, { x: -1, y: 0, }, { x: 0, y: 0, }, + { x: 1, y: 0, }, { x: 0, y: 1, }, { x: 1, y: 1, }], } ]; ```
2017-06-02 18:16:24 +09:00
styles: Object.create(null),
Build the text layer geometry on the worker.
2014-04-10 08:44:07 +09:00
};
Combines standalone divs into text groups.
2015-11-04 01:12:41 +09:00
var textContentItem = {
initialized: false,
str: [],
width: 0,
height: 0,
vertical: false,
lastAdvanceWidth: 0,
lastAdvanceHeight: 0,
textAdvanceScale: 0,
Refactors fake space heuristics for speed.
2015-11-06 23:40:44 +09:00
spaceWidth: 0,
fakeSpaceMin: Infinity,
fakeMultiSpaceMin: Infinity,
fakeMultiSpaceMax: -0,
textRunBreakAllowed: false,
Combines standalone divs into text groups.
2015-11-04 01:12:41 +09:00
transform: null,
Fix inconsistent spacing and trailing commas in objects in `src/core/` files, so we can enable the `comma-dangle` and `object-curly-spacing` ESLint rules later on *Unfortunately this patch is fairly big, even though it only covers the `src/core` folder, but splitting it even further seemed difficult.* http://eslint.org/docs/rules/comma-dangle http://eslint.org/docs/rules/object-curly-spacing Given that we currently have quite inconsistent object formatting, fixing this in *one* big patch probably wouldn't be feasible (since I cannot imagine anyone wanting to review that); hence I've opted to try and do this piecewise instead. Please note: This patch was created automatically, using the ESLint --fix command line option. In a couple of places this caused lines to become too long, and I've fixed those manually; please refer to the interdiff below for the only hand-edits in this patch. ```diff diff --git a/src/core/evaluator.js b/src/core/evaluator.js index abab9027..dcd3594b 100644 --- a/src/core/evaluator.js +++ b/src/core/evaluator.js @@ -2785,7 +2785,8 @@ var EvaluatorPreprocessor = (function EvaluatorPreprocessorClosure() { t['Tz'] = { id: OPS.setHScale, numArgs: 1, variableArgs: false, }; t['TL'] = { id: OPS.setLeading, numArgs: 1, variableArgs: false, }; t['Tf'] = { id: OPS.setFont, numArgs: 2, variableArgs: false, }; - t['Tr'] = { id: OPS.setTextRenderingMode, numArgs: 1, variableArgs: false, }; + t['Tr'] = { id: OPS.setTextRenderingMode, numArgs: 1, + variableArgs: false, }; t['Ts'] = { id: OPS.setTextRise, numArgs: 1, variableArgs: false, }; t['Td'] = { id: OPS.moveText, numArgs: 2, variableArgs: false, }; t['TD'] = { id: OPS.setLeadingMoveText, numArgs: 2, variableArgs: false, }; diff --git a/src/core/jbig2.js b/src/core/jbig2.js index 5a17d482..71671541 100644 --- a/src/core/jbig2.js +++ b/src/core/jbig2.js @@ -123,19 +123,22 @@ var Jbig2Image = (function Jbig2ImageClosure() { { x: -1, y: -1, }, { x: 0, y: -1, }, { x: 1, y: -1, }, { x: -2, y: 0, }, { x: -1, y: 0, }], [{ x: -3, y: -1, }, { x: -2, y: -1, }, { x: -1, y: -1, }, { x: 0, y: -1, }, - { x: 1, y: -1, }, { x: -4, y: 0, }, { x: -3, y: 0, }, { x: -2, y: 0, }, { x: -1, y: 0, }] + { x: 1, y: -1, }, { x: -4, y: 0, }, { x: -3, y: 0, }, { x: -2, y: 0, }, + { x: -1, y: 0, }] ]; var RefinementTemplates = [ { coding: [{ x: 0, y: -1, }, { x: 1, y: -1, }, { x: -1, y: 0, }], - reference: [{ x: 0, y: -1, }, { x: 1, y: -1, }, { x: -1, y: 0, }, { x: 0, y: 0, }, - { x: 1, y: 0, }, { x: -1, y: 1, }, { x: 0, y: 1, }, { x: 1, y: 1, }], + reference: [{ x: 0, y: -1, }, { x: 1, y: -1, }, { x: -1, y: 0, }, + { x: 0, y: 0, }, { x: 1, y: 0, }, { x: -1, y: 1, }, + { x: 0, y: 1, }, { x: 1, y: 1, }], }, { - coding: [{ x: -1, y: -1, }, { x: 0, y: -1, }, { x: 1, y: -1, }, { x: -1, y: 0, }], - reference: [{ x: 0, y: -1, }, { x: -1, y: 0, }, { x: 0, y: 0, }, { x: 1, y: 0, }, - { x: 0, y: 1, }, { x: 1, y: 1, }], + coding: [{ x: -1, y: -1, }, { x: 0, y: -1, }, { x: 1, y: -1, }, + { x: -1, y: 0, }], + reference: [{ x: 0, y: -1, }, { x: -1, y: 0, }, { x: 0, y: 0, }, + { x: 1, y: 0, }, { x: 0, y: 1, }, { x: 1, y: 1, }], } ]; ```
2017-06-02 18:16:24 +09:00
fontName: null,
Combines standalone divs into text groups.
2015-11-04 01:12:41 +09:00
};
Lower threshold Fixes text selection formatting with https://github.com/vortext/vortext/blob/master/resources/public/examples/TestDocument3.pdf
2015-02-14 15:27:17 +09:00
var SPACE_FACTOR = 0.3;
Refactor names in various files. web/viewer.js src/fonts.js (& remove unused global) src/evaluator.js src/canvas.js
2012-11-10 06:34:11 +09:00
var MULTI_SPACE_FACTOR = 1.5;
Refactors fake space heuristics for speed.
2015-11-06 23:40:44 +09:00
var MULTI_SPACE_FACTOR_MAX = 4;
Text char codes extraction
2011-12-11 08:24:54 +09:00
Incrementally render by sending the operator list by chunks as they're ready.
2013-08-01 03:17:36 +09:00
var self = this;
var xref = this.xref;
Make getTextContent return offset array and improve the algorithm. Make parts in viewer.js work again.
2012-09-12 07:10:34 +09:00
// The xobj is parsed iff it's needed, e.g. if there is a `DO` cmd.
var xobjs = null;
Improve caching of empty `/XObject`s in the `PartialEvaluator.getTextContent` method It turns out that `getTextContent` suffers from *similar* problems with repeated images as `getOperatorList`; please see the previous patch. While only `/XObject` resources of the `Form`-type will actually be *parsed* in `PartialEvaluator.getTextContent`, since those are the only ones that may contain text, we're still forced to fetch repeated image resources where the name differs (but not the reference). Obviously it's less bad in this case, since we're not actually parsing `/XObject`s of e.g. the `Image`-type. However, you still want to avoid even fetching the data whenever possible, since `Stream`s are not cached on the `XRef` instance (given their potential size) and the lookup can thus be somewhat expensive in general. To address these issues, we can simply replace the exiting name-only caching in `PartialEvaluator.getTextContent` with a new cache backed by `LocalImageCache` instead.
2020-05-26 16:47:59 +09:00
const emptyXObjectCache = new LocalImageCache();
Text char codes extraction
2011-12-11 08:24:54 +09:00
Build the text layer geometry on the worker.
2014-04-10 08:44:07 +09:00
var preprocessor = new EvaluatorPreprocessor(stream, xref, stateManager);
Make getOperatorList() calls independent and merge queues at end
2013-04-09 07:14:56 +09:00
Build the text layer geometry on the worker.
2014-04-10 08:44:07 +09:00
var textState;
Combines standalone divs into text groups.
2015-11-04 01:12:41 +09:00
function ensureTextContentItem() {
if (textContentItem.initialized) {
return textContentItem;
}
Build the text layer geometry on the worker.
2014-04-10 08:44:07 +09:00
var font = textState.font;
Adds Streams API in getTextContent to stream data. This patch adds Streams API support in getTextContent so that we can stream data in chunks instead of fetching whole data from worker thread to main thread. This patch supports Streams API without changing the core functionality of getTextContent. Enqueue textContent directly at getTextContent in partialEvaluator. Adds desiredSize and ready property in streamSink.
2017-04-17 21:46:53 +09:00
if (!(font.loadedName in seenStyles)) {
seenStyles[font.loadedName] = true;
Build the text layer geometry on the worker.
2014-04-10 08:44:07 +09:00
textContent.styles[font.loadedName] = {
fontFamily: font.fallbackName,
ascent: font.ascent,
descent: font.descent,
Ensure that all `Font` instances have the `vertical` property set to a boolean Given that the `vertical` property is always accessed on the main-thread, ensuring that the property is explicitly defined seems like the correct thing to do since it also avoids boolean casting elsewhere in the code-base.
2020-04-01 20:40:35 +09:00
vertical: font.vertical,
Build the text layer geometry on the worker.
2014-04-10 08:44:07 +09:00
};
}
Combines standalone divs into text groups.
2015-11-04 01:12:41 +09:00
textContentItem.fontName = font.loadedName;
// 9.4.4 Text Space Details
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
var tsm = [
textState.fontSize * textState.textHScale,
0,
0,
textState.fontSize,
0,
textState.textRise,
];
if (
font.isType3Font &&
textState.fontSize <= 1 &&
!isArrayEqual(textState.fontMatrix, FONT_IDENTITY_MATRIX)
) {
Try to improve text-selection for Type3 fonts that utilize a non-default /FontMatrix (bug 1513120) For Type3 fonts text-selection is often not that great, and there's a couple of heuristics used to try and improve things. This patch simple extends those heuristics a bit, and fixes a pre-existing "naive" array comparison, but this all feels a bit brittle to say the least. The existing Type3 test-coverage isn't that great in general, and in particular Type3 `text` tests are few and far between, hence why this patch adds *two* different new `text` tests.
2019-03-08 20:55:44 +09:00
const glyphHeight = font.bbox[3] - font.bbox[1];
Combines standalone divs into text groups.
2015-11-04 01:12:41 +09:00
if (glyphHeight > 0) {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
tsm[3] *= glyphHeight * textState.fontMatrix[3];
Combines standalone divs into text groups.
2015-11-04 01:12:41 +09:00
}
}
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
var trm = Util.transform(
textState.ctm,
Util.transform(textState.textMatrix, tsm)
);
Combines standalone divs into text groups.
2015-11-04 01:12:41 +09:00
textContentItem.transform = trm;
if (!font.vertical) {
textContentItem.width = 0;
textContentItem.height = Math.sqrt(trm[2] * trm[2] + trm[3] * trm[3]);
textContentItem.vertical = false;
} else {
textContentItem.width = Math.sqrt(trm[0] * trm[0] + trm[1] * trm[1]);
textContentItem.height = 0;
textContentItem.vertical = true;
}
var a = textState.textLineMatrix[0];
var b = textState.textLineMatrix[1];
var scaleLineX = Math.sqrt(a * a + b * b);
a = textState.ctm[0];
b = textState.ctm[1];
var scaleCtmX = Math.sqrt(a * a + b * b);
textContentItem.textAdvanceScale = scaleCtmX * scaleLineX;
textContentItem.lastAdvanceWidth = 0;
textContentItem.lastAdvanceHeight = 0;
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
var spaceWidth = (font.spaceWidth / 1000) * textState.fontSize;
Refactors fake space heuristics for speed.
2015-11-06 23:40:44 +09:00
if (spaceWidth) {
textContentItem.spaceWidth = spaceWidth;
textContentItem.fakeSpaceMin = spaceWidth * SPACE_FACTOR;
textContentItem.fakeMultiSpaceMin = spaceWidth * MULTI_SPACE_FACTOR;
textContentItem.fakeMultiSpaceMax =
spaceWidth * MULTI_SPACE_FACTOR_MAX;
// It's okay for monospace fonts to fake as much space as needed.
textContentItem.textRunBreakAllowed = !font.isMonospace;
} else {
textContentItem.spaceWidth = 0;
textContentItem.fakeSpaceMin = Infinity;
textContentItem.fakeMultiSpaceMin = Infinity;
textContentItem.fakeMultiSpaceMax = 0;
textContentItem.textRunBreakAllowed = false;
}
Combines standalone divs into text groups.
2015-11-04 01:12:41 +09:00
textContentItem.initialized = true;
return textContentItem;
Build the text layer geometry on the worker.
2014-04-10 08:44:07 +09:00
}
[api-minor] Add a parameter to `PDFPageProxy_getTextContent` that enables replacing of all whitespace with standard spaces in the textLayer (issue 6612) This patch goes a bit further than issue 6612 requires, and replaces all kinds of whitespace with standard spaces. When testing this locally, it actually seemed to slightly improve two existing test-cases (`tracemonkey-text` and `taro-text`). Fixes 6612.
2015-11-24 00:57:43 +09:00
function replaceWhitespace(str) {
// Replaces all whitespaces with standard spaces (0x20), to avoid
// alignment issues between the textLayer and the canvas if the text
// contains e.g. tabs (fixes issue6612.pdf).
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
var i = 0,
ii = str.length,
code;
while (i < ii && (code = str.charCodeAt(i)) >= 0x20 && code <= 0x7f) {
[api-minor] Add a parameter to `PDFPageProxy_getTextContent` that enables replacing of all whitespace with standard spaces in the textLayer (issue 6612) This patch goes a bit further than issue 6612 requires, and replaces all kinds of whitespace with standard spaces. When testing this locally, it actually seemed to slightly improve two existing test-cases (`tracemonkey-text` and `taro-text`). Fixes 6612.
2015-11-24 00:57:43 +09:00
i++;
}
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
return i < ii ? str.replace(WhitespaceRegexp, " ") : str;
[api-minor] Add a parameter to `PDFPageProxy_getTextContent` that enables replacing of all whitespace with standard spaces in the textLayer (issue 6612) This patch goes a bit further than issue 6612 requires, and replaces all kinds of whitespace with standard spaces. When testing this locally, it actually seemed to slightly improve two existing test-cases (`tracemonkey-text` and `taro-text`). Fixes 6612.
2015-11-24 00:57:43 +09:00
}
Combines standalone divs into text groups.
2015-11-04 01:12:41 +09:00
function runBidiTransform(textChunk) {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
var str = textChunk.str.join("");
Removes global PDFJS usage from the src/core/.
2016-03-03 09:48:21 +09:00
var bidiResult = bidi(str, -1, textChunk.vertical);
Combines standalone divs into text groups.
2015-11-04 01:12:41 +09:00
return {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
str: normalizeWhitespace
? replaceWhitespace(bidiResult.str)
: bidiResult.str,
Combines standalone divs into text groups.
2015-11-04 01:12:41 +09:00
dir: bidiResult.dir,
width: textChunk.width,
height: textChunk.height,
transform: textChunk.transform,
Fix inconsistent spacing and trailing commas in objects in `src/core/` files, so we can enable the `comma-dangle` and `object-curly-spacing` ESLint rules later on *Unfortunately this patch is fairly big, even though it only covers the `src/core` folder, but splitting it even further seemed difficult.* http://eslint.org/docs/rules/comma-dangle http://eslint.org/docs/rules/object-curly-spacing Given that we currently have quite inconsistent object formatting, fixing this in *one* big patch probably wouldn't be feasible (since I cannot imagine anyone wanting to review that); hence I've opted to try and do this piecewise instead. Please note: This patch was created automatically, using the ESLint --fix command line option. In a couple of places this caused lines to become too long, and I've fixed those manually; please refer to the interdiff below for the only hand-edits in this patch. ```diff diff --git a/src/core/evaluator.js b/src/core/evaluator.js index abab9027..dcd3594b 100644 --- a/src/core/evaluator.js +++ b/src/core/evaluator.js @@ -2785,7 +2785,8 @@ var EvaluatorPreprocessor = (function EvaluatorPreprocessorClosure() { t['Tz'] = { id: OPS.setHScale, numArgs: 1, variableArgs: false, }; t['TL'] = { id: OPS.setLeading, numArgs: 1, variableArgs: false, }; t['Tf'] = { id: OPS.setFont, numArgs: 2, variableArgs: false, }; - t['Tr'] = { id: OPS.setTextRenderingMode, numArgs: 1, variableArgs: false, }; + t['Tr'] = { id: OPS.setTextRenderingMode, numArgs: 1, + variableArgs: false, }; t['Ts'] = { id: OPS.setTextRise, numArgs: 1, variableArgs: false, }; t['Td'] = { id: OPS.moveText, numArgs: 2, variableArgs: false, }; t['TD'] = { id: OPS.setLeadingMoveText, numArgs: 2, variableArgs: false, }; diff --git a/src/core/jbig2.js b/src/core/jbig2.js index 5a17d482..71671541 100644 --- a/src/core/jbig2.js +++ b/src/core/jbig2.js @@ -123,19 +123,22 @@ var Jbig2Image = (function Jbig2ImageClosure() { { x: -1, y: -1, }, { x: 0, y: -1, }, { x: 1, y: -1, }, { x: -2, y: 0, }, { x: -1, y: 0, }], [{ x: -3, y: -1, }, { x: -2, y: -1, }, { x: -1, y: -1, }, { x: 0, y: -1, }, - { x: 1, y: -1, }, { x: -4, y: 0, }, { x: -3, y: 0, }, { x: -2, y: 0, }, { x: -1, y: 0, }] + { x: 1, y: -1, }, { x: -4, y: 0, }, { x: -3, y: 0, }, { x: -2, y: 0, }, + { x: -1, y: 0, }] ]; var RefinementTemplates = [ { coding: [{ x: 0, y: -1, }, { x: 1, y: -1, }, { x: -1, y: 0, }], - reference: [{ x: 0, y: -1, }, { x: 1, y: -1, }, { x: -1, y: 0, }, { x: 0, y: 0, }, - { x: 1, y: 0, }, { x: -1, y: 1, }, { x: 0, y: 1, }, { x: 1, y: 1, }], + reference: [{ x: 0, y: -1, }, { x: 1, y: -1, }, { x: -1, y: 0, }, + { x: 0, y: 0, }, { x: 1, y: 0, }, { x: -1, y: 1, }, + { x: 0, y: 1, }, { x: 1, y: 1, }], }, { - coding: [{ x: -1, y: -1, }, { x: 0, y: -1, }, { x: 1, y: -1, }, { x: -1, y: 0, }], - reference: [{ x: 0, y: -1, }, { x: -1, y: 0, }, { x: 0, y: 0, }, { x: 1, y: 0, }, - { x: 0, y: 1, }, { x: 1, y: 1, }], + coding: [{ x: -1, y: -1, }, { x: 0, y: -1, }, { x: 1, y: -1, }, + { x: -1, y: 0, }], + reference: [{ x: 0, y: -1, }, { x: -1, y: 0, }, { x: 0, y: 0, }, + { x: 1, y: 0, }, { x: 0, y: 1, }, { x: 1, y: 1, }], } ]; ```
2017-06-02 18:16:24 +09:00
fontName: textChunk.fontName,
Combines standalone divs into text groups.
2015-11-04 01:12:41 +09:00
};
Build the text layer geometry on the worker.
2014-04-10 08:44:07 +09:00
}
function handleSetFont(fontName, fontRef) {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
return self
.loadFont(fontName, fontRef, resources)
Update Prettier to version 2.0 Please note that these changes were done automatically, using `gulp lint --fix`. Given that the major version number was increased, there's a fair number of (primarily whitespace) changes; please see https://prettier.io/blog/2020/03/21/2.0.0.html In order to reduce the size of these changes somewhat, this patch maintains the old "arrowParens" style for now (once mozilla-central updates Prettier we can simply choose the same formatting, assuming it will differ here).
2020-04-14 19:28:14 +09:00
.then(function (translated) {
Refactors loadFont for translateFont be async; fixes type3 dup data
2014-05-20 06:27:54 +09:00
textState.font = translated.font;
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
textState.fontMatrix =
translated.font.fontMatrix || FONT_IDENTITY_MATRIX;
Adds Promise to the getOperatorList
2014-05-10 10:21:15 +09:00
});
Build the text layer geometry on the worker.
2014-04-10 08:44:07 +09:00
}
Combines standalone divs into text groups.
2015-11-04 01:12:41 +09:00
function buildTextContentItem(chars) {
Build the text layer geometry on the worker.
2014-04-10 08:44:07 +09:00
var font = textState.font;
Combines standalone divs into text groups.
2015-11-04 01:12:41 +09:00
var textChunk = ensureTextContentItem();
Build the text layer geometry on the worker.
2014-04-10 08:44:07 +09:00
var width = 0;
var height = 0;
var glyphs = font.charsToGlyphs(chars);
for (var i = 0; i < glyphs.length; i++) {
var glyph = glyphs[i];
var glyphWidth = null;
Enable the `no-unused-vars` ESLint rule Please see http://eslint.org/docs/rules/no-unused-vars; note that this patch purposely uses the same rule options as in `mozilla-central`, such that it fixes part of issue 7957. It wasn't, in my opinion, entirely straightforward to enable this rule compared to the already existing rules. In many cases a `var descriptiveName = ...` format was used (more or less) to document the code, and I choose to place the old variable name in a trailing comment to not lose that information. I welcome feedback on these changes, since it wasn't always entirely easy to know what changes made the most sense in every situation.
2017-01-19 22:00:36 +09:00
if (font.vertical && glyph.vmetric) {
glyphWidth = glyph.vmetric[0];
Build the text layer geometry on the worker.
2014-04-10 08:44:07 +09:00
} else {
glyphWidth = glyph.width;
}
var glyphUnicode = glyph.unicode;
Lazify NormalizedUnicodes
2016-01-22 07:10:42 +09:00
var NormalizedUnicodes = getNormalizedUnicodes();
evaluator.js minor optimizations
2014-06-02 19:43:20 +09:00
if (NormalizedUnicodes[glyphUnicode] !== undefined) {
Build the text layer geometry on the worker.
2014-04-10 08:44:07 +09:00
glyphUnicode = NormalizedUnicodes[glyphUnicode];
}
glyphUnicode = reverseIfRtl(glyphUnicode);
Better spacing in text layer.
2015-11-02 23:54:15 +09:00
var charSpacing = textState.charSpacing;
if (glyph.isSpace) {
var wordSpacing = textState.wordSpacing;
charSpacing += wordSpacing;
if (wordSpacing > 0) {
Refactors fake space heuristics for speed.
2015-11-06 23:40:44 +09:00
addFakeSpaces(wordSpacing, textChunk.str);
Better spacing in text layer.
2015-11-02 23:54:15 +09:00
}
Apply char spacing only when there are chars.
2015-05-10 18:28:15 +09:00
}
Build the text layer geometry on the worker.
2014-04-10 08:44:07 +09:00
var tx = 0;
var ty = 0;
if (!font.vertical) {
var w0 = glyphWidth * textState.fontMatrix[0];
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
tx = (w0 * textState.fontSize + charSpacing) * textState.textHScale;
Build the text layer geometry on the worker.
2014-04-10 08:44:07 +09:00
width += tx;
} else {
var w1 = glyphWidth * textState.fontMatrix[0];
Apply char spacing only when there are chars.
2015-05-10 18:28:15 +09:00
ty = w1 * textState.fontSize + charSpacing;
Build the text layer geometry on the worker.
2014-04-10 08:44:07 +09:00
height += ty;
}
textState.translateTextMatrix(tx, ty);
Build up textChunk.str more efficiently. PartialEvaluator.getTextContent() builds up textChunk strings 1 char at a time, creating many 100s of 1000s of intermediate strings along the way. This patch make it instead push chars to an array and then join them at the end, as we have done in numerous other places.
2014-06-18 22:59:52 +09:00
textChunk.str.push(glyphUnicode);
Build the text layer geometry on the worker.
2014-04-10 08:44:07 +09:00
}
if (!font.vertical) {
Combines standalone divs into text groups.
2015-11-04 01:12:41 +09:00
textChunk.lastAdvanceWidth = width;
Consitently apply textAdvanceScale during building of textContentItems for improved highlighting. Fixes #7878.
2016-12-07 07:07:16 +09:00
textChunk.width += width;
Build the text layer geometry on the worker.
2014-04-10 08:44:07 +09:00
} else {
Combines standalone divs into text groups.
2015-11-04 01:12:41 +09:00
textChunk.lastAdvanceHeight = height;
Consitently apply textAdvanceScale during building of textContentItems for improved highlighting. Fixes #7878.
2016-12-07 07:07:16 +09:00
textChunk.height += Math.abs(height);
Build the text layer geometry on the worker.
2014-04-10 08:44:07 +09:00
}
Refactors fake space heuristics for speed.
2015-11-06 23:40:44 +09:00
Build the text layer geometry on the worker.
2014-04-10 08:44:07 +09:00
return textChunk;
}
Better spacing in text layer.
2015-11-02 23:54:15 +09:00
function addFakeSpaces(width, strBuf) {
Refactors fake space heuristics for speed.
2015-11-06 23:40:44 +09:00
if (width < textContentItem.fakeSpaceMin) {
Better spacing in text layer.
2015-11-02 23:54:15 +09:00
return;
}
Refactors fake space heuristics for speed.
2015-11-06 23:40:44 +09:00
if (width < textContentItem.fakeMultiSpaceMin) {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
strBuf.push(" ");
Refactors fake space heuristics for speed.
2015-11-06 23:40:44 +09:00
return;
}
var fakeSpaces = Math.round(width / textContentItem.spaceWidth);
while (fakeSpaces-- > 0) {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
strBuf.push(" ");
Better spacing in text layer.
2015-11-02 23:54:15 +09:00
}
}
Combines standalone divs into text groups.
2015-11-04 01:12:41 +09:00
function flushTextContentItem() {
if (!textContentItem.initialized) {
return;
}
Consitently apply textAdvanceScale during building of textContentItems for improved highlighting. Fixes #7878.
2016-12-07 07:07:16 +09:00
Do the final text scaling correctly in `flushTextContentItem` (issue 8276) It's necessary to take into account whether or not the text is vertical, to avoid either the textContent `width` or `height` becoming incorrect.
2019-01-29 22:24:48 +09:00
// Do final text scaling.
if (!textContentItem.vertical) {
textContentItem.width *= textContentItem.textAdvanceScale;
} else {
textContentItem.height *= textContentItem.textAdvanceScale;
}
Combines standalone divs into text groups.
2015-11-04 01:12:41 +09:00
textContent.items.push(runBidiTransform(textContentItem));
textContentItem.initialized = false;
textContentItem.str.length = 0;
}
Adds Streams API in getTextContent to stream data. This patch adds Streams API support in getTextContent so that we can stream data in chunks instead of fetching whole data from worker thread to main thread. This patch supports Streams API without changing the core functionality of getTextContent. Enqueue textContent directly at getTextContent in partialEvaluator. Adds desiredSize and ready property in streamSink.
2017-04-17 21:46:53 +09:00
function enqueueChunk() {
Enable the ESLint `prefer-const` rule globally (PR 11450 follow-up) Please find additional details about the ESLint rule at https://eslint.org/docs/rules/prefer-const With the recent introduction of Prettier this sort of mass enabling of ESLint rules becomes a lot easier, since the code will be automatically reformatted as necessary to account for e.g. changed line lengths. Note that this patch is generated automatically, by using the ESLint `--fix` argument, and will thus require some additional clean-up (which is done separately).
2020-01-24 17:48:21 +09:00
const length = textContent.items.length;
Adds Streams API in getTextContent to stream data. This patch adds Streams API support in getTextContent so that we can stream data in chunks instead of fetching whole data from worker thread to main thread. This patch supports Streams API without changing the core functionality of getTextContent. Enqueue textContent directly at getTextContent in partialEvaluator. Adds desiredSize and ready property in streamSink.
2017-04-17 21:46:53 +09:00
if (length > 0) {
sink.enqueue(textContent, length);
textContent.items = [];
textContent.styles = Object.create(null);
}
}
Terminate getOperationList and getTextContent every 20 ms
2014-05-10 10:41:03 +09:00
var timeSlotManager = new TimeSlotManager();
Better errors capturing at the core and stop rendering on error.
2016-03-11 22:59:09 +09:00
return new Promise(function promiseBody(resolve, reject) {
Update Prettier to version 2.0 Please note that these changes were done automatically, using `gulp lint --fix`. Given that the major version number was increased, there's a fair number of (primarily whitespace) changes; please see https://prettier.io/blog/2020/03/21/2.0.0.html In order to reduce the size of these changes somewhat, this patch maintains the old "arrowParens" style for now (once mozilla-central updates Prettier we can simply choose the same formatting, assuming it will differ here).
2020-04-14 19:28:14 +09:00
const next = function (promise) {
Adds Streams API in getTextContent to stream data. This patch adds Streams API support in getTextContent so that we can stream data in chunks instead of fetching whole data from worker thread to main thread. This patch supports Streams API without changing the core functionality of getTextContent. Enqueue textContent directly at getTextContent in partialEvaluator. Adds desiredSize and ready property in streamSink.
2017-04-17 21:46:53 +09:00
enqueueChunk();
Update Prettier to version 2.0 Please note that these changes were done automatically, using `gulp lint --fix`. Given that the major version number was increased, there's a fair number of (primarily whitespace) changes; please see https://prettier.io/blog/2020/03/21/2.0.0.html In order to reduce the size of these changes somewhat, this patch maintains the old "arrowParens" style for now (once mozilla-central updates Prettier we can simply choose the same formatting, assuming it will differ here).
2020-04-14 19:28:14 +09:00
Promise.all([promise, sink.ready]).then(function () {
Better errors capturing at the core and stop rendering on error.
2016-03-11 22:59:09 +09:00
try {
promiseBody(resolve, reject);
} catch (ex) {
reject(ex);
}
}, reject);
};
Adds thread abort capabilities.
2015-10-21 10:50:32 +09:00
task.ensureNotTerminated();
Terminate getOperationList and getTextContent every 20 ms
2014-05-10 10:41:03 +09:00
timeSlotManager.reset();
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
var stop,
operation = {},
args = [];
Avoid unnecessary array allocations in EvaluatorPreprocessor_read(). EvaluatorPreprocessor_read() is called in two cases. For the normal layer, the args array it produces is used beyond the bounds of the loop in which EvaluatorPreprocessor_read() is called. But for the text layer, the args array is used in a very short-term fashion. This change reworks things so that a single array is repeatedly used for the text layer. This reduces total JS allocations for the Spoorkaart map by 11%, and has similar effects on many other PDFs.
2014-08-11 09:23:23 +09:00
while (!(stop = timeSlotManager.check())) {
// The arguments parsed by read() are not used beyond this loop, so
// we can reuse the same array on every iteration, thus avoiding
// unnecessary allocations.
args.length = 0;
operation.args = args;
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
if (!preprocessor.read(operation)) {
Avoid unnecessary array allocations in EvaluatorPreprocessor_read(). EvaluatorPreprocessor_read() is called in two cases. For the normal layer, the args array it produces is used beyond the bounds of the loop in which EvaluatorPreprocessor_read() is called. But for the text layer, the args array is used in a very short-term fashion. This change reworks things so that a single array is repeatedly used for the text layer. This reduces total JS allocations for the Spoorkaart map by 11%, and has similar effects on many other PDFs.
2014-08-11 09:23:23 +09:00
break;
}
Adds Promise to the getOperatorList
2014-05-10 10:21:15 +09:00
textState = stateManager.state;
Revert "Attempt to combine separate beginText/endText sequences in `getTextContent` (issue 9984)"
2018-09-06 01:01:33 +09:00
var fn = operation.fn;
Avoid unnecessary array allocations in EvaluatorPreprocessor_read(). EvaluatorPreprocessor_read() is called in two cases. For the normal layer, the args array it produces is used beyond the bounds of the loop in which EvaluatorPreprocessor_read() is called. But for the text layer, the args array is used in a very short-term fashion. This change reworks things so that a single array is repeatedly used for the text layer. This reduces total JS allocations for the Spoorkaart map by 11%, and has similar effects on many other PDFs.
2014-08-11 09:23:23 +09:00
args = operation.args;
Attempt to combine text runs positioned with `setTextMatrix`
2016-05-15 05:13:12 +09:00
var advance, diff;
Avoid unnecessary array allocations in EvaluatorPreprocessor_read(). EvaluatorPreprocessor_read() is called in two cases. For the normal layer, the args array it produces is used beyond the bounds of the loop in which EvaluatorPreprocessor_read() is called. But for the text layer, the args array is used in a very short-term fashion. This change reworks things so that a single array is repeatedly used for the text layer. This reduces total JS allocations for the Spoorkaart map by 11%, and has similar effects on many other PDFs.
2014-08-11 09:23:23 +09:00
Revert "Attempt to combine separate beginText/endText sequences in `getTextContent` (issue 9984)"
2018-09-06 01:01:33 +09:00
switch (fn | 0) {
Adds Promise to the getOperatorList
2014-05-10 10:21:15 +09:00
case OPS.setFont:
Attempt to ignore multiple identical Tf (setFont) commands in `PartialEvaluator_getTextContent` (issue 5808) This patch improves the performance of issue 5808, but I'm not sure if it's enough to call it fixed. On average, this patch reduces the number of textLayer div's by a factor of 3, and it also reduces the time spend in `getTextContent` by a factor of ~2. The PDF file is generated by `Scribus PDF`, which for reasons I cannot understand is placing redundant `Tf` commands before *every* showText command. Note how the PDF file also contains lots of (basically) identical fonts, but with slightly different names, which causes unnecessary font-switching. This causes some unnecessary breaking of textLayer div's, but this issue cannot be easily worked around.
2016-06-01 06:01:35 +09:00
// Optimization to ignore multiple identical Tf commands.
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
var fontNameArg = args[0].name,
fontSizeArg = args[1];
if (
textState.font &&
fontNameArg === textState.fontName &&
fontSizeArg === textState.fontSize
) {
Attempt to ignore multiple identical Tf (setFont) commands in `PartialEvaluator_getTextContent` (issue 5808) This patch improves the performance of issue 5808, but I'm not sure if it's enough to call it fixed. On average, this patch reduces the number of textLayer div's by a factor of 3, and it also reduces the time spend in `getTextContent` by a factor of ~2. The PDF file is generated by `Scribus PDF`, which for reasons I cannot understand is placing redundant `Tf` commands before *every* showText command. Note how the PDF file also contains lots of (basically) identical fonts, but with slightly different names, which causes unnecessary font-switching. This causes some unnecessary breaking of textLayer div's, but this issue cannot be easily worked around.
2016-06-01 06:01:35 +09:00
break;
}
Combines standalone divs into text groups.
2015-11-04 01:12:41 +09:00
flushTextContentItem();
Attempt to ignore multiple identical Tf (setFont) commands in `PartialEvaluator_getTextContent` (issue 5808) This patch improves the performance of issue 5808, but I'm not sure if it's enough to call it fixed. On average, this patch reduces the number of textLayer div's by a factor of 3, and it also reduces the time spend in `getTextContent` by a factor of ~2. The PDF file is generated by `Scribus PDF`, which for reasons I cannot understand is placing redundant `Tf` commands before *every* showText command. Note how the PDF file also contains lots of (basically) identical fonts, but with slightly different names, which causes unnecessary font-switching. This causes some unnecessary breaking of textLayer div's, but this issue cannot be easily worked around.
2016-06-01 06:01:35 +09:00
textState.fontName = fontNameArg;
textState.fontSize = fontSizeArg;
next(handleSetFont(fontNameArg, null));
Better errors capturing at the core and stop rendering on error.
2016-03-11 22:59:09 +09:00
return;
Adds Promise to the getOperatorList
2014-05-10 10:21:15 +09:00
case OPS.setTextRise:
Combines standalone divs into text groups.
2015-11-04 01:12:41 +09:00
flushTextContentItem();
Adds Promise to the getOperatorList
2014-05-10 10:21:15 +09:00
textState.textRise = args[0];
break;
case OPS.setHScale:
Combines standalone divs into text groups.
2015-11-04 01:12:41 +09:00
flushTextContentItem();
Adds Promise to the getOperatorList
2014-05-10 10:21:15 +09:00
textState.textHScale = args[0] / 100;
break;
case OPS.setLeading:
Combines standalone divs into text groups.
2015-11-04 01:12:41 +09:00
flushTextContentItem();
Adds Promise to the getOperatorList
2014-05-10 10:21:15 +09:00
textState.leading = args[0];
break;
case OPS.moveText:
Combines standalone divs into text groups.
2015-11-04 01:12:41 +09:00
// Optimization to treat same line movement as advance
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
var isSameTextLine = !textState.font
? false
: (textState.font.vertical ? args[0] : args[1]) === 0;
Refactors fake space heuristics for speed.
2015-11-06 23:40:44 +09:00
advance = args[0] - args[1];
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
if (
combineTextItems &&
isSameTextLine &&
textContentItem.initialized &&
advance > 0 &&
advance <= textContentItem.fakeMultiSpaceMax
) {
Combines standalone divs into text groups.
2015-11-04 01:12:41 +09:00
textState.translateTextLineMatrix(args[0], args[1]);
textContentItem.width +=
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
args[0] - textContentItem.lastAdvanceWidth;
Combines standalone divs into text groups.
2015-11-04 01:12:41 +09:00
textContentItem.height +=
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
args[1] - textContentItem.lastAdvanceHeight;
diff =
args[0] -
textContentItem.lastAdvanceWidth -
Combines standalone divs into text groups.
2015-11-04 01:12:41 +09:00
(args[1] - textContentItem.lastAdvanceHeight);
Refactors fake space heuristics for speed.
2015-11-06 23:40:44 +09:00
addFakeSpaces(diff, textContentItem.str);
Combines standalone divs into text groups.
2015-11-04 01:12:41 +09:00
break;
}
flushTextContentItem();
Adds Promise to the getOperatorList
2014-05-10 10:21:15 +09:00
textState.translateTextLineMatrix(args[0], args[1]);
textState.textMatrix = textState.textLineMatrix.slice();
break;
case OPS.setLeadingMoveText:
Combines standalone divs into text groups.
2015-11-04 01:12:41 +09:00
flushTextContentItem();
Adds Promise to the getOperatorList
2014-05-10 10:21:15 +09:00
textState.leading = -args[1];
textState.translateTextLineMatrix(args[0], args[1]);
textState.textMatrix = textState.textLineMatrix.slice();
break;
case OPS.nextLine:
Combines standalone divs into text groups.
2015-11-04 01:12:41 +09:00
flushTextContentItem();
Adds Promise to the getOperatorList
2014-05-10 10:21:15 +09:00
textState.carriageReturn();
break;
case OPS.setTextMatrix:
Attempt to combine text runs positioned with `setTextMatrix`
2016-05-15 05:13:12 +09:00
// Optimization to treat same line movement as advance.
advance = textState.calcTextLineMatrixAdvance(
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
args[0],
args[1],
args[2],
args[3],
args[4],
args[5]
);
if (
combineTextItems &&
advance !== null &&
textContentItem.initialized &&
advance.value > 0 &&
advance.value <= textContentItem.fakeMultiSpaceMax
) {
textState.translateTextLineMatrix(
advance.width,
advance.height
);
Attempt to combine text runs positioned with `setTextMatrix`
2016-05-15 05:13:12 +09:00
textContentItem.width +=
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
advance.width - textContentItem.lastAdvanceWidth;
Attempt to combine text runs positioned with `setTextMatrix`
2016-05-15 05:13:12 +09:00
textContentItem.height +=
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
advance.height - textContentItem.lastAdvanceHeight;
diff =
advance.width -
textContentItem.lastAdvanceWidth -
Attempt to combine text runs positioned with `setTextMatrix`
2016-05-15 05:13:12 +09:00
(advance.height - textContentItem.lastAdvanceHeight);
addFakeSpaces(diff, textContentItem.str);
break;
}
Combines standalone divs into text groups.
2015-11-04 01:12:41 +09:00
flushTextContentItem();
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
textState.setTextMatrix(
args[0],
args[1],
args[2],
args[3],
args[4],
args[5]
);
textState.setTextLineMatrix(
args[0],
args[1],
args[2],
args[3],
args[4],
args[5]
);
Adds Promise to the getOperatorList
2014-05-10 10:21:15 +09:00
break;
case OPS.setCharSpacing:
textState.charSpacing = args[0];
break;
case OPS.setWordSpacing:
textState.wordSpacing = args[0];
break;
case OPS.beginText:
Revert "Attempt to combine separate beginText/endText sequences in `getTextContent` (issue 9984)"
2018-09-06 01:01:33 +09:00
flushTextContentItem();
textState.textMatrix = IDENTITY_MATRIX.slice();
textState.textLineMatrix = IDENTITY_MATRIX.slice();
Adds Promise to the getOperatorList
2014-05-10 10:21:15 +09:00
break;
case OPS.showSpacedText:
Ensure that there's always a setFont (Tf) operator before text rendering operators (issue 11651) The PDF document in question is *corrupt*, since it contains multiple instances of incorrect operators. We obviously don't want to slow down parsing of *all* documents (since most are valid), just to accommodate a particular bad PDF generator, hence the reason for the inline check before calling the `ensureStateFont` method.
2020-03-02 23:34:00 +09:00
if (!stateManager.state.font) {
self.ensureStateFont(stateManager.state);
continue;
}
Adds Promise to the getOperatorList
2014-05-10 10:21:15 +09:00
var items = args[0];
var offset;
for (var j = 0, jj = items.length; j < jj; j++) {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
if (typeof items[j] === "string") {
Combines standalone divs into text groups.
2015-11-04 01:12:41 +09:00
buildTextContentItem(items[j]);
Fix getTextContent evaluation to only apply TJ horizontal offsets using numeric items/args While the array argument to TJ should only contain strings and numbers, other unfortunate items are found in PDFs in the wild, e.g.: [(Grandes) 0.0 Tc -250.0 (Client\350les,) 0.0 Tc -250.0 (Financements) 0.0 Tc -250.0 (et) 0.0 Tc -250.0 (March\351s) ] TJ getOperatorList already properly ignores any non-string, non-numeric values in TJ arrays; without this patch to getTextContent, returned text items can have NaN widths due to calculations being applied to those non-numeric values.
2016-10-13 20:47:17 +09:00
} else if (isNum(items[j])) {
Refactors fake space heuristics for speed.
2015-11-06 23:40:44 +09:00
ensureTextContentItem();
Fix text spacing with vertical fonts (#6387) According to the PDF spec 5.3.2, a positive value means in horizontal, that the next glyph is further to the left (so narrower), and in vertical that it is further down (so wider). This change fixes the way PDF.js has interpreted the value.
2015-08-28 20:42:01 +09:00
// PDF Specification 5.3.2 states:
// The number is expressed in thousandths of a unit of text
// space.
// This amount is subtracted from the current horizontal or
// vertical coordinate, depending on the writing mode.
// In the default coordinate system, a positive adjustment
// has the effect of moving the next glyph painted either to
// the left or down by the given amount.
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
advance = (items[j] * textState.fontSize) / 1000;
Refactors fake space heuristics for speed.
2015-11-06 23:40:44 +09:00
var breakTextRun = false;
Fix text spacing with vertical fonts (#6387) According to the PDF spec 5.3.2, a positive value means in horizontal, that the next glyph is further to the left (so narrower), and in vertical that it is further down (so wider). This change fixes the way PDF.js has interpreted the value.
2015-08-28 20:42:01 +09:00
if (textState.font.vertical) {
Consitently apply textAdvanceScale during building of textContentItems for improved highlighting. Fixes #7878.
2016-12-07 07:07:16 +09:00
offset = advance;
textState.translateTextMatrix(0, offset);
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
breakTextRun =
textContentItem.textRunBreakAllowed &&
advance > textContentItem.fakeMultiSpaceMax;
Refactors fake space heuristics for speed.
2015-11-06 23:40:44 +09:00
if (!breakTextRun) {
// Value needs to be added to height to paint down.
textContentItem.height += offset;
}
Fix text spacing with vertical fonts (#6387) According to the PDF spec 5.3.2, a positive value means in horizontal, that the next glyph is further to the left (so narrower), and in vertical that it is further down (so wider). This change fixes the way PDF.js has interpreted the value.
2015-08-28 20:42:01 +09:00
} else {
Refactors fake space heuristics for speed.
2015-11-06 23:40:44 +09:00
advance = -advance;
Consitently apply textAdvanceScale during building of textContentItems for improved highlighting. Fixes #7878.
2016-12-07 07:07:16 +09:00
offset = advance * textState.textHScale;
textState.translateTextMatrix(offset, 0);
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
breakTextRun =
textContentItem.textRunBreakAllowed &&
advance > textContentItem.fakeMultiSpaceMax;
Refactors fake space heuristics for speed.
2015-11-06 23:40:44 +09:00
if (!breakTextRun) {
// Value needs to be subtracted from width to paint left.
textContentItem.width += offset;
}
Adds Promise to the getOperatorList
2014-05-10 10:21:15 +09:00
}
Refactors fake space heuristics for speed.
2015-11-06 23:40:44 +09:00
if (breakTextRun) {
flushTextContentItem();
} else if (advance > 0) {
Combines standalone divs into text groups.
2015-11-04 01:12:41 +09:00
addFakeSpaces(advance, textContentItem.str);
Improve the space detection for the getTextContent function
2012-09-15 02:53:06 +09:00
}
Load all resources before getOperatorList/getTextContent.
2013-06-05 09:57:52 +09:00
}
Incrementally render by sending the operator list by chunks as they're ready.
2013-08-01 03:17:36 +09:00
}
Making src/core/evaluator.js adhere to the style guide
2014-03-23 03:15:51 +09:00
break;
Adds Promise to the getOperatorList
2014-05-10 10:21:15 +09:00
case OPS.showText:
Ensure that there's always a setFont (Tf) operator before text rendering operators (issue 11651) The PDF document in question is *corrupt*, since it contains multiple instances of incorrect operators. We obviously don't want to slow down parsing of *all* documents (since most are valid), just to accommodate a particular bad PDF generator, hence the reason for the inline check before calling the `ensureStateFont` method.
2020-03-02 23:34:00 +09:00
if (!stateManager.state.font) {
self.ensureStateFont(stateManager.state);
continue;
}
Combines standalone divs into text groups.
2015-11-04 01:12:41 +09:00
buildTextContentItem(args[0]);
Adds Promise to the getOperatorList
2014-05-10 10:21:15 +09:00
break;
case OPS.nextLineShowText:
Ensure that there's always a setFont (Tf) operator before text rendering operators (issue 11651) The PDF document in question is *corrupt*, since it contains multiple instances of incorrect operators. We obviously don't want to slow down parsing of *all* documents (since most are valid), just to accommodate a particular bad PDF generator, hence the reason for the inline check before calling the `ensureStateFont` method.
2020-03-02 23:34:00 +09:00
if (!stateManager.state.font) {
self.ensureStateFont(stateManager.state);
continue;
}
Combines standalone divs into text groups.
2015-11-04 01:12:41 +09:00
flushTextContentItem();
Adds Promise to the getOperatorList
2014-05-10 10:21:15 +09:00
textState.carriageReturn();
Combines standalone divs into text groups.
2015-11-04 01:12:41 +09:00
buildTextContentItem(args[0]);
Adds Promise to the getOperatorList
2014-05-10 10:21:15 +09:00
break;
case OPS.nextLineSetSpacingShowText:
Ensure that there's always a setFont (Tf) operator before text rendering operators (issue 11651) The PDF document in question is *corrupt*, since it contains multiple instances of incorrect operators. We obviously don't want to slow down parsing of *all* documents (since most are valid), just to accommodate a particular bad PDF generator, hence the reason for the inline check before calling the `ensureStateFont` method.
2020-03-02 23:34:00 +09:00
if (!stateManager.state.font) {
self.ensureStateFont(stateManager.state);
continue;
}
Combines standalone divs into text groups.
2015-11-04 01:12:41 +09:00
flushTextContentItem();
Adds Promise to the getOperatorList
2014-05-10 10:21:15 +09:00
textState.wordSpacing = args[0];
textState.charSpacing = args[1];
textState.carriageReturn();
Combines standalone divs into text groups.
2015-11-04 01:12:41 +09:00
buildTextContentItem(args[2]);
Adds Promise to the getOperatorList
2014-05-10 10:21:15 +09:00
break;
case OPS.paintXObject:
Combines standalone divs into text groups.
2015-11-04 01:12:41 +09:00
flushTextContentItem();
Adds Promise to the getOperatorList
2014-05-10 10:21:15 +09:00
if (!xobjs) {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
xobjs = resources.get("XObject") || Dict.empty;
Adds Promise to the getOperatorList
2014-05-10 10:21:15 +09:00
}
Make getTextContent return offset array and improve the algorithm. Make parts in viewer.js work again.
2012-09-12 07:10:34 +09:00
Adds Promise to the getOperatorList
2014-05-10 10:21:15 +09:00
var name = args[0].name;
Improve caching of empty `/XObject`s in the `PartialEvaluator.getTextContent` method It turns out that `getTextContent` suffers from *similar* problems with repeated images as `getOperatorList`; please see the previous patch. While only `/XObject` resources of the `Form`-type will actually be *parsed* in `PartialEvaluator.getTextContent`, since those are the only ones that may contain text, we're still forced to fetch repeated image resources where the name differs (but not the reference). Obviously it's less bad in this case, since we're not actually parsing `/XObject`s of e.g. the `Image`-type. However, you still want to avoid even fetching the data whenever possible, since `Stream`s are not cached on the `XRef` instance (given their potential size) and the lookup can thus be somewhat expensive in general. To address these issues, we can simply replace the exiting name-only caching in `PartialEvaluator.getTextContent` with a new cache backed by `LocalImageCache` instead.
2020-05-26 16:47:59 +09:00
if (name && emptyXObjectCache.getByName(name)) {
Adds Promise to the getOperatorList
2014-05-10 10:21:15 +09:00
break;
Caches last parsed resource image, recornizes image repeats
2014-02-24 23:00:08 +09:00
}
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
next(
Update Prettier to version 2.0 Please note that these changes were done automatically, using `gulp lint --fix`. Given that the major version number was increased, there's a fair number of (primarily whitespace) changes; please see https://prettier.io/blog/2020/03/21/2.0.0.html In order to reduce the size of these changes somewhat, this patch maintains the old "arrowParens" style for now (once mozilla-central updates Prettier we can simply choose the same formatting, assuming it will differ here).
2020-04-14 19:28:14 +09:00
new Promise(function (resolveXObject, rejectXObject) {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
if (!name) {
throw new FormatError(
"XObject must be referred to by name."
);
}
[api-minor] Always allow e.g. rendering to continue even if there are errors, and add a `stopAtErrors` parameter to `getDocument` to opt-out of this behaviour (issue 6342, issue 3795, bug 1130815) Other PDF readers, e.g. Adobe Reader and PDFium (in Chrome), will attempt to render as much of a page as possible even if there are errors present. Currently we just bail as soon the first error is hit, which means that we'll usually not render anything in these cases and just display a blank page instead. NOTE: This patch changes the default behaviour of the PDF.js API to always attempt to recover as much data as possible, even when encountering errors during e.g. `getOperatorList`/`getTextContent`, which thus improve our handling of corrupt PDF files and allow the default viewer to handle errors slightly more gracefully. In the event that an API consumer wishes to use the old behaviour, where we stop parsing as soon as an error is encountered, the `stopAtErrors` parameter can be set at `getDocument`. Fixes, inasmuch it's possible since the PDF files are corrupt, e.g. issue 6342, issue 3795, and [bug 1130815](https://bugzilla.mozilla.org/show_bug.cgi?id=1130815) (and probably others too).
2017-02-19 22:03:08 +09:00
Improve caching of empty `/XObject`s in the `PartialEvaluator.getTextContent` method It turns out that `getTextContent` suffers from *similar* problems with repeated images as `getOperatorList`; please see the previous patch. While only `/XObject` resources of the `Form`-type will actually be *parsed* in `PartialEvaluator.getTextContent`, since those are the only ones that may contain text, we're still forced to fetch repeated image resources where the name differs (but not the reference). Obviously it's less bad in this case, since we're not actually parsing `/XObject`s of e.g. the `Image`-type. However, you still want to avoid even fetching the data whenever possible, since `Stream`s are not cached on the `XRef` instance (given their potential size) and the lookup can thus be somewhat expensive in general. To address these issues, we can simply replace the exiting name-only caching in `PartialEvaluator.getTextContent` with a new cache backed by `LocalImageCache` instead.
2020-05-26 16:47:59 +09:00
let xobj = xobjs.getRaw(name);
if (xobj instanceof Ref) {
if (emptyXObjectCache.getByRef(xobj)) {
resolveXObject();
return;
}
xobj = xref.fetch(xobj);
}
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
if (!xobj) {
resolveXObject();
return;
}
if (!isStream(xobj)) {
throw new FormatError("XObject should be a stream");
}
Build the text layer geometry on the worker.
2014-04-10 08:44:07 +09:00
Enable the ESLint `prefer-const` rule globally (PR 11450 follow-up) Please find additional details about the ESLint rule at https://eslint.org/docs/rules/prefer-const With the recent introduction of Prettier this sort of mass enabling of ESLint rules becomes a lot easier, since the code will be automatically reformatted as necessary to account for e.g. changed line lengths. Note that this patch is generated automatically, by using the ESLint `--fix` argument, and will thus require some additional clean-up (which is done separately).
2020-01-24 17:48:21 +09:00
const type = xobj.dict.get("Subtype");
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
if (!isName(type)) {
throw new FormatError("XObject should have a Name subtype");
}
Allow `getOperatorList`/`getTextContent` to skip errors when parsing broken XObjects (issue 8702, issue 8704) This patch makes use of the existing `ignoreErrors` property in `src/core/evaluator.js`, see PRs 8240 and 8441, thus allowing us to attempt to recovery as much as possible of a page even when it contains broken XObjects. Fixes 8702. Fixes 8704.
2017-09-17 20:35:18 +09:00
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
if (type.name !== "Form") {
Improve caching of empty `/XObject`s in the `PartialEvaluator.getTextContent` method It turns out that `getTextContent` suffers from *similar* problems with repeated images as `getOperatorList`; please see the previous patch. While only `/XObject` resources of the `Form`-type will actually be *parsed* in `PartialEvaluator.getTextContent`, since those are the only ones that may contain text, we're still forced to fetch repeated image resources where the name differs (but not the reference). Obviously it's less bad in this case, since we're not actually parsing `/XObject`s of e.g. the `Image`-type. However, you still want to avoid even fetching the data whenever possible, since `Stream`s are not cached on the `XRef` instance (given their potential size) and the lookup can thus be somewhat expensive in general. To address these issues, we can simply replace the exiting name-only caching in `PartialEvaluator.getTextContent` with a new cache backed by `LocalImageCache` instead.
2020-05-26 16:47:59 +09:00
emptyXObjectCache.set(name, xobj.dict.objId, true);
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
resolveXObject();
return;
}
Allow `getOperatorList`/`getTextContent` to skip errors when parsing broken XObjects (issue 8702, issue 8704) This patch makes use of the existing `ignoreErrors` property in `src/core/evaluator.js`, see PRs 8240 and 8441, thus allowing us to attempt to recovery as much as possible of a page even when it contains broken XObjects. Fixes 8702. Fixes 8704.
2017-09-17 20:35:18 +09:00
Fix the linting errors, from the Prettier auto-formatting, that ESLint `--fix` couldn't handle This patch makes the follow changes: - Remove no longer necessary inline `// eslint-disable-...` comments. - Fix `// eslint-disable-...` comments that Prettier moved down, thus causing new linting errors. - Concatenate strings which now fit on just one line. - Fix comments that are now too long. - Finally, and most importantly, adjust comments that Prettier moved down, since the new positions often is confusing or outright wrong.
2019-12-26 04:03:46 +09:00
// Use a new `StateManager` to prevent incorrect positioning
// of textItems *after* the Form XObject, since errors in the
// data can otherwise prevent `restore` operators from
// executing.
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
// NOTE: Only an issue when `options.ignoreErrors === true`.
Enable the ESLint `prefer-const` rule globally (PR 11450 follow-up) Please find additional details about the ESLint rule at https://eslint.org/docs/rules/prefer-const With the recent introduction of Prettier this sort of mass enabling of ESLint rules becomes a lot easier, since the code will be automatically reformatted as necessary to account for e.g. changed line lengths. Note that this patch is generated automatically, by using the ESLint `--fix` argument, and will thus require some additional clean-up (which is done separately).
2020-01-24 17:48:21 +09:00
const currentState = stateManager.state.clone();
const xObjStateManager = new StateManager(currentState);
Allow `getOperatorList`/`getTextContent` to skip errors when parsing broken XObjects (issue 8702, issue 8704) This patch makes use of the existing `ignoreErrors` property in `src/core/evaluator.js`, see PRs 8240 and 8441, thus allowing us to attempt to recovery as much as possible of a page even when it contains broken XObjects. Fixes 8702. Fixes 8704.
2017-09-17 20:35:18 +09:00
Enable the ESLint `prefer-const` rule globally (PR 11450 follow-up) Please find additional details about the ESLint rule at https://eslint.org/docs/rules/prefer-const With the recent introduction of Prettier this sort of mass enabling of ESLint rules becomes a lot easier, since the code will be automatically reformatted as necessary to account for e.g. changed line lengths. Note that this patch is generated automatically, by using the ESLint `--fix` argument, and will thus require some additional clean-up (which is done separately).
2020-01-24 17:48:21 +09:00
const matrix = xobj.dict.getArray("Matrix");
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
if (Array.isArray(matrix) && matrix.length === 6) {
xObjStateManager.transform(matrix);
}
Allow `getOperatorList`/`getTextContent` to skip errors when parsing broken XObjects (issue 8702, issue 8704) This patch makes use of the existing `ignoreErrors` property in `src/core/evaluator.js`, see PRs 8240 and 8441, thus allowing us to attempt to recovery as much as possible of a page even when it contains broken XObjects. Fixes 8702. Fixes 8704.
2017-09-17 20:35:18 +09:00
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
// Enqueue the `textContent` chunk before parsing the /Form
// XObject.
enqueueChunk();
Enable the ESLint `prefer-const` rule globally (PR 11450 follow-up) Please find additional details about the ESLint rule at https://eslint.org/docs/rules/prefer-const With the recent introduction of Prettier this sort of mass enabling of ESLint rules becomes a lot easier, since the code will be automatically reformatted as necessary to account for e.g. changed line lengths. Note that this patch is generated automatically, by using the ESLint `--fix` argument, and will thus require some additional clean-up (which is done separately).
2020-01-24 17:48:21 +09:00
const sinkWrapper = {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
enqueueInvoked: false,
enqueue(chunk, size) {
this.enqueueInvoked = true;
sink.enqueue(chunk, size);
},
get desiredSize() {
return sink.desiredSize;
},
get ready() {
return sink.ready;
},
};
self
.getTextContent({
stream: xobj,
task,
resources: xobj.dict.get("Resources") || resources,
stateManager: xObjStateManager,
normalizeWhitespace,
combineTextItems,
sink: sinkWrapper,
seenStyles,
})
Update Prettier to version 2.0 Please note that these changes were done automatically, using `gulp lint --fix`. Given that the major version number was increased, there's a fair number of (primarily whitespace) changes; please see https://prettier.io/blog/2020/03/21/2.0.0.html In order to reduce the size of these changes somewhat, this patch maintains the old "arrowParens" style for now (once mozilla-central updates Prettier we can simply choose the same formatting, assuming it will differ here).
2020-04-14 19:28:14 +09:00
.then(function () {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
if (!sinkWrapper.enqueueInvoked) {
Improve caching of empty `/XObject`s in the `PartialEvaluator.getTextContent` method It turns out that `getTextContent` suffers from *similar* problems with repeated images as `getOperatorList`; please see the previous patch. While only `/XObject` resources of the `Form`-type will actually be *parsed* in `PartialEvaluator.getTextContent`, since those are the only ones that may contain text, we're still forced to fetch repeated image resources where the name differs (but not the reference). Obviously it's less bad in this case, since we're not actually parsing `/XObject`s of e.g. the `Image`-type. However, you still want to avoid even fetching the data whenever possible, since `Stream`s are not cached on the `XRef` instance (given their potential size) and the lookup can thus be somewhat expensive in general. To address these issues, we can simply replace the exiting name-only caching in `PartialEvaluator.getTextContent` with a new cache backed by `LocalImageCache` instead.
2020-05-26 16:47:59 +09:00
emptyXObjectCache.set(name, xobj.dict.objId, true);
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
}
resolveXObject();
}, rejectXObject);
Update Prettier to version 2.0 Please note that these changes were done automatically, using `gulp lint --fix`. Given that the major version number was increased, there's a fair number of (primarily whitespace) changes; please see https://prettier.io/blog/2020/03/21/2.0.0.html In order to reduce the size of these changes somewhat, this patch maintains the old "arrowParens" style for now (once mozilla-central updates Prettier we can simply choose the same formatting, assuming it will differ here).
2020-04-14 19:28:14 +09:00
}).catch(function (reason) {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
if (reason instanceof AbortException) {
return;
Allow `getOperatorList`/`getTextContent` to skip errors when parsing broken XObjects (issue 8702, issue 8704) This patch makes use of the existing `ignoreErrors` property in `src/core/evaluator.js`, see PRs 8240 and 8441, thus allowing us to attempt to recovery as much as possible of a page even when it contains broken XObjects. Fixes 8702. Fixes 8704.
2017-09-17 20:35:18 +09:00
}
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
if (self.options.ignoreErrors) {
// Error(s) in the XObject -- allow text-extraction to
// continue.
warn(`getTextContent - ignoring XObject: "${reason}".`);
return;
}
throw reason;
})
);
Better errors capturing at the core and stop rendering on error.
2016-03-11 22:59:09 +09:00
return;
Adds Promise to the getOperatorList
2014-05-10 10:21:15 +09:00
case OPS.setGState:
Combines standalone divs into text groups.
2015-11-04 01:12:41 +09:00
flushTextContentItem();
Adds Promise to the getOperatorList
2014-05-10 10:21:15 +09:00
var dictName = args[0];
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
var extGState = resources.get("ExtGState");
Making src/core/evaluator.js adhere to the style guide
2014-03-23 03:15:51 +09:00
Fix errors in `setGState` in `PartialEvaluator_getTextContent` that prevents text-selection from working properly Currently `setGState` is completely broken, and looking through the history of that code, it seems to me that this may never have worked correctly. This patch fixes the text-selection in `extgstate.pdf` in the test-suite, which is also added as a `text` test.
2016-06-01 06:40:19 +09:00
if (!isDict(extGState) || !isName(dictName)) {
Adds Promise to the getOperatorList
2014-05-10 10:21:15 +09:00
break;
Add handling for gs in getTextContent
2012-09-15 11:52:37 +09:00
}
Fix errors in `setGState` in `PartialEvaluator_getTextContent` that prevents text-selection from working properly Currently `setGState` is completely broken, and looking through the history of that code, it seems to me that this may never have worked correctly. This patch fixes the text-selection in `extgstate.pdf` in the test-suite, which is also added as a `text` test.
2016-06-01 06:40:19 +09:00
var gState = extGState.get(dictName.name);
if (!isDict(gState)) {
break;
Adds Promise to the getOperatorList
2014-05-10 10:21:15 +09:00
}
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
var gStateFont = gState.get("Font");
Fix errors in `setGState` in `PartialEvaluator_getTextContent` that prevents text-selection from working properly Currently `setGState` is completely broken, and looking through the history of that code, it seems to me that this may never have worked correctly. This patch fixes the text-selection in `extgstate.pdf` in the test-suite, which is also added as a `text` test.
2016-06-01 06:40:19 +09:00
if (gStateFont) {
Attempt to ignore multiple identical Tf (setFont) commands in `PartialEvaluator_getTextContent` (issue 5808) This patch improves the performance of issue 5808, but I'm not sure if it's enough to call it fixed. On average, this patch reduces the number of textLayer div's by a factor of 3, and it also reduces the time spend in `getTextContent` by a factor of ~2. The PDF file is generated by `Scribus PDF`, which for reasons I cannot understand is placing redundant `Tf` commands before *every* showText command. Note how the PDF file also contains lots of (basically) identical fonts, but with slightly different names, which causes unnecessary font-switching. This causes some unnecessary breaking of textLayer div's, but this issue cannot be easily worked around.
2016-06-01 06:01:35 +09:00
textState.fontName = null;
Fix errors in `setGState` in `PartialEvaluator_getTextContent` that prevents text-selection from working properly Currently `setGState` is completely broken, and looking through the history of that code, it seems to me that this may never have worked correctly. This patch fixes the text-selection in `extgstate.pdf` in the test-suite, which is also added as a `text` test.
2016-06-01 06:40:19 +09:00
textState.fontSize = gStateFont[1];
next(handleSetFont(null, gStateFont[0]));
Better errors capturing at the core and stop rendering on error.
2016-03-11 22:59:09 +09:00
return;
Adds Promise to the getOperatorList
2014-05-10 10:21:15 +09:00
}
break;
} // switch
Adds Streams API in getTextContent to stream data. This patch adds Streams API support in getTextContent so that we can stream data in chunks instead of fetching whole data from worker thread to main thread. This patch supports Streams API without changing the core functionality of getTextContent. Enqueue textContent directly at getTextContent in partialEvaluator. Adds desiredSize and ready property in streamSink.
2017-04-17 21:46:53 +09:00
if (textContent.items.length >= sink.desiredSize) {
// Wait for ready, if we reach highWaterMark.
stop = true;
break;
}
Adds Promise to the getOperatorList
2014-05-10 10:21:15 +09:00
} // while
Terminate getOperationList and getTextContent every 20 ms
2014-05-10 10:41:03 +09:00
if (stop) {
Better errors capturing at the core and stop rendering on error.
2016-03-11 22:59:09 +09:00
next(deferred);
Terminate getOperationList and getTextContent every 20 ms
2014-05-10 10:41:03 +09:00
return;
}
Combines standalone divs into text groups.
2015-11-04 01:12:41 +09:00
flushTextContentItem();
Adds Streams API in getTextContent to stream data. This patch adds Streams API support in getTextContent so that we can stream data in chunks instead of fetching whole data from worker thread to main thread. This patch supports Streams API without changing the core functionality of getTextContent. Enqueue textContent directly at getTextContent in partialEvaluator. Adds desiredSize and ready property in streamSink.
2017-04-17 21:46:53 +09:00
enqueueChunk();
resolve();
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
}).catch(reason => {
Properly cancel streams and guard at getTextContent.
2017-08-04 06:36:46 +09:00
if (reason instanceof AbortException) {
return;
}
[api-minor] Always allow e.g. rendering to continue even if there are errors, and add a `stopAtErrors` parameter to `getDocument` to opt-out of this behaviour (issue 6342, issue 3795, bug 1130815) Other PDF readers, e.g. Adobe Reader and PDFium (in Chrome), will attempt to render as much of a page as possible even if there are errors present. Currently we just bail as soon the first error is hit, which means that we'll usually not render anything in these cases and just display a blank page instead. NOTE: This patch changes the default behaviour of the PDF.js API to always attempt to recover as much data as possible, even when encountering errors during e.g. `getOperatorList`/`getTextContent`, which thus improve our handling of corrupt PDF files and allow the default viewer to handle errors slightly more gracefully. In the event that an API consumer wishes to use the old behaviour, where we stop parsing as soon as an error is encountered, the `stopAtErrors` parameter can be set at `getDocument`. Fixes, inasmuch it's possible since the PDF files are corrupt, e.g. issue 6342, issue 3795, and [bug 1130815](https://bugzilla.mozilla.org/show_bug.cgi?id=1130815) (and probably others too).
2017-02-19 22:03:08 +09:00
if (this.options.ignoreErrors) {
// Error(s) in the TextContent -- allow text-extraction to continue.
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
warn(
`getTextContent - ignoring errors during "${task.name}" ` +
`task: "${reason}".`
);
[api-minor] Always allow e.g. rendering to continue even if there are errors, and add a `stopAtErrors` parameter to `getDocument` to opt-out of this behaviour (issue 6342, issue 3795, bug 1130815) Other PDF readers, e.g. Adobe Reader and PDFium (in Chrome), will attempt to render as much of a page as possible even if there are errors present. Currently we just bail as soon the first error is hit, which means that we'll usually not render anything in these cases and just display a blank page instead. NOTE: This patch changes the default behaviour of the PDF.js API to always attempt to recover as much data as possible, even when encountering errors during e.g. `getOperatorList`/`getTextContent`, which thus improve our handling of corrupt PDF files and allow the default viewer to handle errors slightly more gracefully. In the event that an API consumer wishes to use the old behaviour, where we stop parsing as soon as an error is encountered, the `stopAtErrors` parameter can be set at `getDocument`. Fixes, inasmuch it's possible since the PDF files are corrupt, e.g. issue 6342, issue 3795, and [bug 1130815](https://bugzilla.mozilla.org/show_bug.cgi?id=1130815) (and probably others too).
2017-02-19 22:03:08 +09:00
flushTextContentItem();
Adds Streams API in getTextContent to stream data. This patch adds Streams API support in getTextContent so that we can stream data in chunks instead of fetching whole data from worker thread to main thread. This patch supports Streams API without changing the core functionality of getTextContent. Enqueue textContent directly at getTextContent in partialEvaluator. Adds desiredSize and ready property in streamSink.
2017-04-17 21:46:53 +09:00
enqueueChunk();
return;
[api-minor] Always allow e.g. rendering to continue even if there are errors, and add a `stopAtErrors` parameter to `getDocument` to opt-out of this behaviour (issue 6342, issue 3795, bug 1130815) Other PDF readers, e.g. Adobe Reader and PDFium (in Chrome), will attempt to render as much of a page as possible even if there are errors present. Currently we just bail as soon the first error is hit, which means that we'll usually not render anything in these cases and just display a blank page instead. NOTE: This patch changes the default behaviour of the PDF.js API to always attempt to recover as much data as possible, even when encountering errors during e.g. `getOperatorList`/`getTextContent`, which thus improve our handling of corrupt PDF files and allow the default viewer to handle errors slightly more gracefully. In the event that an API consumer wishes to use the old behaviour, where we stop parsing as soon as an error is encountered, the `stopAtErrors` parameter can be set at `getDocument`. Fixes, inasmuch it's possible since the PDF files are corrupt, e.g. issue 6342, issue 3795, and [bug 1130815](https://bugzilla.mozilla.org/show_bug.cgi?id=1130815) (and probably others too).
2017-02-19 22:03:08 +09:00
}
throw reason;
Replace unnecessary `bind(this)` and `var self = this` statements with arrow functions in `src/core/evaluator.js` Note that by using `let` instead of `var` in `PartialEvaluator.setGState` and `TranslatedFont.loadType3Data`, we can get rid of further `bind` usages since `let` is block-scoped. Also, the fact that `bind` wasn't used in the `Font` case inside of `setGState` is actually a bug which has been present ever since PR 5205, where a closure was replaced by a standard loop.[1] --- [1] I'm not aware of any bugs caused by this, but that is probably more a happy accident than anything else, since e.g. just removing the `bind` from the `SMask` case without using block-scoped variables causes test failures.
2017-04-30 06:36:43 +09:00
});
Text char codes extraction
2011-12-11 08:24:54 +09:00
},
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
extractDataStructures: function PartialEvaluator_extractDataStructures(
dict,
baseDict,
properties
) {
Fix remaining linting errors, from enabling the `prefer-const` ESLint rule globally This covers cases that the `--fix` command couldn't deal with, and in a few cases (notably `src/core/jbig2.js`) the code was changed to use block-scoped variables instead.
2020-01-24 21:21:16 +09:00
const xref = this.xref;
let cidToGidBytes;
Migration of the 'encoding-1' branch (ref #674)
2011-10-29 10:38:31 +09:00
// 9.10.2
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
var toUnicode = dict.get("ToUnicode") || baseDict.get("ToUnicode");
var toUnicodePromise = toUnicode
? this.readToUnicode(toUnicode)
: Promise.resolve(undefined);
Refactors CMapFactory.create to make it async
2016-02-29 01:20:29 +09:00
Migration of the 'encoding-1' branch (ref #674)
2011-10-29 10:38:31 +09:00
if (properties.composite) {
// CIDSystemInfo helps to match CID to glyphs
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
var cidSystemInfo = dict.get("CIDSystemInfo");
Splitting files
2011-10-25 08:55:23 +09:00
if (isDict(cidSystemInfo)) {
properties.cidSystemInfo = {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
registry: stringToPDFString(cidSystemInfo.get("Registry")),
ordering: stringToPDFString(cidSystemInfo.get("Ordering")),
supplement: cidSystemInfo.get("Supplement"),
Splitting files
2011-10-25 08:55:23 +09:00
};
}
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
var cidToGidMap = dict.get("CIDToGIDMap");
Making src/core/evaluator.js adhere to the style guide
2014-03-23 03:15:51 +09:00
if (isStream(cidToGidMap)) {
Fix glyph 0 in CIDFontType2 that has a CIDToGIDMap stream
2019-05-08 00:44:37 +09:00
cidToGidBytes = cidToGidMap.getBytes();
Making src/core/evaluator.js adhere to the style guide
2014-03-23 03:15:51 +09:00
}
Splitting files
2011-10-25 08:55:23 +09:00
}
Fix priority of which font encoding is used.
2013-04-11 01:51:06 +09:00
// Based on 9.6.6 of the spec the encoding can come from multiple places
Use built in CMaps and unify the glyph mapping.
2014-02-12 03:27:09 +09:00
// and depends on the font type. The base encoding and differences are
// read here, but the encoding that is actually used is chosen during
// glyph mapping in the font.
// TODO: Loading the built in encoding in the font would allow the
// differences to be merged in here not require us to hold on to it.
Migration of the 'encoding-1' branch (ref #674)
2011-10-29 10:38:31 +09:00
var differences = [];
Use built in CMaps and unify the glyph mapping.
2014-02-12 03:27:09 +09:00
var baseEncodingName = null;
Fixes lint warning W004 in src/core
2014-04-08 06:42:54 +09:00
var encoding;
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
if (dict.has("Encoding")) {
encoding = dict.get("Encoding");
Splitting files
2011-10-25 08:55:23 +09:00
if (isDict(encoding)) {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
baseEncodingName = encoding.get("BaseEncoding");
baseEncodingName = isName(baseEncodingName)
? baseEncodingName.name
: null;
Splitting files
2011-10-25 08:55:23 +09:00
// Load the differences between the base and original
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
if (encoding.has("Differences")) {
var diffEncoding = encoding.get("Differences");
Splitting files
2011-10-25 08:55:23 +09:00
var index = 0;
Progress
2011-11-03 04:08:19 +09:00
for (var j = 0, jj = diffEncoding.length; j < jj; j++) {
Ensure that we don't modify the `Dict` data when the `Differences` array of a font contains indirect objects This patch fixes an issue that I inadvertently introduced in PR 5815, where we accidentally modify the `Differences` array in the encoding dictionary for indirect objects. Instead of this change, we could also have used the now existing `Dict_getArray`. However in this case I don't think that would have been a good idea, since it would mean iterating through the array *twice*.
2016-01-30 02:22:25 +09:00
var data = xref.fetchIfRef(diffEncoding[j]);
Making src/core/evaluator.js adhere to the style guide
2014-03-23 03:15:51 +09:00
if (isNum(data)) {
Splitting files
2011-10-25 08:55:23 +09:00
index = data;
Ensure that entries in the Differences array of Type1 fonts are either numbers or names This patch is yet another installment in the (never ending) series of bugs in PDF files with non-embedded fonts. Fixes http://www.int.washington.edu/talks/WorkShops/int_08_37W/People/Franz_M/Franz.pdf.
2015-03-09 22:36:45 +09:00
} else if (isName(data)) {
Splitting files
2011-10-25 08:55:23 +09:00
differences[index++] = data.name;
Ensure that entries in the Differences array of Type1 fonts are either numbers or names This patch is yet another installment in the (never ending) series of bugs in PDF files with non-embedded fonts. Fixes http://www.int.washington.edu/talks/WorkShops/int_08_37W/People/Franz_M/Franz.pdf.
2015-03-09 22:36:45 +09:00
} else {
Removes error()
2017-06-29 05:51:31 +09:00
throw new FormatError(
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
`Invalid entry in 'Differences' array: ${data}`
);
Making src/core/evaluator.js adhere to the style guide
2014-03-23 03:15:51 +09:00
}
Splitting files
2011-10-25 08:55:23 +09:00
}
}
} else if (isName(encoding)) {
Use built in CMaps and unify the glyph mapping.
2014-02-12 03:27:09 +09:00
baseEncodingName = encoding.name;
Splitting files
2011-10-25 08:55:23 +09:00
} else {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
throw new FormatError("Encoding is not a Name nor a Dict");
Splitting files
2011-10-25 08:55:23 +09:00
}
Use built in CMaps and unify the glyph mapping.
2014-02-12 03:27:09 +09:00
// According to table 114 if the encoding is a named encoding it must be
// one of these predefined encodings.
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
if (
baseEncodingName !== "MacRomanEncoding" &&
baseEncodingName !== "MacExpertEncoding" &&
baseEncodingName !== "WinAnsiEncoding"
) {
Use built in CMaps and unify the glyph mapping.
2014-02-12 03:27:09 +09:00
baseEncodingName = null;
}
}
if (baseEncodingName) {
Refactor Encodings
2016-01-22 06:18:46 +09:00
properties.defaultEncoding = getEncoding(baseEncodingName).slice();
Use built in CMaps and unify the glyph mapping.
2014-02-12 03:27:09 +09:00
} else {
Fallback to the `StandardEncoding` for Nonsymbolic fonts without `/Encoding` entry (issue 7580) Even though this patch passes all tests (unit/font/reference) locally, including the new ones that I added in PR 7621, I'm still a bit nervous about modifying the code that choose the fallback encoding for fonts without an `/Encoding` entry. Note that over the years this code has been changed on a number of occasions, see a possibly incomplete [list here], to deal with various cases of incorrect font data. According to the PDF specification, see http://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/pdfs/PDF32000_2008.pdf#G8.1904184, it seems that we should fallback to the `StandardEncoding` for Nonsymbolic fonts. There's obviously a risk that fixing this particular issue *could* break other PDF files for which we don't have tests. However I've tried to change the logic as little as possible in this patch, to hopefully reduce possible breakage. Based on debugging numerous font issue, it seems that a lot of fonts actually set the Symbolic flag, even when they are in fact *not* Symbolic. Fonts actually marked as Nonsymbolic seem to be somewhat less common, which I hope should reduce the risk of the patch somewhat. Fixes 7580.
2016-09-13 20:43:23 +09:00
var isSymbolicFont = !!(properties.flags & FontFlags.Symbolic);
var isNonsymbolicFont = !!(properties.flags & FontFlags.Nonsymbolic);
// According to "Table 114" in section "9.6.6.1 General" (under
// "9.6.6 Character Encoding") of the PDF specification, a Nonsymbolic
// font should use the `StandardEncoding` if no encoding is specified.
encoding = StandardEncoding;
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
if (properties.type === "TrueType" && !isNonsymbolicFont) {
Fallback to the `StandardEncoding` for Nonsymbolic fonts without `/Encoding` entry (issue 7580) Even though this patch passes all tests (unit/font/reference) locally, including the new ones that I added in PR 7621, I'm still a bit nervous about modifying the code that choose the fallback encoding for fonts without an `/Encoding` entry. Note that over the years this code has been changed on a number of occasions, see a possibly incomplete [list here], to deal with various cases of incorrect font data. According to the PDF specification, see http://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/pdfs/PDF32000_2008.pdf#G8.1904184, it seems that we should fallback to the `StandardEncoding` for Nonsymbolic fonts. There's obviously a risk that fixing this particular issue *could* break other PDF files for which we don't have tests. However I've tried to change the logic as little as possible in this patch, to hopefully reduce possible breakage. Based on debugging numerous font issue, it seems that a lot of fonts actually set the Symbolic flag, even when they are in fact *not* Symbolic. Fonts actually marked as Nonsymbolic seem to be somewhat less common, which I hope should reduce the risk of the patch somewhat. Fixes 7580.
2016-09-13 20:43:23 +09:00
encoding = WinAnsiEncoding;
}
Use built in CMaps and unify the glyph mapping.
2014-02-12 03:27:09 +09:00
// The Symbolic attribute can be misused for regular fonts
// Heuristic: we have to check if the font is a standard one also
Fallback to the `StandardEncoding` for Nonsymbolic fonts without `/Encoding` entry (issue 7580) Even though this patch passes all tests (unit/font/reference) locally, including the new ones that I added in PR 7621, I'm still a bit nervous about modifying the code that choose the fallback encoding for fonts without an `/Encoding` entry. Note that over the years this code has been changed on a number of occasions, see a possibly incomplete [list here], to deal with various cases of incorrect font data. According to the PDF specification, see http://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/pdfs/PDF32000_2008.pdf#G8.1904184, it seems that we should fallback to the `StandardEncoding` for Nonsymbolic fonts. There's obviously a risk that fixing this particular issue *could* break other PDF files for which we don't have tests. However I've tried to change the logic as little as possible in this patch, to hopefully reduce possible breakage. Based on debugging numerous font issue, it seems that a lot of fonts actually set the Symbolic flag, even when they are in fact *not* Symbolic. Fonts actually marked as Nonsymbolic seem to be somewhat less common, which I hope should reduce the risk of the patch somewhat. Fixes 7580.
2016-09-13 20:43:23 +09:00
if (isSymbolicFont) {
Refactor Encodings
2016-01-22 06:18:46 +09:00
encoding = MacRomanEncoding;
Add basic support for ZapfDingbats
2014-09-01 10:22:24 +09:00
if (!properties.file) {
if (/Symbol/i.test(properties.name)) {
Refactor Encodings
2016-01-22 06:18:46 +09:00
encoding = SymbolSetEncoding;
Use the same non-embedded Wingdings fallback for fonts named "Wingdings-Regular" too (PR 5463 follow-up, issue 11451) This patch extends the existing heuristics, which are really the best that we can do in general for these kinds of non-embedded *and* non-standard fonts. Furthermore, this patch also tries to improve the copy-and-paste behaviour for non-embedded Wingdings fonts by also using the `ZapfDingbatsEncoding` in this case. *Note:* I'm not sure that adding additional tests for Wingdings fonts matters that much, given how limited our "support" for them really is.
2020-02-25 01:34:15 +09:00
} else if (/Dingbats|Wingdings/i.test(properties.name)) {
Refactor Encodings
2016-01-22 06:18:46 +09:00
encoding = ZapfDingbatsEncoding;
Add basic support for ZapfDingbats
2014-09-01 10:22:24 +09:00
}
}
Use built in CMaps and unify the glyph mapping.
2014-02-12 03:27:09 +09:00
}
properties.defaultEncoding = encoding;
Splitting files
2011-10-25 08:55:23 +09:00
}
Initial ToUnicode modifications
2011-11-25 00:38:09 +09:00
Migration of the 'encoding-1' branch (ref #674)
2011-10-29 10:38:31 +09:00
properties.differences = differences;
Use built in CMaps and unify the glyph mapping.
2014-02-12 03:27:09 +09:00
properties.baseEncodingName = baseEncodingName;
For embedded Type1 fonts without included `ToUnicode`/`Encoding` data, attempt to improve text selection by using the `builtInEncoding` to amend the `toUnicode` map (issue 6901, issue 7182, issue 7217, bug 917796, bug 1242142) Note that in order to prevent any possible issues, this patch does *not* try to amend the `toUnicode` data for Type1 fonts that contain either `ToUnicode` or `Encoding` entries in the font dictionary. Fixes, or at least improves, issues/bugs such as e.g. 6658, 6901, 7182, 7217, bug 917796, bug 1242142.
2016-08-18 01:33:06 +09:00
properties.hasEncoding = !!baseEncodingName || differences.length > 0;
Use built in CMaps and unify the glyph mapping.
2014-02-12 03:27:09 +09:00
properties.dict = dict;
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
return toUnicodePromise
Remove variable shadowing from the JavaScript files in the `src/core/` folder *This is part of a series of patches that will try to split PR 11566 into smaller chunks, to make reviewing more feasible.* Once all the code has been fixed, we'll be able to eventually enable the ESLint no-shadow rule; see https://eslint.org/docs/rules/no-shadow
2020-03-24 01:04:47 +09:00
.then(readToUnicode => {
properties.toUnicode = readToUnicode;
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
return this.buildToUnicode(properties);
})
Remove variable shadowing from the JavaScript files in the `src/core/` folder *This is part of a series of patches that will try to split PR 11566 into smaller chunks, to make reviewing more feasible.* Once all the code has been fixed, we'll be able to eventually enable the ESLint no-shadow rule; see https://eslint.org/docs/rules/no-shadow
2020-03-24 01:04:47 +09:00
.then(builtToUnicode => {
properties.toUnicode = builtToUnicode;
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
if (cidToGidBytes) {
properties.cidToGidMap = this.readCidToGidMap(
cidToGidBytes,
Remove variable shadowing from the JavaScript files in the `src/core/` folder *This is part of a series of patches that will try to split PR 11566 into smaller chunks, to make reviewing more feasible.* Once all the code has been fixed, we'll be able to eventually enable the ESLint no-shadow rule; see https://eslint.org/docs/rules/no-shadow
2020-03-24 01:04:47 +09:00
builtToUnicode
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
);
}
return properties;
});
Migration of the 'encoding-1' branch (ref #674)
2011-10-29 10:38:31 +09:00
},
Splitting files
2011-10-25 08:55:23 +09:00
Refactor the building of `ToUnicode` maps for simple fonts a helper method
2017-11-26 20:53:06 +09:00
/**
* @returns {ToUnicodeMap}
* @private
*/
Improve the heuristics, in `PartialEvaluator._buildSimpleFontToUnicode`, for glyphNames of the Cdd{d}/cdd{d} format (issue 9655) *Please note:* I've been thinking about possible ways of addressing this issue for a while now, but all of the solutions I came up with became too complicated and thus hurt readability of the code. However, it occured to me that we're essentially trying to add a heuristic *on top* of another heuristic, and that it shouldn't matter how efficient the code is as long as it works. In the PDF file in the issue the Encoding contains glyphNames of the `Cdd` format, which our existing heuristics will treat as base 10 values. However, in this particular file they actually contain base 16 values, which we thus attempt to detect and fix such that text-selection works.
2019-09-30 06:50:58 +09:00
_buildSimpleFontToUnicode(properties, forceGlyphs = false) {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
assert(!properties.composite, "Must be a simple font.");
Refactor the building of `ToUnicode` maps for simple fonts a helper method
2017-11-26 20:53:06 +09:00
Fix remaining linting errors, from enabling the `prefer-const` ESLint rule globally This covers cases that the `--fix` command couldn't deal with, and in a few cases (notably `src/core/jbig2.js`) the code was changed to use block-scoped variables instead.
2020-01-24 21:21:16 +09:00
const toUnicode = [];
Enable the ESLint `prefer-const` rule globally (PR 11450 follow-up) Please find additional details about the ESLint rule at https://eslint.org/docs/rules/prefer-const With the recent introduction of Prettier this sort of mass enabling of ESLint rules becomes a lot easier, since the code will be automatically reformatted as necessary to account for e.g. changed line lengths. Note that this patch is generated automatically, by using the ESLint `--fix` argument, and will thus require some additional clean-up (which is done separately).
2020-01-24 17:48:21 +09:00
const encoding = properties.defaultEncoding.slice();
const baseEncodingName = properties.baseEncodingName;
Refactor the building of `ToUnicode` maps for simple fonts a helper method
2017-11-26 20:53:06 +09:00
// Merge in the differences array.
Enable the ESLint `prefer-const` rule globally (PR 11450 follow-up) Please find additional details about the ESLint rule at https://eslint.org/docs/rules/prefer-const With the recent introduction of Prettier this sort of mass enabling of ESLint rules becomes a lot easier, since the code will be automatically reformatted as necessary to account for e.g. changed line lengths. Note that this patch is generated automatically, by using the ESLint `--fix` argument, and will thus require some additional clean-up (which is done separately).
2020-01-24 17:48:21 +09:00
const differences = properties.differences;
Fix remaining linting errors, from enabling the `prefer-const` ESLint rule globally This covers cases that the `--fix` command couldn't deal with, and in a few cases (notably `src/core/jbig2.js`) the code was changed to use block-scoped variables instead.
2020-01-24 21:21:16 +09:00
for (const charcode in differences) {
const glyphName = differences[charcode];
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
if (glyphName === ".notdef") {
Refactor the building of `ToUnicode` maps for simple fonts a helper method
2017-11-26 20:53:06 +09:00
// Skip .notdef to prevent rendering errors, e.g. boxes appearing
// where there should be spaces (fixes issue5256.pdf).
continue;
}
encoding[charcode] = glyphName;
}
Enable the ESLint `prefer-const` rule globally (PR 11450 follow-up) Please find additional details about the ESLint rule at https://eslint.org/docs/rules/prefer-const With the recent introduction of Prettier this sort of mass enabling of ESLint rules becomes a lot easier, since the code will be automatically reformatted as necessary to account for e.g. changed line lengths. Note that this patch is generated automatically, by using the ESLint `--fix` argument, and will thus require some additional clean-up (which is done separately).
2020-01-24 17:48:21 +09:00
const glyphsUnicodeMap = getGlyphsUnicode();
Fix remaining linting errors, from enabling the `prefer-const` ESLint rule globally This covers cases that the `--fix` command couldn't deal with, and in a few cases (notably `src/core/jbig2.js`) the code was changed to use block-scoped variables instead.
2020-01-24 21:21:16 +09:00
for (const charcode in encoding) {
Refactor the building of `ToUnicode` maps for simple fonts a helper method
2017-11-26 20:53:06 +09:00
// a) Map the character code to a character name.
Fix remaining linting errors, from enabling the `prefer-const` ESLint rule globally This covers cases that the `--fix` command couldn't deal with, and in a few cases (notably `src/core/jbig2.js`) the code was changed to use block-scoped variables instead.
2020-01-24 21:21:16 +09:00
let glyphName = encoding[charcode];
Refactor the building of `ToUnicode` maps for simple fonts a helper method
2017-11-26 20:53:06 +09:00
// b) Look up the character name in the Adobe Glyph List (see the
// Bibliography) to obtain the corresponding Unicode value.
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
if (glyphName === "") {
Refactor the building of `ToUnicode` maps for simple fonts a helper method
2017-11-26 20:53:06 +09:00
continue;
} else if (glyphsUnicodeMap[glyphName] === undefined) {
// (undocumented) c) Few heuristics to recognize unknown glyphs
// NOTE: Adobe Reader does not do this step, but OSX Preview does
let code = 0;
switch (glyphName[0]) {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
case "G": // Gxx glyph
Refactor the building of `ToUnicode` maps for simple fonts a helper method
2017-11-26 20:53:06 +09:00
if (glyphName.length === 3) {
Replace `String.prototype.substr()` occurrences with `String.prototype.substring()` As outlined in https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/substr, which refers to the ECMA-262 specification, using the `substr` function is advised against. Hence this PR, which replaces all remaining `substr` occurrences with `substring` instead. Please refer to https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/substr#Syntax respectively https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/substring#Syntax for the differences between the two functions. Note that in most cases in the code-base there's only one argument passed to `substr`, and those require no other changes except replacing "substr" with "substring". For the other cases, the `substr(start, length)` calls are changed to `substring(start, start + length)` instead.
2018-09-28 18:41:07 +09:00
code = parseInt(glyphName.substring(1), 16);
Refactor the building of `ToUnicode` maps for simple fonts a helper method
2017-11-26 20:53:06 +09:00
}
break;
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
case "g": // g00xx glyph
Refactor the building of `ToUnicode` maps for simple fonts a helper method
2017-11-26 20:53:06 +09:00
if (glyphName.length === 5) {
Replace `String.prototype.substr()` occurrences with `String.prototype.substring()` As outlined in https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/substr, which refers to the ECMA-262 specification, using the `substr` function is advised against. Hence this PR, which replaces all remaining `substr` occurrences with `substring` instead. Please refer to https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/substr#Syntax respectively https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/substring#Syntax for the differences between the two functions. Note that in most cases in the code-base there's only one argument passed to `substr`, and those require no other changes except replacing "substr" with "substring". For the other cases, the `substr(start, length)` calls are changed to `substring(start, start + length)` instead.
2018-09-28 18:41:07 +09:00
code = parseInt(glyphName.substring(1), 16);
Refactor the building of `ToUnicode` maps for simple fonts a helper method
2017-11-26 20:53:06 +09:00
}
break;
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
case "C": // Cdd{d} glyph
case "c": // cdd{d} glyph
Improve the heuristics, in `PartialEvaluator._buildSimpleFontToUnicode`, for glyphNames of the Cdd{d}/cdd{d} format (issue 9655) *Please note:* I've been thinking about possible ways of addressing this issue for a while now, but all of the solutions I came up with became too complicated and thus hurt readability of the code. However, it occured to me that we're essentially trying to add a heuristic *on top* of another heuristic, and that it shouldn't matter how efficient the code is as long as it works. In the PDF file in the issue the Encoding contains glyphNames of the `Cdd` format, which our existing heuristics will treat as base 10 values. However, in this particular file they actually contain base 16 values, which we thus attempt to detect and fix such that text-selection works.
2019-09-30 06:50:58 +09:00
if (glyphName.length >= 3 && glyphName.length <= 4) {
const codeStr = glyphName.substring(1);
if (forceGlyphs) {
code = parseInt(codeStr, 16);
break;
}
// Normally the Cdd{d}/cdd{d} glyphName format will contain
// regular, i.e. base 10, charCodes (see issue4550.pdf)...
code = +codeStr;
// ... however some PDF generators violate that assumption by
// containing glyph, i.e. base 16, codes instead.
// In that case we need to re-parse the *entire* encoding to
// prevent broken text-selection (fixes issue9655_reduced.pdf).
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
if (
Number.isNaN(code) &&
Number.isInteger(parseInt(codeStr, 16))
) {
return this._buildSimpleFontToUnicode(
properties,
/* forceGlyphs */ true
);
Improve the heuristics, in `PartialEvaluator._buildSimpleFontToUnicode`, for glyphNames of the Cdd{d}/cdd{d} format (issue 9655) *Please note:* I've been thinking about possible ways of addressing this issue for a while now, but all of the solutions I came up with became too complicated and thus hurt readability of the code. However, it occured to me that we're essentially trying to add a heuristic *on top* of another heuristic, and that it shouldn't matter how efficient the code is as long as it works. In the PDF file in the issue the Encoding contains glyphNames of the `Cdd` format, which our existing heuristics will treat as base 10 values. However, in this particular file they actually contain base 16 values, which we thus attempt to detect and fix such that text-selection works.
2019-09-30 06:50:58 +09:00
}
Refactor the building of `ToUnicode` maps for simple fonts a helper method
2017-11-26 20:53:06 +09:00
}
break;
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
default:
// 'uniXXXX'/'uXXXX{XX}' glyphs
Enable the ESLint `prefer-const` rule globally (PR 11450 follow-up) Please find additional details about the ESLint rule at https://eslint.org/docs/rules/prefer-const With the recent introduction of Prettier this sort of mass enabling of ESLint rules becomes a lot easier, since the code will be automatically reformatted as necessary to account for e.g. changed line lengths. Note that this patch is generated automatically, by using the ESLint `--fix` argument, and will thus require some additional clean-up (which is done separately).
2020-01-24 17:48:21 +09:00
const unicode = getUnicodeForGlyph(glyphName, glyphsUnicodeMap);
Refactor the building of `ToUnicode` maps for simple fonts a helper method
2017-11-26 20:53:06 +09:00
if (unicode !== -1) {
code = unicode;
}
}
A couple of small `String.fromCodePoint` improvements (PR 11698 and 11769 follow-up) - Add a reduced test-case for issue 11768, to prevent future regressions. (Given that PR 11769 is only a work-around, rather than a proper solution, it may not be entirely accurate for the issue to be closed as fixed.) - Add more validation of the charCode, as found by the heuristics, in `PartialEvaluator._buildSimpleFontToUnicode` to prevent future issues.
2020-04-15 20:34:13 +09:00
if (code > 0 && code <= 0x10ffff && Number.isInteger(code)) {
Refactor the building of `ToUnicode` maps for simple fonts a helper method
2017-11-26 20:53:06 +09:00
// If `baseEncodingName` is one the predefined encodings, and `code`
// equals `charcode`, using the glyph defined in the baseEncoding
// seems to yield a better `toUnicode` mapping (fixes issue 5070).
if (baseEncodingName && code === +charcode) {
Enable the ESLint `prefer-const` rule globally (PR 11450 follow-up) Please find additional details about the ESLint rule at https://eslint.org/docs/rules/prefer-const With the recent introduction of Prettier this sort of mass enabling of ESLint rules becomes a lot easier, since the code will be automatically reformatted as necessary to account for e.g. changed line lengths. Note that this patch is generated automatically, by using the ESLint `--fix` argument, and will thus require some additional clean-up (which is done separately).
2020-01-24 17:48:21 +09:00
const baseEncoding = getEncoding(baseEncodingName);
Refactor the building of `ToUnicode` maps for simple fonts a helper method
2017-11-26 20:53:06 +09:00
if (baseEncoding && (glyphName = baseEncoding[charcode])) {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
toUnicode[charcode] = String.fromCharCode(
glyphsUnicodeMap[glyphName]
);
Refactor the building of `ToUnicode` maps for simple fonts a helper method
2017-11-26 20:53:06 +09:00
continue;
}
}
Fix copying on supplementary plane characters pdf.js had a problem when copying characters on supplementary planes (0xPPXXXX where PP is nonzero). This is because certain methods of PartialEvaluator use classic String.fromCharCode instead of ES6's String.fromCodePoint. Despite the fact that readToUnicode method *tried* to parse out-of-UCS2 code points by parsing UTF-16BE, it was inadequate because String.fromCharCode only supports UCS-2 range of Unicode.
2019-02-09 15:53:16 +09:00
toUnicode[charcode] = String.fromCodePoint(code);
Refactor the building of `ToUnicode` maps for simple fonts a helper method
2017-11-26 20:53:06 +09:00
}
continue;
}
toUnicode[charcode] = String.fromCharCode(glyphsUnicodeMap[glyphName]);
}
return new ToUnicodeMap(toUnicode);
},
Refactors CMapFactory.create to make it async
2016-02-29 01:20:29 +09:00
/**
* Builds a char code to unicode map based on section 9.10 of the spec.
* @param {Object} properties Font properties object.
Consistently use `@returns` for returned data types in JSDoc comments Sometimes we also used `@return`, but `@returns` is what the JSDoc documentation recommends. Even though `@return` works as an alias, it's good to use the recommended syntax and to be consistent within the project.
2019-10-13 01:14:29 +09:00
* @returns {Promise} A Promise that is resolved with a
Remove the remaining usages of `new {Name,Cmd}` in favor of `{Name,Cmd}.get` Using `new {Name,Cmd}` should be avoided, since it creates a new object on *every* call, whereas `{Name,Cmd}.get` uses caches to only create *one* object regardless of how many times they are called. Most of these are found in the unit-tests, where increased memory usage probably doesn't matter very much. But it still seems good to get rid of those cases, since no part of the codebase ought to advertise that usage. Given the small size of the patch, I'm also tweaking a few comments and class names.
2016-04-08 19:14:05 +09:00
* {ToUnicodeMap|IdentityToUnicodeMap} object.
Refactors CMapFactory.create to make it async
2016-02-29 01:20:29 +09:00
*/
Refactor the building of `ToUnicode` maps for simple fonts a helper method
2017-11-26 20:53:06 +09:00
buildToUnicode(properties) {
For embedded Type1 fonts without included `ToUnicode`/`Encoding` data, attempt to improve text selection by using the `builtInEncoding` to amend the `toUnicode` map (issue 6901, issue 7182, issue 7217, bug 917796, bug 1242142) Note that in order to prevent any possible issues, this patch does *not* try to amend the `toUnicode` data for Type1 fonts that contain either `ToUnicode` or `Encoding` entries in the font dictionary. Fixes, or at least improves, issues/bugs such as e.g. 6658, 6901, 7182, 7217, bug 917796, bug 1242142.
2016-08-18 01:33:06 +09:00
properties.hasIncludedToUnicodeMap =
!!properties.toUnicode && properties.toUnicode.length > 0;
Refactor the building of `ToUnicode` maps for simple fonts a helper method
2017-11-26 20:53:06 +09:00
Refactors CMapFactory.create to make it async
2016-02-29 01:20:29 +09:00
// Section 9.10.2 Mapping Character Codes to Unicode Values
For embedded Type1 fonts without included `ToUnicode`/`Encoding` data, attempt to improve text selection by using the `builtInEncoding` to amend the `toUnicode` map (issue 6901, issue 7182, issue 7217, bug 917796, bug 1242142) Note that in order to prevent any possible issues, this patch does *not* try to amend the `toUnicode` data for Type1 fonts that contain either `ToUnicode` or `Encoding` entries in the font dictionary. Fixes, or at least improves, issues/bugs such as e.g. 6658, 6901, 7182, 7217, bug 917796, bug 1242142.
2016-08-18 01:33:06 +09:00
if (properties.hasIncludedToUnicodeMap) {
Build a fallback `ToUnicode` map for simple fonts (issue 8229) In some fonts, the included `ToUnicode` data is incomplete causing text-selection to not work properly. For simple fonts that contain encoding data, we can manually build a `ToUnicode` map to attempt to improve things. Please note that since we're currently using the `ToUnicode` data during glyph mapping, in an attempt to avoid rendering regressions, I purposely didn't want to amend to original `ToUnicode` data for this text-selection edge-case. Instead, I opted for the current solution, which will (hopefully) give slightly better text-extraction results in PDF file with incomplete `ToUnicode` data. According to the PDF specification, see [section 9.10.2](http://www.adobe.com/content/dam/acom/en/devnet/acrobat/pdfs/PDF32000_2008.pdf#G8.1873172): > A conforming reader can use these methods, in the priority given, to map a character code to a Unicode value. > ... Reading that paragraph literally, it doesn't seem too unreasonable to use *different* methods for different charcodes. Fixes 8229.
2017-11-26 21:29:43 +09:00
// Some fonts contain incomplete ToUnicode data, causing issues with
// text-extraction. For simple fonts, containing encoding information,
// use a fallback ToUnicode map to improve this (fixes issue8229.pdf).
if (!properties.composite && properties.hasEncoding) {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
properties.fallbackToUnicode = this._buildSimpleFontToUnicode(
properties
);
Build a fallback `ToUnicode` map for simple fonts (issue 8229) In some fonts, the included `ToUnicode` data is incomplete causing text-selection to not work properly. For simple fonts that contain encoding data, we can manually build a `ToUnicode` map to attempt to improve things. Please note that since we're currently using the `ToUnicode` data during glyph mapping, in an attempt to avoid rendering regressions, I purposely didn't want to amend to original `ToUnicode` data for this text-selection edge-case. Instead, I opted for the current solution, which will (hopefully) give slightly better text-extraction results in PDF file with incomplete `ToUnicode` data. According to the PDF specification, see [section 9.10.2](http://www.adobe.com/content/dam/acom/en/devnet/acrobat/pdfs/PDF32000_2008.pdf#G8.1873172): > A conforming reader can use these methods, in the priority given, to map a character code to a Unicode value. > ... Reading that paragraph literally, it doesn't seem too unreasonable to use *different* methods for different charcodes. Fixes 8229.
2017-11-26 21:29:43 +09:00
}
Refactors CMapFactory.create to make it async
2016-02-29 01:20:29 +09:00
return Promise.resolve(properties.toUnicode);
}
Refactor the building of `ToUnicode` maps for simple fonts a helper method
2017-11-26 20:53:06 +09:00
Refactors CMapFactory.create to make it async
2016-02-29 01:20:29 +09:00
// According to the spec if the font is a simple font we should only map
// to unicode if the base encoding is MacRoman, MacExpert, or WinAnsi or
// the differences array only contains adobe standard or symbol set names,
Refactor the building of `ToUnicode` maps for simple fonts a helper method
2017-11-26 20:53:06 +09:00
// in pratice it seems better to always try to create a toUnicode map
// based of the default encoding.
Refactors CMapFactory.create to make it async
2016-02-29 01:20:29 +09:00
if (!properties.composite /* is simple font */) {
Refactor the building of `ToUnicode` maps for simple fonts a helper method
2017-11-26 20:53:06 +09:00
return Promise.resolve(this._buildSimpleFontToUnicode(properties));
Refactors CMapFactory.create to make it async
2016-02-29 01:20:29 +09:00
}
Refactor the building of `ToUnicode` maps for simple fonts a helper method
2017-11-26 20:53:06 +09:00
Refactors CMapFactory.create to make it async
2016-02-29 01:20:29 +09:00
// If the font is a composite font that uses one of the predefined CMaps
// listed in Table 118 (except Identity–H and Identity–V) or whose
// descendant CIDFont uses the Adobe-GB1, Adobe-CNS1, Adobe-Japan1, or
// Adobe-Korea1 character collection:
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
if (
properties.composite &&
((properties.cMap.builtInCMap &&
!(properties.cMap instanceof IdentityCMap)) ||
(properties.cidSystemInfo.registry === "Adobe" &&
(properties.cidSystemInfo.ordering === "GB1" ||
properties.cidSystemInfo.ordering === "CNS1" ||
properties.cidSystemInfo.ordering === "Japan1" ||
properties.cidSystemInfo.ordering === "Korea1")))
) {
Refactors CMapFactory.create to make it async
2016-02-29 01:20:29 +09:00
// Then:
// a) Map the character code to a character identifier (CID) according
// to the font’s CMap.
// b) Obtain the registry and ordering of the character collection used
// by the font’s CMap (for example, Adobe and Japan1) from its
// CIDSystemInfo dictionary.
Enable the ESLint `prefer-const` rule globally (PR 11450 follow-up) Please find additional details about the ESLint rule at https://eslint.org/docs/rules/prefer-const With the recent introduction of Prettier this sort of mass enabling of ESLint rules becomes a lot easier, since the code will be automatically reformatted as necessary to account for e.g. changed line lengths. Note that this patch is generated automatically, by using the ESLint `--fix` argument, and will thus require some additional clean-up (which is done separately).
2020-01-24 17:48:21 +09:00
const registry = properties.cidSystemInfo.registry;
const ordering = properties.cidSystemInfo.ordering;
Refactors CMapFactory.create to make it async
2016-02-29 01:20:29 +09:00
// c) Construct a second CMap name by concatenating the registry and
// ordering obtained in step (b) in the format registry–ordering–UCS2
// (for example, Adobe–Japan1–UCS2).
Enable the ESLint `prefer-const` rule globally (PR 11450 follow-up) Please find additional details about the ESLint rule at https://eslint.org/docs/rules/prefer-const With the recent introduction of Prettier this sort of mass enabling of ESLint rules becomes a lot easier, since the code will be automatically reformatted as necessary to account for e.g. changed line lengths. Note that this patch is generated automatically, by using the ESLint `--fix` argument, and will thus require some additional clean-up (which is done separately).
2020-01-24 17:48:21 +09:00
const ucs2CMapName = Name.get(registry + "-" + ordering + "-UCS2");
Refactors CMapFactory.create to make it async
2016-02-29 01:20:29 +09:00
// d) Obtain the CMap with the name constructed in step (c) (available
// from the ASN Web site; see the Bibliography).
[api-minor] Refactor fetching of built-in CMaps to utilize a factory on the `display` side instead, to allow users of the API to provide a custom CMap loading factory (e.g. for use with Node.js) Currently the built-in CMap files are loaded in `src/core/cmap.js` using `XMLHttpRequest` directly. For some environments that might be a problem, hence this patch refactors that to instead use a factory to load built-in CMaps on the main thread and message the data to the worker thread. This is inspired by other recent work, e.g. the addition of the `CanvasFactory`, and to a large extent on the IRC discussion starting at http://logs.glob.uno/?c=mozilla%23pdfjs&s=12+Oct+2016&e=12+Oct+2016#c53010.
2017-02-12 23:54:41 +09:00
return CMapFactory.create({
encoding: ucs2CMapName,
fetchBuiltInCMap: this.fetchBuiltInCMap,
useCMap: null,
Update Prettier to version 2.0 Please note that these changes were done automatically, using `gulp lint --fix`. Given that the major version number was increased, there's a fair number of (primarily whitespace) changes; please see https://prettier.io/blog/2020/03/21/2.0.0.html In order to reduce the size of these changes somewhat, this patch maintains the old "arrowParens" style for now (once mozilla-central updates Prettier we can simply choose the same formatting, assuming it will differ here).
2020-04-14 19:28:14 +09:00
}).then(function (ucs2CMap) {
Enable the ESLint `prefer-const` rule globally (PR 11450 follow-up) Please find additional details about the ESLint rule at https://eslint.org/docs/rules/prefer-const With the recent introduction of Prettier this sort of mass enabling of ESLint rules becomes a lot easier, since the code will be automatically reformatted as necessary to account for e.g. changed line lengths. Note that this patch is generated automatically, by using the ESLint `--fix` argument, and will thus require some additional clean-up (which is done separately).
2020-01-24 17:48:21 +09:00
const cMap = properties.cMap;
const toUnicode = [];
Update Prettier to version 2.0 Please note that these changes were done automatically, using `gulp lint --fix`. Given that the major version number was increased, there's a fair number of (primarily whitespace) changes; please see https://prettier.io/blog/2020/03/21/2.0.0.html In order to reduce the size of these changes somewhat, this patch maintains the old "arrowParens" style for now (once mozilla-central updates Prettier we can simply choose the same formatting, assuming it will differ here).
2020-04-14 19:28:14 +09:00
cMap.forEach(function (charcode, cid) {
Remove most `assert()` calls (issue 8506) This replaces `assert` calls with `throw new FormatError()`/`throw new Error()`. In a few places, throwing an `Error` (which is what `assert` meant) isn't correct since the enclosing function is supposed to return a `Promise`, hence some cases were changed to `Promise.reject(...)` and similarily for `createPromiseCapability` instances.
2017-07-20 21:04:54 +09:00
if (cid > 0xffff) {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
throw new FormatError("Max size of CID is 65,535");
Remove most `assert()` calls (issue 8506) This replaces `assert` calls with `throw new FormatError()`/`throw new Error()`. In a few places, throwing an `Error` (which is what `assert` meant) isn't correct since the enclosing function is supposed to return a `Promise`, hence some cases were changed to `Promise.reject(...)` and similarily for `createPromiseCapability` instances.
2017-07-20 21:04:54 +09:00
}
Refactors CMapFactory.create to make it async
2016-02-29 01:20:29 +09:00
// e) Map the CID obtained in step (a) according to the CMap
// obtained in step (d), producing a Unicode value.
Enable the ESLint `prefer-const` rule globally (PR 11450 follow-up) Please find additional details about the ESLint rule at https://eslint.org/docs/rules/prefer-const With the recent introduction of Prettier this sort of mass enabling of ESLint rules becomes a lot easier, since the code will be automatically reformatted as necessary to account for e.g. changed line lengths. Note that this patch is generated automatically, by using the ESLint `--fix` argument, and will thus require some additional clean-up (which is done separately).
2020-01-24 17:48:21 +09:00
const ucs2 = ucs2CMap.lookup(cid);
Refactors CMapFactory.create to make it async
2016-02-29 01:20:29 +09:00
if (ucs2) {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
toUnicode[charcode] = String.fromCharCode(
(ucs2.charCodeAt(0) << 8) + ucs2.charCodeAt(1)
);
Migration of the 'encoding-1' branch (ref #674)
2011-10-29 10:38:31 +09:00
}
Refactors CMapFactory.create to make it async
2016-02-29 01:20:29 +09:00
});
return new ToUnicodeMap(toUnicode);
});
}
// The viewer's choice, just use an identity map.
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
return Promise.resolve(
new IdentityToUnicodeMap(properties.firstChar, properties.lastChar)
);
Refactors CMapFactory.create to make it async
2016-02-29 01:20:29 +09:00
},
readToUnicode: function PartialEvaluator_readToUnicode(toUnicode) {
var cmapObj = toUnicode;
if (isName(cmapObj)) {
[api-minor] Refactor fetching of built-in CMaps to utilize a factory on the `display` side instead, to allow users of the API to provide a custom CMap loading factory (e.g. for use with Node.js) Currently the built-in CMap files are loaded in `src/core/cmap.js` using `XMLHttpRequest` directly. For some environments that might be a problem, hence this patch refactors that to instead use a factory to load built-in CMaps on the main thread and message the data to the worker thread. This is inspired by other recent work, e.g. the addition of the `CanvasFactory`, and to a large extent on the IRC discussion starting at http://logs.glob.uno/?c=mozilla%23pdfjs&s=12+Oct+2016&e=12+Oct+2016#c53010.
2017-02-12 23:54:41 +09:00
return CMapFactory.create({
encoding: cmapObj,
fetchBuiltInCMap: this.fetchBuiltInCMap,
useCMap: null,
Update Prettier to version 2.0 Please note that these changes were done automatically, using `gulp lint --fix`. Given that the major version number was increased, there's a fair number of (primarily whitespace) changes; please see https://prettier.io/blog/2020/03/21/2.0.0.html In order to reduce the size of these changes somewhat, this patch maintains the old "arrowParens" style for now (once mozilla-central updates Prettier we can simply choose the same formatting, assuming it will differ here).
2020-04-14 19:28:14 +09:00
}).then(function (cmap) {
Refactors CMapFactory.create to make it async
2016-02-29 01:20:29 +09:00
if (cmap instanceof IdentityCMap) {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
return new IdentityToUnicodeMap(0, 0xffff);
Refactors CMapFactory.create to make it async
2016-02-29 01:20:29 +09:00
}
return new ToUnicodeMap(cmap.getMap());
});
} else if (isStream(cmapObj)) {
[api-minor] Refactor fetching of built-in CMaps to utilize a factory on the `display` side instead, to allow users of the API to provide a custom CMap loading factory (e.g. for use with Node.js) Currently the built-in CMap files are loaded in `src/core/cmap.js` using `XMLHttpRequest` directly. For some environments that might be a problem, hence this patch refactors that to instead use a factory to load built-in CMaps on the main thread and message the data to the worker thread. This is inspired by other recent work, e.g. the addition of the `CanvasFactory`, and to a large extent on the IRC discussion starting at http://logs.glob.uno/?c=mozilla%23pdfjs&s=12+Oct+2016&e=12+Oct+2016#c53010.
2017-02-12 23:54:41 +09:00
return CMapFactory.create({
encoding: cmapObj,
fetchBuiltInCMap: this.fetchBuiltInCMap,
useCMap: null,
Allow skipping of errors when reading broken/corrupt ToUnicode data (issue 11549) This will allow font loading/parsing to continue, rather than immediately failing, when broken/corrupt CMap data is encountered.
2020-01-30 21:13:51 +09:00
}).then(
Update Prettier to version 2.0 Please note that these changes were done automatically, using `gulp lint --fix`. Given that the major version number was increased, there's a fair number of (primarily whitespace) changes; please see https://prettier.io/blog/2020/03/21/2.0.0.html In order to reduce the size of these changes somewhat, this patch maintains the old "arrowParens" style for now (once mozilla-central updates Prettier we can simply choose the same formatting, assuming it will differ here).
2020-04-14 19:28:14 +09:00
function (cmap) {
Allow skipping of errors when reading broken/corrupt ToUnicode data (issue 11549) This will allow font loading/parsing to continue, rather than immediately failing, when broken/corrupt CMap data is encountered.
2020-01-30 21:13:51 +09:00
if (cmap instanceof IdentityCMap) {
return new IdentityToUnicodeMap(0, 0xffff);
}
var map = new Array(cmap.length);
// Convert UTF-16BE
// NOTE: cmap can be a sparse array, so use forEach instead of
// `for(;;)` to iterate over all keys.
Update Prettier to version 2.0 Please note that these changes were done automatically, using `gulp lint --fix`. Given that the major version number was increased, there's a fair number of (primarily whitespace) changes; please see https://prettier.io/blog/2020/03/21/2.0.0.html In order to reduce the size of these changes somewhat, this patch maintains the old "arrowParens" style for now (once mozilla-central updates Prettier we can simply choose the same formatting, assuming it will differ here).
2020-04-14 19:28:14 +09:00
cmap.forEach(function (charCode, token) {
Allow skipping of errors when reading broken/corrupt ToUnicode data (issue 11549) This will allow font loading/parsing to continue, rather than immediately failing, when broken/corrupt CMap data is encountered.
2020-01-30 21:13:51 +09:00
var str = [];
for (var k = 0; k < token.length; k += 2) {
var w1 = (token.charCodeAt(k) << 8) | token.charCodeAt(k + 1);
if ((w1 & 0xf800) !== 0xd800) {
// w1 < 0xD800 || w1 > 0xDFFF
str.push(w1);
continue;
}
k += 2;
var w2 = (token.charCodeAt(k) << 8) | token.charCodeAt(k + 1);
str.push(((w1 & 0x3ff) << 10) + (w2 & 0x3ff) + 0x10000);
Refactors CMapFactory.create to make it async
2016-02-29 01:20:29 +09:00
}
Allow skipping of errors when reading broken/corrupt ToUnicode data (issue 11549) This will allow font loading/parsing to continue, rather than immediately failing, when broken/corrupt CMap data is encountered.
2020-01-30 21:13:51 +09:00
map[charCode] = String.fromCodePoint.apply(String, str);
});
return new ToUnicodeMap(map);
},
reason => {
if (reason instanceof AbortException) {
return null;
Refactors CMapFactory.create to make it async
2016-02-29 01:20:29 +09:00
}
Allow skipping of errors when reading broken/corrupt ToUnicode data (issue 11549) This will allow font loading/parsing to continue, rather than immediately failing, when broken/corrupt CMap data is encountered.
2020-01-30 21:13:51 +09:00
if (this.options.ignoreErrors) {
// Error in the ToUnicode data -- sending unsupported feature
// notification and allow font parsing to continue.
this.handler.send("UnsupportedFeature", {
Add more categories of unsupported features. Fixes #11815
2020-05-01 07:27:37 +09:00
featureId: UNSUPPORTED_FEATURES.errorFontToUnicode,
Allow skipping of errors when reading broken/corrupt ToUnicode data (issue 11549) This will allow font loading/parsing to continue, rather than immediately failing, when broken/corrupt CMap data is encountered.
2020-01-30 21:13:51 +09:00
});
warn(`readToUnicode - ignoring ToUnicode data: "${reason}".`);
return null;
}
throw reason;
}
);
Splitting files
2011-10-25 08:55:23 +09:00
}
Refactors CMapFactory.create to make it async
2016-02-29 01:20:29 +09:00
return Promise.resolve(null);
Splitting files
2011-10-25 08:55:23 +09:00
},
Making src/core/evaluator.js adhere to the style guide
2014-03-23 03:15:51 +09:00
Fix glyph 0 in CIDFontType2 that has a CIDToGIDMap stream
2019-05-08 00:44:37 +09:00
readCidToGidMap(glyphsData, toUnicode) {
Migration of the 'encoding-1' branch (ref #674)
2011-10-29 10:38:31 +09:00
// Extract the encoding from the CIDToGIDMap
// Set encoding 0 to later verify the font has an encoding
var result = [];
Merge branch 'master' of git://github.com/mozilla/pdf.js.git into encoding-2 Conflicts: src/evaluator.js src/fonts.js
2011-11-13 02:09:19 +09:00
for (var j = 0, jj = glyphsData.length; j < jj; j++) {
Migration of the 'encoding-1' branch (ref #674)
2011-10-29 10:38:31 +09:00
var glyphID = (glyphsData[j++] << 8) | glyphsData[j];
Fix glyph 0 in CIDFontType2 that has a CIDToGIDMap stream
2019-05-08 00:44:37 +09:00
const code = j >> 1;
if (glyphID === 0 && !toUnicode.has(code)) {
Migration of the 'encoding-1' branch (ref #674)
2011-10-29 10:38:31 +09:00
continue;
Making src/core/evaluator.js adhere to the style guide
2014-03-23 03:15:51 +09:00
}
Migration of the 'encoding-1' branch (ref #674)
2011-10-29 10:38:31 +09:00
result[code] = glyphID;
Splitting files
2011-10-25 08:55:23 +09:00
}
Migration of the 'encoding-1' branch (ref #674)
2011-10-29 10:38:31 +09:00
return result;
},
Splitting files
2011-10-25 08:55:23 +09:00
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
extractWidths: function PartialEvaluator_extractWidths(
dict,
descriptor,
properties
) {
Remove unnecessary `xref` parameters from various method signatures in `PartialEvaluator`, since `this.xref` is already available in the relevant scope For reasons I don't pretend to understand, we're passing around `xref` arguments to a bunch of methods despite `this.xref` being available in `PartialEvaluator`. This patch is a small first small step towards cleaning up the, often unwieldy, signatures of methods in `PartialEvaluator`.
2017-03-26 21:12:53 +09:00
var xref = this.xref;
Migration of the 'encoding-1' branch (ref #674)
2011-10-29 10:38:31 +09:00
var glyphsWidths = [];
Splitting files
2011-10-25 08:55:23 +09:00
var defaultWidth = 0;
Implements vertical writing
2013-02-08 21:29:22 +09:00
var glyphsVMetrics = [];
var defaultVMetrics;
Fixes lint warning W004 in src/core
2014-04-08 06:42:54 +09:00
var i, ii, j, jj, start, code, widths;
Migration of the 'encoding-1' branch (ref #674)
2011-10-29 10:38:31 +09:00
if (properties.composite) {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
defaultWidth = dict.has("DW") ? dict.get("DW") : 1000;
Migration of the 'encoding-1' branch (ref #674)
2011-10-29 10:38:31 +09:00
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
widths = dict.get("W");
Migration of the 'encoding-1' branch (ref #674)
2011-10-29 10:38:31 +09:00
if (widths) {
Fixes lint warning W004 in src/core
2014-04-08 06:42:54 +09:00
for (i = 0, ii = widths.length; i < ii; i++) {
Ensure that `PartialEvaluator_extractWidths` is able to handle indirect objects in all kinds of "width" data (issue 7855) Fixes 7855.
2016-11-30 02:28:32 +09:00
start = xref.fetchIfRef(widths[i++]);
Fixes lint warning W004 in src/core
2014-04-08 06:42:54 +09:00
code = xref.fetchIfRef(widths[i]);
Replace the `isArray` helper function with the native `Array.isArray` function *Follow-up to PR 8813.*
2017-09-02 03:27:13 +09:00
if (Array.isArray(code)) {
Fixes lint warning W004 in src/core
2014-04-08 06:42:54 +09:00
for (j = 0, jj = code.length; j < jj; j++) {
Ensure that `PartialEvaluator_extractWidths` is able to handle indirect objects in all kinds of "width" data (issue 7855) Fixes 7855.
2016-11-30 02:28:32 +09:00
glyphsWidths[start++] = xref.fetchIfRef(code[j]);
Making src/core/evaluator.js adhere to the style guide
2014-03-23 03:15:51 +09:00
}
Fixes reading of the widths for CID fonts
2013-01-30 07:19:08 +09:00
} else {
Ensure that `PartialEvaluator_extractWidths` is able to handle indirect objects in all kinds of "width" data (issue 7855) Fixes 7855.
2016-11-30 02:28:32 +09:00
var width = xref.fetchIfRef(widths[++i]);
Fixes lint warning W004 in src/core
2014-04-08 06:42:54 +09:00
for (j = start; j <= code; j++) {
Migration of the 'encoding-1' branch (ref #674)
2011-10-29 10:38:31 +09:00
glyphsWidths[j] = width;
Making src/core/evaluator.js adhere to the style guide
2014-03-23 03:15:51 +09:00
}
Migration of the 'encoding-1' branch (ref #674)
2011-10-29 10:38:31 +09:00
}
}
}
Implements vertical writing
2013-02-08 21:29:22 +09:00
if (properties.vertical) {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
var vmetrics = dict.getArray("DW2") || [880, -1000];
Fix the calculation of default vertical metrics Fixes bug 849627 and 849628. The current code was obviously wrong per the spec 9.7.4.3.
2013-03-13 01:27:45 +09:00
defaultVMetrics = [vmetrics[1], defaultWidth * 0.5, vmetrics[0]];
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
vmetrics = dict.get("W2");
Implements vertical writing
2013-02-08 21:29:22 +09:00
if (vmetrics) {
Fixes lint warning W004 in src/core
2014-04-08 06:42:54 +09:00
for (i = 0, ii = vmetrics.length; i < ii; i++) {
Ensure that `PartialEvaluator_extractWidths` is able to handle indirect objects in all kinds of "width" data (issue 7855) Fixes 7855.
2016-11-30 02:28:32 +09:00
start = xref.fetchIfRef(vmetrics[i++]);
Fixes lint warning W004 in src/core
2014-04-08 06:42:54 +09:00
code = xref.fetchIfRef(vmetrics[i]);
Replace the `isArray` helper function with the native `Array.isArray` function *Follow-up to PR 8813.*
2017-09-02 03:27:13 +09:00
if (Array.isArray(code)) {
Fixes lint warning W004 in src/core
2014-04-08 06:42:54 +09:00
for (j = 0, jj = code.length; j < jj; j++) {
Ensure that `PartialEvaluator_extractWidths` is able to handle indirect objects in all kinds of "width" data (issue 7855) Fixes 7855.
2016-11-30 02:28:32 +09:00
glyphsVMetrics[start++] = [
xref.fetchIfRef(code[j++]),
xref.fetchIfRef(code[j++]),
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
xref.fetchIfRef(code[j]),
Ensure that `PartialEvaluator_extractWidths` is able to handle indirect objects in all kinds of "width" data (issue 7855) Fixes 7855.
2016-11-30 02:28:32 +09:00
];
Making src/core/evaluator.js adhere to the style guide
2014-03-23 03:15:51 +09:00
}
Implements vertical writing
2013-02-08 21:29:22 +09:00
} else {
Ensure that `PartialEvaluator_extractWidths` is able to handle indirect objects in all kinds of "width" data (issue 7855) Fixes 7855.
2016-11-30 02:28:32 +09:00
var vmetric = [
xref.fetchIfRef(vmetrics[++i]),
xref.fetchIfRef(vmetrics[++i]),
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
xref.fetchIfRef(vmetrics[++i]),
Ensure that `PartialEvaluator_extractWidths` is able to handle indirect objects in all kinds of "width" data (issue 7855) Fixes 7855.
2016-11-30 02:28:32 +09:00
];
Fixes lint warning W004 in src/core
2014-04-08 06:42:54 +09:00
for (j = start; j <= code; j++) {
Implements vertical writing
2013-02-08 21:29:22 +09:00
glyphsVMetrics[j] = vmetric;
Making src/core/evaluator.js adhere to the style guide
2014-03-23 03:15:51 +09:00
}
Implements vertical writing
2013-02-08 21:29:22 +09:00
}
}
}
}
Migration of the 'encoding-1' branch (ref #674)
2011-10-29 10:38:31 +09:00
} else {
var firstChar = properties.firstChar;
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
widths = dict.get("Widths");
Migration of the 'encoding-1' branch (ref #674)
2011-10-29 10:38:31 +09:00
if (widths) {
Fixes lint warning W004 in src/core
2014-04-08 06:42:54 +09:00
j = firstChar;
for (i = 0, ii = widths.length; i < ii; i++) {
Ensure that `PartialEvaluator_extractWidths` is able to handle indirect objects in all kinds of "width" data (issue 7855) Fixes 7855.
2016-11-30 02:28:32 +09:00
glyphsWidths[j++] = xref.fetchIfRef(widths[i]);
Making src/core/evaluator.js adhere to the style guide
2014-03-23 03:15:51 +09:00
}
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
defaultWidth = parseFloat(descriptor.get("MissingWidth")) || 0;
Migration of the 'encoding-1' branch (ref #674)
2011-10-29 10:38:31 +09:00
} else {
// Trying get the BaseFont metrics (see comment above).
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
var baseFontName = dict.get("BaseFont");
Migration of the 'encoding-1' branch (ref #674)
2011-10-29 10:38:31 +09:00
if (isName(baseFontName)) {
var metrics = this.getBaseFontMetrics(baseFontName.name);
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
glyphsWidths = this.buildCharCodeToWidth(
metrics.widths,
properties
);
Migration of the 'encoding-1' branch (ref #674)
2011-10-29 10:38:31 +09:00
defaultWidth = metrics.defaultWidth;
}
}
}
Adds heuristic for monospace font detection
2012-09-17 04:38:30 +09:00
// Heuristic: detection of monospace font by checking all non-zero widths
Making src/core/evaluator.js adhere to the style guide
2014-03-23 03:15:51 +09:00
var isMonospace = true;
var firstWidth = defaultWidth;
Adds heuristic for monospace font detection
2012-09-17 04:38:30 +09:00
for (var glyph in glyphsWidths) {
var glyphWidth = glyphsWidths[glyph];
Making src/core/evaluator.js adhere to the style guide
2014-03-23 03:15:51 +09:00
if (!glyphWidth) {
Adds heuristic for monospace font detection
2012-09-17 04:38:30 +09:00
continue;
Making src/core/evaluator.js adhere to the style guide
2014-03-23 03:15:51 +09:00
}
Adds heuristic for monospace font detection
2012-09-17 04:38:30 +09:00
if (!firstWidth) {
firstWidth = glyphWidth;
continue;
}
Add strict equalities in src/core/evaluator.js
2014-08-02 01:25:21 +09:00
if (firstWidth !== glyphWidth) {
Adds heuristic for monospace font detection
2012-09-17 04:38:30 +09:00
isMonospace = false;
break;
}
}
Making src/core/evaluator.js adhere to the style guide
2014-03-23 03:15:51 +09:00
if (isMonospace) {
Adds heuristic for monospace font detection
2012-09-17 04:38:30 +09:00
properties.flags |= FontFlags.FixedPitch;
Making src/core/evaluator.js adhere to the style guide
2014-03-23 03:15:51 +09:00
}
Adds heuristic for monospace font detection
2012-09-17 04:38:30 +09:00
Migration of the 'encoding-1' branch (ref #674)
2011-10-29 10:38:31 +09:00
properties.defaultWidth = defaultWidth;
properties.widths = glyphsWidths;
Implements vertical writing
2013-02-08 21:29:22 +09:00
properties.defaultVMetrics = defaultVMetrics;
properties.vmetrics = glyphsVMetrics;
Migration of the 'encoding-1' branch (ref #674)
2011-10-29 10:38:31 +09:00
},
Default to a built-in font if an invalid non-embedded font is encountered
2013-01-12 04:04:56 +09:00
isSerifFont: function PartialEvaluator_isSerifFont(baseFontName) {
// Simulating descriptor flags attribute
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
var fontNameWoStyle = baseFontName.split("-")[0];
return (
fontNameWoStyle in getSerifFonts() ||
fontNameWoStyle.search(/serif/gi) !== -1
);
Default to a built-in font if an invalid non-embedded font is encountered
2013-01-12 04:04:56 +09:00
},
Refactor class method names. Also move functionality to more logical place in canvas.js and jpx.js.
2012-04-05 05:43:26 +09:00
getBaseFontMetrics: function PartialEvaluator_getBaseFontMetrics(name) {
Making src/core/evaluator.js adhere to the style guide
2014-03-23 03:15:51 +09:00
var defaultWidth = 0;
var widths = [];
var monospace = false;
Lazify stdFontMap, serifFonts, GlyphMapForStandardFonts
2016-01-22 06:52:24 +09:00
var stdFontMap = getStdFontMap();
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
var lookupName = stdFontMap[name] || name;
Lazify Metrics
2016-01-22 07:29:05 +09:00
var Metrics = getMetrics();
Default to a built-in font if an invalid non-embedded font is encountered
2013-01-12 04:04:56 +09:00
if (!(lookupName in Metrics)) {
// Use default fonts for looking up font metrics if the passed
// font is not a base font
if (this.isSerifFont(name)) {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
lookupName = "Times-Roman";
Default to a built-in font if an invalid non-embedded font is encountered
2013-01-12 04:04:56 +09:00
} else {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
lookupName = "Helvetica";
Default to a built-in font if an invalid non-embedded font is encountered
2013-01-12 04:04:56 +09:00
}
}
var glyphWidths = Metrics[lookupName];
Migration of the 'encoding-1' branch (ref #674)
2011-10-29 10:38:31 +09:00
if (isNum(glyphWidths)) {
defaultWidth = glyphWidths;
Adds heuristic for monospace font detection
2012-09-17 04:38:30 +09:00
monospace = true;
Migration of the 'encoding-1' branch (ref #674)
2011-10-29 10:38:31 +09:00
} else {
Lazify Metrics
2016-01-22 07:29:05 +09:00
widths = glyphWidths(); // expand lazy widths array
Splitting files
2011-10-25 08:55:23 +09:00
}
return {
Enable the `object-shorthand` ESLint rule in `src/shared` Please see http://eslint.org/docs/rules/object-shorthand. For the most part, these changes are of the search-and-replace kind, and the previously enabled `no-undef` rule should complement the tests in helping ensure that no stupid errors crept into to the patch.
2017-04-27 19:58:44 +09:00
defaultWidth,
monospace,
widths,
Splitting files
2011-10-25 08:55:23 +09:00
};
},
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
buildCharCodeToWidth: function PartialEvaluator_bulildCharCodeToWidth(
widthsByGlyphName,
properties
) {
Use built in CMaps and unify the glyph mapping.
2014-02-12 03:27:09 +09:00
var widths = Object.create(null);
var differences = properties.differences;
var encoding = properties.defaultEncoding;
for (var charCode = 0; charCode < 256; charCode++) {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
if (
charCode in differences &&
widthsByGlyphName[differences[charCode]]
) {
Use built in CMaps and unify the glyph mapping.
2014-02-12 03:27:09 +09:00
widths[charCode] = widthsByGlyphName[differences[charCode]];
continue;
}
if (charCode in encoding && widthsByGlyphName[encoding[charCode]]) {
widths[charCode] = widthsByGlyphName[encoding[charCode]];
continue;
}
}
return widths;
},
Remove unnecessary `xref` parameters from various method signatures in `PartialEvaluator`, since `this.xref` is already available in the relevant scope For reasons I don't pretend to understand, we're passing around `xref` arguments to a bunch of methods despite `this.xref` being available in `PartialEvaluator`. This patch is a small first small step towards cleaning up the, often unwieldy, signatures of methods in `PartialEvaluator`.
2017-03-26 21:12:53 +09:00
preEvaluateFont: function PartialEvaluator_preEvaluateFont(dict) {
Splitting files
2011-10-25 08:55:23 +09:00
var baseDict = dict;
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
var type = dict.get("Subtype");
Remove most `assert()` calls (issue 8506) This replaces `assert` calls with `throw new FormatError()`/`throw new Error()`. In a few places, throwing an `Error` (which is what `assert` meant) isn't correct since the enclosing function is supposed to return a `Promise`, hence some cases were changed to `Promise.reject(...)` and similarily for `createPromiseCapability` instances.
2017-07-20 21:04:54 +09:00
if (!isName(type)) {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
throw new FormatError("invalid font Subtype");
Remove most `assert()` calls (issue 8506) This replaces `assert` calls with `throw new FormatError()`/`throw new Error()`. In a few places, throwing an `Error` (which is what `assert` meant) isn't correct since the enclosing function is supposed to return a `Promise`, hence some cases were changed to `Promise.reject(...)` and similarily for `createPromiseCapability` instances.
2017-07-20 21:04:54 +09:00
}
Splitting files
2011-10-25 08:55:23 +09:00
var composite = false;
Resolving new lint issues
2014-04-10 02:47:42 +09:00
var uint8array;
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
if (type.name === "Type0") {
Splitting files
2011-10-25 08:55:23 +09:00
// If font is a composite
// - get the descendant font
// - set the type according to the descendant font
// - get the FontDescriptor from the descendant font
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
var df = dict.get("DescendantFonts");
Remove most `assert()` calls (issue 8506) This replaces `assert` calls with `throw new FormatError()`/`throw new Error()`. In a few places, throwing an `Error` (which is what `assert` meant) isn't correct since the enclosing function is supposed to return a `Promise`, hence some cases were changed to `Promise.reject(...)` and similarily for `createPromiseCapability` instances.
2017-07-20 21:04:54 +09:00
if (!df) {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
throw new FormatError("Descendant fonts are not specified");
Remove most `assert()` calls (issue 8506) This replaces `assert` calls with `throw new FormatError()`/`throw new Error()`. In a few places, throwing an `Error` (which is what `assert` meant) isn't correct since the enclosing function is supposed to return a `Promise`, hence some cases were changed to `Promise.reject(...)` and similarily for `createPromiseCapability` instances.
2017-07-20 21:04:54 +09:00
}
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
dict = Array.isArray(df) ? this.xref.fetchIfRef(df[0]) : df;
Splitting files
2011-10-25 08:55:23 +09:00
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
type = dict.get("Subtype");
Remove most `assert()` calls (issue 8506) This replaces `assert` calls with `throw new FormatError()`/`throw new Error()`. In a few places, throwing an `Error` (which is what `assert` meant) isn't correct since the enclosing function is supposed to return a `Promise`, hence some cases were changed to `Promise.reject(...)` and similarily for `createPromiseCapability` instances.
2017-07-20 21:04:54 +09:00
if (!isName(type)) {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
throw new FormatError("invalid font Subtype");
Remove most `assert()` calls (issue 8506) This replaces `assert` calls with `throw new FormatError()`/`throw new Error()`. In a few places, throwing an `Error` (which is what `assert` meant) isn't correct since the enclosing function is supposed to return a `Promise`, hence some cases were changed to `Promise.reject(...)` and similarily for `createPromiseCapability` instances.
2017-07-20 21:04:54 +09:00
}
Splitting files
2011-10-25 08:55:23 +09:00
composite = true;
}
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
var descriptor = dict.get("FontDescriptor");
Treat fonts with the same font descriptor, encoding and unicode map as aliases Different fonts can point to the same font descriptor (see https://github.com/mozilla/pdf.js/issues/4339 for details). With this commit such fonts are treated as aliases if they have also the same encoding and the same toUnicode map. The according info is stored on the font descriptor. This change must also ensure that aliases use always the same font name because translated fonts can get cleared depending on the CLEANUP_TIMEOUT setting.
2014-03-04 02:44:45 +09:00
if (descriptor) {
var hash = new MurmurHash3_64();
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
var encoding = baseDict.getRaw("Encoding");
Treat fonts with the same font descriptor, encoding and unicode map as aliases Different fonts can point to the same font descriptor (see https://github.com/mozilla/pdf.js/issues/4339 for details). With this commit such fonts are treated as aliases if they have also the same encoding and the same toUnicode map. The according info is stored on the font descriptor. This change must also ensure that aliases use always the same font name because translated fonts can get cleared depending on the CLEANUP_TIMEOUT setting.
2014-03-04 02:44:45 +09:00
if (isName(encoding)) {
hash.update(encoding.name);
} else if (isRef(encoding)) {
Slightly refactor the `fontRef` handling in `PartialEvaluator_loadFont` (issue 7403 and issue 7402) Originally, I was just going to change this code to use `Ref_toString` in a couple more places. When I started reading the code, I figured that it wouldn't hurt to clean up a couple of comments. While doing this, I noticed that the logic for the (rare) `isDict(fontRef)` case could do with a few improvements. There should be no functional changes with this patch, but given the added reference checks, we will now avoid bogus `Ref`s when resolving font aliases. In practice, as issue 7403 shows, the current code can break certain PDF files even if it's very rare. Note that the only thing that this patch will change, is the `font.loadedName` in the case where a `fontRef` is a reference *and* the font doesn't have a descriptor. Previously for `fontRef = Ref(4, 0)` we'd get `font.loadedName = 'g_d0_f4_0'`, and with this patch `font.loadedName = g_d0_f4R`, which is actually one character shorted in most cases. (Given that `Ref_toString` contains an optimization for the `gen === 0` case, which is by far the most common `gen` value.) In the already existing fallback case, where the `fontName` is used to when creating the `font.loadedName`, we allow any alphanumeric character. Hence I don't see how (as mentioned above) e.g. `font.loadedName = g_d0_f4R` would be an issue here.
2016-05-23 22:32:04 +09:00
hash.update(encoding.toString());
Handle the Encoding being a dictionary in PartialEvaluator_preEvaluateFont (bug 1157493) *This is a regression from PR 4423.* Fixes https://bugzilla.mozilla.org/show_bug.cgi?id=1157493.
2015-04-25 20:27:10 +09:00
} else if (isDict(encoding)) {
var keys = encoding.getKeys();
for (var i = 0, ii = keys.length; i < ii; i++) {
var entry = encoding.getRaw(keys[i]);
if (isName(entry)) {
hash.update(entry.name);
} else if (isRef(entry)) {
Slightly refactor the `fontRef` handling in `PartialEvaluator_loadFont` (issue 7403 and issue 7402) Originally, I was just going to change this code to use `Ref_toString` in a couple more places. When I started reading the code, I figured that it wouldn't hurt to clean up a couple of comments. While doing this, I noticed that the logic for the (rare) `isDict(fontRef)` case could do with a few improvements. There should be no functional changes with this patch, but given the added reference checks, we will now avoid bogus `Ref`s when resolving font aliases. In practice, as issue 7403 shows, the current code can break certain PDF files even if it's very rare. Note that the only thing that this patch will change, is the `font.loadedName` in the case where a `fontRef` is a reference *and* the font doesn't have a descriptor. Previously for `fontRef = Ref(4, 0)` we'd get `font.loadedName = 'g_d0_f4_0'`, and with this patch `font.loadedName = g_d0_f4R`, which is actually one character shorted in most cases. (Given that `Ref_toString` contains an optimization for the `gen === 0` case, which is by far the most common `gen` value.) In the already existing fallback case, where the `fontName` is used to when creating the `font.loadedName`, we allow any alphanumeric character. Hence I don't see how (as mentioned above) e.g. `font.loadedName = g_d0_f4R` would be an issue here.
2016-05-23 22:32:04 +09:00
hash.update(entry.toString());
Replace the `isArray` helper function with the native `Array.isArray` function *Follow-up to PR 8813.*
2017-09-02 03:27:13 +09:00
} else if (Array.isArray(entry)) {
Improve the handling of `Encoding` dictionary, with `Differences` array, in `PartialEvaluator_preEvaluateFont` I recently happened to look at the code I wrote for PR 5964, which fixed [bug 1157493](https://bugzilla.mozilla.org/show_bug.cgi?id=1157493), and I quickly realized that the solution is way too simplistic. The fact that only using the `length` of a `Differences` array worked seems more like a happy accident for a particular set of font data, but could just as easily be incorrect for other PDF files. Note that in practice, the case where the `Encoding` entry is a regular `Dict` (and not a `Ref` or `Name`) is very rare, hence I don't think that we really need to worry about having to reparse this data. Also, the performance of this code-block is quite a bit better by updating the `hash` with the data from the *entire* `Differences` array, instead of at every loop iteration.
2016-12-28 08:06:54 +09:00
// 'Differences' array (fixes bug1157493.pdf).
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
var diffLength = entry.length,
diffBuf = new Array(diffLength);
Improve the handling of `Encoding` dictionary, with `Differences` array, in `PartialEvaluator_preEvaluateFont` I recently happened to look at the code I wrote for PR 5964, which fixed [bug 1157493](https://bugzilla.mozilla.org/show_bug.cgi?id=1157493), and I quickly realized that the solution is way too simplistic. The fact that only using the `length` of a `Differences` array worked seems more like a happy accident for a particular set of font data, but could just as easily be incorrect for other PDF files. Note that in practice, the case where the `Encoding` entry is a regular `Dict` (and not a `Ref` or `Name`) is very rare, hence I don't think that we really need to worry about having to reparse this data. Also, the performance of this code-block is quite a bit better by updating the `hash` with the data from the *entire* `Differences` array, instead of at every loop iteration.
2016-12-28 08:06:54 +09:00
for (var j = 0; j < diffLength; j++) {
var diffEntry = entry[j];
if (isName(diffEntry)) {
diffBuf[j] = diffEntry.name;
} else if (isNum(diffEntry) || isRef(diffEntry)) {
diffBuf[j] = diffEntry.toString();
}
}
hash.update(diffBuf.join());
Handle the Encoding being a dictionary in PartialEvaluator_preEvaluateFont (bug 1157493) *This is a regression from PR 4423.* Fixes https://bugzilla.mozilla.org/show_bug.cgi?id=1157493.
2015-04-25 20:27:10 +09:00
}
}
Treat fonts with the same font descriptor, encoding and unicode map as aliases Different fonts can point to the same font descriptor (see https://github.com/mozilla/pdf.js/issues/4339 for details). With this commit such fonts are treated as aliases if they have also the same encoding and the same toUnicode map. The according info is stored on the font descriptor. This change must also ensure that aliases use always the same font name because translated fonts can get cleared depending on the CLEANUP_TIMEOUT setting.
2014-03-04 02:44:45 +09:00
}
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
const firstChar = dict.get("FirstChar") || 0;
const lastChar = dict.get("LastChar") || (composite ? 0xffff : 0xff);
Take the `FirstChar`/`LastChar` properties into account when computing the hash in `PartialEvaluator.preEvaluateFont` (issue 10665) Without this some fonts may incorrectly end up with matching `hash`es, thus breaking rendering since we'll not actually try to load/parse some of the fonts.
2019-03-27 08:25:34 +09:00
hash.update(`${firstChar}-${lastChar}`);
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
var toUnicode = dict.get("ToUnicode") || baseDict.get("ToUnicode");
Treat fonts with the same font descriptor, encoding and unicode map as aliases Different fonts can point to the same font descriptor (see https://github.com/mozilla/pdf.js/issues/4339 for details). With this commit such fonts are treated as aliases if they have also the same encoding and the same toUnicode map. The according info is stored on the font descriptor. This change must also ensure that aliases use always the same font name because translated fonts can get cleared depending on the CLEANUP_TIMEOUT setting.
2014-03-04 02:44:45 +09:00
if (isStream(toUnicode)) {
var stream = toUnicode.str || toUnicode;
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
uint8array = stream.buffer
? new Uint8Array(stream.buffer.buffer, 0, stream.bufferLength)
: new Uint8Array(
stream.bytes.buffer,
stream.start,
stream.end - stream.start
);
Treat fonts with the same font descriptor, encoding and unicode map as aliases Different fonts can point to the same font descriptor (see https://github.com/mozilla/pdf.js/issues/4339 for details). With this commit such fonts are treated as aliases if they have also the same encoding and the same toUnicode map. The according info is stored on the font descriptor. This change must also ensure that aliases use always the same font name because translated fonts can get cleared depending on the CLEANUP_TIMEOUT setting.
2014-03-04 02:44:45 +09:00
hash.update(uint8array);
} else if (isName(toUnicode)) {
hash.update(toUnicode.name);
}
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
var widths = dict.get("Widths") || baseDict.get("Widths");
Treat fonts with the same font descriptor, encoding and unicode map as aliases Different fonts can point to the same font descriptor (see https://github.com/mozilla/pdf.js/issues/4339 for details). With this commit such fonts are treated as aliases if they have also the same encoding and the same toUnicode map. The according info is stored on the font descriptor. This change must also ensure that aliases use always the same font name because translated fonts can get cleared depending on the CLEANUP_TIMEOUT setting.
2014-03-04 02:44:45 +09:00
if (widths) {
Resolving new lint issues
2014-04-10 02:47:42 +09:00
uint8array = new Uint8Array(new Uint32Array(widths).buffer);
Treat fonts with the same font descriptor, encoding and unicode map as aliases Different fonts can point to the same font descriptor (see https://github.com/mozilla/pdf.js/issues/4339 for details). With this commit such fonts are treated as aliases if they have also the same encoding and the same toUnicode map. The according info is stored on the font descriptor. This change must also ensure that aliases use always the same font name because translated fonts can get cleared depending on the CLEANUP_TIMEOUT setting.
2014-03-04 02:44:45 +09:00
hash.update(uint8array);
}
}
return {
Enable the `object-shorthand` ESLint rule in `src/shared` Please see http://eslint.org/docs/rules/object-shorthand. For the most part, these changes are of the search-and-replace kind, and the previously enabled `no-undef` rule should complement the tests in helping ensure that no stupid errors crept into to the patch.
2017-04-27 19:58:44 +09:00
descriptor,
dict,
baseDict,
composite,
Telemetry for used stream and font types
2014-06-16 23:52:04 +09:00
type: type.name,
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
hash: hash ? hash.hexdigest() : "",
Treat fonts with the same font descriptor, encoding and unicode map as aliases Different fonts can point to the same font descriptor (see https://github.com/mozilla/pdf.js/issues/4339 for details). With this commit such fonts are treated as aliases if they have also the same encoding and the same toUnicode map. The according info is stored on the font descriptor. This change must also ensure that aliases use always the same font name because translated fonts can get cleared depending on the CLEANUP_TIMEOUT setting.
2014-03-04 02:44:45 +09:00
};
},
Remove unnecessary `xref` parameters from various method signatures in `PartialEvaluator`, since `this.xref` is already available in the relevant scope For reasons I don't pretend to understand, we're passing around `xref` arguments to a bunch of methods despite `this.xref` being available in `PartialEvaluator`. This patch is a small first small step towards cleaning up the, often unwieldy, signatures of methods in `PartialEvaluator`.
2017-03-26 21:12:53 +09:00
translateFont: function PartialEvaluator_translateFont(preEvaluatedFont) {
Treat fonts with the same font descriptor, encoding and unicode map as aliases Different fonts can point to the same font descriptor (see https://github.com/mozilla/pdf.js/issues/4339 for details). With this commit such fonts are treated as aliases if they have also the same encoding and the same toUnicode map. The according info is stored on the font descriptor. This change must also ensure that aliases use always the same font name because translated fonts can get cleared depending on the CLEANUP_TIMEOUT setting.
2014-03-04 02:44:45 +09:00
var baseDict = preEvaluatedFont.baseDict;
var dict = preEvaluatedFont.dict;
var composite = preEvaluatedFont.composite;
var descriptor = preEvaluatedFont.descriptor;
Telemetry for used stream and font types
2014-06-16 23:52:04 +09:00
var type = preEvaluatedFont.type;
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
var maxCharIndex = composite ? 0xffff : 0xff;
Resolving new lint issues
2014-04-10 02:47:42 +09:00
var properties;
Hide .notdef glyphs in non-embedded Type1 fonts and don't ignore Widths Fixes #11403 The PDF uses the non-embedded Type1 font Helvetica. Character codes 194 and 160 (`Â` and `NBSP`) are encoded as `.notdef`. We shouldn't show those glyphs because it seems that Acrobat Reader doesn't draw glyphs that are named `.notdef` in fonts like this. In addition to testing `glyphName === ".notdef"`, we must test also `glyphName === ""` because the name `""` is used in `core/encodings.js` for undefined glyphs in encodings like `WinAnsiEncoding`. The solution above hides the `Â` characters but now the replacement character (space) appears to be too wide. I found out that PDF.js ignores font's `Widths` array if the font has no `FontDescriptor` entry. That happens in #11403, so the default widths of Helvetica were used as specified in `core/metrics.js` and `.nodef` got a width of 333. The correct width is 0 as specified by the `Widths` array in the PDF. Thus we must never ignore `Widths`.
2020-01-22 03:36:41 +09:00
const firstChar = dict.get("FirstChar") || 0;
const lastChar = dict.get("LastChar") || maxCharIndex;
Treat fonts with the same font descriptor, encoding and unicode map as aliases Different fonts can point to the same font descriptor (see https://github.com/mozilla/pdf.js/issues/4339 for details). With this commit such fonts are treated as aliases if they have also the same encoding and the same toUnicode map. The according info is stored on the font descriptor. This change must also ensure that aliases use always the same font name because translated fonts can get cleared depending on the CLEANUP_TIMEOUT setting.
2014-03-04 02:44:45 +09:00
Splitting files
2011-10-25 08:55:23 +09:00
if (!descriptor) {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
if (type === "Type3") {
Splitting files
2011-10-25 08:55:23 +09:00
// FontDescriptor is only required for Type3 fonts when the document
// is a tagged pdf. Create a barbebones one to get by.
Doesn't traverse cyclic references in Dict.getAll; reduces empty-Dict garbage
2014-03-26 23:07:38 +09:00
descriptor = new Dict(null);
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
descriptor.set("FontName", Name.get(type));
Slightly simplify the lookup of data in `Dict.{get, getAsync, has}` Note that `Dict.set` will only be called with values returned through `Parser.getObj`, and thus indirectly via `Lexer.getObj`. Since neither of those methods will ever return `undefined`, we can simply assert that that's the case when inserting data into the `Dict` and thus get rid of `in` checks when doing the data lookups. In this case, since `Dict.set` is fairly hot, the patch utilizes an *inline check* and when necessary a direct call to `unreachable` to not affect performance of `gulp server/test` too much (rather than always just calling `assert`). For very large and complex PDF files this will help performance *slightly*, since `Dict.{get, getAsync, has}` is called *a lot* during parsing in the worker. This patch was tested using the PDF file from issue 2618, i.e. http://bugzilla-attachments.gnome.org/attachment.cgi?id=226471, with the following manifest file: ``` [ { "id": "issue2618", "file": "../web/pdfs/issue2618.pdf", "md5": "", "rounds": 250, "type": "eq" } ] ``` which gave the following results when comparing this patch against the `master` branch: ``` -- Grouped By browser, stat -- browser | stat | Count | Baseline(ms) | Current(ms) | +/- | % | Result(P<.05) ------- | ------------ | ----- | ------------ | ----------- | --- | ----- | ------------- Firefox | Overall | 250 | 2838 | 2820 | -18 | -0.65 | faster Firefox | Page Request | 250 | 1 | 2 | 0 | 11.92 | slower Firefox | Rendering | 250 | 2837 | 2818 | -19 | -0.65 | faster ```
2020-01-31 19:39:48 +09:00
descriptor.set("FontBBox", dict.getArray("FontBBox") || [0, 0, 0, 0]);
Splitting files
2011-10-25 08:55:23 +09:00
} else {
// Before PDF 1.5 if the font was one of the base 14 fonts, having a
// FontDescriptor was not required.
// This case is here for compatibility.
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
var baseFontName = dict.get("BaseFont");
Remove most `assert()` calls (issue 8506) This replaces `assert` calls with `throw new FormatError()`/`throw new Error()`. In a few places, throwing an `Error` (which is what `assert` meant) isn't correct since the enclosing function is supposed to return a `Promise`, hence some cases were changed to `Promise.reject(...)` and similarily for `createPromiseCapability` instances.
2017-07-20 21:04:54 +09:00
if (!isName(baseFontName)) {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
throw new FormatError("Base font is not specified");
Remove most `assert()` calls (issue 8506) This replaces `assert` calls with `throw new FormatError()`/`throw new Error()`. In a few places, throwing an `Error` (which is what `assert` meant) isn't correct since the enclosing function is supposed to return a `Promise`, hence some cases were changed to `Promise.reject(...)` and similarily for `createPromiseCapability` instances.
2017-07-20 21:04:54 +09:00
}
Splitting files
2011-10-25 08:55:23 +09:00
// Using base font name as a font name.
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
baseFontName = baseFontName.name.replace(/[,_]/g, "-");
Migration of the 'encoding-1' branch (ref #674)
2011-10-29 10:38:31 +09:00
var metrics = this.getBaseFontMetrics(baseFontName);
Splitting files
2011-10-25 08:55:23 +09:00
fix serif and symbol attribute detection for standard fonts
2012-01-10 12:15:18 +09:00
// Simulating descriptor flags attribute
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
var fontNameWoStyle = baseFontName.split("-")[0];
Making src/core/evaluator.js adhere to the style guide
2014-03-23 03:15:51 +09:00
var flags =
(this.isSerifFont(fontNameWoStyle) ? FontFlags.Serif : 0) |
Adds heuristic for monospace font detection
2012-09-17 04:38:30 +09:00
(metrics.monospace ? FontFlags.FixedPitch : 0) |
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
(getSymbolsFonts()[fontNameWoStyle]
? FontFlags.Symbolic
: FontFlags.Nonsymbolic);
fix serif and symbol attribute detection for standard fonts
2012-01-10 12:15:18 +09:00
Fixes lint warning W004 in src/core
2014-04-08 06:42:54 +09:00
properties = {
Enable the `object-shorthand` ESLint rule in `src/shared` Please see http://eslint.org/docs/rules/object-shorthand. For the most part, these changes are of the search-and-replace kind, and the previously enabled `no-undef` rule should complement the tests in helping ensure that no stupid errors crept into to the patch.
2017-04-27 19:58:44 +09:00
type,
Fixes fips regression from #4068
2014-01-09 07:33:22 +09:00
name: baseFontName,
Migration of the 'encoding-1' branch (ref #674)
2011-10-29 10:38:31 +09:00
widths: metrics.widths,
defaultWidth: metrics.defaultWidth,
Enable the `object-shorthand` ESLint rule in `src/shared` Please see http://eslint.org/docs/rules/object-shorthand. For the most part, these changes are of the search-and-replace kind, and the previously enabled `no-undef` rule should complement the tests in helping ensure that no stupid errors crept into to the patch.
2017-04-27 19:58:44 +09:00
flags,
Hide .notdef glyphs in non-embedded Type1 fonts and don't ignore Widths Fixes #11403 The PDF uses the non-embedded Type1 font Helvetica. Character codes 194 and 160 (`Â` and `NBSP`) are encoded as `.notdef`. We shouldn't show those glyphs because it seems that Acrobat Reader doesn't draw glyphs that are named `.notdef` in fonts like this. In addition to testing `glyphName === ".notdef"`, we must test also `glyphName === ""` because the name `""` is used in `core/encodings.js` for undefined glyphs in encodings like `WinAnsiEncoding`. The solution above hides the `Â` characters but now the replacement character (space) appears to be too wide. I found out that PDF.js ignores font's `Widths` array if the font has no `FontDescriptor` entry. That happens in #11403, so the default widths of Helvetica were used as specified in `core/metrics.js` and `.nodef` got a width of 333. The correct width is 0 as specified by the `Widths` array in the PDF. Thus we must never ignore `Widths`.
2020-01-22 03:36:41 +09:00
firstChar,
lastChar,
Splitting files
2011-10-25 08:55:23 +09:00
};
Hide .notdef glyphs in non-embedded Type1 fonts and don't ignore Widths Fixes #11403 The PDF uses the non-embedded Type1 font Helvetica. Character codes 194 and 160 (`Â` and `NBSP`) are encoded as `.notdef`. We shouldn't show those glyphs because it seems that Acrobat Reader doesn't draw glyphs that are named `.notdef` in fonts like this. In addition to testing `glyphName === ".notdef"`, we must test also `glyphName === ""` because the name `""` is used in `core/encodings.js` for undefined glyphs in encodings like `WinAnsiEncoding`. The solution above hides the `Â` characters but now the replacement character (space) appears to be too wide. I found out that PDF.js ignores font's `Widths` array if the font has no `FontDescriptor` entry. That happens in #11403, so the default widths of Helvetica were used as specified in `core/metrics.js` and `.nodef` got a width of 333. The correct width is 0 as specified by the `Widths` array in the PDF. Thus we must never ignore `Widths`.
2020-01-22 03:36:41 +09:00
const widths = dict.get("Widths");
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
return this.extractDataStructures(dict, dict, properties).then(
Remove variable shadowing from the JavaScript files in the `src/core/` folder *This is part of a series of patches that will try to split PR 11566 into smaller chunks, to make reviewing more feasible.* Once all the code has been fixed, we'll be able to eventually enable the ESLint no-shadow rule; see https://eslint.org/docs/rules/no-shadow
2020-03-24 01:04:47 +09:00
newProperties => {
Hide .notdef glyphs in non-embedded Type1 fonts and don't ignore Widths Fixes #11403 The PDF uses the non-embedded Type1 font Helvetica. Character codes 194 and 160 (`Â` and `NBSP`) are encoded as `.notdef`. We shouldn't show those glyphs because it seems that Acrobat Reader doesn't draw glyphs that are named `.notdef` in fonts like this. In addition to testing `glyphName === ".notdef"`, we must test also `glyphName === ""` because the name `""` is used in `core/encodings.js` for undefined glyphs in encodings like `WinAnsiEncoding`. The solution above hides the `Â` characters but now the replacement character (space) appears to be too wide. I found out that PDF.js ignores font's `Widths` array if the font has no `FontDescriptor` entry. That happens in #11403, so the default widths of Helvetica were used as specified in `core/metrics.js` and `.nodef` got a width of 333. The correct width is 0 as specified by the `Widths` array in the PDF. Thus we must never ignore `Widths`.
2020-01-22 03:36:41 +09:00
if (widths) {
const glyphWidths = [];
let j = firstChar;
for (let i = 0, ii = widths.length; i < ii; i++) {
glyphWidths[j++] = this.xref.fetchIfRef(widths[i]);
}
Remove variable shadowing from the JavaScript files in the `src/core/` folder *This is part of a series of patches that will try to split PR 11566 into smaller chunks, to make reviewing more feasible.* Once all the code has been fixed, we'll be able to eventually enable the ESLint no-shadow rule; see https://eslint.org/docs/rules/no-shadow
2020-03-24 01:04:47 +09:00
newProperties.widths = glyphWidths;
Hide .notdef glyphs in non-embedded Type1 fonts and don't ignore Widths Fixes #11403 The PDF uses the non-embedded Type1 font Helvetica. Character codes 194 and 160 (`Â` and `NBSP`) are encoded as `.notdef`. We shouldn't show those glyphs because it seems that Acrobat Reader doesn't draw glyphs that are named `.notdef` in fonts like this. In addition to testing `glyphName === ".notdef"`, we must test also `glyphName === ""` because the name `""` is used in `core/encodings.js` for undefined glyphs in encodings like `WinAnsiEncoding`. The solution above hides the `Â` characters but now the replacement character (space) appears to be too wide. I found out that PDF.js ignores font's `Widths` array if the font has no `FontDescriptor` entry. That happens in #11403, so the default widths of Helvetica were used as specified in `core/metrics.js` and `.nodef` got a width of 333. The correct width is 0 as specified by the `Widths` array in the PDF. Thus we must never ignore `Widths`.
2020-01-22 03:36:41 +09:00
} else {
Remove variable shadowing from the JavaScript files in the `src/core/` folder *This is part of a series of patches that will try to split PR 11566 into smaller chunks, to make reviewing more feasible.* Once all the code has been fixed, we'll be able to eventually enable the ESLint no-shadow rule; see https://eslint.org/docs/rules/no-shadow
2020-03-24 01:04:47 +09:00
newProperties.widths = this.buildCharCodeToWidth(
Hide .notdef glyphs in non-embedded Type1 fonts and don't ignore Widths Fixes #11403 The PDF uses the non-embedded Type1 font Helvetica. Character codes 194 and 160 (`Â` and `NBSP`) are encoded as `.notdef`. We shouldn't show those glyphs because it seems that Acrobat Reader doesn't draw glyphs that are named `.notdef` in fonts like this. In addition to testing `glyphName === ".notdef"`, we must test also `glyphName === ""` because the name `""` is used in `core/encodings.js` for undefined glyphs in encodings like `WinAnsiEncoding`. The solution above hides the `Â` characters but now the replacement character (space) appears to be too wide. I found out that PDF.js ignores font's `Widths` array if the font has no `FontDescriptor` entry. That happens in #11403, so the default widths of Helvetica were used as specified in `core/metrics.js` and `.nodef` got a width of 333. The correct width is 0 as specified by the `Widths` array in the PDF. Thus we must never ignore `Widths`.
2020-01-22 03:36:41 +09:00
metrics.widths,
Remove variable shadowing from the JavaScript files in the `src/core/` folder *This is part of a series of patches that will try to split PR 11566 into smaller chunks, to make reviewing more feasible.* Once all the code has been fixed, we'll be able to eventually enable the ESLint no-shadow rule; see https://eslint.org/docs/rules/no-shadow
2020-03-24 01:04:47 +09:00
newProperties
Hide .notdef glyphs in non-embedded Type1 fonts and don't ignore Widths Fixes #11403 The PDF uses the non-embedded Type1 font Helvetica. Character codes 194 and 160 (`Â` and `NBSP`) are encoded as `.notdef`. We shouldn't show those glyphs because it seems that Acrobat Reader doesn't draw glyphs that are named `.notdef` in fonts like this. In addition to testing `glyphName === ".notdef"`, we must test also `glyphName === ""` because the name `""` is used in `core/encodings.js` for undefined glyphs in encodings like `WinAnsiEncoding`. The solution above hides the `Â` characters but now the replacement character (space) appears to be too wide. I found out that PDF.js ignores font's `Widths` array if the font has no `FontDescriptor` entry. That happens in #11403, so the default widths of Helvetica were used as specified in `core/metrics.js` and `.nodef` got a width of 333. The correct width is 0 as specified by the `Widths` array in the PDF. Thus we must never ignore `Widths`.
2020-01-22 03:36:41 +09:00
);
}
Remove variable shadowing from the JavaScript files in the `src/core/` folder *This is part of a series of patches that will try to split PR 11566 into smaller chunks, to make reviewing more feasible.* Once all the code has been fixed, we'll be able to eventually enable the ESLint no-shadow rule; see https://eslint.org/docs/rules/no-shadow
2020-03-24 01:04:47 +09:00
return new Font(baseFontName, null, newProperties);
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
}
);
Splitting files
2011-10-25 08:55:23 +09:00
}
}
// According to the spec if 'FontDescriptor' is declared, 'FirstChar',
Fix worker message, better error handling
2012-01-20 04:19:19 +09:00
// 'LastChar' and 'Widths' should exist too, but some PDF encoders seem
trivial spelling fixes
2016-07-17 21:33:41 +09:00
// to ignore this rule when a variant of a standard font is used.
Splitting files
2011-10-25 08:55:23 +09:00
// TODO Fill the width array depending on which of the base font this is
// a variant.
Handle missing 'FontName' entry in FontDescriptor object
2013-01-12 10:10:09 +09:00
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
var fontName = descriptor.get("FontName");
var baseFont = dict.get("BaseFont");
Making src/core/evaluator.js adhere to the style guide
2014-03-23 03:15:51 +09:00
// Some bad PDFs have a string as the font name.
Handle missing 'FontName' entry in FontDescriptor object
2013-01-12 10:10:09 +09:00
if (isString(fontName)) {
Use a cache to minimize the number of Name objects.
2014-02-28 13:41:03 +09:00
fontName = Name.get(fontName);
Handle missing 'FontName' entry in FontDescriptor object
2013-01-12 10:10:09 +09:00
}
if (isString(baseFont)) {
Use a cache to minimize the number of Name objects.
2014-02-28 13:41:03 +09:00
baseFont = Name.get(baseFont);
Handle missing 'FontName' entry in FontDescriptor object
2013-01-12 10:10:09 +09:00
}
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
if (type !== "Type3") {
Skip FontName vs. BaseFont check for Type 3 fonts Type 3 font dict does not have a BaseFont entry (see PDF Reference 9.6.5 Table 112). This check is actually causing false positives: http://math.berkeley.edu/~daisuke/Bonn2013.pdf http://math.berkeley.edu/~daisuke/BVSOL.pdf http://www.ieice-hbkb.org/files/06/06gun_02hen_04.pdf http://www.asahi-net.or.jp/~td6i-st/fuku-cathedral/new/gat.pdf
2013-03-03 21:30:08 +09:00
var fontNameStr = fontName && fontName.name;
var baseFontStr = baseFont && baseFont.name;
if (fontNameStr !== baseFontStr) {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
info(
`The FontDescriptor\'s FontName is "${fontNameStr}" but ` +
`should be the same as the Font\'s BaseFont "${baseFontStr}".`
);
Workaround for cases where FontName in the FontDescriptor differs from BaseFont in the Font (bug 847420)
2014-04-09 05:49:51 +09:00
// Workaround for cases where e.g. fontNameStr = 'Arial' and
// baseFontStr = 'Arial,Bold' (needed when no font file is embedded).
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
if (
fontNameStr &&
baseFontStr &&
baseFontStr.startsWith(fontNameStr)
) {
Workaround for cases where FontName in the FontDescriptor differs from BaseFont in the Font (bug 847420)
2014-04-09 05:49:51 +09:00
fontName = baseFont;
}
Skip FontName vs. BaseFont check for Type 3 fonts Type 3 font dict does not have a BaseFont entry (see PDF Reference 9.6.5 Table 112). This check is actually causing false positives: http://math.berkeley.edu/~daisuke/Bonn2013.pdf http://math.berkeley.edu/~daisuke/BVSOL.pdf http://www.ieice-hbkb.org/files/06/06gun_02hen_04.pdf http://www.asahi-net.or.jp/~td6i-st/fuku-cathedral/new/gat.pdf
2013-03-03 21:30:08 +09:00
}
Handle missing 'FontName' entry in FontDescriptor object
2013-01-12 10:10:09 +09:00
}
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
fontName = fontName || baseFont;
Handle missing 'FontName' entry in FontDescriptor object
2013-01-12 10:10:09 +09:00
Remove most `assert()` calls (issue 8506) This replaces `assert` calls with `throw new FormatError()`/`throw new Error()`. In a few places, throwing an `Error` (which is what `assert` meant) isn't correct since the enclosing function is supposed to return a `Promise`, hence some cases were changed to `Promise.reject(...)` and similarily for `createPromiseCapability` instances.
2017-07-20 21:04:54 +09:00
if (!isName(fontName)) {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
throw new FormatError("invalid font name");
Remove most `assert()` calls (issue 8506) This replaces `assert` calls with `throw new FormatError()`/`throw new Error()`. In a few places, throwing an `Error` (which is what `assert` meant) isn't correct since the enclosing function is supposed to return a `Promise`, hence some cases were changed to `Promise.reject(...)` and similarily for `createPromiseCapability` instances.
2017-07-20 21:04:54 +09:00
}
Splitting files
2011-10-25 08:55:23 +09:00
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
var fontFile = descriptor.get("FontFile", "FontFile2", "FontFile3");
Splitting files
2011-10-25 08:55:23 +09:00
if (fontFile) {
if (fontFile.dict) {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
var subtype = fontFile.dict.get("Subtype");
Making src/core/evaluator.js adhere to the style guide
2014-03-23 03:15:51 +09:00
if (subtype) {
Splitting files
2011-10-25 08:55:23 +09:00
subtype = subtype.name;
Making src/core/evaluator.js adhere to the style guide
2014-03-23 03:15:51 +09:00
}
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
var length1 = fontFile.dict.get("Length1");
var length2 = fontFile.dict.get("Length2");
var length3 = fontFile.dict.get("Length3");
Splitting files
2011-10-25 08:55:23 +09:00
}
}
Fixes lint warning W004 in src/core
2014-04-08 06:42:54 +09:00
properties = {
Enable the `object-shorthand` ESLint rule in `src/shared` Please see http://eslint.org/docs/rules/object-shorthand. For the most part, these changes are of the search-and-replace kind, and the previously enabled `no-undef` rule should complement the tests in helping ensure that no stupid errors crept into to the patch.
2017-04-27 19:58:44 +09:00
type,
Fixes fips regression from #4068
2014-01-09 07:33:22 +09:00
name: fontName.name,
Enable the `object-shorthand` ESLint rule in `src/shared` Please see http://eslint.org/docs/rules/object-shorthand. For the most part, these changes are of the search-and-replace kind, and the previously enabled `no-undef` rule should complement the tests in helping ensure that no stupid errors crept into to the patch.
2017-04-27 19:58:44 +09:00
subtype,
Splitting files
2011-10-25 08:55:23 +09:00
file: fontFile,
Enable the `object-shorthand` ESLint rule in `src/shared` Please see http://eslint.org/docs/rules/object-shorthand. For the most part, these changes are of the search-and-replace kind, and the previously enabled `no-undef` rule should complement the tests in helping ensure that no stupid errors crept into to the patch.
2017-04-27 19:58:44 +09:00
length1,
length2,
length3,
Refactor text extraction / font loading logic
2012-09-14 00:09:46 +09:00
loadedName: baseDict.loadedName,
Enable the `object-shorthand` ESLint rule in `src/shared` Please see http://eslint.org/docs/rules/object-shorthand. For the most part, these changes are of the search-and-replace kind, and the previously enabled `no-undef` rule should complement the tests in helping ensure that no stupid errors crept into to the patch.
2017-04-27 19:58:44 +09:00
composite,
Splitting files
2011-10-25 08:55:23 +09:00
fixedPitch: false,
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
fontMatrix: dict.getArray("FontMatrix") || FONT_IDENTITY_MATRIX,
Splitting files
2011-10-25 08:55:23 +09:00
firstChar: firstChar || 0,
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
lastChar: lastChar || maxCharIndex,
bbox: descriptor.getArray("FontBBox"),
ascent: descriptor.get("Ascent"),
descent: descriptor.get("Descent"),
xHeight: descriptor.get("XHeight"),
capHeight: descriptor.get("CapHeight"),
flags: descriptor.get("Flags"),
italicAngle: descriptor.get("ItalicAngle"),
Replace the `coded` property with `isType3Font` when building the font `properties` object in `PartialEvaluator.translateFont` This appears to simply have been forgotten in the re-factoring in PR 4815, where the `coded` property was renamed to the *much* more descriptive `isType3Font` property.
2017-08-08 21:03:02 +09:00
isType3Font: false,
Splitting files
2011-10-25 08:55:23 +09:00
};
Implements vertical writing
2013-02-08 21:29:22 +09:00
Refactors CMapFactory.create to make it async
2016-02-29 01:20:29 +09:00
var cMapPromise;
Implements vertical writing
2013-02-08 21:29:22 +09:00
if (composite) {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
var cidEncoding = baseDict.get("Encoding");
Implements vertical writing
2013-02-08 21:29:22 +09:00
if (isName(cidEncoding)) {
properties.cidEncoding = cidEncoding.name;
}
[api-minor] Refactor fetching of built-in CMaps to utilize a factory on the `display` side instead, to allow users of the API to provide a custom CMap loading factory (e.g. for use with Node.js) Currently the built-in CMap files are loaded in `src/core/cmap.js` using `XMLHttpRequest` directly. For some environments that might be a problem, hence this patch refactors that to instead use a factory to load built-in CMaps on the main thread and message the data to the worker thread. This is inspired by other recent work, e.g. the addition of the `CanvasFactory`, and to a large extent on the IRC discussion starting at http://logs.glob.uno/?c=mozilla%23pdfjs&s=12+Oct+2016&e=12+Oct+2016#c53010.
2017-02-12 23:54:41 +09:00
cMapPromise = CMapFactory.create({
encoding: cidEncoding,
fetchBuiltInCMap: this.fetchBuiltInCMap,
useCMap: null,
Update Prettier to version 2.0 Please note that these changes were done automatically, using `gulp lint --fix`. Given that the major version number was increased, there's a fair number of (primarily whitespace) changes; please see https://prettier.io/blog/2020/03/21/2.0.0.html In order to reduce the size of these changes somewhat, this patch maintains the old "arrowParens" style for now (once mozilla-central updates Prettier we can simply choose the same formatting, assuming it will differ here).
2020-04-14 19:28:14 +09:00
}).then(function (cMap) {
Refactors CMapFactory.create to make it async
2016-02-29 01:20:29 +09:00
properties.cMap = cMap;
properties.vertical = properties.cMap.vertical;
});
} else {
cMapPromise = Promise.resolve(undefined);
Implements vertical writing
2013-02-08 21:29:22 +09:00
}
Splitting files
2011-10-25 08:55:23 +09:00
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
return cMapPromise
.then(() => {
return this.extractDataStructures(dict, baseDict, properties);
})
Remove variable shadowing from the JavaScript files in the `src/core/` folder *This is part of a series of patches that will try to split PR 11566 into smaller chunks, to make reviewing more feasible.* Once all the code has been fixed, we'll be able to eventually enable the ESLint no-shadow rule; see https://eslint.org/docs/rules/no-shadow
2020-03-24 01:04:47 +09:00
.then(newProperties => {
this.extractWidths(dict, descriptor, newProperties);
Refactors CMapFactory.create to make it async
2016-02-29 01:20:29 +09:00
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
if (type === "Type3") {
Remove variable shadowing from the JavaScript files in the `src/core/` folder *This is part of a series of patches that will try to split PR 11566 into smaller chunks, to make reviewing more feasible.* Once all the code has been fixed, we'll be able to eventually enable the ESLint no-shadow rule; see https://eslint.org/docs/rules/no-shadow
2020-03-24 01:04:47 +09:00
newProperties.isType3Font = true;
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
}
Remove variable shadowing from the JavaScript files in the `src/core/` folder *This is part of a series of patches that will try to split PR 11566 into smaller chunks, to make reviewing more feasible.* Once all the code has been fixed, we'll be able to eventually enable the ESLint no-shadow rule; see https://eslint.org/docs/rules/no-shadow
2020-03-24 01:04:47 +09:00
return new Font(fontName.name, fontFile, newProperties);
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
});
Fix inconsistent spacing and trailing commas in objects in `src/core/` files, so we can enable the `comma-dangle` and `object-curly-spacing` ESLint rules later on *Unfortunately this patch is fairly big, even though it only covers the `src/core` folder, but splitting it even further seemed difficult.* http://eslint.org/docs/rules/comma-dangle http://eslint.org/docs/rules/object-curly-spacing Given that we currently have quite inconsistent object formatting, fixing this in *one* big patch probably wouldn't be feasible (since I cannot imagine anyone wanting to review that); hence I've opted to try and do this piecewise instead. Please note: This patch was created automatically, using the ESLint --fix command line option. In a couple of places this caused lines to become too long, and I've fixed those manually; please refer to the interdiff below for the only hand-edits in this patch. ```diff diff --git a/src/core/evaluator.js b/src/core/evaluator.js index abab9027..dcd3594b 100644 --- a/src/core/evaluator.js +++ b/src/core/evaluator.js @@ -2785,7 +2785,8 @@ var EvaluatorPreprocessor = (function EvaluatorPreprocessorClosure() { t['Tz'] = { id: OPS.setHScale, numArgs: 1, variableArgs: false, }; t['TL'] = { id: OPS.setLeading, numArgs: 1, variableArgs: false, }; t['Tf'] = { id: OPS.setFont, numArgs: 2, variableArgs: false, }; - t['Tr'] = { id: OPS.setTextRenderingMode, numArgs: 1, variableArgs: false, }; + t['Tr'] = { id: OPS.setTextRenderingMode, numArgs: 1, + variableArgs: false, }; t['Ts'] = { id: OPS.setTextRise, numArgs: 1, variableArgs: false, }; t['Td'] = { id: OPS.moveText, numArgs: 2, variableArgs: false, }; t['TD'] = { id: OPS.setLeadingMoveText, numArgs: 2, variableArgs: false, }; diff --git a/src/core/jbig2.js b/src/core/jbig2.js index 5a17d482..71671541 100644 --- a/src/core/jbig2.js +++ b/src/core/jbig2.js @@ -123,19 +123,22 @@ var Jbig2Image = (function Jbig2ImageClosure() { { x: -1, y: -1, }, { x: 0, y: -1, }, { x: 1, y: -1, }, { x: -2, y: 0, }, { x: -1, y: 0, }], [{ x: -3, y: -1, }, { x: -2, y: -1, }, { x: -1, y: -1, }, { x: 0, y: -1, }, - { x: 1, y: -1, }, { x: -4, y: 0, }, { x: -3, y: 0, }, { x: -2, y: 0, }, { x: -1, y: 0, }] + { x: 1, y: -1, }, { x: -4, y: 0, }, { x: -3, y: 0, }, { x: -2, y: 0, }, + { x: -1, y: 0, }] ]; var RefinementTemplates = [ { coding: [{ x: 0, y: -1, }, { x: 1, y: -1, }, { x: -1, y: 0, }], - reference: [{ x: 0, y: -1, }, { x: 1, y: -1, }, { x: -1, y: 0, }, { x: 0, y: 0, }, - { x: 1, y: 0, }, { x: -1, y: 1, }, { x: 0, y: 1, }, { x: 1, y: 1, }], + reference: [{ x: 0, y: -1, }, { x: 1, y: -1, }, { x: -1, y: 0, }, + { x: 0, y: 0, }, { x: 1, y: 0, }, { x: -1, y: 1, }, + { x: 0, y: 1, }, { x: 1, y: 1, }], }, { - coding: [{ x: -1, y: -1, }, { x: 0, y: -1, }, { x: 1, y: -1, }, { x: -1, y: 0, }], - reference: [{ x: 0, y: -1, }, { x: -1, y: 0, }, { x: 0, y: 0, }, { x: 1, y: 0, }, - { x: 0, y: 1, }, { x: 1, y: 1, }], + coding: [{ x: -1, y: -1, }, { x: 0, y: -1, }, { x: 1, y: -1, }, + { x: -1, y: 0, }], + reference: [{ x: 0, y: -1, }, { x: -1, y: 0, }, { x: 0, y: 0, }, + { x: 1, y: 0, }, { x: 0, y: 1, }, { x: 1, y: 1, }], } ]; ```
2017-06-02 18:16:24 +09:00
},
Splitting files
2011-10-25 08:55:23 +09:00
};
Update Prettier to version 2.0 Please note that these changes were done automatically, using `gulp lint --fix`. Given that the major version number was increased, there's a fair number of (primarily whitespace) changes; please see https://prettier.io/blog/2020/03/21/2.0.0.html In order to reduce the size of these changes somewhat, this patch maintains the old "arrowParens" style for now (once mozilla-central updates Prettier we can simply choose the same formatting, assuming it will differ here).
2020-04-14 19:28:14 +09:00
PartialEvaluator.buildFontPaths = function (font, glyphs, handler) {
Fallback to the built-in font renderer when font loading fails After PR 9340 all glyphs are now re-mapped to a Private Use Area (PUA) which means that if a font fails to load, for whatever reason[1], all glyphs in the font will now render as Unicode glyph outlines. This obviously doesn't look good, to say the least, and might be seen as a "regression" since previously many glyphs were left in their original positions which provided a slightly better fallback[2]. Hence this patch, which implements a *general* fallback to the PDF.js built-in font renderer for fonts that fail to load (i.e. are rejected by the sanitizer). One caveat here is that this only works for the Font Loading API, since it's easy to handle errors in that case[3]. The solution implemented in this patch does *not* in any way delay the loading of valid fonts, which was the problem with my previous attempt at a solution, and will only require a bit of extra work/waiting for those fonts that actually fail to load. *Please note:* This patch doesn't fix any of the underlying PDF.js font conversion bugs that's responsible for creating corrupt font files, however it does *improve* rendering in a number of cases; refer to this possibly incomplete list: [Bug 1524888](https://bugzilla.mozilla.org/show_bug.cgi?id=1524888) Issue 10175 Issue 10232 --- [1] Usually because the PDF.js font conversion code wasn't able to parse the font file correctly. [2] Glyphs fell back to some default font, which while not accurate was more useful than the current state. [3] Furthermore I'm not sure how to implement this generally, assuming that's even possible, and don't really have time/interest to look into it either.
2019-02-11 08:47:56 +09:00
function buildPath(fontChar) {
if (font.renderer.hasBuiltPath(fontChar)) {
return;
}
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
handler.send("commonobj", [
Fallback to the built-in font renderer when font loading fails After PR 9340 all glyphs are now re-mapped to a Private Use Area (PUA) which means that if a font fails to load, for whatever reason[1], all glyphs in the font will now render as Unicode glyph outlines. This obviously doesn't look good, to say the least, and might be seen as a "regression" since previously many glyphs were left in their original positions which provided a slightly better fallback[2]. Hence this patch, which implements a *general* fallback to the PDF.js built-in font renderer for fonts that fail to load (i.e. are rejected by the sanitizer). One caveat here is that this only works for the Font Loading API, since it's easy to handle errors in that case[3]. The solution implemented in this patch does *not* in any way delay the loading of valid fonts, which was the problem with my previous attempt at a solution, and will only require a bit of extra work/waiting for those fonts that actually fail to load. *Please note:* This patch doesn't fix any of the underlying PDF.js font conversion bugs that's responsible for creating corrupt font files, however it does *improve* rendering in a number of cases; refer to this possibly incomplete list: [Bug 1524888](https://bugzilla.mozilla.org/show_bug.cgi?id=1524888) Issue 10175 Issue 10232 --- [1] Usually because the PDF.js font conversion code wasn't able to parse the font file correctly. [2] Glyphs fell back to some default font, which while not accurate was more useful than the current state. [3] Furthermore I'm not sure how to implement this generally, assuming that's even possible, and don't really have time/interest to look into it either.
2019-02-11 08:47:56 +09:00
`${font.loadedName}_path_${fontChar}`,
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
"FontPath",
Fallback to the built-in font renderer when font loading fails After PR 9340 all glyphs are now re-mapped to a Private Use Area (PUA) which means that if a font fails to load, for whatever reason[1], all glyphs in the font will now render as Unicode glyph outlines. This obviously doesn't look good, to say the least, and might be seen as a "regression" since previously many glyphs were left in their original positions which provided a slightly better fallback[2]. Hence this patch, which implements a *general* fallback to the PDF.js built-in font renderer for fonts that fail to load (i.e. are rejected by the sanitizer). One caveat here is that this only works for the Font Loading API, since it's easy to handle errors in that case[3]. The solution implemented in this patch does *not* in any way delay the loading of valid fonts, which was the problem with my previous attempt at a solution, and will only require a bit of extra work/waiting for those fonts that actually fail to load. *Please note:* This patch doesn't fix any of the underlying PDF.js font conversion bugs that's responsible for creating corrupt font files, however it does *improve* rendering in a number of cases; refer to this possibly incomplete list: [Bug 1524888](https://bugzilla.mozilla.org/show_bug.cgi?id=1524888) Issue 10175 Issue 10232 --- [1] Usually because the PDF.js font conversion code wasn't able to parse the font file correctly. [2] Glyphs fell back to some default font, which while not accurate was more useful than the current state. [3] Furthermore I'm not sure how to implement this generally, assuming that's even possible, and don't really have time/interest to look into it either.
2019-02-11 08:47:56 +09:00
font.renderer.getPathJs(fontChar),
]);
}
for (const glyph of glyphs) {
buildPath(glyph.fontChar);
// If the glyph has an accent we need to build a path for its
// fontChar too, otherwise CanvasGraphics_paintChar will fail.
const accent = glyph.accent;
if (accent && accent.fontChar) {
buildPath(accent.fontChar);
}
}
};
Cache the fallback font dictionary on the `PartialEvaluator` (PR 11218 follow-up) This way we'll benefit from the existing font caching, and can thus avoid re-creating a fallback font over and over again during parsing. (Thece changes necessitated the previous patch, since otherwise breakage could occur e.g. with fake workers.)
2020-01-16 23:08:25 +09:00
// TODO: Change this to a `static` getter, using shadowing, once
// `PartialEvaluator` is converted to a proper class.
Update Prettier to version 2.0 Please note that these changes were done automatically, using `gulp lint --fix`. Given that the major version number was increased, there's a fair number of (primarily whitespace) changes; please see https://prettier.io/blog/2020/03/21/2.0.0.html In order to reduce the size of these changes somewhat, this patch maintains the old "arrowParens" style for now (once mozilla-central updates Prettier we can simply choose the same formatting, assuming it will differ here).
2020-04-14 19:28:14 +09:00
PartialEvaluator.getFallbackFontDict = function () {
Cache the fallback font dictionary on the `PartialEvaluator` (PR 11218 follow-up) This way we'll benefit from the existing font caching, and can thus avoid re-creating a fallback font over and over again during parsing. (Thece changes necessitated the previous patch, since otherwise breakage could occur e.g. with fake workers.)
2020-01-16 23:08:25 +09:00
if (this._fallbackFontDict) {
return this._fallbackFontDict;
}
const dict = new Dict();
dict.set("BaseFont", Name.get("PDFJS-FallbackFont"));
dict.set("Type", Name.get("FallbackType"));
dict.set("Subtype", Name.get("FallbackType"));
dict.set("Encoding", Name.get("WinAnsiEncoding"));
return (this._fallbackFontDict = dict);
};
Name all constructors.
2011-12-09 07:18:43 +09:00
return PartialEvaluator;
Splitting files
2011-10-25 08:55:23 +09:00
})();
Change the signature of `TranslatedFont`, and convert it to a proper class In preparation for the next patch, this changes the signature of `TranslatedFont` to take an object rather than individual parameters. This also, in my opinion, makes the call-sites easier to read since it essentially provides a small bit of documentation of the arguments. Finally, since it was necessary to touch `TranslatedFont` anyway it seemed like a good idea to also convert it to a proper `class`.
2020-04-03 17:19:02 +09:00
class TranslatedFont {
[api-minor] Change `Font.exportData` to, by default, stop exporting properties which are completely unused on the main-thread and/or in the API (PR 11773 follow-up) For years now, the `Font.exportData` method has (because of its previous implementation) been exporting many properties despite them being completely unused on the main-thread and/or in the API. This is unfortunate, since among those properties there's a number of potentially very large data-structures, containing e.g. Arrays and Objects, which thus have to be first structured cloned and then stored on the main-thread. With the changes in this patch, we'll thus by default save memory for *every* `Font` instance created (there can be a lot in longer documents). The memory savings obviously depends a lot on the actual font data, but some approximate figures are: For non-embedded fonts it can save a couple of kilobytes, for simple embedded fonts a handful of kilobytes, and for composite fonts the size of this auxiliary can even be larger than the actual font program itself. All-in-all, there's no good reason to keep exporting these properties by default when they're unused. However, since we cannot be sure that every property is unused in custom implementations of the PDF.js library, this patch adds a new `getDocument` option (named `fontExtraProperties`) that still allows access to the following properties: - "cMap": An internal data structure, only used with composite fonts and never really intended to be exposed on the main-thread and/or in the API. Note also that the `CMap`/`IdentityCMap` classes are a lot more complex than simple Objects, but only their "internal" properties survive the structured cloning used to send data to the main-thread. Given that CMaps can often be *very* large, not exporting them can also save a fair bit of memory. - "defaultEncoding": An internal property used with simple fonts, and used when building the glyph mapping on the worker-thread. Considering how complex that topic is, and given that not all font types are handled identically, exposing this on the main-thread and/or in the API most likely isn't useful. - "differences": An internal property used with simple fonts, and used when building the glyph mapping on the worker-thread. Considering how complex that topic is, and given that not all font types are handled identically, exposing this on the main-thread and/or in the API most likely isn't useful. - "isSymbolicFont": An internal property, used during font parsing and building of the glyph mapping on the worker-thread. - "seacMap": An internal map, only potentially used with *some* Type1/CFF fonts and never intended to be exposed in the API. The existing `Font.{charToGlyph, charToGlyphs}` functionality already takes this data into account when handling text. - "toFontChar": The glyph map, necessary for mapping characters to glyphs in the font, which is built upon the various encoding information contained in the font dictionary and/or font program. This is not directly used on the main-thread and/or in the API. - "toUnicode": The unicode map, necessary for text-extraction to work correctly, which is built upon the ToUnicode/CMap information contained in the font dictionary, but not directly used on the main-thread and/or in the API. - "vmetrics": An array of width data used with fonts which are composite *and* vertical, but not directly used on the main-thread and/or in the API. - "widths": An array of width data used with most fonts, but not directly used on the main-thread and/or in the API.
2020-04-03 18:51:46 +09:00
constructor({ loadedName, font, dict, extraProperties = false }) {
Refactors loadFont for translateFont be async; fixes type3 dup data
2014-05-20 06:27:54 +09:00
this.loadedName = loadedName;
this.font = font;
this.dict = dict;
[api-minor] Change `Font.exportData` to, by default, stop exporting properties which are completely unused on the main-thread and/or in the API (PR 11773 follow-up) For years now, the `Font.exportData` method has (because of its previous implementation) been exporting many properties despite them being completely unused on the main-thread and/or in the API. This is unfortunate, since among those properties there's a number of potentially very large data-structures, containing e.g. Arrays and Objects, which thus have to be first structured cloned and then stored on the main-thread. With the changes in this patch, we'll thus by default save memory for *every* `Font` instance created (there can be a lot in longer documents). The memory savings obviously depends a lot on the actual font data, but some approximate figures are: For non-embedded fonts it can save a couple of kilobytes, for simple embedded fonts a handful of kilobytes, and for composite fonts the size of this auxiliary can even be larger than the actual font program itself. All-in-all, there's no good reason to keep exporting these properties by default when they're unused. However, since we cannot be sure that every property is unused in custom implementations of the PDF.js library, this patch adds a new `getDocument` option (named `fontExtraProperties`) that still allows access to the following properties: - "cMap": An internal data structure, only used with composite fonts and never really intended to be exposed on the main-thread and/or in the API. Note also that the `CMap`/`IdentityCMap` classes are a lot more complex than simple Objects, but only their "internal" properties survive the structured cloning used to send data to the main-thread. Given that CMaps can often be *very* large, not exporting them can also save a fair bit of memory. - "defaultEncoding": An internal property used with simple fonts, and used when building the glyph mapping on the worker-thread. Considering how complex that topic is, and given that not all font types are handled identically, exposing this on the main-thread and/or in the API most likely isn't useful. - "differences": An internal property used with simple fonts, and used when building the glyph mapping on the worker-thread. Considering how complex that topic is, and given that not all font types are handled identically, exposing this on the main-thread and/or in the API most likely isn't useful. - "isSymbolicFont": An internal property, used during font parsing and building of the glyph mapping on the worker-thread. - "seacMap": An internal map, only potentially used with *some* Type1/CFF fonts and never intended to be exposed in the API. The existing `Font.{charToGlyph, charToGlyphs}` functionality already takes this data into account when handling text. - "toFontChar": The glyph map, necessary for mapping characters to glyphs in the font, which is built upon the various encoding information contained in the font dictionary and/or font program. This is not directly used on the main-thread and/or in the API. - "toUnicode": The unicode map, necessary for text-extraction to work correctly, which is built upon the ToUnicode/CMap information contained in the font dictionary, but not directly used on the main-thread and/or in the API. - "vmetrics": An array of width data used with fonts which are composite *and* vertical, but not directly used on the main-thread and/or in the API. - "widths": An array of width data used with most fonts, but not directly used on the main-thread and/or in the API.
2020-04-03 18:51:46 +09:00
this._extraProperties = extraProperties;
Refactors loadFont for translateFont be async; fixes type3 dup data
2014-05-20 06:27:54 +09:00
this.type3Loaded = null;
this.sent = false;
}
Fallback to the built-in font renderer when font loading fails After PR 9340 all glyphs are now re-mapped to a Private Use Area (PUA) which means that if a font fails to load, for whatever reason[1], all glyphs in the font will now render as Unicode glyph outlines. This obviously doesn't look good, to say the least, and might be seen as a "regression" since previously many glyphs were left in their original positions which provided a slightly better fallback[2]. Hence this patch, which implements a *general* fallback to the PDF.js built-in font renderer for fonts that fail to load (i.e. are rejected by the sanitizer). One caveat here is that this only works for the Font Loading API, since it's easy to handle errors in that case[3]. The solution implemented in this patch does *not* in any way delay the loading of valid fonts, which was the problem with my previous attempt at a solution, and will only require a bit of extra work/waiting for those fonts that actually fail to load. *Please note:* This patch doesn't fix any of the underlying PDF.js font conversion bugs that's responsible for creating corrupt font files, however it does *improve* rendering in a number of cases; refer to this possibly incomplete list: [Bug 1524888](https://bugzilla.mozilla.org/show_bug.cgi?id=1524888) Issue 10175 Issue 10232 --- [1] Usually because the PDF.js font conversion code wasn't able to parse the font file correctly. [2] Glyphs fell back to some default font, which while not accurate was more useful than the current state. [3] Furthermore I'm not sure how to implement this generally, assuming that's even possible, and don't really have time/interest to look into it either.
2019-02-11 08:47:56 +09:00
Change the signature of `TranslatedFont`, and convert it to a proper class In preparation for the next patch, this changes the signature of `TranslatedFont` to take an object rather than individual parameters. This also, in my opinion, makes the call-sites easier to read since it essentially provides a small bit of documentation of the arguments. Finally, since it was necessary to touch `TranslatedFont` anyway it seemed like a good idea to also convert it to a proper `class`.
2020-04-03 17:19:02 +09:00
send(handler) {
if (this.sent) {
return;
}
this.sent = true;
Fallback to the built-in font renderer when font loading fails After PR 9340 all glyphs are now re-mapped to a Private Use Area (PUA) which means that if a font fails to load, for whatever reason[1], all glyphs in the font will now render as Unicode glyph outlines. This obviously doesn't look good, to say the least, and might be seen as a "regression" since previously many glyphs were left in their original positions which provided a slightly better fallback[2]. Hence this patch, which implements a *general* fallback to the PDF.js built-in font renderer for fonts that fail to load (i.e. are rejected by the sanitizer). One caveat here is that this only works for the Font Loading API, since it's easy to handle errors in that case[3]. The solution implemented in this patch does *not* in any way delay the loading of valid fonts, which was the problem with my previous attempt at a solution, and will only require a bit of extra work/waiting for those fonts that actually fail to load. *Please note:* This patch doesn't fix any of the underlying PDF.js font conversion bugs that's responsible for creating corrupt font files, however it does *improve* rendering in a number of cases; refer to this possibly incomplete list: [Bug 1524888](https://bugzilla.mozilla.org/show_bug.cgi?id=1524888) Issue 10175 Issue 10232 --- [1] Usually because the PDF.js font conversion code wasn't able to parse the font file correctly. [2] Glyphs fell back to some default font, which while not accurate was more useful than the current state. [3] Furthermore I'm not sure how to implement this generally, assuming that's even possible, and don't really have time/interest to look into it either.
2019-02-11 08:47:56 +09:00
Change the signature of `TranslatedFont`, and convert it to a proper class In preparation for the next patch, this changes the signature of `TranslatedFont` to take an object rather than individual parameters. This also, in my opinion, makes the call-sites easier to read since it essentially provides a small bit of documentation of the arguments. Finally, since it was necessary to touch `TranslatedFont` anyway it seemed like a good idea to also convert it to a proper `class`.
2020-04-03 17:19:02 +09:00
handler.send("commonobj", [
this.loadedName,
"Font",
[api-minor] Change `Font.exportData` to, by default, stop exporting properties which are completely unused on the main-thread and/or in the API (PR 11773 follow-up) For years now, the `Font.exportData` method has (because of its previous implementation) been exporting many properties despite them being completely unused on the main-thread and/or in the API. This is unfortunate, since among those properties there's a number of potentially very large data-structures, containing e.g. Arrays and Objects, which thus have to be first structured cloned and then stored on the main-thread. With the changes in this patch, we'll thus by default save memory for *every* `Font` instance created (there can be a lot in longer documents). The memory savings obviously depends a lot on the actual font data, but some approximate figures are: For non-embedded fonts it can save a couple of kilobytes, for simple embedded fonts a handful of kilobytes, and for composite fonts the size of this auxiliary can even be larger than the actual font program itself. All-in-all, there's no good reason to keep exporting these properties by default when they're unused. However, since we cannot be sure that every property is unused in custom implementations of the PDF.js library, this patch adds a new `getDocument` option (named `fontExtraProperties`) that still allows access to the following properties: - "cMap": An internal data structure, only used with composite fonts and never really intended to be exposed on the main-thread and/or in the API. Note also that the `CMap`/`IdentityCMap` classes are a lot more complex than simple Objects, but only their "internal" properties survive the structured cloning used to send data to the main-thread. Given that CMaps can often be *very* large, not exporting them can also save a fair bit of memory. - "defaultEncoding": An internal property used with simple fonts, and used when building the glyph mapping on the worker-thread. Considering how complex that topic is, and given that not all font types are handled identically, exposing this on the main-thread and/or in the API most likely isn't useful. - "differences": An internal property used with simple fonts, and used when building the glyph mapping on the worker-thread. Considering how complex that topic is, and given that not all font types are handled identically, exposing this on the main-thread and/or in the API most likely isn't useful. - "isSymbolicFont": An internal property, used during font parsing and building of the glyph mapping on the worker-thread. - "seacMap": An internal map, only potentially used with *some* Type1/CFF fonts and never intended to be exposed in the API. The existing `Font.{charToGlyph, charToGlyphs}` functionality already takes this data into account when handling text. - "toFontChar": The glyph map, necessary for mapping characters to glyphs in the font, which is built upon the various encoding information contained in the font dictionary and/or font program. This is not directly used on the main-thread and/or in the API. - "toUnicode": The unicode map, necessary for text-extraction to work correctly, which is built upon the ToUnicode/CMap information contained in the font dictionary, but not directly used on the main-thread and/or in the API. - "vmetrics": An array of width data used with fonts which are composite *and* vertical, but not directly used on the main-thread and/or in the API. - "widths": An array of width data used with most fonts, but not directly used on the main-thread and/or in the API.
2020-04-03 18:51:46 +09:00
this.font.exportData(this._extraProperties),
Change the signature of `TranslatedFont`, and convert it to a proper class In preparation for the next patch, this changes the signature of `TranslatedFont` to take an object rather than individual parameters. This also, in my opinion, makes the call-sites easier to read since it essentially provides a small bit of documentation of the arguments. Finally, since it was necessary to touch `TranslatedFont` anyway it seemed like a good idea to also convert it to a proper `class`.
2020-04-03 17:19:02 +09:00
]);
}
Fallback to the built-in font renderer when font loading fails After PR 9340 all glyphs are now re-mapped to a Private Use Area (PUA) which means that if a font fails to load, for whatever reason[1], all glyphs in the font will now render as Unicode glyph outlines. This obviously doesn't look good, to say the least, and might be seen as a "regression" since previously many glyphs were left in their original positions which provided a slightly better fallback[2]. Hence this patch, which implements a *general* fallback to the PDF.js built-in font renderer for fonts that fail to load (i.e. are rejected by the sanitizer). One caveat here is that this only works for the Font Loading API, since it's easy to handle errors in that case[3]. The solution implemented in this patch does *not* in any way delay the loading of valid fonts, which was the problem with my previous attempt at a solution, and will only require a bit of extra work/waiting for those fonts that actually fail to load. *Please note:* This patch doesn't fix any of the underlying PDF.js font conversion bugs that's responsible for creating corrupt font files, however it does *improve* rendering in a number of cases; refer to this possibly incomplete list: [Bug 1524888](https://bugzilla.mozilla.org/show_bug.cgi?id=1524888) Issue 10175 Issue 10232 --- [1] Usually because the PDF.js font conversion code wasn't able to parse the font file correctly. [2] Glyphs fell back to some default font, which while not accurate was more useful than the current state. [3] Furthermore I'm not sure how to implement this generally, assuming that's even possible, and don't really have time/interest to look into it either.
2019-02-11 08:47:56 +09:00
Change the signature of `TranslatedFont`, and convert it to a proper class In preparation for the next patch, this changes the signature of `TranslatedFont` to take an object rather than individual parameters. This also, in my opinion, makes the call-sites easier to read since it essentially provides a small bit of documentation of the arguments. Finally, since it was necessary to touch `TranslatedFont` anyway it seemed like a good idea to also convert it to a proper `class`.
2020-04-03 17:19:02 +09:00
fallback(handler) {
if (!this.font.data) {
return;
}
// When font loading failed, fall back to the built-in font renderer.
this.font.disableFontFace = true;
// An arbitrary number of text rendering operators could have been
// encountered between the point in time when the 'Font' message was sent
// to the main-thread, and the point in time when the 'FontFallback'
// message was received on the worker-thread.
// To ensure that all 'FontPath's are available on the main-thread, when
// font loading failed, attempt to resend *all* previously parsed glyphs.
const glyphs = this.font.glyphCacheValues;
PartialEvaluator.buildFontPaths(this.font, glyphs, handler);
}
Refactors loadFont for translateFont be async; fixes type3 dup data
2014-05-20 06:27:54 +09:00
Change the signature of `TranslatedFont`, and convert it to a proper class In preparation for the next patch, this changes the signature of `TranslatedFont` to take an object rather than individual parameters. This also, in my opinion, makes the call-sites easier to read since it essentially provides a small bit of documentation of the arguments. Finally, since it was necessary to touch `TranslatedFont` anyway it seemed like a good idea to also convert it to a proper `class`.
2020-04-03 17:19:02 +09:00
loadType3Data(evaluator, resources, parentOperatorList, task) {
if (!this.font.isType3Font) {
throw new Error("Must be a Type3 font.");
}
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
Change the signature of `TranslatedFont`, and convert it to a proper class In preparation for the next patch, this changes the signature of `TranslatedFont` to take an object rather than individual parameters. This also, in my opinion, makes the call-sites easier to read since it essentially provides a small bit of documentation of the arguments. Finally, since it was necessary to touch `TranslatedFont` anyway it seemed like a good idea to also convert it to a proper `class`.
2020-04-03 17:19:02 +09:00
if (this.type3Loaded) {
Refactors loadFont for translateFont be async; fixes type3 dup data
2014-05-20 06:27:54 +09:00
return this.type3Loaded;
Change the signature of `TranslatedFont`, and convert it to a proper class In preparation for the next patch, this changes the signature of `TranslatedFont` to take an object rather than individual parameters. This also, in my opinion, makes the call-sites easier to read since it essentially provides a small bit of documentation of the arguments. Finally, since it was necessary to touch `TranslatedFont` anyway it seemed like a good idea to also convert it to a proper `class`.
2020-04-03 17:19:02 +09:00
}
// When parsing Type3 glyphs, always ignore them if there are errors.
// Compared to the parsing of e.g. an entire page, it doesn't really
// make sense to only be able to render a Type3 glyph partially.
//
// Also, ensure that any Type3 image resources (which should be very rare
// in practice) are completely decoded on the worker-thread, to simplify
// the rendering code on the main-thread (see issue10717.pdf).
var type3Options = Object.create(evaluator.options);
type3Options.ignoreErrors = false;
var type3Evaluator = evaluator.clone(type3Options);
type3Evaluator.parsingType3Font = true;
var translatedFont = this.font;
var loadCharProcsPromise = Promise.resolve();
var charProcs = this.dict.get("CharProcs");
var fontResources = this.dict.get("Resources") || resources;
var charProcKeys = charProcs.getKeys();
var charProcOperatorList = Object.create(null);
for (var i = 0, n = charProcKeys.length; i < n; ++i) {
const key = charProcKeys[i];
Update Prettier to version 2.0 Please note that these changes were done automatically, using `gulp lint --fix`. Given that the major version number was increased, there's a fair number of (primarily whitespace) changes; please see https://prettier.io/blog/2020/03/21/2.0.0.html In order to reduce the size of these changes somewhat, this patch maintains the old "arrowParens" style for now (once mozilla-central updates Prettier we can simply choose the same formatting, assuming it will differ here).
2020-04-14 19:28:14 +09:00
loadCharProcsPromise = loadCharProcsPromise.then(function () {
Change the signature of `TranslatedFont`, and convert it to a proper class In preparation for the next patch, this changes the signature of `TranslatedFont` to take an object rather than individual parameters. This also, in my opinion, makes the call-sites easier to read since it essentially provides a small bit of documentation of the arguments. Finally, since it was necessary to touch `TranslatedFont` anyway it seemed like a good idea to also convert it to a proper `class`.
2020-04-03 17:19:02 +09:00
var glyphStream = charProcs.get(key);
var operatorList = new OperatorList();
return type3Evaluator
.getOperatorList({
stream: glyphStream,
task,
resources: fontResources,
operatorList,
})
Update Prettier to version 2.0 Please note that these changes were done automatically, using `gulp lint --fix`. Given that the major version number was increased, there's a fair number of (primarily whitespace) changes; please see https://prettier.io/blog/2020/03/21/2.0.0.html In order to reduce the size of these changes somewhat, this patch maintains the old "arrowParens" style for now (once mozilla-central updates Prettier we can simply choose the same formatting, assuming it will differ here).
2020-04-14 19:28:14 +09:00
.then(function () {
Change the signature of `TranslatedFont`, and convert it to a proper class In preparation for the next patch, this changes the signature of `TranslatedFont` to take an object rather than individual parameters. This also, in my opinion, makes the call-sites easier to read since it essentially provides a small bit of documentation of the arguments. Finally, since it was necessary to touch `TranslatedFont` anyway it seemed like a good idea to also convert it to a proper `class`.
2020-04-03 17:19:02 +09:00
charProcOperatorList[key] = operatorList.getIR();
// Add the dependencies to the parent operator list so they are
// resolved before sub operator list is executed synchronously.
parentOperatorList.addDependencies(operatorList.dependencies);
})
Update Prettier to version 2.0 Please note that these changes were done automatically, using `gulp lint --fix`. Given that the major version number was increased, there's a fair number of (primarily whitespace) changes; please see https://prettier.io/blog/2020/03/21/2.0.0.html In order to reduce the size of these changes somewhat, this patch maintains the old "arrowParens" style for now (once mozilla-central updates Prettier we can simply choose the same formatting, assuming it will differ here).
2020-04-14 19:28:14 +09:00
.catch(function (reason) {
Change the signature of `TranslatedFont`, and convert it to a proper class In preparation for the next patch, this changes the signature of `TranslatedFont` to take an object rather than individual parameters. This also, in my opinion, makes the call-sites easier to read since it essentially provides a small bit of documentation of the arguments. Finally, since it was necessary to touch `TranslatedFont` anyway it seemed like a good idea to also convert it to a proper `class`.
2020-04-03 17:19:02 +09:00
warn(`Type3 font resource "${key}" is not available.`);
const dummyOperatorList = new OperatorList();
charProcOperatorList[key] = dummyOperatorList.getIR();
});
});
}
Update Prettier to version 2.0 Please note that these changes were done automatically, using `gulp lint --fix`. Given that the major version number was increased, there's a fair number of (primarily whitespace) changes; please see https://prettier.io/blog/2020/03/21/2.0.0.html In order to reduce the size of these changes somewhat, this patch maintains the old "arrowParens" style for now (once mozilla-central updates Prettier we can simply choose the same formatting, assuming it will differ here).
2020-04-14 19:28:14 +09:00
this.type3Loaded = loadCharProcsPromise.then(function () {
Change the signature of `TranslatedFont`, and convert it to a proper class In preparation for the next patch, this changes the signature of `TranslatedFont` to take an object rather than individual parameters. This also, in my opinion, makes the call-sites easier to read since it essentially provides a small bit of documentation of the arguments. Finally, since it was necessary to touch `TranslatedFont` anyway it seemed like a good idea to also convert it to a proper `class`.
2020-04-03 17:19:02 +09:00
translatedFont.charProcOperatorList = charProcOperatorList;
});
return this.type3Loaded;
}
}
Refactors loadFont for translateFont be async; fixes type3 dup data
2014-05-20 06:27:54 +09:00
Build the text layer geometry on the worker.
2014-04-10 08:44:07 +09:00
var StateManager = (function StateManagerClosure() {
Whitelist closure related cases to address the remaining `no-shadow` linting errors Given the way that "classes" were previously implemented in PDF.js, using regular functions and closures, there's a fair number of false positives when the `no-shadow` ESLint rule was enabled. Note that while *some* of these `eslint-disable` statements can be removed if/when the relevant code is converted to proper `class`es, we'll probably never be able to get rid of all of them given our naming/coding conventions (however I don't really see this being a problem).
2020-03-25 18:15:50 +09:00
// eslint-disable-next-line no-shadow
Build the text layer geometry on the worker.
2014-04-10 08:44:07 +09:00
function StateManager(initialState) {
this.state = initialState;
this.stateStack = [];
}
StateManager.prototype = {
Enable the `object-shorthand` ESLint rule in `src/shared` Please see http://eslint.org/docs/rules/object-shorthand. For the most part, these changes are of the search-and-replace kind, and the previously enabled `no-undef` rule should complement the tests in helping ensure that no stupid errors crept into to the patch.
2017-04-27 19:58:44 +09:00
save() {
Build the text layer geometry on the worker.
2014-04-10 08:44:07 +09:00
var old = this.state;
this.stateStack.push(this.state);
this.state = old.clone();
},
Enable the `object-shorthand` ESLint rule in `src/shared` Please see http://eslint.org/docs/rules/object-shorthand. For the most part, these changes are of the search-and-replace kind, and the previously enabled `no-undef` rule should complement the tests in helping ensure that no stupid errors crept into to the patch.
2017-04-27 19:58:44 +09:00
restore() {
Build the text layer geometry on the worker.
2014-04-10 08:44:07 +09:00
var prev = this.stateStack.pop();
if (prev) {
this.state = prev;
}
},
Enable the `object-shorthand` ESLint rule in `src/shared` Please see http://eslint.org/docs/rules/object-shorthand. For the most part, these changes are of the search-and-replace kind, and the previously enabled `no-undef` rule should complement the tests in helping ensure that no stupid errors crept into to the patch.
2017-04-27 19:58:44 +09:00
transform(args) {
Build the text layer geometry on the worker.
2014-04-10 08:44:07 +09:00
this.state.ctm = Util.transform(this.state.ctm, args);
Fix inconsistent spacing and trailing commas in objects in `src/core/` files, so we can enable the `comma-dangle` and `object-curly-spacing` ESLint rules later on *Unfortunately this patch is fairly big, even though it only covers the `src/core` folder, but splitting it even further seemed difficult.* http://eslint.org/docs/rules/comma-dangle http://eslint.org/docs/rules/object-curly-spacing Given that we currently have quite inconsistent object formatting, fixing this in *one* big patch probably wouldn't be feasible (since I cannot imagine anyone wanting to review that); hence I've opted to try and do this piecewise instead. Please note: This patch was created automatically, using the ESLint --fix command line option. In a couple of places this caused lines to become too long, and I've fixed those manually; please refer to the interdiff below for the only hand-edits in this patch. ```diff diff --git a/src/core/evaluator.js b/src/core/evaluator.js index abab9027..dcd3594b 100644 --- a/src/core/evaluator.js +++ b/src/core/evaluator.js @@ -2785,7 +2785,8 @@ var EvaluatorPreprocessor = (function EvaluatorPreprocessorClosure() { t['Tz'] = { id: OPS.setHScale, numArgs: 1, variableArgs: false, }; t['TL'] = { id: OPS.setLeading, numArgs: 1, variableArgs: false, }; t['Tf'] = { id: OPS.setFont, numArgs: 2, variableArgs: false, }; - t['Tr'] = { id: OPS.setTextRenderingMode, numArgs: 1, variableArgs: false, }; + t['Tr'] = { id: OPS.setTextRenderingMode, numArgs: 1, + variableArgs: false, }; t['Ts'] = { id: OPS.setTextRise, numArgs: 1, variableArgs: false, }; t['Td'] = { id: OPS.moveText, numArgs: 2, variableArgs: false, }; t['TD'] = { id: OPS.setLeadingMoveText, numArgs: 2, variableArgs: false, }; diff --git a/src/core/jbig2.js b/src/core/jbig2.js index 5a17d482..71671541 100644 --- a/src/core/jbig2.js +++ b/src/core/jbig2.js @@ -123,19 +123,22 @@ var Jbig2Image = (function Jbig2ImageClosure() { { x: -1, y: -1, }, { x: 0, y: -1, }, { x: 1, y: -1, }, { x: -2, y: 0, }, { x: -1, y: 0, }], [{ x: -3, y: -1, }, { x: -2, y: -1, }, { x: -1, y: -1, }, { x: 0, y: -1, }, - { x: 1, y: -1, }, { x: -4, y: 0, }, { x: -3, y: 0, }, { x: -2, y: 0, }, { x: -1, y: 0, }] + { x: 1, y: -1, }, { x: -4, y: 0, }, { x: -3, y: 0, }, { x: -2, y: 0, }, + { x: -1, y: 0, }] ]; var RefinementTemplates = [ { coding: [{ x: 0, y: -1, }, { x: 1, y: -1, }, { x: -1, y: 0, }], - reference: [{ x: 0, y: -1, }, { x: 1, y: -1, }, { x: -1, y: 0, }, { x: 0, y: 0, }, - { x: 1, y: 0, }, { x: -1, y: 1, }, { x: 0, y: 1, }, { x: 1, y: 1, }], + reference: [{ x: 0, y: -1, }, { x: 1, y: -1, }, { x: -1, y: 0, }, + { x: 0, y: 0, }, { x: 1, y: 0, }, { x: -1, y: 1, }, + { x: 0, y: 1, }, { x: 1, y: 1, }], }, { - coding: [{ x: -1, y: -1, }, { x: 0, y: -1, }, { x: 1, y: -1, }, { x: -1, y: 0, }], - reference: [{ x: 0, y: -1, }, { x: -1, y: 0, }, { x: 0, y: 0, }, { x: 1, y: 0, }, - { x: 0, y: 1, }, { x: 1, y: 1, }], + coding: [{ x: -1, y: -1, }, { x: 0, y: -1, }, { x: 1, y: -1, }, + { x: -1, y: 0, }], + reference: [{ x: 0, y: -1, }, { x: -1, y: 0, }, { x: 0, y: 0, }, + { x: 1, y: 0, }, { x: 0, y: 1, }, { x: 1, y: 1, }], } ]; ```
2017-06-02 18:16:24 +09:00
},
Build the text layer geometry on the worker.
2014-04-10 08:44:07 +09:00
};
return StateManager;
})();
implementing transform matrix to getTextContent
2013-09-15 02:58:58 +09:00
var TextState = (function TextStateClosure() {
Whitelist closure related cases to address the remaining `no-shadow` linting errors Given the way that "classes" were previously implemented in PDF.js, using regular functions and closures, there's a fair number of false positives when the `no-shadow` ESLint rule was enabled. Note that while *some* of these `eslint-disable` statements can be removed if/when the relevant code is converted to proper `class`es, we'll probably never be able to get rid of all of them given our naming/coding conventions (however I don't really see this being a problem).
2020-03-25 18:15:50 +09:00
// eslint-disable-next-line no-shadow
implementing transform matrix to getTextContent
2013-09-15 02:58:58 +09:00
function TextState() {
Build the text layer geometry on the worker.
2014-04-10 08:44:07 +09:00
this.ctm = new Float32Array(IDENTITY_MATRIX);
Attempt to ignore multiple identical Tf (setFont) commands in `PartialEvaluator_getTextContent` (issue 5808) This patch improves the performance of issue 5808, but I'm not sure if it's enough to call it fixed. On average, this patch reduces the number of textLayer div's by a factor of 3, and it also reduces the time spend in `getTextContent` by a factor of ~2. The PDF file is generated by `Scribus PDF`, which for reasons I cannot understand is placing redundant `Tf` commands before *every* showText command. Note how the PDF file also contains lots of (basically) identical fonts, but with slightly different names, which causes unnecessary font-switching. This causes some unnecessary breaking of textLayer div's, but this issue cannot be easily worked around.
2016-06-01 06:01:35 +09:00
this.fontName = null;
implementing transform matrix to getTextContent
2013-09-15 02:58:58 +09:00
this.fontSize = 0;
Build the text layer geometry on the worker.
2014-04-10 08:44:07 +09:00
this.font = null;
this.fontMatrix = FONT_IDENTITY_MATRIX;
this.textMatrix = IDENTITY_MATRIX.slice();
this.textLineMatrix = IDENTITY_MATRIX.slice();
this.charSpacing = 0;
this.wordSpacing = 0;
implementing transform matrix to getTextContent
2013-09-15 02:58:58 +09:00
this.leading = 0;
this.textHScale = 1;
this.textRise = 0;
}
Making src/core/evaluator.js adhere to the style guide
2014-03-23 03:15:51 +09:00
implementing transform matrix to getTextContent
2013-09-15 02:58:58 +09:00
TextState.prototype = {
setTextMatrix: function TextState_setTextMatrix(a, b, c, d, e, f) {
var m = this.textMatrix;
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
m[0] = a;
m[1] = b;
m[2] = c;
m[3] = d;
m[4] = e;
m[5] = f;
implementing transform matrix to getTextContent
2013-09-15 02:58:58 +09:00
},
Build the text layer geometry on the worker.
2014-04-10 08:44:07 +09:00
setTextLineMatrix: function TextState_setTextMatrix(a, b, c, d, e, f) {
var m = this.textLineMatrix;
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
m[0] = a;
m[1] = b;
m[2] = c;
m[3] = d;
m[4] = e;
m[5] = f;
Build the text layer geometry on the worker.
2014-04-10 08:44:07 +09:00
},
implementing transform matrix to getTextContent
2013-09-15 02:58:58 +09:00
translateTextMatrix: function TextState_translateTextMatrix(x, y) {
var m = this.textMatrix;
m[4] = m[0] * x + m[2] * y + m[4];
m[5] = m[1] * x + m[3] * y + m[5];
},
Build the text layer geometry on the worker.
2014-04-10 08:44:07 +09:00
translateTextLineMatrix: function TextState_translateTextMatrix(x, y) {
var m = this.textLineMatrix;
m[4] = m[0] * x + m[2] * y + m[4];
m[5] = m[1] * x + m[3] * y + m[5];
implementing transform matrix to getTextContent
2013-09-15 02:58:58 +09:00
},
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
calcTextLineMatrixAdvance: function TextState_calcTextLineMatrixAdvance(
a,
b,
c,
d,
e,
f
) {
Attempt to combine text runs positioned with `setTextMatrix`
2016-05-15 05:13:12 +09:00
var font = this.font;
if (!font) {
return null;
}
var m = this.textLineMatrix;
if (!(a === m[0] && b === m[1] && c === m[2] && d === m[3])) {
return null;
}
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
var txDiff = e - m[4],
tyDiff = f - m[5];
Attempt to combine text runs positioned with `setTextMatrix`
2016-05-15 05:13:12 +09:00
if ((font.vertical && txDiff !== 0) || (!font.vertical && tyDiff !== 0)) {
return null;
}
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
var tx,
ty,
denominator = a * d - b * c;
Attempt to combine text runs positioned with `setTextMatrix`
2016-05-15 05:13:12 +09:00
if (font.vertical) {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
tx = (-tyDiff * c) / denominator;
ty = (tyDiff * a) / denominator;
Attempt to combine text runs positioned with `setTextMatrix`
2016-05-15 05:13:12 +09:00
} else {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
tx = (txDiff * d) / denominator;
ty = (-txDiff * b) / denominator;
Attempt to combine text runs positioned with `setTextMatrix`
2016-05-15 05:13:12 +09:00
}
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
return { width: tx, height: ty, value: font.vertical ? ty : tx };
Attempt to combine text runs positioned with `setTextMatrix`
2016-05-15 05:13:12 +09:00
},
Build the text layer geometry on the worker.
2014-04-10 08:44:07 +09:00
calcRenderMatrix: function TextState_calcRendeMatrix(ctm) {
// 9.4.4 Text Space Details
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
var tsm = [
this.fontSize * this.textHScale,
0,
0,
this.fontSize,
0,
this.textRise,
];
Build the text layer geometry on the worker.
2014-04-10 08:44:07 +09:00
return Util.transform(ctm, Util.transform(this.textMatrix, tsm));
},
carriageReturn: function TextState_carriageReturn() {
this.translateTextLineMatrix(0, -this.leading);
this.textMatrix = this.textLineMatrix.slice();
},
clone: function TextState_clone() {
var clone = Object.create(this);
clone.textMatrix = this.textMatrix.slice();
clone.textLineMatrix = this.textLineMatrix.slice();
clone.fontMatrix = this.fontMatrix.slice();
return clone;
Fix inconsistent spacing and trailing commas in objects in `src/core/` files, so we can enable the `comma-dangle` and `object-curly-spacing` ESLint rules later on *Unfortunately this patch is fairly big, even though it only covers the `src/core` folder, but splitting it even further seemed difficult.* http://eslint.org/docs/rules/comma-dangle http://eslint.org/docs/rules/object-curly-spacing Given that we currently have quite inconsistent object formatting, fixing this in *one* big patch probably wouldn't be feasible (since I cannot imagine anyone wanting to review that); hence I've opted to try and do this piecewise instead. Please note: This patch was created automatically, using the ESLint --fix command line option. In a couple of places this caused lines to become too long, and I've fixed those manually; please refer to the interdiff below for the only hand-edits in this patch. ```diff diff --git a/src/core/evaluator.js b/src/core/evaluator.js index abab9027..dcd3594b 100644 --- a/src/core/evaluator.js +++ b/src/core/evaluator.js @@ -2785,7 +2785,8 @@ var EvaluatorPreprocessor = (function EvaluatorPreprocessorClosure() { t['Tz'] = { id: OPS.setHScale, numArgs: 1, variableArgs: false, }; t['TL'] = { id: OPS.setLeading, numArgs: 1, variableArgs: false, }; t['Tf'] = { id: OPS.setFont, numArgs: 2, variableArgs: false, }; - t['Tr'] = { id: OPS.setTextRenderingMode, numArgs: 1, variableArgs: false, }; + t['Tr'] = { id: OPS.setTextRenderingMode, numArgs: 1, + variableArgs: false, }; t['Ts'] = { id: OPS.setTextRise, numArgs: 1, variableArgs: false, }; t['Td'] = { id: OPS.moveText, numArgs: 2, variableArgs: false, }; t['TD'] = { id: OPS.setLeadingMoveText, numArgs: 2, variableArgs: false, }; diff --git a/src/core/jbig2.js b/src/core/jbig2.js index 5a17d482..71671541 100644 --- a/src/core/jbig2.js +++ b/src/core/jbig2.js @@ -123,19 +123,22 @@ var Jbig2Image = (function Jbig2ImageClosure() { { x: -1, y: -1, }, { x: 0, y: -1, }, { x: 1, y: -1, }, { x: -2, y: 0, }, { x: -1, y: 0, }], [{ x: -3, y: -1, }, { x: -2, y: -1, }, { x: -1, y: -1, }, { x: 0, y: -1, }, - { x: 1, y: -1, }, { x: -4, y: 0, }, { x: -3, y: 0, }, { x: -2, y: 0, }, { x: -1, y: 0, }] + { x: 1, y: -1, }, { x: -4, y: 0, }, { x: -3, y: 0, }, { x: -2, y: 0, }, + { x: -1, y: 0, }] ]; var RefinementTemplates = [ { coding: [{ x: 0, y: -1, }, { x: 1, y: -1, }, { x: -1, y: 0, }], - reference: [{ x: 0, y: -1, }, { x: 1, y: -1, }, { x: -1, y: 0, }, { x: 0, y: 0, }, - { x: 1, y: 0, }, { x: -1, y: 1, }, { x: 0, y: 1, }, { x: 1, y: 1, }], + reference: [{ x: 0, y: -1, }, { x: 1, y: -1, }, { x: -1, y: 0, }, + { x: 0, y: 0, }, { x: 1, y: 0, }, { x: -1, y: 1, }, + { x: 0, y: 1, }, { x: 1, y: 1, }], }, { - coding: [{ x: -1, y: -1, }, { x: 0, y: -1, }, { x: 1, y: -1, }, { x: -1, y: 0, }], - reference: [{ x: 0, y: -1, }, { x: -1, y: 0, }, { x: 0, y: 0, }, { x: 1, y: 0, }, - { x: 0, y: 1, }, { x: 1, y: 1, }], + coding: [{ x: -1, y: -1, }, { x: 0, y: -1, }, { x: 1, y: -1, }, + { x: -1, y: 0, }], + reference: [{ x: 0, y: -1, }, { x: -1, y: 0, }, { x: 0, y: 0, }, + { x: 1, y: 0, }, { x: 0, y: 1, }, { x: 1, y: 1, }], } ]; ```
2017-06-02 18:16:24 +09:00
},
implementing transform matrix to getTextContent
2013-09-15 02:58:58 +09:00
};
return TextState;
})();
Incrementally render by sending the operator list by chunks as they're ready.
2013-08-01 03:17:36 +09:00
Name all constructors.
2011-12-09 07:18:43 +09:00
var EvalState = (function EvalStateClosure() {
Whitelist closure related cases to address the remaining `no-shadow` linting errors Given the way that "classes" were previously implemented in PDF.js, using regular functions and closures, there's a fair number of false positives when the `no-shadow` ESLint rule was enabled. Note that while *some* of these `eslint-disable` statements can be removed if/when the relevant code is converted to proper `class`es, we'll probably never be able to get rid of all of them given our naming/coding conventions (however I don't really see this being a problem).
2020-03-25 18:15:50 +09:00
// eslint-disable-next-line no-shadow
Name all constructors.
2011-12-09 07:18:43 +09:00
function EvalState() {
Build the text layer geometry on the worker.
2014-04-10 08:44:07 +09:00
this.ctm = new Float32Array(IDENTITY_MATRIX);
Move chars to glyphs conversion to the worker.
2013-08-01 06:01:55 +09:00
this.font = null;
Move the creation of canvas path fonts to the worker.
2013-08-20 08:33:20 +09:00
this.textRenderingMode = TextRenderingMode.FILL;
Moves ColorSpace logic into evaluator
2014-05-22 02:47:42 +09:00
this.fillColorSpace = ColorSpace.singletons.gray;
this.strokeColorSpace = ColorSpace.singletons.gray;
Splitting files
2011-10-25 08:55:23 +09:00
}
Name all constructors.
2011-12-09 07:18:43 +09:00
EvalState.prototype = {
Move chars to glyphs conversion to the worker.
2013-08-01 06:01:55 +09:00
clone: function CanvasExtraState_clone() {
return Object.create(this);
},
Splitting files
2011-10-25 08:55:23 +09:00
};
Name all constructors.
2011-12-09 07:18:43 +09:00
return EvalState;
Splitting files
2011-10-25 08:55:23 +09:00
})();
Fix js strict warning in worker.js. Also fix a few minor nits.
2011-10-28 03:51:10 +09:00
Fixes lint warning W004 in src/core
2014-04-08 06:42:54 +09:00
var EvaluatorPreprocessor = (function EvaluatorPreprocessorClosure() {
Extracts evaluator preprocessor and refactor text extraction
2014-01-17 22:16:52 +09:00
// Specifies properties for each command
//
// If variableArgs === true: [0, `numArgs`] expected
// If variableArgs === false: exactly `numArgs` expected
Update Prettier to version 2.0 Please note that these changes were done automatically, using `gulp lint --fix`. Given that the major version number was increased, there's a fair number of (primarily whitespace) changes; please see https://prettier.io/blog/2020/03/21/2.0.0.html In order to reduce the size of these changes somewhat, this patch maintains the old "arrowParens" style for now (once mozilla-central updates Prettier we can simply choose the same formatting, assuming it will differ here).
2020-04-14 19:28:14 +09:00
var getOPMap = getLookupTableFactory(function (t) {
Extracts evaluator preprocessor and refactor text extraction
2014-01-17 22:16:52 +09:00
// Graphic state
Enable the `dot-notation` ESLint rule *Please note:* These changes were done automatically, using the `gulp lint --fix` command. This rule is already enabled in mozilla-central, see https://searchfox.org/mozilla-central/rev/567b68b8ff4b6d607ba34a6f1926873d21a7b4d7/tools/lint/eslint/eslint-plugin-mozilla/lib/configs/recommended.js#103-104 The main advantage, besides improved consistency, of this rule is that it reduces the size of the code (by 3 bytes for each case). In the PDF.js code-base there's close to 8000 instances being fixed by the `dot-notation` ESLint rule, which end up reducing the size of even the *built* files significantly; the total size of the `gulp mozcentral` build target changes from `3 247 456` to `3 224 278` bytes, which is a *reduction* of `23 178` bytes (or ~0.7%) for a completely mechanical change. A large number of these changes affect the (large) lookup tables used on the worker-thread, but given that they are still initialized lazily I don't *think* that the new formatting this patch introduces should undo any of the improvements from PR 6915. Please find additional details about the ESLint rule at https://eslint.org/docs/rules/dot-notation
2020-04-17 19:06:27 +09:00
t.w = { id: OPS.setLineWidth, numArgs: 1, variableArgs: false };
t.J = { id: OPS.setLineCap, numArgs: 1, variableArgs: false };
t.j = { id: OPS.setLineJoin, numArgs: 1, variableArgs: false };
t.M = { id: OPS.setMiterLimit, numArgs: 1, variableArgs: false };
t.d = { id: OPS.setDash, numArgs: 2, variableArgs: false };
t.ri = { id: OPS.setRenderingIntent, numArgs: 1, variableArgs: false };
t.i = { id: OPS.setFlatness, numArgs: 1, variableArgs: false };
t.gs = { id: OPS.setGState, numArgs: 1, variableArgs: false };
t.q = { id: OPS.save, numArgs: 0, variableArgs: false };
t.Q = { id: OPS.restore, numArgs: 0, variableArgs: false };
t.cm = { id: OPS.transform, numArgs: 6, variableArgs: false };
Extracts evaluator preprocessor and refactor text extraction
2014-01-17 22:16:52 +09:00
// Path
Enable the `dot-notation` ESLint rule *Please note:* These changes were done automatically, using the `gulp lint --fix` command. This rule is already enabled in mozilla-central, see https://searchfox.org/mozilla-central/rev/567b68b8ff4b6d607ba34a6f1926873d21a7b4d7/tools/lint/eslint/eslint-plugin-mozilla/lib/configs/recommended.js#103-104 The main advantage, besides improved consistency, of this rule is that it reduces the size of the code (by 3 bytes for each case). In the PDF.js code-base there's close to 8000 instances being fixed by the `dot-notation` ESLint rule, which end up reducing the size of even the *built* files significantly; the total size of the `gulp mozcentral` build target changes from `3 247 456` to `3 224 278` bytes, which is a *reduction* of `23 178` bytes (or ~0.7%) for a completely mechanical change. A large number of these changes affect the (large) lookup tables used on the worker-thread, but given that they are still initialized lazily I don't *think* that the new formatting this patch introduces should undo any of the improvements from PR 6915. Please find additional details about the ESLint rule at https://eslint.org/docs/rules/dot-notation
2020-04-17 19:06:27 +09:00
t.m = { id: OPS.moveTo, numArgs: 2, variableArgs: false };
t.l = { id: OPS.lineTo, numArgs: 2, variableArgs: false };
t.c = { id: OPS.curveTo, numArgs: 6, variableArgs: false };
t.v = { id: OPS.curveTo2, numArgs: 4, variableArgs: false };
t.y = { id: OPS.curveTo3, numArgs: 4, variableArgs: false };
t.h = { id: OPS.closePath, numArgs: 0, variableArgs: false };
t.re = { id: OPS.rectangle, numArgs: 4, variableArgs: false };
t.S = { id: OPS.stroke, numArgs: 0, variableArgs: false };
t.s = { id: OPS.closeStroke, numArgs: 0, variableArgs: false };
t.f = { id: OPS.fill, numArgs: 0, variableArgs: false };
t.F = { id: OPS.fill, numArgs: 0, variableArgs: false };
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
t["f*"] = { id: OPS.eoFill, numArgs: 0, variableArgs: false };
Enable the `dot-notation` ESLint rule *Please note:* These changes were done automatically, using the `gulp lint --fix` command. This rule is already enabled in mozilla-central, see https://searchfox.org/mozilla-central/rev/567b68b8ff4b6d607ba34a6f1926873d21a7b4d7/tools/lint/eslint/eslint-plugin-mozilla/lib/configs/recommended.js#103-104 The main advantage, besides improved consistency, of this rule is that it reduces the size of the code (by 3 bytes for each case). In the PDF.js code-base there's close to 8000 instances being fixed by the `dot-notation` ESLint rule, which end up reducing the size of even the *built* files significantly; the total size of the `gulp mozcentral` build target changes from `3 247 456` to `3 224 278` bytes, which is a *reduction* of `23 178` bytes (or ~0.7%) for a completely mechanical change. A large number of these changes affect the (large) lookup tables used on the worker-thread, but given that they are still initialized lazily I don't *think* that the new formatting this patch introduces should undo any of the improvements from PR 6915. Please find additional details about the ESLint rule at https://eslint.org/docs/rules/dot-notation
2020-04-17 19:06:27 +09:00
t.B = { id: OPS.fillStroke, numArgs: 0, variableArgs: false };
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
t["B*"] = { id: OPS.eoFillStroke, numArgs: 0, variableArgs: false };
Enable the `dot-notation` ESLint rule *Please note:* These changes were done automatically, using the `gulp lint --fix` command. This rule is already enabled in mozilla-central, see https://searchfox.org/mozilla-central/rev/567b68b8ff4b6d607ba34a6f1926873d21a7b4d7/tools/lint/eslint/eslint-plugin-mozilla/lib/configs/recommended.js#103-104 The main advantage, besides improved consistency, of this rule is that it reduces the size of the code (by 3 bytes for each case). In the PDF.js code-base there's close to 8000 instances being fixed by the `dot-notation` ESLint rule, which end up reducing the size of even the *built* files significantly; the total size of the `gulp mozcentral` build target changes from `3 247 456` to `3 224 278` bytes, which is a *reduction* of `23 178` bytes (or ~0.7%) for a completely mechanical change. A large number of these changes affect the (large) lookup tables used on the worker-thread, but given that they are still initialized lazily I don't *think* that the new formatting this patch introduces should undo any of the improvements from PR 6915. Please find additional details about the ESLint rule at https://eslint.org/docs/rules/dot-notation
2020-04-17 19:06:27 +09:00
t.b = { id: OPS.closeFillStroke, numArgs: 0, variableArgs: false };
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
t["b*"] = { id: OPS.closeEOFillStroke, numArgs: 0, variableArgs: false };
Enable the `dot-notation` ESLint rule *Please note:* These changes were done automatically, using the `gulp lint --fix` command. This rule is already enabled in mozilla-central, see https://searchfox.org/mozilla-central/rev/567b68b8ff4b6d607ba34a6f1926873d21a7b4d7/tools/lint/eslint/eslint-plugin-mozilla/lib/configs/recommended.js#103-104 The main advantage, besides improved consistency, of this rule is that it reduces the size of the code (by 3 bytes for each case). In the PDF.js code-base there's close to 8000 instances being fixed by the `dot-notation` ESLint rule, which end up reducing the size of even the *built* files significantly; the total size of the `gulp mozcentral` build target changes from `3 247 456` to `3 224 278` bytes, which is a *reduction* of `23 178` bytes (or ~0.7%) for a completely mechanical change. A large number of these changes affect the (large) lookup tables used on the worker-thread, but given that they are still initialized lazily I don't *think* that the new formatting this patch introduces should undo any of the improvements from PR 6915. Please find additional details about the ESLint rule at https://eslint.org/docs/rules/dot-notation
2020-04-17 19:06:27 +09:00
t.n = { id: OPS.endPath, numArgs: 0, variableArgs: false };
Extracts evaluator preprocessor and refactor text extraction
2014-01-17 22:16:52 +09:00
// Clipping
Enable the `dot-notation` ESLint rule *Please note:* These changes were done automatically, using the `gulp lint --fix` command. This rule is already enabled in mozilla-central, see https://searchfox.org/mozilla-central/rev/567b68b8ff4b6d607ba34a6f1926873d21a7b4d7/tools/lint/eslint/eslint-plugin-mozilla/lib/configs/recommended.js#103-104 The main advantage, besides improved consistency, of this rule is that it reduces the size of the code (by 3 bytes for each case). In the PDF.js code-base there's close to 8000 instances being fixed by the `dot-notation` ESLint rule, which end up reducing the size of even the *built* files significantly; the total size of the `gulp mozcentral` build target changes from `3 247 456` to `3 224 278` bytes, which is a *reduction* of `23 178` bytes (or ~0.7%) for a completely mechanical change. A large number of these changes affect the (large) lookup tables used on the worker-thread, but given that they are still initialized lazily I don't *think* that the new formatting this patch introduces should undo any of the improvements from PR 6915. Please find additional details about the ESLint rule at https://eslint.org/docs/rules/dot-notation
2020-04-17 19:06:27 +09:00
t.W = { id: OPS.clip, numArgs: 0, variableArgs: false };
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
t["W*"] = { id: OPS.eoClip, numArgs: 0, variableArgs: false };
Extracts evaluator preprocessor and refactor text extraction
2014-01-17 22:16:52 +09:00
// Text
Enable the `dot-notation` ESLint rule *Please note:* These changes were done automatically, using the `gulp lint --fix` command. This rule is already enabled in mozilla-central, see https://searchfox.org/mozilla-central/rev/567b68b8ff4b6d607ba34a6f1926873d21a7b4d7/tools/lint/eslint/eslint-plugin-mozilla/lib/configs/recommended.js#103-104 The main advantage, besides improved consistency, of this rule is that it reduces the size of the code (by 3 bytes for each case). In the PDF.js code-base there's close to 8000 instances being fixed by the `dot-notation` ESLint rule, which end up reducing the size of even the *built* files significantly; the total size of the `gulp mozcentral` build target changes from `3 247 456` to `3 224 278` bytes, which is a *reduction* of `23 178` bytes (or ~0.7%) for a completely mechanical change. A large number of these changes affect the (large) lookup tables used on the worker-thread, but given that they are still initialized lazily I don't *think* that the new formatting this patch introduces should undo any of the improvements from PR 6915. Please find additional details about the ESLint rule at https://eslint.org/docs/rules/dot-notation
2020-04-17 19:06:27 +09:00
t.BT = { id: OPS.beginText, numArgs: 0, variableArgs: false };
t.ET = { id: OPS.endText, numArgs: 0, variableArgs: false };
t.Tc = { id: OPS.setCharSpacing, numArgs: 1, variableArgs: false };
t.Tw = { id: OPS.setWordSpacing, numArgs: 1, variableArgs: false };
t.Tz = { id: OPS.setHScale, numArgs: 1, variableArgs: false };
t.TL = { id: OPS.setLeading, numArgs: 1, variableArgs: false };
t.Tf = { id: OPS.setFont, numArgs: 2, variableArgs: false };
t.Tr = { id: OPS.setTextRenderingMode, numArgs: 1, variableArgs: false };
t.Ts = { id: OPS.setTextRise, numArgs: 1, variableArgs: false };
t.Td = { id: OPS.moveText, numArgs: 2, variableArgs: false };
t.TD = { id: OPS.setLeadingMoveText, numArgs: 2, variableArgs: false };
t.Tm = { id: OPS.setTextMatrix, numArgs: 6, variableArgs: false };
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
t["T*"] = { id: OPS.nextLine, numArgs: 0, variableArgs: false };
Enable the `dot-notation` ESLint rule *Please note:* These changes were done automatically, using the `gulp lint --fix` command. This rule is already enabled in mozilla-central, see https://searchfox.org/mozilla-central/rev/567b68b8ff4b6d607ba34a6f1926873d21a7b4d7/tools/lint/eslint/eslint-plugin-mozilla/lib/configs/recommended.js#103-104 The main advantage, besides improved consistency, of this rule is that it reduces the size of the code (by 3 bytes for each case). In the PDF.js code-base there's close to 8000 instances being fixed by the `dot-notation` ESLint rule, which end up reducing the size of even the *built* files significantly; the total size of the `gulp mozcentral` build target changes from `3 247 456` to `3 224 278` bytes, which is a *reduction* of `23 178` bytes (or ~0.7%) for a completely mechanical change. A large number of these changes affect the (large) lookup tables used on the worker-thread, but given that they are still initialized lazily I don't *think* that the new formatting this patch introduces should undo any of the improvements from PR 6915. Please find additional details about the ESLint rule at https://eslint.org/docs/rules/dot-notation
2020-04-17 19:06:27 +09:00
t.Tj = { id: OPS.showText, numArgs: 1, variableArgs: false };
t.TJ = { id: OPS.showSpacedText, numArgs: 1, variableArgs: false };
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
t["'"] = { id: OPS.nextLineShowText, numArgs: 1, variableArgs: false };
t['"'] = {
id: OPS.nextLineSetSpacingShowText,
numArgs: 3,
variableArgs: false,
};
Extracts evaluator preprocessor and refactor text extraction
2014-01-17 22:16:52 +09:00
// Type3 fonts
Enable the `dot-notation` ESLint rule *Please note:* These changes were done automatically, using the `gulp lint --fix` command. This rule is already enabled in mozilla-central, see https://searchfox.org/mozilla-central/rev/567b68b8ff4b6d607ba34a6f1926873d21a7b4d7/tools/lint/eslint/eslint-plugin-mozilla/lib/configs/recommended.js#103-104 The main advantage, besides improved consistency, of this rule is that it reduces the size of the code (by 3 bytes for each case). In the PDF.js code-base there's close to 8000 instances being fixed by the `dot-notation` ESLint rule, which end up reducing the size of even the *built* files significantly; the total size of the `gulp mozcentral` build target changes from `3 247 456` to `3 224 278` bytes, which is a *reduction* of `23 178` bytes (or ~0.7%) for a completely mechanical change. A large number of these changes affect the (large) lookup tables used on the worker-thread, but given that they are still initialized lazily I don't *think* that the new formatting this patch introduces should undo any of the improvements from PR 6915. Please find additional details about the ESLint rule at https://eslint.org/docs/rules/dot-notation
2020-04-17 19:06:27 +09:00
t.d0 = { id: OPS.setCharWidth, numArgs: 2, variableArgs: false };
t.d1 = {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
id: OPS.setCharWidthAndBounds,
numArgs: 6,
variableArgs: false,
};
Extracts evaluator preprocessor and refactor text extraction
2014-01-17 22:16:52 +09:00
// Color
Enable the `dot-notation` ESLint rule *Please note:* These changes were done automatically, using the `gulp lint --fix` command. This rule is already enabled in mozilla-central, see https://searchfox.org/mozilla-central/rev/567b68b8ff4b6d607ba34a6f1926873d21a7b4d7/tools/lint/eslint/eslint-plugin-mozilla/lib/configs/recommended.js#103-104 The main advantage, besides improved consistency, of this rule is that it reduces the size of the code (by 3 bytes for each case). In the PDF.js code-base there's close to 8000 instances being fixed by the `dot-notation` ESLint rule, which end up reducing the size of even the *built* files significantly; the total size of the `gulp mozcentral` build target changes from `3 247 456` to `3 224 278` bytes, which is a *reduction* of `23 178` bytes (or ~0.7%) for a completely mechanical change. A large number of these changes affect the (large) lookup tables used on the worker-thread, but given that they are still initialized lazily I don't *think* that the new formatting this patch introduces should undo any of the improvements from PR 6915. Please find additional details about the ESLint rule at https://eslint.org/docs/rules/dot-notation
2020-04-17 19:06:27 +09:00
t.CS = { id: OPS.setStrokeColorSpace, numArgs: 1, variableArgs: false };
t.cs = { id: OPS.setFillColorSpace, numArgs: 1, variableArgs: false };
t.SC = { id: OPS.setStrokeColor, numArgs: 4, variableArgs: true };
t.SCN = { id: OPS.setStrokeColorN, numArgs: 33, variableArgs: true };
t.sc = { id: OPS.setFillColor, numArgs: 4, variableArgs: true };
t.scn = { id: OPS.setFillColorN, numArgs: 33, variableArgs: true };
t.G = { id: OPS.setStrokeGray, numArgs: 1, variableArgs: false };
t.g = { id: OPS.setFillGray, numArgs: 1, variableArgs: false };
t.RG = { id: OPS.setStrokeRGBColor, numArgs: 3, variableArgs: false };
t.rg = { id: OPS.setFillRGBColor, numArgs: 3, variableArgs: false };
t.K = { id: OPS.setStrokeCMYKColor, numArgs: 4, variableArgs: false };
t.k = { id: OPS.setFillCMYKColor, numArgs: 4, variableArgs: false };
Extracts evaluator preprocessor and refactor text extraction
2014-01-17 22:16:52 +09:00
// Shading
Enable the `dot-notation` ESLint rule *Please note:* These changes were done automatically, using the `gulp lint --fix` command. This rule is already enabled in mozilla-central, see https://searchfox.org/mozilla-central/rev/567b68b8ff4b6d607ba34a6f1926873d21a7b4d7/tools/lint/eslint/eslint-plugin-mozilla/lib/configs/recommended.js#103-104 The main advantage, besides improved consistency, of this rule is that it reduces the size of the code (by 3 bytes for each case). In the PDF.js code-base there's close to 8000 instances being fixed by the `dot-notation` ESLint rule, which end up reducing the size of even the *built* files significantly; the total size of the `gulp mozcentral` build target changes from `3 247 456` to `3 224 278` bytes, which is a *reduction* of `23 178` bytes (or ~0.7%) for a completely mechanical change. A large number of these changes affect the (large) lookup tables used on the worker-thread, but given that they are still initialized lazily I don't *think* that the new formatting this patch introduces should undo any of the improvements from PR 6915. Please find additional details about the ESLint rule at https://eslint.org/docs/rules/dot-notation
2020-04-17 19:06:27 +09:00
t.sh = { id: OPS.shadingFill, numArgs: 1, variableArgs: false };
Extracts evaluator preprocessor and refactor text extraction
2014-01-17 22:16:52 +09:00
// Images
Enable the `dot-notation` ESLint rule *Please note:* These changes were done automatically, using the `gulp lint --fix` command. This rule is already enabled in mozilla-central, see https://searchfox.org/mozilla-central/rev/567b68b8ff4b6d607ba34a6f1926873d21a7b4d7/tools/lint/eslint/eslint-plugin-mozilla/lib/configs/recommended.js#103-104 The main advantage, besides improved consistency, of this rule is that it reduces the size of the code (by 3 bytes for each case). In the PDF.js code-base there's close to 8000 instances being fixed by the `dot-notation` ESLint rule, which end up reducing the size of even the *built* files significantly; the total size of the `gulp mozcentral` build target changes from `3 247 456` to `3 224 278` bytes, which is a *reduction* of `23 178` bytes (or ~0.7%) for a completely mechanical change. A large number of these changes affect the (large) lookup tables used on the worker-thread, but given that they are still initialized lazily I don't *think* that the new formatting this patch introduces should undo any of the improvements from PR 6915. Please find additional details about the ESLint rule at https://eslint.org/docs/rules/dot-notation
2020-04-17 19:06:27 +09:00
t.BI = { id: OPS.beginInlineImage, numArgs: 0, variableArgs: false };
t.ID = { id: OPS.beginImageData, numArgs: 0, variableArgs: false };
t.EI = { id: OPS.endInlineImage, numArgs: 1, variableArgs: false };
Extracts evaluator preprocessor and refactor text extraction
2014-01-17 22:16:52 +09:00
// XObjects
Enable the `dot-notation` ESLint rule *Please note:* These changes were done automatically, using the `gulp lint --fix` command. This rule is already enabled in mozilla-central, see https://searchfox.org/mozilla-central/rev/567b68b8ff4b6d607ba34a6f1926873d21a7b4d7/tools/lint/eslint/eslint-plugin-mozilla/lib/configs/recommended.js#103-104 The main advantage, besides improved consistency, of this rule is that it reduces the size of the code (by 3 bytes for each case). In the PDF.js code-base there's close to 8000 instances being fixed by the `dot-notation` ESLint rule, which end up reducing the size of even the *built* files significantly; the total size of the `gulp mozcentral` build target changes from `3 247 456` to `3 224 278` bytes, which is a *reduction* of `23 178` bytes (or ~0.7%) for a completely mechanical change. A large number of these changes affect the (large) lookup tables used on the worker-thread, but given that they are still initialized lazily I don't *think* that the new formatting this patch introduces should undo any of the improvements from PR 6915. Please find additional details about the ESLint rule at https://eslint.org/docs/rules/dot-notation
2020-04-17 19:06:27 +09:00
t.Do = { id: OPS.paintXObject, numArgs: 1, variableArgs: false };
t.MP = { id: OPS.markPoint, numArgs: 1, variableArgs: false };
t.DP = { id: OPS.markPointProps, numArgs: 2, variableArgs: false };
t.BMC = { id: OPS.beginMarkedContent, numArgs: 1, variableArgs: false };
t.BDC = {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
id: OPS.beginMarkedContentProps,
numArgs: 2,
variableArgs: false,
};
Enable the `dot-notation` ESLint rule *Please note:* These changes were done automatically, using the `gulp lint --fix` command. This rule is already enabled in mozilla-central, see https://searchfox.org/mozilla-central/rev/567b68b8ff4b6d607ba34a6f1926873d21a7b4d7/tools/lint/eslint/eslint-plugin-mozilla/lib/configs/recommended.js#103-104 The main advantage, besides improved consistency, of this rule is that it reduces the size of the code (by 3 bytes for each case). In the PDF.js code-base there's close to 8000 instances being fixed by the `dot-notation` ESLint rule, which end up reducing the size of even the *built* files significantly; the total size of the `gulp mozcentral` build target changes from `3 247 456` to `3 224 278` bytes, which is a *reduction* of `23 178` bytes (or ~0.7%) for a completely mechanical change. A large number of these changes affect the (large) lookup tables used on the worker-thread, but given that they are still initialized lazily I don't *think* that the new formatting this patch introduces should undo any of the improvements from PR 6915. Please find additional details about the ESLint rule at https://eslint.org/docs/rules/dot-notation
2020-04-17 19:06:27 +09:00
t.EMC = { id: OPS.endMarkedContent, numArgs: 0, variableArgs: false };
Extracts evaluator preprocessor and refactor text extraction
2014-01-17 22:16:52 +09:00
// Compatibility
Enable the `dot-notation` ESLint rule *Please note:* These changes were done automatically, using the `gulp lint --fix` command. This rule is already enabled in mozilla-central, see https://searchfox.org/mozilla-central/rev/567b68b8ff4b6d607ba34a6f1926873d21a7b4d7/tools/lint/eslint/eslint-plugin-mozilla/lib/configs/recommended.js#103-104 The main advantage, besides improved consistency, of this rule is that it reduces the size of the code (by 3 bytes for each case). In the PDF.js code-base there's close to 8000 instances being fixed by the `dot-notation` ESLint rule, which end up reducing the size of even the *built* files significantly; the total size of the `gulp mozcentral` build target changes from `3 247 456` to `3 224 278` bytes, which is a *reduction* of `23 178` bytes (or ~0.7%) for a completely mechanical change. A large number of these changes affect the (large) lookup tables used on the worker-thread, but given that they are still initialized lazily I don't *think* that the new formatting this patch introduces should undo any of the improvements from PR 6915. Please find additional details about the ESLint rule at https://eslint.org/docs/rules/dot-notation
2020-04-17 19:06:27 +09:00
t.BX = { id: OPS.beginCompat, numArgs: 0, variableArgs: false };
t.EX = { id: OPS.endCompat, numArgs: 0, variableArgs: false };
Extracts evaluator preprocessor and refactor text extraction
2014-01-17 22:16:52 +09:00
// (reserved partial commands for the lexer)
Enable the `dot-notation` ESLint rule *Please note:* These changes were done automatically, using the `gulp lint --fix` command. This rule is already enabled in mozilla-central, see https://searchfox.org/mozilla-central/rev/567b68b8ff4b6d607ba34a6f1926873d21a7b4d7/tools/lint/eslint/eslint-plugin-mozilla/lib/configs/recommended.js#103-104 The main advantage, besides improved consistency, of this rule is that it reduces the size of the code (by 3 bytes for each case). In the PDF.js code-base there's close to 8000 instances being fixed by the `dot-notation` ESLint rule, which end up reducing the size of even the *built* files significantly; the total size of the `gulp mozcentral` build target changes from `3 247 456` to `3 224 278` bytes, which is a *reduction* of `23 178` bytes (or ~0.7%) for a completely mechanical change. A large number of these changes affect the (large) lookup tables used on the worker-thread, but given that they are still initialized lazily I don't *think* that the new formatting this patch introduces should undo any of the improvements from PR 6915. Please find additional details about the ESLint rule at https://eslint.org/docs/rules/dot-notation
2020-04-17 19:06:27 +09:00
t.BM = null;
t.BD = null;
t.true = null;
t.fa = null;
t.fal = null;
t.fals = null;
t.false = null;
t.nu = null;
t.nul = null;
t.null = null;
Lazify OP_MAP.
2016-01-22 07:43:27 +09:00
});
Extracts evaluator preprocessor and refactor text extraction
2014-01-17 22:16:52 +09:00
Error, rather than warn, once a number of invalid path operators are encountered in `EvaluatorPreprocessor.read` (bug 1443140) Incomplete path operators, in particular, can result in fairly chaotic rendering artifacts, as can be observed on page four of the referenced PDF file. The initial (naive) solution that was attempted, was to simply throw a `FormatError` as soon as any invalid (i.e. too short) operator was found and rely on the existing `ignoreErrors` code-paths. However, doing so would have caused regressions in some files; see the existing `issue2391-1` test-case, which was promoted to an `eq` test to help prevent future bugs. Hence this patch, which adds special handling for invalid path operators since those may cause quite bad rendering artifacts. You could, in all fairness, argue that the patch is a handwavy solution and I wouldn't object. However, given that this only concerns *corrupt* PDF files, the way that PDF viewers (PDF.js included) try to gracefully deal with those could probably be described as a best-effort solution anyway. This patch also adjusts the existing `warn`/`info` messages to print the command name according to the PDF specification, rather than an internal PDF.js enumeration value. The former should be much more useful for debugging purposes. Fixes https://bugzilla.mozilla.org/show_bug.cgi?id=1443140.
2018-06-24 16:53:32 +09:00
const MAX_INVALID_PATH_OPS = 20;
Whitelist closure related cases to address the remaining `no-shadow` linting errors Given the way that "classes" were previously implemented in PDF.js, using regular functions and closures, there's a fair number of false positives when the `no-shadow` ESLint rule was enabled. Note that while *some* of these `eslint-disable` statements can be removed if/when the relevant code is converted to proper `class`es, we'll probably never be able to get rid of all of them given our naming/coding conventions (however I don't really see this being a problem).
2020-03-25 18:15:50 +09:00
// eslint-disable-next-line no-shadow
Build the text layer geometry on the worker.
2014-04-10 08:44:07 +09:00
function EvaluatorPreprocessor(stream, xref, stateManager) {
Lazify OP_MAP.
2016-01-22 07:43:27 +09:00
this.opMap = getOPMap();
// TODO(mduan): pass array of knownCommands rather than this.opMap
Extracts evaluator preprocessor and refactor text extraction
2014-01-17 22:16:52 +09:00
// dictionary
Change the signature of the `Parser` constructor to take a parameter object A lot of the `new Parser()` call-sites look quite unwieldy/ugly as-is, with a bunch of somewhat randomly ordered arguments, which we can avoid by changing the constructor to accept an object instead. As an added bonus, this provides better documentation without having to add inline argument comments in the code.
2019-06-23 23:01:45 +09:00
this.parser = new Parser({
lexer: new Lexer(stream, this.opMap),
xref,
});
Build the text layer geometry on the worker.
2014-04-10 08:44:07 +09:00
this.stateManager = stateManager;
Handle nested post script arguments in the preprocessor Fix for issue #4785
2014-05-15 15:07:43 +09:00
this.nonProcessedArgs = [];
Error, rather than warn, once a number of invalid path operators are encountered in `EvaluatorPreprocessor.read` (bug 1443140) Incomplete path operators, in particular, can result in fairly chaotic rendering artifacts, as can be observed on page four of the referenced PDF file. The initial (naive) solution that was attempted, was to simply throw a `FormatError` as soon as any invalid (i.e. too short) operator was found and rely on the existing `ignoreErrors` code-paths. However, doing so would have caused regressions in some files; see the existing `issue2391-1` test-case, which was promoted to an `eq` test to help prevent future bugs. Hence this patch, which adds special handling for invalid path operators since those may cause quite bad rendering artifacts. You could, in all fairness, argue that the patch is a handwavy solution and I wouldn't object. However, given that this only concerns *corrupt* PDF files, the way that PDF viewers (PDF.js included) try to gracefully deal with those could probably be described as a best-effort solution anyway. This patch also adjusts the existing `warn`/`info` messages to print the command name according to the PDF specification, rather than an internal PDF.js enumeration value. The former should be much more useful for debugging purposes. Fixes https://bugzilla.mozilla.org/show_bug.cgi?id=1443140.
2018-06-24 16:53:32 +09:00
this._numInvalidPathOPS = 0;
Extracts evaluator preprocessor and refactor text extraction
2014-01-17 22:16:52 +09:00
}
Making src/core/evaluator.js adhere to the style guide
2014-03-23 03:15:51 +09:00
Extracts evaluator preprocessor and refactor text extraction
2014-01-17 22:16:52 +09:00
EvaluatorPreprocessor.prototype = {
get savedStatesDepth() {
Build the text layer geometry on the worker.
2014-04-10 08:44:07 +09:00
return this.stateManager.stateStack.length;
Extracts evaluator preprocessor and refactor text extraction
2014-01-17 22:16:52 +09:00
},
Making src/core/evaluator.js adhere to the style guide
2014-03-23 03:15:51 +09:00
Avoid unnecessary array allocations in EvaluatorPreprocessor_read(). EvaluatorPreprocessor_read() is called in two cases. For the normal layer, the args array it produces is used beyond the bounds of the loop in which EvaluatorPreprocessor_read() is called. But for the text layer, the args array is used in a very short-term fashion. This change reworks things so that a single array is repeatedly used for the text layer. This reduces total JS allocations for the Spoorkaart map by 11%, and has similar effects on many other PDFs.
2014-08-11 09:23:23 +09:00
// |operation| is an object with two fields:
//
// - |fn| is an out param.
//
// - |args| is an inout param. On entry, it should have one of two values.
//
// - An empty array. This indicates that the caller is providing the
// array in which the args will be stored in. The caller should use
// this value if it can reuse a single array for each call to read().
//
// - |null|. This indicates that the caller needs this function to create
// the array in which any args are stored in. If there are zero args,
// this function will leave |operation.args| as |null| (thus avoiding
// allocations that would occur if we used an empty array to represent
// zero arguments). Otherwise, it will replace |null| with a new array
// containing the arguments. The caller should use this value if it
// cannot reuse an array for each call to read().
//
// These two modes are present because this function is very hot and so
// avoiding allocations where possible is worthwhile.
//
Avoid allocating return object in EvaluatorPreprocessor_read(). This function can be called 100s of 1000s or even millions of times, and the allocated return object accounts for 10% of all GC thing allocations for some documents. It's easy to avoid, which reduces stress on the garbage collector, and this patch does that.
2014-06-19 00:15:35 +09:00
read: function EvaluatorPreprocessor_read(operation) {
Avoid unnecessary array allocations in EvaluatorPreprocessor_read(). EvaluatorPreprocessor_read() is called in two cases. For the normal layer, the args array it produces is used beyond the bounds of the loop in which EvaluatorPreprocessor_read() is called. But for the text layer, the args array is used in a very short-term fashion. This change reworks things so that a single array is repeatedly used for the text layer. This reduces total JS allocations for the Spoorkaart map by 11%, and has similar effects on many other PDFs.
2014-08-11 09:23:23 +09:00
var args = operation.args;
Extracts evaluator preprocessor and refactor text extraction
2014-01-17 22:16:52 +09:00
while (true) {
var obj = this.parser.getObj();
Reduce the number of function calls in `EvaluatorPreprocessor.read` For very large and complex PDF files this will help performance slightly, since `EvaluatorPreprocessor.read` is called a lot during parsing in the worker. This patch was tested using the PDF file from issue 2618, i.e. http://bugzilla-attachments.gnome.org/attachment.cgi?id=226471, using the following manifest file: ``` [ { "id": "issue2618", "file": "../web/pdfs/issue2618.pdf", "md5": "", "rounds": 200, "type": "eq" } ] ``` This gave the following results when comparing this patch against the `master` branch: ``` -- Grouped By browser, stat -- browser | stat | Count | Baseline(ms) | Current(ms) | +/- | % | Result(P<.05) ------- | ------------ | ----- | ------------ | ----------- | --- | ----- | ------------- Firefox | Overall | 200 | 3402 | 3358 | -43 | -1.28 | faster Firefox | Page Request | 200 | 1 | 1 | 0 | 26.71 | Firefox | Rendering | 200 | 3401 | 3357 | -44 | -1.28 | faster ```
2019-07-28 23:24:58 +09:00
if (obj instanceof Cmd) {
Restructured EvaluatorPreprocessor_read to be more natural.
2014-06-19 19:47:00 +09:00
var cmd = obj.cmd;
// Check that the command is valid
Lazify OP_MAP.
2016-01-22 07:43:27 +09:00
var opSpec = this.opMap[cmd];
Restructured EvaluatorPreprocessor_read to be more natural.
2014-06-19 19:47:00 +09:00
if (!opSpec) {
Error, rather than warn, once a number of invalid path operators are encountered in `EvaluatorPreprocessor.read` (bug 1443140) Incomplete path operators, in particular, can result in fairly chaotic rendering artifacts, as can be observed on page four of the referenced PDF file. The initial (naive) solution that was attempted, was to simply throw a `FormatError` as soon as any invalid (i.e. too short) operator was found and rely on the existing `ignoreErrors` code-paths. However, doing so would have caused regressions in some files; see the existing `issue2391-1` test-case, which was promoted to an `eq` test to help prevent future bugs. Hence this patch, which adds special handling for invalid path operators since those may cause quite bad rendering artifacts. You could, in all fairness, argue that the patch is a handwavy solution and I wouldn't object. However, given that this only concerns *corrupt* PDF files, the way that PDF viewers (PDF.js included) try to gracefully deal with those could probably be described as a best-effort solution anyway. This patch also adjusts the existing `warn`/`info` messages to print the command name according to the PDF specification, rather than an internal PDF.js enumeration value. The former should be much more useful for debugging purposes. Fixes https://bugzilla.mozilla.org/show_bug.cgi?id=1443140.
2018-06-24 16:53:32 +09:00
warn(`Unknown command "${cmd}".`);
Restructured EvaluatorPreprocessor_read to be more natural.
2014-06-19 19:47:00 +09:00
continue;
}
var fn = opSpec.id;
var numArgs = opSpec.numArgs;
Fixes a regression from PR 4982 After PR 4982, the rendering of the first two pages of http://www.openmagazin.cz/pdf/2011/openMagazin-2011-04.pdf (from issue 215) no longer completes. The issue is that we cannot have `args === null` in `PartialEvaluator_buildPath`, but *must* use an empty array instead. In this patch I've also moved the `argsLength` variable definition in `EvaluatorPreprocessor_read`, to make sure that it's always defined.
2014-08-08 19:50:54 +09:00
var argsLength = args !== null ? args.length : 0;
Restructured EvaluatorPreprocessor_read to be more natural.
2014-06-19 19:47:00 +09:00
if (!opSpec.variableArgs) {
// Postscript commands can be nested, e.g. /F2 /GS2 gs 5.711 Tf
if (argsLength !== numArgs) {
var nonProcessedArgs = this.nonProcessedArgs;
while (argsLength > numArgs) {
nonProcessedArgs.push(args.shift());
argsLength--;
}
while (argsLength < numArgs && nonProcessedArgs.length !== 0) {
For commands with with too few arguments, clear out `args` if it's an Array instead of replacing it with `null` in `EvaluatorPreprocessor_read` (issue 7804) For `PartialEvaluator_getTextContent`, the same `args` Array should be re-used for every `EvaluatorPreprocessor_read` call. Hence we want to ensure that it's not accidentally replaced with `null` in `EvaluatorPreprocessor_read`, since otherwise corrupt PDF files (with too few arguments for certain commands) will cause errors in `PartialEvaluator_getTextContent`. Perhaps a micro-optimization, but this patch also changes two `!args` comparisons to `args === null`, since that should be a tiny bit more efficient.
2016-11-15 21:09:41 +09:00
if (args === null) {
Restructured EvaluatorPreprocessor_read to be more natural.
2014-06-19 19:47:00 +09:00
args = [];
}
args.unshift(nonProcessedArgs.pop());
argsLength++;
}
}
if (argsLength < numArgs) {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
const partialMsg =
`command ${cmd}: expected ${numArgs} args, ` +
`but received ${argsLength} args.`;
Error, rather than warn, once a number of invalid path operators are encountered in `EvaluatorPreprocessor.read` (bug 1443140) Incomplete path operators, in particular, can result in fairly chaotic rendering artifacts, as can be observed on page four of the referenced PDF file. The initial (naive) solution that was attempted, was to simply throw a `FormatError` as soon as any invalid (i.e. too short) operator was found and rely on the existing `ignoreErrors` code-paths. However, doing so would have caused regressions in some files; see the existing `issue2391-1` test-case, which was promoted to an `eq` test to help prevent future bugs. Hence this patch, which adds special handling for invalid path operators since those may cause quite bad rendering artifacts. You could, in all fairness, argue that the patch is a handwavy solution and I wouldn't object. However, given that this only concerns *corrupt* PDF files, the way that PDF viewers (PDF.js included) try to gracefully deal with those could probably be described as a best-effort solution anyway. This patch also adjusts the existing `warn`/`info` messages to print the command name according to the PDF specification, rather than an internal PDF.js enumeration value. The former should be much more useful for debugging purposes. Fixes https://bugzilla.mozilla.org/show_bug.cgi?id=1443140.
2018-06-24 16:53:32 +09:00
// Incomplete path operators, in particular, can result in fairly
// chaotic rendering artifacts. Hence the following heuristics is
// used to error, rather than just warn, once a number of invalid
// path operators have been encountered (fixes bug1443140.pdf).
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
if (
fn >= OPS.moveTo &&
fn <= OPS.endPath && // Path operator
++this._numInvalidPathOPS > MAX_INVALID_PATH_OPS
) {
Error, rather than warn, once a number of invalid path operators are encountered in `EvaluatorPreprocessor.read` (bug 1443140) Incomplete path operators, in particular, can result in fairly chaotic rendering artifacts, as can be observed on page four of the referenced PDF file. The initial (naive) solution that was attempted, was to simply throw a `FormatError` as soon as any invalid (i.e. too short) operator was found and rely on the existing `ignoreErrors` code-paths. However, doing so would have caused regressions in some files; see the existing `issue2391-1` test-case, which was promoted to an `eq` test to help prevent future bugs. Hence this patch, which adds special handling for invalid path operators since those may cause quite bad rendering artifacts. You could, in all fairness, argue that the patch is a handwavy solution and I wouldn't object. However, given that this only concerns *corrupt* PDF files, the way that PDF viewers (PDF.js included) try to gracefully deal with those could probably be described as a best-effort solution anyway. This patch also adjusts the existing `warn`/`info` messages to print the command name according to the PDF specification, rather than an internal PDF.js enumeration value. The former should be much more useful for debugging purposes. Fixes https://bugzilla.mozilla.org/show_bug.cgi?id=1443140.
2018-06-24 16:53:32 +09:00
throw new FormatError(`Invalid ${partialMsg}`);
}
For commands with with too few arguments, clear out `args` if it's an Array instead of replacing it with `null` in `EvaluatorPreprocessor_read` (issue 7804) For `PartialEvaluator_getTextContent`, the same `args` Array should be re-used for every `EvaluatorPreprocessor_read` call. Hence we want to ensure that it's not accidentally replaced with `null` in `EvaluatorPreprocessor_read`, since otherwise corrupt PDF files (with too few arguments for certain commands) will cause errors in `PartialEvaluator_getTextContent`. Perhaps a micro-optimization, but this patch also changes two `!args` comparisons to `args === null`, since that should be a tiny bit more efficient.
2016-11-15 21:09:41 +09:00
// If we receive too few arguments, it's not possible to execute
// the command, hence we skip the command.
Error, rather than warn, once a number of invalid path operators are encountered in `EvaluatorPreprocessor.read` (bug 1443140) Incomplete path operators, in particular, can result in fairly chaotic rendering artifacts, as can be observed on page four of the referenced PDF file. The initial (naive) solution that was attempted, was to simply throw a `FormatError` as soon as any invalid (i.e. too short) operator was found and rely on the existing `ignoreErrors` code-paths. However, doing so would have caused regressions in some files; see the existing `issue2391-1` test-case, which was promoted to an `eq` test to help prevent future bugs. Hence this patch, which adds special handling for invalid path operators since those may cause quite bad rendering artifacts. You could, in all fairness, argue that the patch is a handwavy solution and I wouldn't object. However, given that this only concerns *corrupt* PDF files, the way that PDF viewers (PDF.js included) try to gracefully deal with those could probably be described as a best-effort solution anyway. This patch also adjusts the existing `warn`/`info` messages to print the command name according to the PDF specification, rather than an internal PDF.js enumeration value. The former should be much more useful for debugging purposes. Fixes https://bugzilla.mozilla.org/show_bug.cgi?id=1443140.
2018-06-24 16:53:32 +09:00
warn(`Skipping ${partialMsg}`);
For commands with with too few arguments, clear out `args` if it's an Array instead of replacing it with `null` in `EvaluatorPreprocessor_read` (issue 7804) For `PartialEvaluator_getTextContent`, the same `args` Array should be re-used for every `EvaluatorPreprocessor_read` call. Hence we want to ensure that it's not accidentally replaced with `null` in `EvaluatorPreprocessor_read`, since otherwise corrupt PDF files (with too few arguments for certain commands) will cause errors in `PartialEvaluator_getTextContent`. Perhaps a micro-optimization, but this patch also changes two `!args` comparisons to `args === null`, since that should be a tiny bit more efficient.
2016-11-15 21:09:41 +09:00
if (args !== null) {
args.length = 0;
}
Restructured EvaluatorPreprocessor_read to be more natural.
2014-06-19 19:47:00 +09:00
continue;
}
} else if (argsLength > numArgs) {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
info(
`Command ${cmd}: expected [0, ${numArgs}] args, ` +
`but received ${argsLength} args.`
);
Restructured EvaluatorPreprocessor_read to be more natural.
2014-06-19 19:47:00 +09:00
}
// TODO figure out how to type-check vararg functions
this.preprocessCommand(fn, args);
operation.fn = fn;
operation.args = args;
return true;
Enable the `no-else-return` ESLint rule Using `else` after `return` is not necessary, and can often lead to unnecessarily cluttered code. By using the `no-else-return` rule in ESLint we can avoid this pattern, see http://eslint.org/docs/rules/no-else-return.
2016-12-16 21:05:33 +09:00
}
Reduce the number of function calls in `EvaluatorPreprocessor.read` For very large and complex PDF files this will help performance slightly, since `EvaluatorPreprocessor.read` is called a lot during parsing in the worker. This patch was tested using the PDF file from issue 2618, i.e. http://bugzilla-attachments.gnome.org/attachment.cgi?id=226471, using the following manifest file: ``` [ { "id": "issue2618", "file": "../web/pdfs/issue2618.pdf", "md5": "", "rounds": 200, "type": "eq" } ] ``` This gave the following results when comparing this patch against the `master` branch: ``` -- Grouped By browser, stat -- browser | stat | Count | Baseline(ms) | Current(ms) | +/- | % | Result(P<.05) ------- | ------------ | ----- | ------------ | ----------- | --- | ----- | ------------- Firefox | Overall | 200 | 3402 | 3358 | -43 | -1.28 | faster Firefox | Page Request | 200 | 1 | 1 | 0 | 26.71 | Firefox | Rendering | 200 | 3401 | 3357 | -44 | -1.28 | faster ```
2019-07-28 23:24:58 +09:00
if (obj === EOF) {
Enable the `no-else-return` ESLint rule Using `else` after `return` is not necessary, and can often lead to unnecessarily cluttered code. By using the `no-else-return` rule in ESLint we can avoid this pattern, see http://eslint.org/docs/rules/no-else-return.
2016-12-16 21:05:33 +09:00
return false; // no more commands
}
// argument
if (obj !== null) {
if (args === null) {
args = [];
Extracts evaluator preprocessor and refactor text extraction
2014-01-17 22:16:52 +09:00
}
Enable the `no-else-return` ESLint rule Using `else` after `return` is not necessary, and can often lead to unnecessarily cluttered code. By using the `no-else-return` rule in ESLint we can avoid this pattern, see http://eslint.org/docs/rules/no-else-return.
2016-12-16 21:05:33 +09:00
args.push(obj);
Remove most `assert()` calls (issue 8506) This replaces `assert` calls with `throw new FormatError()`/`throw new Error()`. In a few places, throwing an `Error` (which is what `assert` meant) isn't correct since the enclosing function is supposed to return a `Promise`, hence some cases were changed to `Promise.reject(...)` and similarily for `createPromiseCapability` instances.
2017-07-20 21:04:54 +09:00
if (args.length > 33) {
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
throw new FormatError("Too many arguments");
Remove most `assert()` calls (issue 8506) This replaces `assert` calls with `throw new FormatError()`/`throw new Error()`. In a few places, throwing an `Error` (which is what `assert` meant) isn't correct since the enclosing function is supposed to return a `Promise`, hence some cases were changed to `Promise.reject(...)` and similarily for `createPromiseCapability` instances.
2017-07-20 21:04:54 +09:00
}
Extracts evaluator preprocessor and refactor text extraction
2014-01-17 22:16:52 +09:00
}
}
},
Making src/core/evaluator.js adhere to the style guide
2014-03-23 03:15:51 +09:00
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
preprocessCommand: function EvaluatorPreprocessor_preprocessCommand(
fn,
args
) {
Extracts evaluator preprocessor and refactor text extraction
2014-01-17 22:16:52 +09:00
switch (fn | 0) {
case OPS.save:
Build the text layer geometry on the worker.
2014-04-10 08:44:07 +09:00
this.stateManager.save();
Extracts evaluator preprocessor and refactor text extraction
2014-01-17 22:16:52 +09:00
break;
case OPS.restore:
Build the text layer geometry on the worker.
2014-04-10 08:44:07 +09:00
this.stateManager.restore();
Extracts evaluator preprocessor and refactor text extraction
2014-01-17 22:16:52 +09:00
break;
case OPS.transform:
Build the text layer geometry on the worker.
2014-04-10 08:44:07 +09:00
this.stateManager.transform(args);
Extracts evaluator preprocessor and refactor text extraction
2014-01-17 22:16:52 +09:00
break;
}
Fix inconsistent spacing and trailing commas in objects in `src/core/` files, so we can enable the `comma-dangle` and `object-curly-spacing` ESLint rules later on *Unfortunately this patch is fairly big, even though it only covers the `src/core` folder, but splitting it even further seemed difficult.* http://eslint.org/docs/rules/comma-dangle http://eslint.org/docs/rules/object-curly-spacing Given that we currently have quite inconsistent object formatting, fixing this in *one* big patch probably wouldn't be feasible (since I cannot imagine anyone wanting to review that); hence I've opted to try and do this piecewise instead. Please note: This patch was created automatically, using the ESLint --fix command line option. In a couple of places this caused lines to become too long, and I've fixed those manually; please refer to the interdiff below for the only hand-edits in this patch. ```diff diff --git a/src/core/evaluator.js b/src/core/evaluator.js index abab9027..dcd3594b 100644 --- a/src/core/evaluator.js +++ b/src/core/evaluator.js @@ -2785,7 +2785,8 @@ var EvaluatorPreprocessor = (function EvaluatorPreprocessorClosure() { t['Tz'] = { id: OPS.setHScale, numArgs: 1, variableArgs: false, }; t['TL'] = { id: OPS.setLeading, numArgs: 1, variableArgs: false, }; t['Tf'] = { id: OPS.setFont, numArgs: 2, variableArgs: false, }; - t['Tr'] = { id: OPS.setTextRenderingMode, numArgs: 1, variableArgs: false, }; + t['Tr'] = { id: OPS.setTextRenderingMode, numArgs: 1, + variableArgs: false, }; t['Ts'] = { id: OPS.setTextRise, numArgs: 1, variableArgs: false, }; t['Td'] = { id: OPS.moveText, numArgs: 2, variableArgs: false, }; t['TD'] = { id: OPS.setLeadingMoveText, numArgs: 2, variableArgs: false, }; diff --git a/src/core/jbig2.js b/src/core/jbig2.js index 5a17d482..71671541 100644 --- a/src/core/jbig2.js +++ b/src/core/jbig2.js @@ -123,19 +123,22 @@ var Jbig2Image = (function Jbig2ImageClosure() { { x: -1, y: -1, }, { x: 0, y: -1, }, { x: 1, y: -1, }, { x: -2, y: 0, }, { x: -1, y: 0, }], [{ x: -3, y: -1, }, { x: -2, y: -1, }, { x: -1, y: -1, }, { x: 0, y: -1, }, - { x: 1, y: -1, }, { x: -4, y: 0, }, { x: -3, y: 0, }, { x: -2, y: 0, }, { x: -1, y: 0, }] + { x: 1, y: -1, }, { x: -4, y: 0, }, { x: -3, y: 0, }, { x: -2, y: 0, }, + { x: -1, y: 0, }] ]; var RefinementTemplates = [ { coding: [{ x: 0, y: -1, }, { x: 1, y: -1, }, { x: -1, y: 0, }], - reference: [{ x: 0, y: -1, }, { x: 1, y: -1, }, { x: -1, y: 0, }, { x: 0, y: 0, }, - { x: 1, y: 0, }, { x: -1, y: 1, }, { x: 0, y: 1, }, { x: 1, y: 1, }], + reference: [{ x: 0, y: -1, }, { x: 1, y: -1, }, { x: -1, y: 0, }, + { x: 0, y: 0, }, { x: 1, y: 0, }, { x: -1, y: 1, }, + { x: 0, y: 1, }, { x: 1, y: 1, }], }, { - coding: [{ x: -1, y: -1, }, { x: 0, y: -1, }, { x: 1, y: -1, }, { x: -1, y: 0, }], - reference: [{ x: 0, y: -1, }, { x: -1, y: 0, }, { x: 0, y: 0, }, { x: 1, y: 0, }, - { x: 0, y: 1, }, { x: 1, y: 1, }], + coding: [{ x: -1, y: -1, }, { x: 0, y: -1, }, { x: 1, y: -1, }, + { x: -1, y: 0, }], + reference: [{ x: 0, y: -1, }, { x: -1, y: 0, }, { x: 0, y: 0, }, + { x: 1, y: 0, }, { x: 0, y: 1, }, { x: 1, y: 1, }], } ]; ```
2017-06-02 18:16:24 +09:00
},
Extracts evaluator preprocessor and refactor text extraction
2014-01-17 22:16:52 +09:00
};
return EvaluatorPreprocessor;
})();
Refactors optimization list
2014-02-24 11:42:54 +09:00
Enable auto-formatting of the entire code-base using Prettier (issue 11444) Note that Prettier, purposely, has only limited [configuration options](https://prettier.io/docs/en/options.html). The configuration file is based on [the one in `mozilla central`](https://searchfox.org/mozilla-central/source/.prettierrc) with just a few additions (to avoid future breakage if the defaults ever changes). Prettier is being used for a couple of reasons: - To be consistent with `mozilla-central`, where Prettier is already in use across the tree. - To ensure a *consistent* coding style everywhere, which is automatically enforced during linting (since Prettier is used as an ESLint plugin). This thus ends "all" formatting disussions once and for all, removing the need for review comments on most stylistic matters. Many ESLint options are now redundant, and I've tried my best to remove all the now unnecessary options (but I may have missed some). Note also that since Prettier considers the `printWidth` option as a guide, rather than a hard rule, this patch resorts to a small hack in the ESLint config to ensure that *comments* won't become too long. *Please note:* This patch is generated automatically, by appending the `--fix` argument to the ESLint call used in the `gulp lint` task. It will thus require some additional clean-up, which will be done in a *separate* commit. (On a more personal note, I'll readily admit that some of the changes Prettier makes are *extremely* ugly. However, in the name of consistency we'll probably have to live with that.)
2019-12-25 23:59:37 +09:00
export { PartialEvaluator };
Reference in New Issue Copy Permalink