Apache OpenOffice (AOO) Bugzilla – Issue 103463
Special character formatting lost when copy/past or 'Save As' to WordPad/RTF format
Last modified: 2017-05-20 11:18:17 UTC
Formatting of characters confused/lost when trying to do a 'Save As...' to the WordPad RTF format. Problem can occur just from doing a copy/paste from/to OO/WordPad (in other words, using the clipboard to transfer data). 1. Start OpenOffice 3.1 2. Select the 'Insert/Special Character...' menu/submenu. The 'Special Characters' dialog will open. 3. Select "Symbol" from the 'Font' drop down. 4. Scroll down and then click on the U+F0B7 bullet symbol (10 rows down, 8th column over). 5. Select the OK button on the "Special Characters" dialog. The bullet looking character will be typed into the OpenOffice document by OpenOffice. 6. Back at the document, Highlight the bullet character, and either press Ctrl+C or menu option 'Edit/Copy'. 7. Back in Windows, start WordPad (for Windows XP its START/All Programs/Accessories/WordPad). 8. In WordPad, either press Ctrl-P or menu option 'Edit/Paste'. 9. You should see that a Wingdings/12/Symbol character has been pasted in. The actual character looks like a clock showing 1pm. This is the wrong character. 10. Highlight the character in WordPad, then from the 'Font' drop down, select the 'Symbol' font. 11. You should now see the same character formatting representation that was originally entered in the OpenOffice document. If, instead of doing steps 6-11, you do a 'File/Save As...' from OpenOffice, and select a file type of 'Rich Text Format (.rtf)', and save the document, then reopen the saved document in WordPad, you will see that the symbol being displayed is the incorrect Wingdings symbol of a clock at 1pm. If you instead open the same previously saved rtf document in OpenOffice 3.1, you will see the character is formatted as a Times New Roman 12 character.
Issue is confirmed Windows: XP SP3 OOo: OOo-Dev_OOO310_m15_Win32Intel
No data loss, no regression (happens in 2.4 too) -> P3. HDU: Please have a look.
I would argue the switch of priority of P2 to P3, based on this "Measures/Examples" in the P2 section... --> "User data is corrupted in an easy-to-encounter way; e.g. saving a document corrupts the resulting file and renders it unusable" The saved RTF file (remember this bug affects copy/paste to clipboard AND "Save As..." to RTF file type) is corrupted and unusable, because its visually incorrect and cannot be used in a production environment. The physical file can be opened, but if you can't use the file, then why bother opening the file? For compatibility reasons, its important to be able to save to a RTF format (as well as being able to trust copy/paste for moving subsections of a document into other proprietary products like bug tracking systems, etc.), and not being able to do so will cause us to fall back to non-OpenOffice-based word processing applications. :(
This problem is to be found in RTF filter, not in font handling. Reassigning to HBRINKM.
I cannot reproduce with using ooo320-m19.
Reset assigne to the default "issues@openoffice.apache.org".