State the spreadsheet limit rather than inheriting it

[andiwand]

CoreLoader.host() states every other thing it wants from HtmlConfig — embedImages, relativeResourcePaths, textDocumentMargin, editable, colorScheme — and left this one to whatever the core's default happened to be. The numbers are unchanged, 10000 rows by 500 columns and trimmed to content first, so nothing renders differently today; they are just numbers this app chose now, and a release that reshuffles HtmlConfig cannot move them without a line changing here.

Worth stating because of what the limit does: cells past it are dropped and nothing is written in their place, so the <table> simply ends and the reader sees a document that looks complete and is not. That is what a user complained about.

It is not the max-size case it is often taken for. sheet_content only counts a cell that has a child, so an ODS declaring the full 1048576 rows with fifty used ones renders fifty — spreadsheetLimitByContent is what handles those. What is left hitting the limit is a sheet that genuinely carries more than 10000 rows, which is an ordinary export.

The silent part is the core's to fix, and is opendocument-app/OpenDocument.core#740: translation computes the content extent and the clamped end row and discards both, so it could mark the cut in the output and report the numbers to the embedder. Once it does, this app can put a bar over a cut sheet with a button that renders it in full — DocumentRequest already carries exactly this kind of after-the-fact answer next to editable and password, and reload already re-renders from the cached copy without losing the tab or the reading position. None of that is here.

🤖 Generated with Claude Code