diff options
| author | Tor Andersson <tor.andersson@artifex.com> | 2016-07-14 00:56:37 +0200 |
|---|---|---|
| committer | Tor Andersson <tor.andersson@artifex.com> | 2016-07-14 01:04:27 +0200 |
| commit | de4a540efee75970a7ff7949ada2304c786b1da8 (patch) | |
| tree | 0d9375e02015f20f7290a4423dd9731bfff3ebd2 /docs | |
| parent | b8aeced92d5a3576e9bc5fbd87656dc97e380c52 (diff) | |
| download | mupdf-de4a540efee75970a7ff7949ada2304c786b1da8.tar.xz | |
Fix whitespace and indentation.
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/overview.txt | 2 | ||||
| -rw-r--r-- | docs/progressive.txt | 6 | ||||
| -rw-r--r-- | docs/thirdparty.txt | 4 |
3 files changed, 2 insertions, 10 deletions
diff --git a/docs/overview.txt b/docs/overview.txt index 2bb6b843..0e558fe8 100644 --- a/docs/overview.txt +++ b/docs/overview.txt @@ -225,7 +225,7 @@ multi-threaded operations run smoothly: cause it to get confused and may crash. Calling a device from several different threads is perfectly acceptable as long as there are safeguards in place to prevent the calls being - simultaneous. + simultaneous. So, how does a multi-threaded example differ from a non-multithreaded one? diff --git a/docs/progressive.txt b/docs/progressive.txt index a39e70d9..081f599e 100644 --- a/docs/progressive.txt +++ b/docs/progressive.txt @@ -16,7 +16,6 @@ For optimum performance a file should be both linearized and be available over a byte-range supporting link, but benefits can still be had with either one of these alone. - Progressive download using "linearized" files ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -54,7 +53,6 @@ uses, shared or otherwise, subsequent pages do not get shared resources until after all the unshared page objects have been sent.] - The Hint Stream ~~~~~~~~~~~~~~~ @@ -67,7 +65,6 @@ Consequently very few people actually use it. MuPDF will use it after sanity checking the values, and should cope with illegal/ incorrect values. - So how does MuPDF handle progressive loading? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -148,7 +145,6 @@ progressive loading. the caller can check the value of the 'incomplete' field and know that the rendering it received is not authoritative. - Progressive loading using byte range requests ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -248,7 +244,7 @@ a server. non-linear file can be 20%+ of the file data. Once past this initial point however, pages and data can be pulled from the file almost as fast as with a linearized file.] - + For a non-linearized PDF on a non-byte request capable stream: - MuPDF will immediately seek to the end of the file to attempt diff --git a/docs/thirdparty.txt b/docs/thirdparty.txt index 5f7563ba..a8e9ba5e 100644 --- a/docs/thirdparty.txt +++ b/docs/thirdparty.txt @@ -1,10 +1,8 @@ Third Party Libraries Used by MuPDF =================================== - Library Version Function License URL - freetype 2.5.5 Font scaling Freetype http://www.freetype.org/ and rendering License @@ -23,7 +21,6 @@ openjpeg 2.0.0 JPEG 2000 BSD-style http://www.openjpeg.org/ zlib 1.2.7 (De)Flate zlib License http://www.zlib.net/ compression - (Optional) curl 7.31.0 HTTP data MIT-style http://curl.haxx.se/ @@ -38,5 +35,4 @@ Luratech JBIG2 JBIG2 commercial http://www.luratech.com/ JPEG-XR 1.8 JPEG-XR special https://www.itu.int/rec/T-REC-T.835/ reference (with patches) decoding - NOTE: jbig2dec and mujs are included in "thirdparty" but are copyright Artifex Software Inc. |