mirror of
https://github.com/mozilla/pdf.js.git
synced 2026-07-04 06:05:47 +02:00
Updated Frequently Asked Questions (markdown)
parent
0d4c2e69a5
commit
c783846b56
@ -11,7 +11,8 @@
|
||||
* [I know that my PDFs are corrupted. Will PDF.js attempt to display it?](#corrupted-pdf)
|
||||
* [I have a really great idea. Where is the best place to record it?](#idea)
|
||||
* [I'm developing a custom solution based on PDF.js core library. Can you help me?](#custom)
|
||||
* [I want to render all 100 pages in a document at high resolution. Is it a good idea?](#allthepages)
|
||||
* [I want to render all 100 pages in a document at high resolution. Is it a good idea?](#allthepages)
|
||||
* [PDF.js is fetching entire PDF file from a server. Can it fetch only its portion?](#range)
|
||||
* [What is a latest stable version of PDF.js?](#version)
|
||||
* [What types of PDF files are slow in PDF.js? Can I optimize a PDF file to make PDF.js faster?](#optimize)
|
||||
|
||||
@ -176,6 +177,11 @@ Not really. You can count yourself: a letter page size is 816⨉1056px at 96DPI
|
||||
|
||||
The demo viewer creates, renders, and holds canvases only for visible pages to reduce amount of used memory. Our recommendation is to create and render only visible pages.
|
||||
|
||||
<a name="range"></a>
|
||||
## PDF.js is fetching entire PDF file from a server. Can it fetch only its portion?
|
||||
|
||||
Actually PDF.js is doing just that. The PDF is a complicated format;in most of the cases, vital data of a PDF document is located at the end. Depending on [browser support](#faq-support) and on what web server returns in the [HTTP Range Requests headers](https://tools.ietf.org/html/rfc7233), the PDF.js automatically may start using HTTP Range Requests to fetch not-yet-loaded portions of a PDF needed for rendering of visible pages, so a document can be rendered without fully loading it.
|
||||
|
||||
<a name="version"></a>
|
||||
## What is a latest stable version of PDF.js?
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user