Issue 62949 - Pasting frame inserts RTF content as ASCII text from clipboard
Summary: Pasting frame inserts RTF content as ASCII text from clipboard
Alias: None
Product: Writer
Classification: Application
Component: editing (show other issues)
Version: OOo 2.0.2
Hardware: PC (x86_64) Linux, all
: P3 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
Keywords: needmoreinfo
Depends on:
Reported: 2006-03-09 02:08 UTC by ednisley
Modified: 2013-08-07 14:38 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Note You need to log in before you can comment on or make changes to this issue.
Description ednisley 2006-03-09 02:08:19 UTC
SuSE 10.0, KDE

Insert a jpg image from a file. Right-click on the image, add a caption, 
and set up the borders. Select the overall frame containing the image 
and caption, Ctrl-C to copy, click on another page, then 
Ctrl-V to paste. The result is a blizzard of ASCII text 
that seems to describe the image and caption, but it's 
surely not what happened in previous versions!

This will also occur after manually inserting a blank frame with nothing in it
at all, then copy/pasting the frame. It -seems- to occur more frequently with a
frame containing an image: almost always as opposed to frequently.

A snippet from one such episode:

{\fonttbl{\f0\froman\fprq2\fcharset0 Thorndale AMT{\*\falt 
Times New Roman};}{\f1\fswiss\fprq2\fcharset0 Helvetica;}
{\f2\fswiss\fprq2\fcharset0 Helvetica;}
{\f3\fnil\fprq2\fcharset0 Albany AMT{\*\falt Arial};}
{\f4\fnil\fprq2\fcharset0 Lucidasans;}}




Caption characters;}

Of course, once in a while the frame pastes perfectly, but the failure is
entirely reproduceable.

This happened first with the SuSE 10.0 packages of OO 2.0, which I removed and
manually replaced with the (new today!) 2.0.2 version: same failure. It did work
correctly in previous versions of OO Writer; I used it a lot.

This is something of a showstopper for me, because I'm putting a book together
(yes, using a Master Document) and need identical frames for the illustrations.
Manually reconfiguring every single default frame to the correct appearance will
get -really- tedious after the first few hundred pages!

Comment 1 michael.ruess 2006-03-09 07:35:46 UTC
MRU->ES: I cannot reproduce this on Windows. Please have a look on Linux.
It looks that the RTF content will be inserted as plain text from Clipboard in
some cases.
Comment 2 linuxjoe 2006-03-25 20:50:19 UTC
I was unable to reproduce on Ubuntu or Fedora Core 4
Comment 3 eric.savary 2006-03-27 14:35:48 UTC
I could reproduce it on SuSE 10 but only when:
- klipper is ON
- klipper is configured with "Synchronize contents of the clipboard and the

->ednisley: can you confirm this?
Comment 4 ednisley 2006-03-27 15:22:13 UTC
After a few minutes of cutting-and-pasting frames and images, that seems to be
correct: "synchronized" causes pasting failures, "separate" does not. However,
after pasting fails in sync mode, it continues to fail in separate mode.

The Klipper setting when I started testing was "separate". I believe I had
changed this while I was diagnosing the problem originally and did not restore
it. I -think- Writer continued to paste RTF after I changed to separate, but I
cannot be sure. In fact, I may be remembering that I tried pasting after
changing this mode and, as above, it continued to fail because the clipboard was

I tried two original documents I was having problems with and frame
cut-and-paste works dependably in "separate" mode. I think it's safe to say that
the problem incidence is much, much, much lower and that may be a completel
work-around... previously, it failed routinely, as it still does in "sync" mode.

I'll leave it set to "separate" and report back if pasting fails.


Comment 5 eric.savary 2006-05-09 09:02:11 UTC
ES->AMA: please have a look.
Comment 6 eric.savary 2006-05-09 09:02:54 UTC
Comment 7 eric.savary 2006-05-19 14:01:53 UTC