1. Create numbered list in Writer 2. Select the list and copy 3. Paste to Impress Observe the first letter of each list item has been lost. Seen on Linux and Windows. Bibisected with linux-64-25.2 to 2cb039f570379213ffc9469a132f5b24f425b7be tdf#36709 editeng: Layout for font-relative first-line indent First reported in bug 37592 comment 13
Already reported here: https://bugs.documentfoundation.org/show_bug.cgi?id=167020
*** Bug 167020 has been marked as a duplicate of this bug. ***
The root cause is unsafe implicit casting between signed and unsigned ints inside editeng's RTF parser. The SvxLRSpaceItem rework made it possible to represent the very large unsigned first line indent generated by the RTF code, rather than it silently overflowing and being treated as the small negative first line indent that is intended.
Jonathan Clark committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/c93d70db199cc7f89490cf9f34aa43ea67892c52 tdf#168424 editeng: Fix unsafe s/uint implicit cast in RTF parser It will be available in 26.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
This bug caused text to be indented past the edge of the screen. Doing this forces a line break between the first and second characters, giving documents the appearance of losing the first letter when it is still actually present. Although this change fixes the issue reported in bug 37592 comment 13, it does not fix the long-standing bug 37592.
Thanks! I can confirm that does indeed fix the apparently missing first character. Thanks again!
Jonathan Clark committed a patch related to this issue. It has been pushed to "libreoffice-25-8": https://git.libreoffice.org/core/commit/2ef84ee2e6856b5a4729f0f59f8c02f2e1106e9d tdf#168424 editeng: Fix unsafe s/uint implicit cast in RTF parser It will be available in 25.8.2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Jonathan Clark committed a patch related to this issue. It has been pushed to "libreoffice-25-2": https://git.libreoffice.org/core/commit/8323008a38bf23a0a5f04377bdf3ddaaf471117a tdf#168424 editeng: Fix unsafe s/uint implicit cast in RTF parser It will be available in 25.2.7. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.