Bug 69289 - DATALOSS: column is lost and replaced with previously hidden column after save and reopen when copying a table with hidden columns from calc to writer
Summary: DATALOSS: column is lost and replaced with previously hidden column after sav...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.2.0.2 rc
Hardware: All All
: medium major
Assignee: Miklos Vajna
URL:
Whiteboard: target:4.3.0 target:4.2.4
Keywords: filter:rtf, regression
Depends on:
Blocks:
 
Reported: 2013-09-12 19:51 UTC by Roman Kuznetsov
Modified: 2019-01-29 09:00 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Roman Kuznetsov 2013-09-12 19:51:56 UTC
Create a table in calc 3 columns. Hide the second column. copy the resulting table with two columns in a Skeeter "format RTF." save a text document in a format writer. odt. Close libreoffice. open the saved file. the second column is inserted into the table, replace the hidden column of calc.
Comment 1 Roman Kuznetsov 2013-09-12 19:54:52 UTC
damn Google interpreter. Skeeter == writer
Comment 2 Anatoliy 2013-09-13 04:26:36 UTC
confirm bug
Comment 3 Mike Kaganski 2013-09-15 10:00:59 UTC
Reproducible with LO 4.0.1.1 - 4.1.2.1 under Win7x64, and 4.1.1.2 under Ubuntu 13.04 x64.
Not reproducible with LO 3.6.x and earlier -> regression. In those earlier versions, the second column is inserted with near-zero width, and this persists after save-and-reopen.
4.0.0.0.beta1 - in this version nothing is inserted from clipboard.
4.0.0.3 - the table is inserted from clipboard having all three columns, second is a little narrower, third is a little wider.

Steps to reproduce:
1. Create a new spreadsheet.
2. Put ones into A1,A2, twos into B1,B2, threes into C1,C2.
3. Right-click the B column, click "Hide" in context menu.
4. Select range A1:C2, copy to clipboard.
5. Create a new Text Document.
6. Edit->Paste Special->Formatted text [RTF]. Note that the table have two columns, second has "3" in its cells.
7. Save, close and reopen the text document.

Expected: the table should have two columns, with threes in the second column.

Actual: the table has twos in the second column.
Comment 4 Mike Kaganski 2013-09-16 11:01:32 UTC
Additional information: if the text of a cell in the last column is edited in writer, all editions are also lost upon save and reopen.

Considering this, and the fact that the change is only apparent after closing and reopening document (i.e., delayed and unobvious manifestation), and it's easy to overlook this dataloss, I raise the severity a bit.
Comment 5 Michael Stahl (allotropia) 2013-10-08 22:53:56 UTC
actually it's broken in 4.0.0.3 too but differently
than in 4.0.1.2 and later:

the hidden column is not hidden after pasting as RTF.

... and it is broken when using the new RTF filter
and works with the old one.
Comment 6 Miklos Vajna 2013-12-17 16:11:06 UTC
Isn't this a duplicate of bug 65090?
Comment 7 Mike Kaganski 2013-12-18 03:53:40 UTC
(In reply to comment #6)
Well, only you are knowledgeable enough to answer for sure :)

Bug 65090 is about merged cells; this one is about hidden (i.e. having width=0) columns.

Bug 65090 is about automatic unmerge of those cells; this one looks differently if all versions newer than 4.0.0.3: the hidden column stays hidden upon insert, but appears after save/reopen.

Bug 65090 says nothing about data loss; this one causes an inserted column, previously visible in editor and available for editing, to disappear after save/reopen.

On the other side, these two appeared simultaneously. According to comment 5, they may had been caused by new RTF filter (I had impression that the filter change happened around 3.6?).
Comment 8 Miklos Vajna 2013-12-22 21:10:51 UTC
The RTF import rewrite happened between 3.4 and 3.5.

Anyway, sure, thanks for the confirmation, then I won't just close this as a duplicate of bug 65090; let's see if it still occurs when that will be fixed. :-)
Comment 9 Roman Kuznetsov 2014-01-14 10:12:18 UTC
bug in version 4.2 RC2 is still preserved
Comment 10 Mike Kaganski 2014-01-14 13:15:13 UTC
(In reply to comment #9)
> bug in version 4.2 RC2 is still preserved

Confirm. And so, it's not a duplicate of already fixed bug 65090 (the latter isn't reproducible with 4.2.0.2).
Comment 11 Roman Kuznetsov 2014-01-15 15:43:51 UTC
there is an extension, which solves the problem, copy only the visible cells.
http://extensions.libreoffice.org/extension-center/copy-only-visible-cells
fix this bug so - it is a good idea =)
Comment 12 Miklos Vajna 2014-03-13 18:56:55 UTC
Ah, I see what's the problem here; the second cell has zero width, but Writer has a hardcoded minimal width for cells (can't be smaller than 0.07cm), and the RTF filter should respect that, that's how it worked in LO 3.4.
Comment 13 Commit Notification 2014-03-14 09:56:40 UTC
Miklos Vajna committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=3e2cda224e4119b31d85263ff16a383e693dcbbd

fdo#69289 RTF import: handle cells with zero width



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 14 Miklos Vajna 2014-03-14 10:07:17 UTC
-4-2 review: https://gerrit.libreoffice.org/8585
Comment 15 Commit Notification 2014-03-14 20:49:50 UTC
Miklos Vajna committed a patch related to this issue.
It has been pushed to "libreoffice-4-2":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=3fbab40c16d272e9c34e3923e685945cb8f94c1f&h=libreoffice-4-2

fdo#69289 RTF import: handle cells with zero width


It will be available in LibreOffice 4.2.4.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 16 Roman Kuznetsov 2014-04-17 19:04:43 UTC
when you insert a table from calc with hidden column in the writer, a hidden column visible. extremely inconvenient to correct it manually

LO 4.2.4.1
Comment 17 Mike Kaganski 2014-04-18 08:57:16 UTC
(In reply to comment #16)
What exactly is incorrect for you?

For me, everything in 4.2.4.1 under Win7x64 works as it used to in 3.6.X, so I would say it is VERIFIED FIXED. No more problems you reported in comment 0, hidden columns are inserted with minimal width allowed in writer.

If it works for you as well, but you feel like you need other handling (like, say, removing the hidden column entirely), then you should set this issued back to FIXED and file another enhancement request, as that is clearly different issue.
Only reopen it if the original problem is somehow not resolved for you.

Please provide additional info and set status back to REOPENED or RESOLVED FIXED, as appropriate.

Thank you for participating in LO improvement!
Comment 18 Roman Kuznetsov 2014-04-18 16:21:45 UTC
ok, I create a new bug
Comment 19 Robinson Tryon (qubit) 2015-12-17 12:23:05 UTC
Migrating Whiteboard tags to Keywords: (filter:rtf)
Replace rtf_filter -> filter:rtf.
[NinjaEdit]