Next: Directed downloads Up: Implementation Previous: Progressive Streams Contents Index
Once a page has been loaded, if its contents are to be `run' as normal (using e.g. fz_run_page) any error (such as failing to read a font, or an image, or even a content stream belonging to the page) will result in a rendering that aborts with a FZ_ERROR_TRYLATER error. The caller can catch this and display a placeholder instead.
If each pages data was entirely self-contained and sent in sequence this would perhaps be acceptable, with each page appearing one after the other. Unfortunately, the linearization procedure as laid down by Adobe does NOT do this: objects shared between multiple pages (other than the first) are not sent with the pages themselves, but rather AFTER all the pages have been sent.
This means that a document that has a title page, then contents that share a font used on pages 2 onwards, will not be able to correctly display page 2 until after the font has arrived in the file, which will not be until all the page data has been sent.
To mitigate against this, MuPDF provides a way whereby callers can indicate that they are prepared to accept an `incomplete' rendering of the file (perhaps with missing images, or with substitute fonts).
Callers prepared to tolerate such renderings should set the `incomplete_ok' flag in the cookie, then call fz_run_page etc as normal. If a FZ_ERROR_TRYLATER error is thrown at any point during the page rendering, the error will be swallowed, the `incomplete' field in the cookie will become non-zero and rendering will continue. When control returns to the caller the caller can check the value of the `incomplete' field and know that the rendering it received is not authoritative.