@extend-ai/react-docx 0.8.4 → 0.9.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md CHANGED
@@ -158,6 +158,46 @@ export function EditorExample() {
158
158
  }
159
159
  ```
160
160
 
161
+ ## Thumbnail-only rendering
162
+
163
+ Use the imperative renderer when a cover or page preview is needed before the
164
+ full viewer mounts. The parsed document can be passed to `useDocxEditor` later,
165
+ so the source is read and parsed only once.
166
+
167
+ ```tsx
168
+ import {
169
+ createDocxThumbnailRenderer,
170
+ parseDocxForViewer,
171
+ useDocxEditor,
172
+ } from "@extend-ai/react-docx";
173
+
174
+ const document = await parseDocxForViewer(file, {
175
+ loadEmbeddedFonts: false,
176
+ });
177
+ const renderer = createDocxThumbnailRenderer(document, {
178
+ scheduling: "immediate",
179
+ pixelRatio: 1,
180
+ pageIndexes: [0],
181
+ });
182
+ const cover = await renderer.renderPage(0, {
183
+ maxWidth: 240,
184
+ output: "blob",
185
+ });
186
+
187
+ function FullEditor() {
188
+ const editor = useDocxEditor({ document });
189
+ return <DocxEditorViewer editor={editor} />;
190
+ }
191
+ ```
192
+
193
+ `renderPage` supports `canvas`, `blob`, and `imageBitmap` output. Pass `canvas`
194
+ to draw into a caller-owned canvas without an encoding round trip. Its timings
195
+ separate pagination, page mounting, rasterization, and encoding; the parsed
196
+ document timings separately expose file reading, parsing, model construction,
197
+ and embedded-font loading. Use `loadEmbeddedFonts: "defer"` to load fonts later
198
+ through `document.loadEmbeddedFonts()`. The renderer also accepts an existing
199
+ `DocModel` directly when the OOXML package is not needed.
200
+
161
201
  ## Thumbnail Hook
162
202
 
163
203
  The library can expose page thumbnails so you can build your own page strip, mini-map, or navigation UI. Thumbnail painting can render from the live page surface when it is mounted, or from an offscreen one-page surface when viewer virtualization has unmounted that page.
@@ -177,6 +217,7 @@ export function ThumbnailExample() {
177
217
  maxHeightPx: 220,
178
218
  pixelRatio: 2,
179
219
  minRasterIntervalMs: 40,
220
+ pageIndexes: [0, 1, 2, 3, 4, 5],
180
221
  renderWindow: {
181
222
  visiblePageIndexes: [0, 1, 2],
182
223
  prefetchPageIndexes: [3, 4, 5],
@@ -211,6 +252,8 @@ Notes:
211
252
 
212
253
  - Thumbnail canvases can stay attached in a virtualized sidebar; only canvases you mount request paint work.
213
254
  - Use `renderWindow.visiblePageIndexes` for thumbnails currently visible in your sidebar, and `renderWindow.prefetchPageIndexes` to warm nearby pages after visible work.
255
+ - Use `pageIndexes` as a hard render set when unlisted pages must remain metadata-only. It is distinct from the priority hints in `renderWindow`.
256
+ - Call `thumbnail.renderToCanvas(canvas, { scheduling: "immediate" })` for a visible cover that must bypass idle scheduling.
214
257
  - `minRasterIntervalMs` controls repeat renders for the same canvas. Lower values are useful when the consumer already limits thumbnail work to a small visible window.
215
258
  - Thumbnail sizing is bounded by `maxWidthPx` and `maxHeightPx`, so downstream UIs can bias toward portrait thumbnail rails.
216
259
  - Thumbnails use a direct layout/model canvas renderer first; if a page has no usable snapshot, the hook falls back to an isolated offscreen page surface.
Binary file