To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=99031 Issue #|99031 Summary|Text Encoded with CR&LF: 0a or 0d alone next to text l |oses text Component|Word processor Version|OOo 2.4.0 Platform|PC URL| OS/Version|Linux Status|UNCONFIRMED Status whiteboard| Keywords| Resolution| Issue type|DEFECT Priority|P2 Subcomponent|editing Assigned to|writerneedsconfirm Reported by|nicklevinson
------- Additional comments from nicklevin...@openoffice.org Mon Feb 9 06:39:43 +0000 2009 ------- To reproduce: 1. In Writer (without JRE (Java Runtime Environment)), create and save a file as Text Encoded with charset 8859-1 and paragraphing as CR&LF. 2. Go somewhere to find qualifying strings. Suggested Web pages are mentioned below and you might make and edit a file using a text editor like gedit 2.10.2 using UTF-8 and a hex editor like KHexEdit 0.8.6. You can paste into gedit and verify with KHexEdit or, probably, you can type into gedit and, with KHexEdit, delete an unwanted nonprinting character and move subsequent characters left one position. 3. Find text strings that end in a hex 0A character or include in the middle a hex 0D character but not both together. 4. Copy the string and paste into the Text Encoded document. 5. The text ending in a lone 0x0A will fail to paste. 6. Save. Close. Open. If the ASCII filter settings dialog asks if you want paragraph breaking at CR, change to CR&LF (that being my default and I want consistency). The text following the lone 0x0D will disappear. 7. Close (without saving). Reopen. If the ASCII filter settings dialog asks if you want paragraph breaking at CR, leave it that way. The text following the lone 0x0D will reappear. I don't use JRE since it crashed my system, but, while I'm not able to use OOo Base, I'm not sure it matters for this problem. When closing and reopening a saved Text Encoded file that has been saved with paragraph breaking at CR&LF and charset 8859-1, some content disappears. The content lost is from a hex 0D to the end of the paragraph containing the character; however, the loss is only if the hex 0D is not followed by hex 0A but is followed by visible text. Preceding text is not affected. No warning of loss is given by OOo; I only found out when I needed to reopen a file. Closely related (and therefore in this report) is that when a text string is followed by a space and the hex 0A character alone, the total string cannot be pasted into the Text Encoded file. Pasting results in nothing appearing. It can, however, be pasted into gedit, which is how I identified the hex character involved (using a hex editor on the file saved in gedit), but copying from gedit and into the Writer Text Encoded file fails. Thus, it doesn't matter from where the string was originally copied (it was originally copied from http://bugzilla.gnome.org/show_bug.cgi?id=570931 (the string "Add me to CC list" but only when selected so as to include a trailing space)). On the other hand, I discovered the hex-0D text-loss problem when copying text from fields in the Bug Report Wizard at <https://bugs.opera.com/wizard/>, as accessed Feb. 7, 2009. Their software apparently adds the 0x0d unsolicited when I paste text into their field; I assume they need it for breaking paragraphs within a field. If, in Writer, a Save command is given without closing the file, text does not disappear at the time of the save (it can be seen using a hex editor), although it will still disappear later. I do not know if the disappearance relative to Writer occurs upon closure or upon reopening, but all reopening was done without having quit Writer and opening as read-only or read-write makes no difference. If the file has been saved but has not been closed, it is possible to recover the text that will be lost after closing by using Undo. Thus, Save per se does not cause the loss. In the hex 0D case, when text is lost while opening with CR&LF but recovered by closing and reopening with only CR set for paragraph breaks, that is not a permanent preservation. If the file is always opened as CR&LF and new text is written at the place of loss, the file is saved and closed, the user quits OOo, and Writer and the file are opened later, the lost content is permanently lost. Expected behavior is that the Text Encoded format using CR&LF and 8859-1 will ignore or delete the nonprinting characters, depending on the character, but not delete any visible characters. It should not add hex 0A to a lonely hex 0D or vice versa, lest that change the page layout by creating a new paragraph break not in the original. (Recovering data: Tangential note: If you're losing data and want it back, try closing without writing or saving, then reopening with the filter settings at whatever the file wants, such as CR or LF. If that doesn't work, try the other setting. If that displays what you want, save-as to a new file name, close, and reopen. If that succeeded, delete the file you no longer need.) Thank you. -- Nick --------------------------------------------------------------------- Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@sw.openoffice.org For additional commands, e-mail: issues-h...@sw.openoffice.org --------------------------------------------------------------------- To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
