2011-10-11 05:46:43 +09:00
|
|
|
<!DOCTYPE html>
|
2012-09-01 07:48:21 +09:00
|
|
|
<!--
|
|
|
|
|
Copyright 2012 Mozilla Foundation
|
|
|
|
|
|
|
|
|
|
Licensed under the Apache License, Version 2.0 (the "License");
|
|
|
|
|
you may not use this file except in compliance with the License.
|
|
|
|
|
You may obtain a copy of the License at
|
|
|
|
|
|
|
|
|
|
http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
|
|
|
|
|
|
Unless required by applicable law or agreed to in writing, software
|
|
|
|
|
distributed under the License is distributed on an "AS IS" BASIS,
|
|
|
|
|
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
|
|
|
See the License for the specific language governing permissions and
|
|
|
|
|
limitations under the License.
|
|
|
|
|
-->
|
|
|
|
|
|
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>
|
2011-10-11 05:46:43 +09:00
|
|
|
<head>
|
|
|
|
|
<title>pdf.js test slave</title>
|
|
|
|
|
<style type="text/css"></style>
|
2013-02-07 08:19:29 +09:00
|
|
|
<script type="text/javascript" src="/src/network.js"></script>
|
|
|
|
|
<script type="text/javascript" src="/src/chunked_stream.js"></script>
|
|
|
|
|
<script type="text/javascript" src="/src/pdf_manager.js"></script>
|
2011-11-02 03:32:20 +09:00
|
|
|
<script type="text/javascript" src="/src/core.js"></script>
|
|
|
|
|
<script type="text/javascript" src="/src/util.js"></script>
|
2012-04-12 10:05:43 +09:00
|
|
|
<script type="text/javascript" src="/src/api.js"></script>
|
2011-11-02 03:32:20 +09:00
|
|
|
<script type="text/javascript" src="/src/canvas.js"></script>
|
|
|
|
|
<script type="text/javascript" src="/src/obj.js"></script>
|
2013-03-21 17:04:44 +09:00
|
|
|
<script type="text/javascript" src="/src/annotation.js"></script>
|
2011-11-02 03:32:20 +09:00
|
|
|
<script type="text/javascript" src="/src/function.js"></script>
|
|
|
|
|
<script type="text/javascript" src="/src/charsets.js"></script>
|
|
|
|
|
<script type="text/javascript" src="/src/cidmaps.js"></script>
|
|
|
|
|
<script type="text/javascript" src="/src/colorspace.js"></script>
|
|
|
|
|
<script type="text/javascript" src="/src/crypto.js"></script>
|
|
|
|
|
<script type="text/javascript" src="/src/evaluator.js"></script>
|
|
|
|
|
<script type="text/javascript" src="/src/fonts.js"></script>
|
|
|
|
|
<script type="text/javascript" src="/src/glyphlist.js"></script>
|
|
|
|
|
<script type="text/javascript" src="/src/image.js"></script>
|
|
|
|
|
<script type="text/javascript" src="/src/metrics.js"></script>
|
|
|
|
|
<script type="text/javascript" src="/src/parser.js"></script>
|
|
|
|
|
<script type="text/javascript" src="/src/pattern.js"></script>
|
|
|
|
|
<script type="text/javascript" src="/src/stream.js"></script>
|
|
|
|
|
<script type="text/javascript" src="/src/worker.js"></script>
|
2011-11-09 01:48:10 +09:00
|
|
|
<script type="text/javascript" src="/external/jpgjs/jpg.js"></script>
|
2012-01-12 11:08:46 +09:00
|
|
|
<script type="text/javascript" src="/src/jpx.js"></script>
|
2012-06-17 05:15:42 +09:00
|
|
|
<script type="text/javascript" src="/src/jbig2.js"></script>
|
2012-02-13 23:38:44 +09:00
|
|
|
<script type="text/javascript" src="/src/bidi.js"></script>
|
2011-10-11 05:46:43 +09:00
|
|
|
<script type="text/javascript" src="driver.js"></script>
|
2011-11-02 03:32:20 +09:00
|
|
|
|
|
|
|
|
<script type="text/javascript">
|
|
|
|
|
PDFJS.workerSrc = '/src/worker_loader.js';
|
|
|
|
|
</script>
|
2011-10-11 05:46:43 +09:00
|
|
|
</head>
|
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-10-11 05:46:43 +09:00
|
|
|
<body>
|
|
|
|
|
<pre style="width:800px; height:800px; overflow:scroll;" id="stdout"></pre>
|
|
|
|
|
<p>Inflight requests: <span id="inFlightCount"></span></p>
|
|
|
|
|
<div id="content-end"></div>
|
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-10-11 05:46:43 +09:00
|
|
|
<script type="text/javascript">
|
|
|
|
|
'use strict';
|
|
|
|
|
load();
|
|
|
|
|
</script>
|
|
|
|
|
</body>
|
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>
|
2011-10-11 05:46:43 +09:00
|
|
|
|
