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
|
|
|
<html>
|
|
|
|
<head>
|
|
|
|
<title>pdf.js test slave</title>
|
2011-06-23 10:37:58 +09:00
|
|
|
<style type="text/css"></style>
|
2011-06-24 01:48:34 +09:00
|
|
|
<script type="text/javascript" src="/pdf.js"></script>
|
|
|
|
<script type="text/javascript" src="/fonts.js"></script>
|
2011-06-30 12:43:59 +09:00
|
|
|
<script type="text/javascript" src="/crypto.js"></script>
|
2011-06-24 01:48:34 +09:00
|
|
|
<script type="text/javascript" src="/glyphlist.js"></script>
|
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
|
|
|
<script type="application/javascript">
|
2011-06-29 08:29:52 +09:00
|
|
|
var appPath, browser, canvas, currentTask, currentTaskIdx, failure, manifest, numPages, pdfDoc, stdout;
|
2011-06-22 06:53:57 +09:00
|
|
|
|
|
|
|
function queryParams() {
|
|
|
|
var qs = window.location.search.substring(1);
|
|
|
|
var kvs = qs.split("&");
|
|
|
|
var params = { };
|
|
|
|
for (var i = 0; i < kvs.length; ++i) {
|
|
|
|
var kv = kvs[i].split("=");
|
|
|
|
params[unescape(kv[0])] = unescape(kv[1]);
|
|
|
|
}
|
|
|
|
return params;
|
|
|
|
}
|
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
|
|
|
|
|
|
|
function load() {
|
2011-06-22 06:53:57 +09:00
|
|
|
var params = queryParams();
|
|
|
|
browser = params.browser;
|
|
|
|
manifestFile = params.manifestFile;
|
2011-06-29 08:29:52 +09:00
|
|
|
appPath = params.path;
|
2011-06-22 06:53:57 +09:00
|
|
|
|
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
|
|
|
canvas = document.createElement("canvas");
|
|
|
|
canvas.mozOpaque = true;
|
|
|
|
stdout = document.getElementById("stdout");
|
|
|
|
|
2011-06-29 08:29:52 +09:00
|
|
|
log("Harness thinks this browser is '"+ browser + "' with path " + appPath + "\n");
|
2011-06-23 10:37:58 +09:00
|
|
|
log("Fetching manifest "+ manifestFile +"...");
|
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
|
|
|
|
|
|
|
var r = new XMLHttpRequest();
|
2011-06-22 06:53:57 +09:00
|
|
|
r.open("GET", manifestFile, false);
|
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
|
|
|
r.onreadystatechange = function(e) {
|
|
|
|
if (r.readyState == 4) {
|
|
|
|
log("done\n");
|
|
|
|
|
|
|
|
manifest = JSON.parse(r.responseText);
|
|
|
|
currentTaskIdx = 0, nextTask();
|
|
|
|
}
|
|
|
|
};
|
|
|
|
r.send(null);
|
|
|
|
}
|
|
|
|
|
|
|
|
function nextTask() {
|
|
|
|
if (currentTaskIdx == manifest.length) {
|
|
|
|
return done();
|
|
|
|
}
|
|
|
|
currentTask = manifest[currentTaskIdx];
|
|
|
|
currentTask.round = 0;
|
|
|
|
|
|
|
|
log("Loading file "+ currentTask.file +"\n");
|
|
|
|
|
|
|
|
var r = new XMLHttpRequest();
|
|
|
|
r.open("GET", currentTask.file);
|
|
|
|
r.mozResponseType = r.responseType = "arraybuffer";
|
|
|
|
r.onreadystatechange = function() {
|
|
|
|
if (r.readyState == 4) {
|
|
|
|
var data = r.mozResponseArrayBuffer || r.mozResponse ||
|
|
|
|
r.responseArrayBuffer || r.response;
|
2011-06-25 11:23:29 +09:00
|
|
|
|
|
|
|
try {
|
|
|
|
pdfDoc = new PDFDoc(new Stream(data));
|
2011-06-25 12:41:47 +09:00
|
|
|
numPages = pdfDoc.numPages;
|
2011-06-25 11:23:29 +09:00
|
|
|
} catch(e) {
|
2011-06-25 12:41:47 +09:00
|
|
|
numPages = 1;
|
2011-06-25 11:23:29 +09:00
|
|
|
failure = 'load PDF doc: '+ e.toString();
|
|
|
|
}
|
|
|
|
|
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
|
|
|
currentTask.pageNum = 1, nextPage();
|
|
|
|
}
|
|
|
|
};
|
|
|
|
r.send(null);
|
|
|
|
}
|
|
|
|
|
|
|
|
function nextPage() {
|
2011-06-25 12:41:47 +09:00
|
|
|
if (currentTask.pageNum > numPages) {
|
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
|
|
|
if (++currentTask.round < currentTask.rounds) {
|
|
|
|
log(" Round "+ (1 + currentTask.round) +"\n");
|
|
|
|
currentTask.pageNum = 1;
|
|
|
|
} else {
|
|
|
|
++currentTaskIdx, nextTask();
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
failure = '';
|
2011-06-23 10:37:58 +09:00
|
|
|
log(" loading page "+ currentTask.pageNum +"... ");
|
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
|
|
|
|
|
|
|
var ctx = canvas.getContext("2d");
|
|
|
|
|
|
|
|
var fonts = [];
|
2011-06-25 12:41:47 +09:00
|
|
|
var gfx = null;
|
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
|
|
|
try {
|
2011-06-25 12:41:47 +09:00
|
|
|
gfx = new CanvasGraphics(ctx);
|
2011-06-22 16:05:45 +09:00
|
|
|
currentPage = pdfDoc.getPage(currentTask.pageNum);
|
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
|
|
|
currentPage.compile(gfx, fonts);
|
|
|
|
} catch(e) {
|
|
|
|
failure = 'compile: '+ e.toString();
|
|
|
|
}
|
|
|
|
|
2011-06-26 23:15:33 +09:00
|
|
|
try {
|
2011-06-30 12:43:59 +09:00
|
|
|
var pdfToCssUnitsCoef = 96.0 / 72.0;
|
2011-06-26 23:15:33 +09:00
|
|
|
// using mediaBox for the canvas size
|
2011-06-30 12:43:59 +09:00
|
|
|
var pageWidth = (currentPage.mediaBox[2] - currentPage.mediaBox[0]);
|
|
|
|
var pageHeight = (currentPage.mediaBox[3] - currentPage.mediaBox[1]);
|
|
|
|
canvas.width = pageWidth * pdfToCssUnitsCoef;
|
|
|
|
canvas.height = pageHeight * pdfToCssUnitsCoef;
|
2011-06-26 23:15:33 +09:00
|
|
|
clear(ctx);
|
|
|
|
} catch(e) {
|
|
|
|
failure = 'page setup: '+ e.toString();
|
|
|
|
}
|
|
|
|
|
2011-06-30 18:08:53 +09:00
|
|
|
if (!failure) {
|
2011-06-25 12:41:47 +09:00
|
|
|
try {
|
2011-06-30 18:08:53 +09:00
|
|
|
FontLoader.bind(fonts, function() { snapshotCurrentPage(gfx); });
|
2011-06-25 12:41:47 +09:00
|
|
|
} catch(e) {
|
|
|
|
failure = 'fonts: '+ e.toString();
|
2011-06-23 10:37:58 +09:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-06-25 09:11:39 +09:00
|
|
|
if (failure) {
|
2011-06-30 18:08:53 +09:00
|
|
|
// Skip right to snapshotting if there was a failure, since the
|
|
|
|
// fonts might be in an inconsistent state.
|
2011-06-23 10:37:58 +09:00
|
|
|
snapshotCurrentPage(gfx);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
function snapshotCurrentPage(gfx) {
|
|
|
|
log("done, snapshotting... ");
|
|
|
|
|
|
|
|
if (!failure) {
|
|
|
|
try {
|
|
|
|
currentPage.display(gfx);
|
|
|
|
} catch(e) {
|
|
|
|
failure = 'render: '+ e.toString();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
sendTaskResult(canvas.toDataURL("image/png"));
|
|
|
|
log("done"+ (failure ? " (failed!)" : "") +"\n");
|
|
|
|
|
2011-06-25 08:14:33 +09:00
|
|
|
// Set up the next request
|
|
|
|
backoff = (inFlightRequests > 0) ? inFlightRequests * 10 : 0;
|
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
|
|
|
setTimeout(function() {
|
2011-06-25 08:14:33 +09:00
|
|
|
++currentTask.pageNum, nextPage();
|
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
|
|
|
},
|
2011-06-25 08:14:33 +09:00
|
|
|
backoff
|
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
|
|
|
);
|
|
|
|
}
|
|
|
|
|
2011-06-29 08:29:52 +09:00
|
|
|
function sendQuitRequest() {
|
|
|
|
var r = new XMLHttpRequest();
|
|
|
|
r.open("POST", "/tellMeToQuit?path=" + escape(appPath), false);
|
|
|
|
r.send("");
|
|
|
|
}
|
|
|
|
|
2011-06-25 08:14:33 +09:00
|
|
|
function quitApp() {
|
|
|
|
log("Done!");
|
|
|
|
document.body.innerHTML = "Tests are finished. <h1>CLOSE ME!</h1>";
|
2011-06-29 08:29:52 +09:00
|
|
|
if (window.SpecialPowers) {
|
2011-06-25 08:14:33 +09:00
|
|
|
SpecialPowers.quitApplication();
|
2011-06-29 08:29:52 +09:00
|
|
|
} else {
|
|
|
|
sendQuitRequest();
|
2011-06-25 08:14:33 +09:00
|
|
|
window.close();
|
2011-06-29 08:29:52 +09:00
|
|
|
}
|
2011-06-25 08:14:33 +09:00
|
|
|
}
|
|
|
|
|
|
|
|
function done() {
|
|
|
|
if (inFlightRequests > 0) {
|
|
|
|
document.getElementById("inFlightCount").innerHTML = inFlightRequests;
|
|
|
|
setTimeout(done, 100);
|
|
|
|
} else {
|
|
|
|
setTimeout(quitApp, 100);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
var inFlightRequests = 0;
|
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
|
|
|
function sendTaskResult(snapshot) {
|
2011-06-22 06:53:57 +09:00
|
|
|
var result = { browser: browser,
|
|
|
|
id: currentTask.id,
|
2011-06-25 12:41:47 +09:00
|
|
|
numPages: numPages,
|
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
|
|
|
failure: failure,
|
|
|
|
file: currentTask.file,
|
|
|
|
round: currentTask.round,
|
|
|
|
page: currentTask.pageNum,
|
|
|
|
snapshot: snapshot };
|
|
|
|
|
|
|
|
var r = new XMLHttpRequest();
|
|
|
|
// (The POST URI is ignored atm.)
|
2011-06-25 08:14:33 +09:00
|
|
|
r.open("POST", "/submit_task_results", true);
|
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
|
|
|
r.setRequestHeader("Content-Type", "application/json");
|
2011-06-25 08:14:33 +09:00
|
|
|
r.onreadystatechange = function(e) {
|
|
|
|
if (r.readyState == 4) {
|
|
|
|
inFlightRequests--;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
document.getElementById("inFlightCount").innerHTML = inFlightRequests++;
|
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
|
|
|
r.send(JSON.stringify(result));
|
|
|
|
}
|
|
|
|
|
|
|
|
function clear(ctx) {
|
|
|
|
ctx.save();
|
|
|
|
ctx.fillStyle = "rgb(255, 255, 255)";
|
|
|
|
ctx.fillRect(0, 0, canvas.width, canvas.height);
|
|
|
|
ctx.restore();
|
|
|
|
}
|
|
|
|
|
2011-06-26 01:51:27 +09:00
|
|
|
/* Auto-scroll if the scrollbar is near the bottom, otherwise do nothing. */
|
2011-06-26 01:42:59 +09:00
|
|
|
function checkScrolling() {
|
|
|
|
if ((stdout.scrollHeight - stdout.scrollTop) <= stdout.offsetHeight) {
|
2011-06-26 03:02:35 +09:00
|
|
|
stdout.scrollTop = stdout.scrollHeight;
|
2011-06-26 01:42:59 +09:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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
|
|
|
function log(str) {
|
|
|
|
stdout.innerHTML += str;
|
2011-06-26 01:42:59 +09:00
|
|
|
checkScrolling();
|
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
|
|
|
}
|
|
|
|
</script>
|
|
|
|
</head>
|
|
|
|
|
|
|
|
<body onload="load();">
|
2011-06-25 08:14:33 +09:00
|
|
|
<pre style="width:800; height:800; overflow: scroll;"id="stdout"></pre>
|
|
|
|
<p>Inflight requests: <span id="inFlightCount"></span></p>
|
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
|
|
|
</body>
|
|
|
|
|
|
|
|
</html>
|