Sakurai/pdf.js
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
42c4ebfdb2
pdf.js/test/test_manifest.json

108 lines
2.4 KiB
JSON
Raw Normal View History

Initial import of first test harness The harness (test.py) operates as follows. First it locates executable browsers (or symlinks or scripts) named "[browser][version]", e.g. "firefox4". It then launches the located browsers and asks them to load the file test_slave.html. At the same time, test.py sets up an HTTP server on localhost:8080 (there's a race condition here currently ;). After test_slave loads in the browser(s), it fetches the task manifest (test_manifest.json). The entries in the manifest specify which PDF to load and how many times to cycle through page rendering. This will probably evolve over time. test_slave then performs the requested tasks and POSTs the results back to test.py, which saves them. When all the results of for a task are in, test.py checks them. There are three types of tests currently. "==" tests compare the rendering of a PDF against a master copy. This is not yet implemented because setting up a master copy is complicated. "fbf" tests render all a PDF's pages, then go back to page 1 and render all pages a second time. The renderings from the first round must match the ones from the second round. "load" tests just check that a PDF's pages load without errors. Currently the test harness will only launch a "firefox4" target. This can be a bash script in your pdf.js checkout, pdf.js/firefox4, something like the following #!/bin/bash dist="/path/to/firefox4/installation" profile=`mktemp -dt 'pdf.js-test-ff-profile-XXXXXXXXXX'` $dist/firefox -no-remote -profile $profile $* rm -rf $profile (Yes, this script doesn't clean up properly on early termination.) It's possible to run the tests in a normal browsing session, but that might be annoying. With that set up, run the harness like so python test.py If all goes well, you'll see all "TEST-PASS" messages printed to stdout. If something goes wrong, you'll see "TEST-UNEXPECTED-FAIL" printed to stdout.
2011-06-19 10:09:21 +09:00
[
test-harness improvements
2011-06-22 06:53:57 +09:00
{ "id": "tracemonkey-eq",
Modify paths of web resources to work with test resources more buried.
2011-06-24 01:48:34 +09:00
"file": "pdfs/tracemonkey.pdf",
Initial import of first test harness The harness (test.py) operates as follows. First it locates executable browsers (or symlinks or scripts) named "[browser][version]", e.g. "firefox4". It then launches the located browsers and asks them to load the file test_slave.html. At the same time, test.py sets up an HTTP server on localhost:8080 (there's a race condition here currently ;). After test_slave loads in the browser(s), it fetches the task manifest (test_manifest.json). The entries in the manifest specify which PDF to load and how many times to cycle through page rendering. This will probably evolve over time. test_slave then performs the requested tasks and POSTs the results back to test.py, which saves them. When all the results of for a task are in, test.py checks them. There are three types of tests currently. "==" tests compare the rendering of a PDF against a master copy. This is not yet implemented because setting up a master copy is complicated. "fbf" tests render all a PDF's pages, then go back to page 1 and render all pages a second time. The renderings from the first round must match the ones from the second round. "load" tests just check that a PDF's pages load without errors. Currently the test harness will only launch a "firefox4" target. This can be a bash script in your pdf.js checkout, pdf.js/firefox4, something like the following #!/bin/bash dist="/path/to/firefox4/installation" profile=`mktemp -dt 'pdf.js-test-ff-profile-XXXXXXXXXX'` $dist/firefox -no-remote -profile $profile $* rm -rf $profile (Yes, this script doesn't clean up properly on early termination.) It's possible to run the tests in a normal browsing session, but that might be annoying. With that set up, run the harness like so python test.py If all goes well, you'll see all "TEST-PASS" messages printed to stdout. If something goes wrong, you'll see "TEST-UNEXPECTED-FAIL" printed to stdout.
2011-06-19 10:09:21 +09:00
"rounds": 1,
test-harness improvements
2011-06-22 06:53:57 +09:00
"type": "eq"
Initial import of first test harness The harness (test.py) operates as follows. First it locates executable browsers (or symlinks or scripts) named "[browser][version]", e.g. "firefox4". It then launches the located browsers and asks them to load the file test_slave.html. At the same time, test.py sets up an HTTP server on localhost:8080 (there's a race condition here currently ;). After test_slave loads in the browser(s), it fetches the task manifest (test_manifest.json). The entries in the manifest specify which PDF to load and how many times to cycle through page rendering. This will probably evolve over time. test_slave then performs the requested tasks and POSTs the results back to test.py, which saves them. When all the results of for a task are in, test.py checks them. There are three types of tests currently. "==" tests compare the rendering of a PDF against a master copy. This is not yet implemented because setting up a master copy is complicated. "fbf" tests render all a PDF's pages, then go back to page 1 and render all pages a second time. The renderings from the first round must match the ones from the second round. "load" tests just check that a PDF's pages load without errors. Currently the test harness will only launch a "firefox4" target. This can be a bash script in your pdf.js checkout, pdf.js/firefox4, something like the following #!/bin/bash dist="/path/to/firefox4/installation" profile=`mktemp -dt 'pdf.js-test-ff-profile-XXXXXXXXXX'` $dist/firefox -no-remote -profile $profile $* rm -rf $profile (Yes, this script doesn't clean up properly on early termination.) It's possible to run the tests in a normal browsing session, but that might be annoying. With that set up, run the harness like so python test.py If all goes well, you'll see all "TEST-PASS" messages printed to stdout. If something goes wrong, you'll see "TEST-UNEXPECTED-FAIL" printed to stdout.
2011-06-19 10:09:21 +09:00
},
{ "id": "tracemonkey-fbf",
Modify paths of web resources to work with test resources more buried.
2011-06-24 01:48:34 +09:00
"file": "pdfs/tracemonkey.pdf",
Initial import of first test harness The harness (test.py) operates as follows. First it locates executable browsers (or symlinks or scripts) named "[browser][version]", e.g. "firefox4". It then launches the located browsers and asks them to load the file test_slave.html. At the same time, test.py sets up an HTTP server on localhost:8080 (there's a race condition here currently ;). After test_slave loads in the browser(s), it fetches the task manifest (test_manifest.json). The entries in the manifest specify which PDF to load and how many times to cycle through page rendering. This will probably evolve over time. test_slave then performs the requested tasks and POSTs the results back to test.py, which saves them. When all the results of for a task are in, test.py checks them. There are three types of tests currently. "==" tests compare the rendering of a PDF against a master copy. This is not yet implemented because setting up a master copy is complicated. "fbf" tests render all a PDF's pages, then go back to page 1 and render all pages a second time. The renderings from the first round must match the ones from the second round. "load" tests just check that a PDF's pages load without errors. Currently the test harness will only launch a "firefox4" target. This can be a bash script in your pdf.js checkout, pdf.js/firefox4, something like the following #!/bin/bash dist="/path/to/firefox4/installation" profile=`mktemp -dt 'pdf.js-test-ff-profile-XXXXXXXXXX'` $dist/firefox -no-remote -profile $profile $* rm -rf $profile (Yes, this script doesn't clean up properly on early termination.) It's possible to run the tests in a normal browsing session, but that might be annoying. With that set up, run the harness like so python test.py If all goes well, you'll see all "TEST-PASS" messages printed to stdout. If something goes wrong, you'll see "TEST-UNEXPECTED-FAIL" printed to stdout.
2011-06-19 10:09:21 +09:00
"rounds": 2,
"type": "fbf"
},
{ "id": "html5-canvas-cheat-sheet-load",
Modify paths of web resources to work with test resources more buried.
2011-06-24 01:48:34 +09:00
"file": "pdfs/canvas.pdf",
Initial import of first test harness The harness (test.py) operates as follows. First it locates executable browsers (or symlinks or scripts) named "[browser][version]", e.g. "firefox4". It then launches the located browsers and asks them to load the file test_slave.html. At the same time, test.py sets up an HTTP server on localhost:8080 (there's a race condition here currently ;). After test_slave loads in the browser(s), it fetches the task manifest (test_manifest.json). The entries in the manifest specify which PDF to load and how many times to cycle through page rendering. This will probably evolve over time. test_slave then performs the requested tasks and POSTs the results back to test.py, which saves them. When all the results of for a task are in, test.py checks them. There are three types of tests currently. "==" tests compare the rendering of a PDF against a master copy. This is not yet implemented because setting up a master copy is complicated. "fbf" tests render all a PDF's pages, then go back to page 1 and render all pages a second time. The renderings from the first round must match the ones from the second round. "load" tests just check that a PDF's pages load without errors. Currently the test harness will only launch a "firefox4" target. This can be a bash script in your pdf.js checkout, pdf.js/firefox4, something like the following #!/bin/bash dist="/path/to/firefox4/installation" profile=`mktemp -dt 'pdf.js-test-ff-profile-XXXXXXXXXX'` $dist/firefox -no-remote -profile $profile $* rm -rf $profile (Yes, this script doesn't clean up properly on early termination.) It's possible to run the tests in a normal browsing session, but that might be annoying. With that set up, run the harness like so python test.py If all goes well, you'll see all "TEST-PASS" messages printed to stdout. If something goes wrong, you'll see "TEST-UNEXPECTED-FAIL" printed to stdout.
2011-06-19 10:09:21 +09:00
"rounds": 1,
"type": "load"
add support for linking pdfs we can't/won't distribute
2011-06-22 07:14:42 +09:00
},
add Intel ISA doc as load test, and make harness resilient to bad PDF loads
2011-06-25 11:23:29 +09:00
{ "id": "intelisa-load",
"file": "pdfs/intelisa.pdf",
"link": true,
"rounds": 1,
"type": "load"
},
add support for linking pdfs we can't/won't distribute
2011-06-22 07:14:42 +09:00
{ "id": "pdfspec-load",
Modify paths of web resources to work with test resources more buried.
2011-06-24 01:48:34 +09:00
"file": "pdfs/pdf.pdf",
add support for linking pdfs we can't/won't distribute
2011-06-22 07:14:42 +09:00
"link": true,
"rounds": 1,
"type": "load"
Support for multi-size page PDFs
2011-06-26 23:15:33 +09:00
},
add unicode test
2011-07-06 02:21:28 +09:00
{ "id": "shavian-load",
"file": "pdfs/shavian.pdf",
"link": true,
"rounds": 1,
"type": "load"
},
Support for multi-size page PDFs
2011-06-26 23:15:33 +09:00
{ "id": "sizes",
"file": "pdfs/sizes.pdf",
"rounds": 1,
"type": "eq"
openweb-cover test
2011-06-28 10:13:11 +09:00
},
{ "id": "openweb-cover",
"file": "pdfs/openweb_tm-PRINT.pdf",
the new test file is a .link
2011-06-28 10:28:29 +09:00
"link": true,
openweb-cover test
2011-06-28 10:13:11 +09:00
"rounds": 1,
"type": "eq"
Added sample OpenOffice file to tests
2011-07-06 08:43:47 +09:00
},
{ "id": "openoffice-pdf",
"file": "pdfs/DiwanProfile.pdf",
"link": true,
"rounds": 1,
"type": "load"
Add and wire in test files
2011-07-13 17:55:13 +09:00
},
{ "id": "openofficecidtruetype-pdf",
"file": "pdfs/arial_unicode_en_cidfont.pdf",
"rounds": 1,
"type": "load"
},
{ "id": "openofficearabiccidtruetype-pdf",
"file": "pdfs/arial_unicode_ab_cidfont.pdf",
"rounds": 1,
"type": "load"
},
{ "id": "arabiccidtruetype-pdf",
"file": "pdfs/ArabicCIDTrueType.pdf",
"rounds": 1,
"type": "load"
link to AESV2 encrypted file
2011-07-21 13:17:31 +09:00
},
Change the way Type 2 CID fonts are encoded. Move the cmap glyphs above the first 255 unicode values so that fillText does not change them and create an encoding to map characters to the glyphs.
2011-08-19 22:04:34 +09:00
{ "id": "complexttffont-pdf",
"file": "pdfs/complex_ttf_font.pdf",
"rounds": 1,
"type": "load"
},
link to AESV2 encrypted file
2011-07-21 13:17:31 +09:00
{ "id": "i9-pdf",
"file": "pdfs/i9.pdf",
"link": true,
"rounds": 1,
"type": "eq"
Added test for inline images
2011-08-04 14:22:24 +09:00
},
{ "id": "hmm-pdf",
"file": "pdfs/hmm.pdf",
"link": true,
"rounds": 1,
"type": "load"
Adding support for page rotation
2011-08-07 06:41:18 +09:00
},
{ "id": "rotation",
"file": "pdfs/rotation.pdf",
"rounds": 1,
"type": "load"
BaseFont and misc fonts fixes
2011-08-14 22:40:22 +09:00
},
{ "id": "ecma262-pdf",
"file": "pdfs/ecma262.pdf",
"link": true,
"rounds": 1,
"type": "load"
Add JAI.pdf (issue #292) to the ref tests
2011-08-15 02:26:48 +09:00
},
{ "id": "jai-pdf",
"file": "pdfs/jai.pdf",
"link": true,
"rounds": 1,
"type": "load"
Adds cable.pdf link to tests
2011-08-29 06:36:58 +09:00
},
{ "id": "cable",
"file": "pdfs/cable.pdf",
"link": true,
"rounds": 1,
"type": "eq"
Initial import of first test harness The harness (test.py) operates as follows. First it locates executable browsers (or symlinks or scripts) named "[browser][version]", e.g. "firefox4". It then launches the located browsers and asks them to load the file test_slave.html. At the same time, test.py sets up an HTTP server on localhost:8080 (there's a race condition here currently ;). After test_slave loads in the browser(s), it fetches the task manifest (test_manifest.json). The entries in the manifest specify which PDF to load and how many times to cycle through page rendering. This will probably evolve over time. test_slave then performs the requested tasks and POSTs the results back to test.py, which saves them. When all the results of for a task are in, test.py checks them. There are three types of tests currently. "==" tests compare the rendering of a PDF against a master copy. This is not yet implemented because setting up a master copy is complicated. "fbf" tests render all a PDF's pages, then go back to page 1 and render all pages a second time. The renderings from the first round must match the ones from the second round. "load" tests just check that a PDF's pages load without errors. Currently the test harness will only launch a "firefox4" target. This can be a bash script in your pdf.js checkout, pdf.js/firefox4, something like the following #!/bin/bash dist="/path/to/firefox4/installation" profile=`mktemp -dt 'pdf.js-test-ff-profile-XXXXXXXXXX'` $dist/firefox -no-remote -profile $profile $* rm -rf $profile (Yes, this script doesn't clean up properly on early termination.) It's possible to run the tests in a normal browsing session, but that might be annoying. With that set up, run the harness like so python test.py If all goes well, you'll see all "TEST-PASS" messages printed to stdout. If something goes wrong, you'll see "TEST-UNEXPECTED-FAIL" printed to stdout.
2011-06-19 10:09:21 +09:00
}
]
Reference in New Issue Copy Permalink