pdf.js/test/unit/evaluator_spec.js

345 lines
12 KiB
JavaScript
Raw Normal View History

2017-01-10 01:40:57 +09:00
/* Copyright 2017 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.
*/
2012-05-11 06:11:27 +09:00
import { Dict, Name } from '../../src/core/primitives';
import { FormatError, OPS } from '../../src/shared/util';
import { Stream, StringStream } from '../../src/core/stream';
import { OperatorList } from '../../src/core/operator_list';
import { PartialEvaluator } from '../../src/core/evaluator';
import { WorkerTask } from '../../src/core/worker';
import { XRefMock } from './test_utils';
2017-01-10 01:40:57 +09:00
2012-05-11 06:11:27 +09:00
describe('evaluator', function() {
function HandlerMock() {
this.inputs = [];
}
HandlerMock.prototype = {
send(name, data) {
this.inputs.push({ name, data, });
Fix inconsistent spacing and trailing commas in objects in `test/` files, so we can enable the `comma-dangle` and `object-curly-spacing` ESLint rules later on 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/test/chromium/test-telemetry.js b/test/chromium/test-telemetry.js index cc412a31..2e5bdfa1 100755 --- a/test/chromium/test-telemetry.js +++ b/test/chromium/test-telemetry.js @@ -324,7 +324,7 @@ var tests = [ var window = createExtensionGlobal(); telemetryScript.runInNewContext(window); window.chrome.runtime.getManifest = function() { - return { version: '1.0.1', }; + return { version: '1.0.1', }; }; window.Date.test_now_value += 12 * 36E5; telemetryScript.runInNewContext(window); diff --git a/test/unit/api_spec.js b/test/unit/api_spec.js index 1f00747a..f22988e7 100644 --- a/test/unit/api_spec.js +++ b/test/unit/api_spec.js @@ -503,8 +503,9 @@ describe('api', function() { it('gets destinations, from /Dests dictionary', function(done) { var promise = doc.getDestinations(); promise.then(function(data) { - expect(data).toEqual({ chapter1: [{ gen: 0, num: 17, }, { name: 'XYZ', }, - 0, 841.89, null], }); + expect(data).toEqual({ + chapter1: [{ gen: 0, num: 17, }, { name: 'XYZ', }, 0, 841.89, null], + }); done(); }).catch(function (reason) { done.fail(reason); diff --git a/test/unit/function_spec.js b/test/unit/function_spec.js index 66441212..62127eb9 100644 --- a/test/unit/function_spec.js +++ b/test/unit/function_spec.js @@ -492,9 +492,11 @@ describe('function', function() { it('check compiled mul', function() { check([0.25, 0.5, 'mul'], [], [0, 1], [{ input: [], output: [0.125], }]); check([0, 'mul'], [0, 1], [0, 1], [{ input: [0.25], output: [0], }]); - check([0.5, 'mul'], [0, 1], [0, 1], [{ input: [0.25], output: [0.125], }]); + check([0.5, 'mul'], [0, 1], [0, 1], + [{ input: [0.25], output: [0.125], }]); check([1, 'mul'], [0, 1], [0, 1], [{ input: [0.25], output: [0.25], }]); - check([0, 'exch', 'mul'], [0, 1], [0, 1], [{ input: [0.25], output: [0], }]); + check([0, 'exch', 'mul'], [0, 1], [0, 1], + [{ input: [0.25], output: [0], }]); check([0.5, 'exch', 'mul'], [0, 1], [0, 1], [{ input: [0.25], output: [0.125], }]); check([1, 'exch', 'mul'], [0, 1], [0, 1], ```
2017-06-02 19:55:01 +09:00
},
2012-05-11 06:11:27 +09:00
};
function ResourcesMock() { }
ResourcesMock.prototype = {
get(name) {
2012-05-11 06:11:27 +09:00
return this[name];
Fix inconsistent spacing and trailing commas in objects in `test/` files, so we can enable the `comma-dangle` and `object-curly-spacing` ESLint rules later on 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/test/chromium/test-telemetry.js b/test/chromium/test-telemetry.js index cc412a31..2e5bdfa1 100755 --- a/test/chromium/test-telemetry.js +++ b/test/chromium/test-telemetry.js @@ -324,7 +324,7 @@ var tests = [ var window = createExtensionGlobal(); telemetryScript.runInNewContext(window); window.chrome.runtime.getManifest = function() { - return { version: '1.0.1', }; + return { version: '1.0.1', }; }; window.Date.test_now_value += 12 * 36E5; telemetryScript.runInNewContext(window); diff --git a/test/unit/api_spec.js b/test/unit/api_spec.js index 1f00747a..f22988e7 100644 --- a/test/unit/api_spec.js +++ b/test/unit/api_spec.js @@ -503,8 +503,9 @@ describe('api', function() { it('gets destinations, from /Dests dictionary', function(done) { var promise = doc.getDestinations(); promise.then(function(data) { - expect(data).toEqual({ chapter1: [{ gen: 0, num: 17, }, { name: 'XYZ', }, - 0, 841.89, null], }); + expect(data).toEqual({ + chapter1: [{ gen: 0, num: 17, }, { name: 'XYZ', }, 0, 841.89, null], + }); done(); }).catch(function (reason) { done.fail(reason); diff --git a/test/unit/function_spec.js b/test/unit/function_spec.js index 66441212..62127eb9 100644 --- a/test/unit/function_spec.js +++ b/test/unit/function_spec.js @@ -492,9 +492,11 @@ describe('function', function() { it('check compiled mul', function() { check([0.25, 0.5, 'mul'], [], [0, 1], [{ input: [], output: [0.125], }]); check([0, 'mul'], [0, 1], [0, 1], [{ input: [0.25], output: [0], }]); - check([0.5, 'mul'], [0, 1], [0, 1], [{ input: [0.25], output: [0.125], }]); + check([0.5, 'mul'], [0, 1], [0, 1], + [{ input: [0.25], output: [0.125], }]); check([1, 'mul'], [0, 1], [0, 1], [{ input: [0.25], output: [0.25], }]); - check([0, 'exch', 'mul'], [0, 1], [0, 1], [{ input: [0.25], output: [0], }]); + check([0, 'exch', 'mul'], [0, 1], [0, 1], + [{ input: [0.25], output: [0], }]); check([0.5, 'exch', 'mul'], [0, 1], [0, 1], [{ input: [0.25], output: [0.125], }]); check([1, 'exch', 'mul'], [0, 1], [0, 1], ```
2017-06-02 19:55:01 +09:00
},
2012-05-11 06:11:27 +09:00
};
2013-04-19 02:41:33 +09:00
function PdfManagerMock() { }
2016-03-29 23:34:13 +09:00
function runOperatorListCheck(evaluator, stream, resources, callback) {
var result = new OperatorList();
var task = new WorkerTask('OperatorListCheck');
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
evaluator.getOperatorList({
stream,
task,
resources,
operatorList: result,
}).then(function() {
2016-03-29 23:34:13 +09:00
callback(result);
}, function(reason) {
callback(reason);
2014-05-10 10:21:15 +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
var partialEvaluator;
beforeAll(function(done) {
partialEvaluator = new PartialEvaluator({
pdfManager: new PdfManagerMock(),
xref: new XRefMock(),
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
handler: new HandlerMock(),
pageIndex: 0,
});
done();
});
afterAll(function() {
partialEvaluator = null;
});
2012-05-11 06:11:27 +09:00
describe('splitCombinedOperations', function() {
2016-03-29 23:34:13 +09:00
it('should reject unknown operations', function(done) {
var stream = new StringStream('fTT');
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
runOperatorListCheck(partialEvaluator, stream, new ResourcesMock(),
2014-05-10 10:21:15 +09:00
function(result) {
expect(!!result.fnArray && !!result.argsArray).toEqual(true);
expect(result.fnArray.length).toEqual(1);
expect(result.fnArray[0]).toEqual(OPS.fill);
expect(result.argsArray[0]).toEqual(null);
2016-03-29 23:34:13 +09:00
done();
2014-05-10 10:21:15 +09:00
});
2012-05-11 06:11:27 +09:00
});
it('should handle one operation', function(done) {
2012-05-11 06:11:27 +09:00
var stream = new StringStream('Q');
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
runOperatorListCheck(partialEvaluator, stream, new ResourcesMock(),
2014-05-10 10:21:15 +09:00
function(result) {
expect(!!result.fnArray && !!result.argsArray).toEqual(true);
expect(result.fnArray.length).toEqual(1);
expect(result.fnArray[0]).toEqual(OPS.restore);
2016-03-29 23:34:13 +09:00
done();
2014-05-10 10:21:15 +09:00
});
2012-05-11 06:11:27 +09:00
});
2016-03-29 23:34:13 +09:00
it('should handle two glued operations', function(done) {
2012-05-11 06:11:27 +09:00
var resources = new ResourcesMock();
resources.Res1 = {};
var stream = new StringStream('/Res1 DoQ');
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
runOperatorListCheck(partialEvaluator, stream, resources,
function(result) {
2014-05-10 10:21:15 +09:00
expect(!!result.fnArray && !!result.argsArray).toEqual(true);
expect(result.fnArray.length).toEqual(2);
expect(result.fnArray[0]).toEqual(OPS.paintXObject);
expect(result.fnArray[1]).toEqual(OPS.restore);
2016-03-29 23:34:13 +09:00
done();
2014-05-10 10:21:15 +09:00
});
2012-05-11 06:11:27 +09:00
});
it('should handle three glued operations', function(done) {
var stream = new StringStream('fff');
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
runOperatorListCheck(partialEvaluator, stream, new ResourcesMock(),
2014-05-10 10:21:15 +09:00
function (result) {
expect(!!result.fnArray && !!result.argsArray).toEqual(true);
expect(result.fnArray.length).toEqual(3);
expect(result.fnArray[0]).toEqual(OPS.fill);
expect(result.fnArray[1]).toEqual(OPS.fill);
expect(result.fnArray[2]).toEqual(OPS.fill);
2016-03-29 23:34:13 +09:00
done();
2014-05-10 10:21:15 +09:00
});
2012-05-11 06:11:27 +09:00
});
2012-05-21 03:44:03 +09:00
2016-03-29 23:34:13 +09:00
it('should handle three glued operations #2', function(done) {
2012-05-21 03:44:03 +09:00
var resources = new ResourcesMock();
resources.Res1 = {};
var stream = new StringStream('B*Bf*');
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
runOperatorListCheck(partialEvaluator, stream, resources,
function(result) {
2014-05-10 10:21:15 +09:00
expect(!!result.fnArray && !!result.argsArray).toEqual(true);
expect(result.fnArray.length).toEqual(3);
expect(result.fnArray[0]).toEqual(OPS.eoFillStroke);
expect(result.fnArray[1]).toEqual(OPS.fillStroke);
expect(result.fnArray[2]).toEqual(OPS.eoFill);
2016-03-29 23:34:13 +09:00
done();
2014-05-10 10:21:15 +09:00
});
2012-05-21 03:44:03 +09:00
});
2016-03-29 23:34:13 +09:00
it('should handle glued operations and operands', function(done) {
var stream = new StringStream('f5 Ts');
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
runOperatorListCheck(partialEvaluator, stream, new ResourcesMock(),
2014-05-10 10:21:15 +09:00
function (result) {
expect(!!result.fnArray && !!result.argsArray).toEqual(true);
expect(result.fnArray.length).toEqual(2);
expect(result.fnArray[0]).toEqual(OPS.fill);
expect(result.fnArray[1]).toEqual(OPS.setTextRise);
expect(result.argsArray.length).toEqual(2);
expect(result.argsArray[1].length).toEqual(1);
expect(result.argsArray[1][0]).toEqual(5);
2016-03-29 23:34:13 +09:00
done();
2014-05-10 10:21:15 +09:00
});
2012-05-21 03:44:03 +09:00
});
2012-05-21 04:05:23 +09:00
2016-03-29 23:34:13 +09:00
it('should handle glued operations and literals', function(done) {
var stream = new StringStream('trueifalserinulln');
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
runOperatorListCheck(partialEvaluator, stream, new ResourcesMock(),
2014-05-10 10:21:15 +09:00
function (result) {
expect(!!result.fnArray && !!result.argsArray).toEqual(true);
expect(result.fnArray.length).toEqual(3);
expect(result.fnArray[0]).toEqual(OPS.setFlatness);
expect(result.fnArray[1]).toEqual(OPS.setRenderingIntent);
expect(result.fnArray[2]).toEqual(OPS.endPath);
expect(result.argsArray.length).toEqual(3);
expect(result.argsArray[0].length).toEqual(1);
expect(result.argsArray[0][0]).toEqual(true);
expect(result.argsArray[1].length).toEqual(1);
expect(result.argsArray[1][0]).toEqual(false);
expect(result.argsArray[2]).toEqual(null);
2016-03-29 23:34:13 +09:00
done();
2014-05-10 10:21:15 +09:00
});
});
});
describe('validateNumberOfArgs', function() {
2016-03-29 23:34:13 +09:00
it('should execute if correct number of arguments', function(done) {
var stream = new StringStream('5 1 d0');
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
runOperatorListCheck(partialEvaluator, stream, new ResourcesMock(),
2014-05-10 10:21:15 +09:00
function (result) {
expect(result.argsArray[0][0]).toEqual(5);
expect(result.argsArray[0][1]).toEqual(1);
expect(result.fnArray[0]).toEqual(OPS.setCharWidth);
2016-03-29 23:34:13 +09:00
done();
2014-05-10 10:21:15 +09:00
});
});
2016-03-29 23:34:13 +09:00
it('should execute if too many arguments', function(done) {
var stream = new StringStream('5 1 4 d0');
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
runOperatorListCheck(partialEvaluator, stream, new ResourcesMock(),
2014-05-10 10:21:15 +09:00
function (result) {
expect(result.argsArray[0][0]).toEqual(1);
expect(result.argsArray[0][1]).toEqual(4);
expect(result.fnArray[0]).toEqual(OPS.setCharWidth);
2016-03-29 23:34:13 +09:00
done();
2014-05-10 10:21:15 +09:00
});
});
2016-03-29 23:34:13 +09:00
it('should execute if nested commands', function(done) {
var stream = new StringStream('/F2 /GS2 gs 5.711 Tf');
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
runOperatorListCheck(partialEvaluator, stream, new ResourcesMock(),
2014-05-10 10:21:15 +09:00
function (result) {
expect(result.fnArray.length).toEqual(3);
expect(result.fnArray[0]).toEqual(OPS.setGState);
expect(result.fnArray[1]).toEqual(OPS.dependency);
expect(result.fnArray[2]).toEqual(OPS.setFont);
expect(result.argsArray.length).toEqual(3);
expect(result.argsArray[0].length).toEqual(1);
expect(result.argsArray[1].length).toEqual(1);
expect(result.argsArray[2].length).toEqual(2);
2016-03-29 23:34:13 +09:00
done();
2014-05-10 10:21:15 +09:00
});
});
2016-03-29 23:34:13 +09:00
it('should skip if too few arguments', function(done) {
var stream = new StringStream('5 d0');
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
runOperatorListCheck(partialEvaluator, stream, new ResourcesMock(),
2014-05-10 10:21:15 +09:00
function (result) {
expect(result.argsArray).toEqual([]);
expect(result.fnArray).toEqual([]);
2016-03-29 23:34:13 +09:00
done();
2014-05-10 10:21:15 +09:00
});
2012-05-21 04:05:23 +09:00
});
it('should error if (many) path operators have too few arguments ' +
'(bug 1443140)', function(done) {
const NUM_INVALID_OPS = 25;
const tempArr = new Array(NUM_INVALID_OPS + 1);
// Non-path operators, should be ignored.
const invalidMoveText = tempArr.join('10 Td\n');
const moveTextStream = new StringStream(invalidMoveText);
runOperatorListCheck(partialEvaluator, moveTextStream,
new ResourcesMock(), function(result) {
expect(result.argsArray).toEqual([]);
expect(result.fnArray).toEqual([]);
done();
});
// Path operators, should throw error.
const invalidLineTo = tempArr.join('20 l\n');
const lineToStream = new StringStream(invalidLineTo);
runOperatorListCheck(partialEvaluator, lineToStream, new ResourcesMock(),
function(error) {
expect(error instanceof FormatError).toEqual(true);
expect(error.message).toEqual(
'Invalid command l: expected 2 args, but received 1 args.');
done();
});
});
2016-03-29 23:34:13 +09:00
it('should close opened saves', function(done) {
var stream = new StringStream('qq');
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
runOperatorListCheck(partialEvaluator, stream, new ResourcesMock(),
2014-05-10 10:21:15 +09:00
function (result) {
expect(!!result.fnArray && !!result.argsArray).toEqual(true);
expect(result.fnArray.length).toEqual(4);
expect(result.fnArray[0]).toEqual(OPS.save);
expect(result.fnArray[1]).toEqual(OPS.save);
expect(result.fnArray[2]).toEqual(OPS.restore);
expect(result.fnArray[3]).toEqual(OPS.restore);
2016-03-29 23:34:13 +09:00
done();
2014-05-10 10:21:15 +09:00
});
});
2019-03-20 20:52:32 +09:00
it('should error on paintXObject if name is missing', function(done) {
var stream = new StringStream('/ Do');
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
runOperatorListCheck(partialEvaluator, stream, new ResourcesMock(),
function(result) {
expect(result instanceof FormatError).toEqual(true);
expect(result.message).toEqual('XObject must be referred to by name.');
2016-03-29 23:34:13 +09:00
done();
});
});
2016-03-29 23:34:13 +09:00
it('should skip paintXObject if subtype is PS', function(done) {
var xobjStreamDict = new Dict();
xobjStreamDict.set('Subtype', Name.get('PS'));
var xobjStream = new Stream([], 0, 0, xobjStreamDict);
var xobjs = new Dict();
xobjs.set('Res1', xobjStream);
var resources = new Dict();
resources.set('XObject', xobjs);
var stream = new StringStream('/Res1 Do');
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
runOperatorListCheck(partialEvaluator, stream, resources,
function(result) {
expect(result.argsArray).toEqual([]);
expect(result.fnArray).toEqual([]);
2016-03-29 23:34:13 +09:00
done();
});
});
2012-05-11 06:11:27 +09:00
});
2015-10-21 10:50:32 +09:00
describe('thread control', function() {
2016-03-29 23:34:13 +09:00
it('should abort operator list parsing', function (done) {
2015-10-21 10:50:32 +09:00
var stream = new StringStream('qqQQ');
var resources = new ResourcesMock();
2016-03-29 23:34:13 +09:00
var result = new OperatorList();
var task = new WorkerTask('OperatorListAbort');
task.terminate();
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
partialEvaluator.getOperatorList({
stream,
task,
resources,
operatorList: result,
}).catch(function() {
expect(!!result.fnArray && !!result.argsArray).toEqual(true);
expect(result.fnArray.length).toEqual(0);
done();
});
2015-10-21 10:50:32 +09:00
});
2016-03-29 23:34:13 +09:00
it('should abort text parsing parsing', function (done) {
2015-10-21 10:50:32 +09:00
var resources = new ResourcesMock();
var stream = new StringStream('qqQQ');
2016-03-29 23:34:13 +09:00
var task = new WorkerTask('TextContentAbort');
task.terminate();
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
partialEvaluator.getTextContent({
stream,
task,
resources,
}).catch(function() {
expect(true).toEqual(true);
done();
});
2015-10-21 10:50:32 +09:00
});
});
describe('operator list', function () {
function MessageHandlerMock() { }
MessageHandlerMock.prototype = {
send() { },
};
it('should get correct total length after flushing', function () {
var operatorList = new OperatorList(null, new MessageHandlerMock());
operatorList.addOp(OPS.save, null);
operatorList.addOp(OPS.restore, null);
expect(operatorList.totalLength).toEqual(2);
expect(operatorList.length).toEqual(2);
operatorList.flush();
expect(operatorList.totalLength).toEqual(2);
expect(operatorList.length).toEqual(0);
});
});
2012-05-11 06:11:27 +09:00
});