Issue 62949 - Pasting frame inserts RTF content as ASCII text from clipboard
Summary: Pasting frame inserts RTF content as ASCII text from clipboard
Status: CONFIRMED
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:
URL:
Keywords: needmoreinfo
Depends on:
Blocks:
 
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: ---


Attachments

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:

------------------------
{\rtf1\ansi\deff0\adeflang1025
{\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;}}
{\colortbl;\red0\green0\blue0;\red128\green128\blue128;}
{\stylesheet{\s1\rtlch\afs24\lang1023\ltrch\dbch\langfe1023\hich\fs24\lang1023\loch\fs24\lang1023\snext1

Normal;}
{\s2\sb120\sa120\rtlch\afs20\lang1023\ai\ltrch\dbch\langfe1023\hich\f1\fs20\lang1023\i\loch\f1\fs20\lang1023\i\sbasedon1\snext2

caption;}
{\s3\sb120\sa120\rtlch\afs20\lang1023\ai\ltrch\dbch\langfe1023\hich\f1\fs20\lang1023\i\loch\f1\fs20\lang1023\i\sbasedon2\snext3

Photo;}
{\*\cs5\rtlch\afs24\lang1023\ltrch\dbch\langfe1023\hich\f2\fs20\lang1023\i\b\loch\f2\fs20\lang1023\i\b

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!

Thanks...
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
selection"

->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
incorrect.

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.

Thanks!

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
.