[Libreoffice-bugs] [Bug 144521] FILESAVE: Stop storing empty cells
bugzilla-daemon at bugs.documentfoundation.org
bugzilla-daemon at bugs.documentfoundation.org
Tue Sep 28 15:45:02 UTC 2021
https://bugs.documentfoundation.org/show_bug.cgi?id=144521
Mike Kaganski <mikekaganski at hotmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |erack at redhat.com
--- Comment #10 from Mike Kaganski <mikekaganski at hotmail.com> ---
(In reply to robert from comment #9)
> Unzip all three ODS files, format the main "content.xml" of all three with
> xmllint, compare the files with WinMerge.
LOL. Compare something like *that* with WinMerge? Not everyone has that much
time.
Every report should be reasonable, allowing one to see the problem.
Anyway, likely all that was about something as easy as:
1. Create a new spreadsheet.
2. Put "1" to C2.
3. Put "1" to D4.
4. Save and inspect content.xml, to see that:
a. It has first two rows with all four repeated columns:
> <table:table-row table:style-name="ro1"
table:number-rows-repeated="2">
> <table:table-cell table:number-columns-repeated="4"/>
> </table:table-row>
b. It has second row with two trailing repeated columns:
> <table:table-row table:style-name="ro1">
> <table:table-cell/>
> <table:table-cell office:value-type="float"
office:value="1"
calcext:value-type="float">
> <text:p>1</text:p>
> </table:table-cell>
> <table:table-cell table:number-columns-repeated="2"/>
> </table:table-row>
c. It has the third row without trailing repeated columns.
One might notice that all three rows have four elements each. One may conclude
that there is one algorithm, taking the used rectangle, and outputting the rows
one by one, merging completely empty rows and columns into a single "repeated"
element.
One may imagine that not having those in the file would be problematic. But (1)
having more code to avoid that would make more code that can have bugs; (2) it
is unclear how robust that would be, given that e.g. ODF tells [1]:
> The behavior of a consumer when a cell is referenced but not declared is implementation-dependent.
which means that there *might* be complications when some cells are not
declared in the file - if not for LibreOffice (are we sure in that?), then for
some other standard-compliand consumers that have their
"implementation-dependent" behavior for such case.
Anyway, I assume this issue in its current form, without anything specific,
filled with rant, emotions, subjective opinions, but no manageable stuff, to be
INVALID.
I'm not closing it; maybe erAck has something to say?
[1]
https://docs.oasis-open.org/office/OpenDocument/v1.3/os/part3-schema/OpenDocument-v1.3-os-part3-schema.html#__RefHeading__1415630_253892949
--
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20210928/ec9d27cc/attachment.htm>
More information about the Libreoffice-bugs
mailing list