Rendering Pages

To render a page, you first need to know how big it is. This can be discovered by calling fz_bound_page, passing a fz_rect in to be populated:

$\begin{lstlisting} /* fz_bound_page: Determine the size of a page at 72 dpi. \p... ... *fz_bound_page(fz_context *ctx, fz_page *page, fz_rect *rect); \end{lstlisting}$

MuPDF operates on page contents (and annotations) by processing them to a Device. There are various different devices in MuPDF (and you can implement your own). See Device Device for more information. For now, just consider devices to be things that are called with each of the graphical items on the page in turn.

The simplest way to process a page is to call fz_run_page:

$\begin{lstlisting} /* fz_run_page: Run a page through a device. \par page: Page... ...fz_device *dev, const fz_matrix *transform, fz_cookie *cookie); \end{lstlisting}$

This will cause each graphical object from the page contents and annotations in turn to be transformed, and fed to the device.

For finer control, you may wish to run the page contents, and the annotations separately:

$\begin{lstlisting} /* fz_run_page_contents: Run a page through a device. Just t... ...fz_device *dev, const fz_matrix *transform, fz_cookie *cookie); \end{lstlisting}$

These functions enable viewer applications to generate separate display lists for page contents and annotations. This can be useful if annotations are frequently changed, as it allows regeneration/redraw to happen on a per-annotation rather than per-page level.

All three of these functions (fz_run_page, fz_run_page_contents, fz_run_annot) take a fz_cookie pointer. The Cookie is a lightweight way of controlling the processing of the page. For more details, see Cookie Cookie. For most simple cases this can be NULL.