HtmlConfig::spreadsheet_limit (10000x500 by default) drops every cell past it and writes
nothing in its place: the <table> simply ends, and Html::translate reports nothing back to
the embedder. A reader whose sheet is longer than that sees a document that looks complete and
is not, and an embedder cannot tell them otherwise.
This came out of a user complaint on Android, where the app inherits the default. Note the
limit is not the max-size-declaration case - sheet_content only counts cells with a child,
so an ODS declaring the full 1048576 rows with fifty used ones renders fifty. What is left
hitting the limit is a sheet that genuinely carries more than 10000 rows, which is an ordinary
export rather than a pathological file.
What would help
1. Report what was cut. html::translate_sheet (src/odr/internal/html/document_element.cpp:82)
already computes the content extent and the clamped end_row/end_column and then discards
both. Two things could come out of that for free:
- a marker in the output - a trailing row saying which rows are not shown - so a reader looking
at the page knows;
- the numbers on the returned
HtmlViews/HtmlPage, so an embedder can say so in its own UI
and offer to render the sheet in full.
The second is what OpenDocument.droid wants: a bar over the document saying the sheet was cut,
with a button that re-renders it with spreadsheet_limit unset. Measuring it app-side is
possible (Sheet::content(std::nullopt)) but needs a Document opened purely to measure -
a second parse for a read-only format - to re-derive something translation just computed.
2. Consider budgeting cells rather than a rectangle. 10000x500 is 5M cells if actually
filled, which no WebView survives, while 5 columns x 100000 rows is 500k cells and a common
shape. As a rectangle the limit punishes tall-narrow sheets to protect against wide ones.
Capping the product of the content extent - and deriving the row cut from the real column
count - would be the same protection while letting most sheets that hit the limit today
through in full.
(1) is worth having on its own, whatever happens to (2): silent loss is the complaint, not
the number.
HtmlConfig::spreadsheet_limit(10000x500 by default) drops every cell past it and writesnothing in its place: the
<table>simply ends, andHtml::translatereports nothing back tothe embedder. A reader whose sheet is longer than that sees a document that looks complete and
is not, and an embedder cannot tell them otherwise.
This came out of a user complaint on Android, where the app inherits the default. Note the
limit is not the max-size-declaration case -
sheet_contentonly counts cells with a child,so an ODS declaring the full 1048576 rows with fifty used ones renders fifty. What is left
hitting the limit is a sheet that genuinely carries more than 10000 rows, which is an ordinary
export rather than a pathological file.
What would help
1. Report what was cut.
html::translate_sheet(src/odr/internal/html/document_element.cpp:82)already computes the content extent and the clamped
end_row/end_columnand then discardsboth. Two things could come out of that for free:
at the page knows;
HtmlViews/HtmlPage, so an embedder can say so in its own UIand offer to render the sheet in full.
The second is what OpenDocument.droid wants: a bar over the document saying the sheet was cut,
with a button that re-renders it with
spreadsheet_limitunset. Measuring it app-side ispossible (
Sheet::content(std::nullopt)) but needs aDocumentopened purely to measure -a second parse for a read-only format - to re-derive something translation just computed.
2. Consider budgeting cells rather than a rectangle. 10000x500 is 5M cells if actually
filled, which no WebView survives, while 5 columns x 100000 rows is 500k cells and a common
shape. As a rectangle the limit punishes tall-narrow sheets to protect against wide ones.
Capping the product of the content extent - and deriving the row cut from the real column
count - would be the same protection while letting most sheets that hit the limit today
through in full.
(1) is worth having on its own, whatever happens to (2): silent loss is the complaint, not
the number.