PdfPageCollection Class

Definition

The pages of a document, in page order: the leaves of the page tree. Pages are inserted, removed and moved here.

public sealed class PdfPageCollection : IReadOnlyList<PdfPage>, IReadOnlyCollection<PdfPage>, IEnumerable<PdfPage>, IEnumerable

Remarks

ISO 32000-2 §7.7.3. The page tree is walked on first use (count, index or enumeration), once, by its Kids arrays; its Count entries are only checked, never trusted (§7.7.3.2 calls them redundant). Each PdfPage is a live view over its page object, but the list itself is the tree's shape at the first walk or the last edit made here: a change made to the page tree through the COS layer after that is not seen.

Editing (PDF 1.0): Insert(Int32, PdfRectangle), Insert(Int32, CosReference), RemoveAt(Int32) and Move(Int32, Int32) rebuild the page tree at once, balanced, with every page's inherited attributes (§7.7.3.4) made its own first, so a page keeps its Resources, MediaBox, CropBox and Rotate wherever it moves; the root keeps its object, and intermediate nodes are reused. Views of the pages stay valid across edits. Each edit is a mutation: no read may run concurrently with it.

A linearized file opened through range requests (OpenAsync(HttpClient, Uri, CancellationToken)) finds its pages through its page offset hint table instead (ISO 32000-2 F.4.2 and Annex G, G.4; issue #208): the count is the linearization dictionary's N, and each page's object is read when the page is first asked for, so going to a page fetches that page and not the tree. The page tree is still read, on first use, by anything that needs it: IndexOf(PdfPage), editing, or a page the hints do not locate (reported as LinearizationHintsInvalid; the pages then come from the tree, the views already handed out included).

Tip: use kind:method, kind:property, kind:ctor. Press Esc to clear.

Properties (2)

Methods (10)

Explicit Interface Implementation Methods (1)