@platejs/plite-layout derives page geometry, line fragments, and page-level
mount plans from a Plite editor. Use it for pagination lanes, print-like
surfaces, and page virtualization that still keeps Plite as the document model.
Keep production use behind explicit flags until your browser, export, table,
image, and collaboration requirements are proven.
Create a layout reader with createPliteLayout. The reader chooses the built-in
measurement engine and derives layout from the current editor snapshot and your
page settings.
import { createPliteLayout } from "@platejs/plite-layout";
const layout = createPliteLayout(editor, {
page: {
margins: 72,
preset: "letter",
import { createPliteLayout } from "@platejs/plite-layout";
const layout = createPliteLayout(editor, {
page: {
margins: 72,
preset: "letter",
},
});
layout.reconfigure({
page: {
margins: 48,
preset: "a4",
},
});The layout output is derived state. Store document content in Plite roots and store product settings in state fields; do not write layout fragments into the document unless your product explicitly needs authoritative page breaks.
Use PagedEditable from @platejs/plite-layout/react when the editor surface should
render pages.
import { Plite, usePliteEditor } from "@platejs/plite-react";
import { PagedEditable, usePliteLayout } from "@platejs/plite-layout/react";
const DocumentEditor = () => {
const editor = usePliteEditor({
initialValue,
});
const layout = usePliteLayout(editor, {
page: { margins: 72, preset: "letter" },
});
return (
<Plite editor={editor}>
<PagedEditable layout={layout} />
</Plite>
);
};import { Plite, usePliteEditor } from "@platejs/plite-react";
import { PagedEditable, usePliteLayout } from "@platejs/plite-layout/react";
const DocumentEditor = () => {
const editor = usePliteEditor({
initialValue,
});
const layout = usePliteLayout(editor, {
page: { margins: 72, preset: "letter" },
});
return (
<Plite editor={editor}>
<PagedEditable layout={layout} />
</Plite>
);
};PagedEditable wraps Editable, so normal Editable props still apply:
renderElement, renderLeaf, decorate, domStrategy, and keyboard handlers
stay on the editor surface.
usePliteLayout publishes option changes after React commits. Outside React,
call layout.reconfigure(nextOptions) to replace the complete configuration in
one atomic refresh.
Use createPlitePageLayout or usePlitePageLayout only when you provide an
explicit engine, such as a custom measurement engine or
pretextPageLayoutEngine().
createPliteLayout can run outside React and can fall back to an estimated
engine when browser canvas measurement is unavailable. Use that for previews,
tests, and export planning. Treat static output as derived geometry, not as an
authoritative PDF, print, or collaboration layout source unless your product
provides the measurement engine and proof for that target.
Tables, images, embeds, and other block formatting context style nodes should own their layout units through the selected layout engine. The engine should not split the Plite table node just to paginate a table. It can paginate engine-owned row units while the document tree stays stable.
Use page-level virtualization when pagination is enabled. Virtualizing whole pages keeps layout, selection, and page chrome aligned better than mounting and unmounting individual blocks inside a page.
The page mount plan keeps pages mounted when they are visible, selected, promoted by interaction, or involved in composition. That makes it the right boundary for print-like editors.
The built-in Pretext-backed engine measures text with browser font metrics. That gives stable results inside one browser profile, but different operating systems and browsers can still produce slightly different line breaks. Products that need exact collaboration or export parity should use an authoritative page break source or a shared measurement profile.