Description: When pasting a Psalm with verses numbered via superscript, the numbered lines may be omitted entirely, or may be collected and poorly formatted at end of non-numbered text. Steps to Reproduce: Run provided sample program, click "Load, Highlight 1, Copy", then paste into empty Writer document. On sample program, click "Load, Highlight 2, Copy", then paste into Writer document again. Actual Results: The first paste omits all numbered lines that were copied from the source. The second paste (whose last line is numbered) will first include the unnumbered source content followed by the numbered content, with the first and second of the numbered lines concatenated. Further, the first numbered line is correctly indented and the remaining numbered lines were missing the indent. Expected Results: Writer should have pasted the content in a form roughly matching that shown in the sample program, with the numbered content interspersed with the unnumbered content, and indentation should have been consistent with a small amount on the numbered lines and slightly larger amount on the unnumbered lines. Reproducible: Always User Profile Reset: Yes Additional Info: LibreOfice The Document Foundation LibreOffice is a modern, easy-to-use, open source productivity suite for word processing, spreadsheets, presentations and more. This release was supplied by The Document Foundation. Copyright (c) 20000-2023 LibreOffice contributors. LibreOffice was based on OpenOffice.org Version Information: Version: 7.6.0.3 (X86_64) / LibreOffice Community Build ID: 69edd8b8ebc41d00b4de3915dc82f8f0fc3b6265 CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded
Created attachment 189965 [details] Zipped Win32 executable to create the copy/paste content The attachment is a .zip file containing a Windows 32-bit .exe file for creating the copy/paste errors referenced in the problem description.
Since I encountered the same problem, I'll try to add additional information and correction. The problem is in reading superscript text from RTF, if superscript text is not enclosed in {}. In this case, superscript text either not read at all, or causes a mess (text is displayed out of place). Here is the simple example: {\rtf1 \pard\plain problematic superscript: \super this superscript causes a mess \plain (end of paragraph 1) \par \pard\plain correct superscript: {\super I'm ok in my brackets} \plain (end of paragraph 2)\par} Expected (and displayed in MS Word or WordPad): problematic superscript: this superscript causes a mess (end of paragraph 1) correct superscript: I'm ok in my brackets (end of paragraph 2) In Libre Office: problematic superscript: correct superscript: this superscript causes a mess (end of paragraph 1) I'm ok in my brackets (end of paragraph 2)
Further research shows the issue pertains specifically to superscript (\super ) rather than numbering. Superscript appears to work correctly when the command and text to be superscripted is enclosed in braces. {\rtf1 \pard\plain problematic superscript: \super this superscript causes a mess \plain (end of paragraph 1) \par \pard\plain correct superscript: {\super I'm ok in my brackets} \plain (end of paragraph 2)\par}
Reproduced with comment 2's RTF in: Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: e9374f74385d7dfe77d1902d3d82af20143bc775 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded and in libreoffice-3.5.0rc3. I assume it started with 13c00ce322e78eb4e0f50ab84ded19cd6aae1ded. No repro in OOo 3.3 nor libreoffice-3.4.6rc2 -> regression. Miklos, I've heard you have some history with RTF, what do you think?
Created attachment 190258 [details] sample RTF ...using markup in comment 2.
Created attachment 190259 [details] Screenshot comparing LO 24.2 alpha0+ (left) and MS Office 365 (right)
(In reply to Stéphane Guillou (stragu) from comment #4) > Miklos, I've heard you have some history with RTF, what do you think? Note that an easy way to test RTF paste problems is the SW_DEBUG_RTF_PASTE_FROM environment variable, it allows specifying a path and then if you ctrl-shift-v (paste special) into an empty Writer document, we'll read from that file on paste, not from the system clipboard. That's handy when trying to fix bugs like this.
(In reply to Miklos Vajna from comment #7) > Note that an easy way to test RTF paste problems is the > SW_DEBUG_RTF_PASTE_FROM environment variable, it allows specifying a path > and then if you ctrl-shift-v (paste special) into an empty Writer document, > we'll read from that file on paste, not from the system clipboard. That's > handy when trying to fix bugs like this. Thanks, that's great to know! However, I couldn't make it work with: SW_DEBUG_RTF_PASTE_FROM=/home/stragu/Downloads/test.rtf libreoffice7.6 --writer It would just grab from the system clipboard. Am I missing something?
Sorry, I wasn't specific enough. :-) 1) start up Writer as you described 2) type a character so you have something to cut 3) select the character 4) cut it with e.g. ctrl-x 5) ctrl-shift-v, now you can select rtf This way you trigger the RTF paste, and then that will read from your test.rtf, not from the system clipboard when the env var is specified.
(In reply to Miklos Vajna from comment #9) Great, that works! Same result as with opening the file itself: text in wrong order. I've added your tip to bug 109040 comment 1.