Bug 137127 - FILEOPEN RTF: Control word \up14 in blank table cell leaks into adjacent cell
Summary: FILEOPEN RTF: Control word \up14 in blank table cell leaks into adjacent cell
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.0.0.3 release
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: filter:rtf
Depends on:
Blocks: RTF-Tables
  Show dependency treegraph
 
Reported: 2020-09-29 13:54 UTC by MikeM
Modified: 2022-04-14 13:44 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments
Two RTF documents demonstrating the issue and a workaround (25.13 KB, application/x-zip-compressed)
2020-09-29 13:54 UTC, MikeM
Details

Note You need to log in before you can comment on or make changes to this bug.
Description MikeM 2020-09-29 13:54:26 UTC
Created attachment 165947 [details]
Two RTF documents demonstrating the issue and a workaround

As I understand it, the \upN control word should only apply within its own bracket-delimited group, but it seems that LibreOffice allows it to leak into the next group under some conditions.  The effect persists until the next group ends.

I have attached a pruned document (Broken.rtf) from a customer that demonstrates the bug, and my modified document (Fixed.rtf) where I simply deleted the \up14 word.  The problem is visible around the "Standardpreis AZV" text.  If you click on it, LibreOffice identifies it as a Superscript.  I think this pushes the rest of the text down, so it no longer fits in the cell.

The group causing the problem looks like this:
{\rtlch\fcs1 \af0\afs20 \ltrch\fcs0 \fs20\up14\lang1031\langfe1033\loch\af0\hich\af0\dbch\af31505\langnp1031\insrsid3419495 \cell }

The problem has been seen on Windows 8.1, Windows Server 2008 R2, and Windows Server 2012 R2.  I have reproduced it with three LibreOffice versions 6.1.2.1, 6.4.6.2, and 7.0.1.2.
Comment 1 Dieter 2021-04-16 16:25:15 UTC
Mike, unfortunately nobody could confirm this bug report during the last months. So I'd like to ask, if it is still valid. Could you please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version.
Comment 2 MikeM 2021-04-30 16:46:17 UTC
Dieter, thank you for responding.  The issue is still present in LibreOffice version 7.0.5.2.  Please observe the difference in the way Broken.rtf and Fixed.rtf are displayed, around the "Standardpreis AZV" text.  For now I cannot test version 7.1.2.2 because the Writer application crashes on my Windows Server 2008 R2 machine.
Comment 3 Buovjaga 2022-04-14 13:40:38 UTC
Reproduced.

I bisected the change in behaviour with Linux bibisect-43all to range https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=934e051b16349a1ab6d2bdd9f03e60aaafcb2ec8..75df7739309ccc5342084e668d9d869620cb3233

I'm not sure the change is a regression as such, so I won't add the keywords.

Arch Linux 64-bit
Version: 7.4.0.0.alpha0+ / LibreOffice Community
Build ID: 9a42c99d7b3e8a8429f14d7d851f3d186fa04594
CPU threads: 8; OS: Linux 5.17; UI render: default; VCL: kf5 (cairo+xcb)
Locale: fi-FI (fi_FI.UTF-8); UI: en-US
Calc: threaded Jumbo
Built on 14 April 2022