[Libreoffice-bugs] [Bug 108228] New: Formatting lost for hidden "cells" of a merged cell when document is saved to disk (as .odt)

bugzilla-daemon at bugs.documentfoundation.org bugzilla-daemon at bugs.documentfoundation.org
Mon May 29 16:29:02 UTC 2017


https://bugs.documentfoundation.org/show_bug.cgi?id=108228

            Bug ID: 108228
           Summary: Formatting lost for hidden "cells" of a merged cell
                    when document is saved to disk (as .odt)
           Product: LibreOffice
           Version: 5.3.3.2 release
          Hardware: All
                OS: All
            Status: UNCONFIRMED
          Severity: normal
          Priority: medium
         Component: Writer
          Assignee: libreoffice-bugs at lists.freedesktop.org
          Reporter: lo.bugzilla at minosi.eu

Description:
At present it seems that the document state referring to the "hidden" cells of
a merged cell is kept in memory but is not saved into ODT file. This results in
inconsisted and also undesirable behavior.

Observed with "ODF1.2 Extended (Recommended)" format, both Linux and Windows
x64 builds.

Steps to Reproduce:
1. Create a custom paragraph style
2. Create a new Table, apply the custom style to the whole document + all table
cells
  Note: after this "Applied Styles" view will show only the custom style
3. Merge 2 cells with the custom style into one
4. Save the document
  Note: after this "Applied Styles" view will stil show only the custom style
5. Edit the merged cell formatting (style or manually)
6. Split the merged cell into 2 original cells
  Observe the expected behavior - the "upper" cell retains the formatting and
content of the merged cell. "Lower" cell reverts its original formatting
(before the merge).
7. Merge different 2 cells with the custom style

8. Save and close the document, open it again in Writer
9. Notice that "Applied Styles" view now shows also "Default Style" despite
doing no modification since the save action.
10. Search for "Default Style" via Control-H finds the style as applied to the
"hidden" cell
11. Split back the second merged cell
  Observe unexpected behavior - the "Upper cell retains the merged cell content
and formatting. The "Lower cell(s) formatting is reset to "Default Style".

Actual Results:  
See steps to reproduce.

Expected Results:
Expected behavior:
A1) The save/open of the document does not silently(!) reset the formatting of
the "hidden cells" and stores it in the file.
   => ODF format limitation possibly?

A2) To work around the (hypothetical) ODF limitation, set a policy that when a
cell is split, the resultant cells that are "un-hidden" will inhering the style
of the merged cell at the time of the split. This is the most desirable
actually and is also the user expectation.
   => Should not present any cross-compatibility issues.

C) The in-memory representation is made consistent with the saving behaviour
and the formatting is allways reset once a cell is merged.
   => Makes it bit less practical for user, but would make the "merge" action
at least consistent across save/open ensuring the user "trusts" the application
does not "corrupt" his files.


Reproducible: Always

User Profile Reset: Yes, no effect, tested also on fresh install on Linux x64.

Additional Info:
This is very hard to investigate can cause negative view of the user on LO.

It would be nice to have split cells inherit the formatting of the cell being
split. That would also increase user productivity.

However, the real issue is inconsistency in how in-memory and on-disk data is
handled when working with LO's native document format.

We discovered this bug due to a colleague complaining that someone "corrupted"
his document while collaboratively editing it ...


User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML,
like Gecko) Chrome/58.0.3029.97 Safari/537.36 Vivaldi/1.9.818.49

-- 
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/20170529/5d13af64/attachment-0001.html>


More information about the Libreoffice-bugs mailing list