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.
damn Google interpreter. Skeeter == writer
confirm bug
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.
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.
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.
Isn't this a duplicate of bug 65090?
(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?).
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. :-)
bug in version 4.2 RC2 is still preserved
(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).
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 =)
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.
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.
-4-2 review: https://gerrit.libreoffice.org/8585
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.
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
(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!
ok, I create a new bug
Migrating Whiteboard tags to Keywords: (filter:rtf) Replace rtf_filter -> filter:rtf. [NinjaEdit]