GNOME Bugzilla – Bug 431014
Tomboy copy/paste to other applications doesn't support text formatting
Last modified: 2010-07-10 04:12:54 UTC
All of these office applications need to play nice with one another. Tomboy bullets show up like this in OpenOffice Writer when you copy-and-paste New Note 22 \u2022 Line 1 \u2022 Line 2 \u2022 Line 3 I know that OpenOffice can accept bullets because you can copy and paste bullets from Evolution-->OOo just fine. Maybe the copy buffer can be altered after text is highlighted, or another type of bullet used? Other information:
Copied from bug #488077: I love the automatic bullets in Tomboy. However, whenever I copy and paste from a note into another app (such as an Evolution e-mail or text file) the tabbing for the bulleted items is lost. I usually have to go through and manually fix the indents. Is there anyway to do this automatically as part of pasting in the text from tomboy into another app?
*** Bug 488077 has been marked as a duplicate of this bug. ***
Please ignore comment #1 (which came from bug #488077). I misunderstood the report; that bug is not a dupe.
Setting the default assignee and QA Contact to "tomboy-maint@gnome.bugs".
The problem here seems to be that when you copy bulleted items, they are not turned into proper (RTF?) bulleted text ... you even loose the bullets (not the characters, but the state of being) when you copy-paste a list from one note to another.
Created attachment 128876 [details] Screenshot showing Evolution and OOo Writer with pasted bullet list I cannot quite get it. This bug seems to tackle several issues: 1) Bullet lists aren't copied the right way. Sample applications are OOo or Evolution. My screenshot shows that both "work for me", although I have to admit that the indentation is messed up. That's a valid complaint/bug, but so far not the topic of this bug. Should I update it? It would probably end up being a duplicate of the bug above (see sandy's comment) then. So in my opinion the bug title is wrong and needs an update. It works, doesn't crash and shows the bullets. 2) Copying of bullet lists between notes (in the same tomboy instance) doesn't work. I cannot reproduce that, I would like to flag that as invalid. If you can provide more details I'm happy to investigate the issue.
I think you're not understanding what's really happening when "the indentation is messed up" ... it's not the INDENTATION that's gone, it's the STATE OF BEING a bulleted list. Basically, you're trying to copy a bulleted list, but instead you're copying some text with bullet characters in it. The problem is THE SAME PROBLEM: it doesn't matter if you paste into Tomboy or OpenOffice Writer or Word ... the stuff on the clipboard is just text with bullet characters in it, not a list. You need to have some sort of rtf or html formatting that can preserve the list -- and when you paste it in, you need to support that too. For example, in the original note, if you write a list and look at the SOURCE (that is, the .note file) you might have something like this: <note-content version="0.1"> <list> <list-item dir="ltr">this is a list</list-item> <list-item dir="ltr">with three items in it <list> <list-item dir="ltr">plus these two</list-item> <list-item dir="ltr">sub-items</list-item> </list> </list-item> <list-item dir="ltr">Yay, last item</list-item> </list> </note-content> But when you paste it, the new note just has this: <note-content version="0.1"> • this is a list • with three items in it ∘ plus these two ∘ sub-items • Yay, last item </note-content> Notice that there are actual bullet charaters? If you try to apply list formatting using the menu or the ALT+LEFT-ARROW, you'll get double bullets, because the first character of the list item will be that bullet character.
Thank you for the long and great response. You were right, I didn't get it so far, I assumed that something was broken, crashing etc. You did a great job to update me and to lecture me what the real problem is. Thanks, I'll look into the issue if I can. It seems completely untrivial for me so far, but I might be wrong. Again.
(In reply to comment #8) Yeah, it's extremely untrivial. Root cause: Tomboy copies NO FORMATTING AT ALL to the clipboard. I don't know how the Linux clipboard works (even from .Net), but in Windows, if you're using the clipboard through, say, System.Windows.Clipboard (WPF) or System.Windows.Forms.Clipboard (WinForms) ... you can get and set text with various formats: Text, UnicodeText, Rtf, Html, CommaSeparatedValue ... and in WPF: Xaml When a .Net app copies text, it basically always sets the "Text" and "UnicodeText" formats: System.Windows.Forms.Clipboard.SetText("whatever") Which is basically the same as doing: System.Windows.Forms.Clipboard.SetText("whatever", System.Windows.Forms.TextDataFormat.Text) System.Windows.Forms.Clipboard.SetText("whatever", System.Windows.Forms.TextDataFormat.UnicodeText) But if you want to preserve the formatting, you must **also** set either Rtf or Html (or Xaml, in WPF). That is: set the text, in case it gets pasted into notepad or a console ... but also set a formatted text option so when you paste, it can be beautiful. Tomboy doesn't ever do that. I blame your editing widget ;) I don't know why it is that if you copy-paste WITHIN a single Tomboy note, everything is fine -- Tomboy's obviously cheating here, because in reality, there's no formatting information on the clipboard at all. This means the bug is MUCH MUCH BIGGER: If you copy anything formatted, and paste it either to another app, or to another Tomboy note, all of the formatting which can't be expressed as just spaces and text characters is lost. It's not just lists, it's italics, bold, strikeout, size ... everything. Ultimately the solution seems both simple and extremely complicated. "All" you have to do is set the HTML format on the clipboard. The problem, of course, is that to copy the formatting, you have to convert your proprietary xml into html. I'm sure there are lots of xsl stylesheets for that floating around everyone's private stashes ... -- Joel P.S.: Just for fun, I did a little more testing ... if you copy from Firefox to MS Word, the lists are preserved (of course). If you pull out PowerShell and start exploring, there is no RTF data, just HTML. I'm going to paste an example copied from my POwerShell buffer, so here's the PowerShell syntax, in case you don't know (the [##]: at the front is my prompt) [This] is a namepsace and class, and :: is a static member, and enums can be specified as quoted strings. [21]: [System.Windows.Clipboard]::GetText("Rtf") [22]: [System.Windows.Clipboard]::GetText("Text") * Ordered o Ordered LI types o Ordered types o Start * Unordered o Unordered LI types [23]: [System.Windows.Forms.Clipboard]::GetText("html") Version:0.9 StartHTML:00000153 EndHTML:00000785 StartFragment:00000187 EndFragment:00000749 SourceURL:http://www.mountaindragon.com/html/lists.htm <html><body> <!--StartFragment--><ul> <li><a href="http://www.mountaindragon.com/html/lists.htm#order">Ordered</a> <ul> <li><a href="http://www.mountaindragon.com/html/lists.htm#orli">Ordered LI types</a> </li><li><a href="http://www.mountaindragon.com/html/lists.htm#ortype">Ordered types</a> </li><li><a href="http://www.mountaindragon.com/html/lists.htm#olstart">Start</a> </li></ul> </li><li><a href="http://www.mountaindragon.com/html/lists.htm#unorder">Unordered</a><ul> <li><a href="http://www.mountaindragon.com/html/lists.htm#unorli">Unordered LI types</a></li></ul> </li></ul><!--EndFragment--> </body> </html>
I appreciate the comments on this issue. Users do not understand the complexities of copy and paste (like we all do). Their view is that if you paste from one product into another, the resulting paste is identical to what they copied. When you spend time teaching users to use copy-and-paste and not re-type things, it probably should work. :)
I just tested this on SLED 11, and the list symbols copied into OOo Writer just fine for me.
Ok, I guess I should have read all the comments; sorry for the noise.
Created attachment 147703 [details] [review] Add a HTML serializer to the NoteBuffer, which adds that to its list of mimetypes it can give to apps via the clipboard This patch depends on a fix to Gtk# for https://bugzilla.novell.com/show_bug.cgi?id=555495
Things to test: * Pasting note text into OO.o * Pasting note text into Evolution (HTML and plain text mode) * Pasting note text into another note (to make sure we didn't break anything) Desired features: * Use same technique to provide markdown-like text for text/plain pasting I am more than willing to manually bind the problematic gtk+ function (maybe add something to gtk-sharp-beans) if we need to. Thanks for the patch, Gabriel. I'll give it a real review soon.
Created attachment 147946 [details] [review] Tested, improved patch I actually fixed the Gtk# bug, and so was able to test and improve the prior patch. This one handles internal, bug, and evo links better. I've tested it with Evo plain compose and html compose, and OOo writer, and copying between notes. I'm seeing a crash when copying text into an empty note, but I'm seeing the crash without my patch too (so probably not related).
Created attachment 147947 [details] Screenshot showing rich copy working in Evo (plain + html composers) and OOo Writer
Sandy: I think you'd have to include the entire TextBuffer binding, which is probably unreasonable to do.
Created attachment 147994 [details] [review] Same patch, except uses introspection to be compatible with Gtk# with or without the patch I've tested compiling this with Gtk# w/o the TextBufferSerializeFunc patch and running it on that Gtk# and the fixed one, and vice versa.
To be clear, if Gtk# isn't fixed, this patch won't add rich copy support; the current behavior will be unchanged.
(In reply to comment #18) > Sandy: I think you'd have to include the entire TextBuffer binding, which is > probably unreasonable to do. Why? We've done it before when we needed fixes that were in releases not available on most distros (panel applet bindings, for example). With no gtk-sharp releases on the horizon, I don't see much risk here. (In reply to comment #19) > Created an attachment (id=147994) [details] [review] > Same patch, except uses introspection to be compatible with Gtk# with or > without the patch Excellent, this means we can get this pushed to master soon. At this point my only real issue with the patch is the duplicated xslt. Assuming they're actually identical, at the very least I'd like the HTML Export add-in to stop including its copy, and instead load the one included in Tomboy.exe. If they're not identical, we should probably fix that somehow. (In reply to comment #16) > I'm seeing a crash when copying text into an empty note, but I'm seeing > the crash without my patch too (so probably not related). Please file a bug for this; it is news to me.
(In reply to comment #21) > (In reply to comment #18) > > Sandy: I think you'd have to include the entire TextBuffer binding, which is > > probably unreasonable to do. > > Why? We've done it before when we needed fixes that were in releases not > available on most distros (panel applet bindings, for example). With no > gtk-sharp releases on the horizon, I don't see much risk here. Ok, I don't have as much experience doing that, was concerned it could be quite an undertaking. > Excellent, this means we can get this pushed to master soon. At this point my > only real issue with the patch is the duplicated xslt. Assuming they're > actually identical, at the very least I'd like the HTML Export add-in to stop > including its copy, and instead load the one included in Tomboy.exe. > > If they're not identical, we should probably fix that somehow. They're not identical, for several reasons: 1) The XML produced by NoteBufferArchiver.Serialize is not an entire XML document with the tomboy elements (note-content, for example) namespaced. This could probably be changed, but is the status quo. 2) The SerializeToHtml function can serialize a selection of the note, not it's entirety. The ExportToHtml addin's HTMl includes the note title, etc - when that's not necessarily part of the user's selection. 3) ExportToHtml is producing HTML to be consumed by a browser, so it's embedded image for Evolution e-mail links works; this doesn't show up properly when pasted into OOo Writer 4) ExportToHtml can export links and content of linked notes; I don't think this makes sense when copying 5) The ExportToHtml.xsl includes a <title> and <style> section that aren't appropriate for copying
Created attachment 148015 [details] [review] Updated patch with some xsl improvements Turn newlines into <br>, and don't treat the first line of the note-content specially since we can't assume it's the first line of the note (and therefore should be <h1>).
Review of attachment 148015 [details] [review]: I haven't had a chance to test this with a fixed gtk#, but there are at least no regressions. Thanks again!
Closing this bug. I may experiment with bundling the fixes to gtk#, but it may be too big a hassle.
Hi - is this feature supposed to work in Windows? I just installed GTK sharp 2.12.10 (made available for windows today in novell's site) and copy/paste from a note to a) outlook b) word c) openoffice writer strips out the formatting as always. Bold, underline, and indentation are all lost. Is this due to "windows limitations" or is it a bug?
Bug opened - https://bugzilla.gnome.org/show_bug.cgi?id=624002