Bug 127742 - Cell with Arabic (only?) text that starts with LTR character is rendered incorrectly
Summary: Cell with Arabic (only?) text that starts with LTR character is rendered inco...
Status: RESOLVED INSUFFICIENTDATA
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
5.2.5.1 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-09-24 13:00 UTC by J. R. Schmid
Modified: 2020-07-11 03:42 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments
Screenshot of example document showing correct (cell A1) alongside broken (cell A2) Arabic rendering (16.58 KB, image/png)
2019-09-24 13:01 UTC, J. R. Schmid
Details
Document capable of showing correct vs. broken Arabic rendering if doubleclicking either cell A1 or A2 (7.92 KB, application/vnd.oasis.opendocument.spreadsheet)
2019-09-24 13:01 UTC, J. R. Schmid
Details
Screenshot of example document showing correct (cell A1) alongside broken (cell A2) Arabic rendering (37.57 KB, image/png)
2019-09-24 13:31 UTC, J. R. Schmid
Details
Document capable of showing correct vs. broken Arabic rendering if doubleclicking either cell A1 or A2 (10.33 KB, application/vnd.oasis.opendocument.spreadsheet)
2019-09-24 13:33 UTC, J. R. Schmid
Details
How it looks in LibreOffice 6.5 master (29.60 KB, image/png)
2019-12-11 13:38 UTC, Xisco Faulí
Details

Note You need to log in before you can comment on or make changes to this bug.
Description J. R. Schmid 2019-09-24 13:00:08 UTC
Description:
What it says in the summary.

There is a screenshot here at https://bug-attachments.documentfoundation.org/attachment.cgi?id=154293 that shows the problem in the wild. The first comment will also provide an additional test screenshot that might be helpful along with an example document.

This issue *could* be a duplicate of #116641, but is for Calc (the other bug is for Impress and there seems to be no way of having a bug marked as affecting more than one component). Earliest affected version is as far as we know; could be earlier.

Marking as "Normal" and not "Trivial", because, although it might seem cosmetic to someone who hasn't learned to read the text of the RTL script being used, the only "workaround" for someone who needs to read it is to keep copying and pasting things out of and into a text editor.

Steps to Reproduce:
1. Install LO, for example the latest version
2. Open Calc
3. Type an English word into some cell, hit space, switch keyboard layouts, then type some Arabic characters.

Actual Results:
See screenshot and compare cells A1 (not in editing mode; correct rendering) and A2 (in editing mode, incorrect rendering) as well as the editing bar above the spreadsheet view.

Expected Results:
Cells A1 and A2 should look the same instead.


Reproducible: Always


User Profile Reset: Yes


OpenGL enabled: Yes

Additional Info:
Providing the information from the version that testing started with, as supplied by my distribution.

Version: 6.3.1.2
Build ID: 30(Build:2)
CPU threads: 2; OS: Linux 4.9; UI render: default; VCL: gtk3; 
Locale: de-DE (en_GB.utf8); UI-Language: en-GB
Calc: threaded

There is only one Windows (10) machine NOT exhibiting the problem. It has had Version 5.2.5.1 installed since the day of that version's release, so, basically, since forever.

Other versions tested, downloaded from their respective websites, all exhibit the same problem:

- 5.2.5.1 on Solus OS
- 5.2.5.1 on Ubuntu 18.04
- 5.2.5.1 on LinuxMint Sylvia
- 6.0.7 on LinuxMint Sylvia
- 6.2.7 on Solus OS
- 6.2.7 on Windows 10
- 6.3.1 on Windows 10

NOT exhibiting the problem on either Linux or Windows was Apache OpenOffice 4.1.7.

OpenGL was disabled on one Linux machine while it was running 5.2.5.1. Disabling OpenGL did not improve the rendering.
Comment 1 J. R. Schmid 2019-09-24 13:01:04 UTC
Created attachment 154436 [details]
Screenshot of example document showing correct (cell A1) alongside broken (cell A2) Arabic rendering
Comment 2 J. R. Schmid 2019-09-24 13:01:54 UTC
Created attachment 154437 [details]
Document capable of showing correct vs. broken Arabic rendering if doubleclicking either cell A1 or A2
Comment 3 J. R. Schmid 2019-09-24 13:31:46 UTC
Created attachment 154441 [details]
Screenshot of example document showing correct (cell A1) alongside broken (cell A2) Arabic rendering
Comment 4 J. R. Schmid 2019-09-24 13:33:04 UTC
Created attachment 154442 [details]
Document capable of showing correct vs. broken Arabic rendering if doubleclicking either cell A1 or A2
Comment 5 Xisco Faulí 2019-12-11 13:38:59 UTC
Created attachment 156491 [details]
How it looks in LibreOffice 6.5 master
Comment 6 Xisco Faulí 2019-12-11 13:39:19 UTC
it looks fine 

Version: 6.5.0.0.alpha0+
Build ID: b9d6ea1dd7541c4bd866571f9e3f0aa894687c07
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US
Calc: threaded

Could you please try to reproduce it with a master build from http://dev-builds.libreoffice.org/daily/master/ ?
You can install it alongside the standard version.
I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the master build
Comment 7 QA Administrators 2020-06-10 03:48:24 UTC Comment hidden (obsolete)
Comment 8 QA Administrators 2020-07-11 03:42:31 UTC
Dear J. R. Schmid,

Please read this message in its entirety before proceeding.

Your bug report is being closed as INSUFFICIENTDATA due to inactivity and
a lack of information which is needed in order to accurately
reproduce and confirm the problem. We encourage you to retest
your bug against the latest release. If the issue is still
present in the latest stable release, we need the following
information (please ignore any that you've already provided):

a) Provide details of your system including your operating
   system and the latest version of LibreOffice that you have
   confirmed the bug to be present

b) Provide easy to reproduce steps – the simpler the better

c) Provide any test case(s) which will help us confirm the problem

d) Provide screenshots of the problem if you think it might help

e) Read all comments and provide any requested information

Once all of this is done, please set the bug back to UNCONFIRMED
and we will attempt to reproduce the issue. Please do not:

a) respond via email 

b) update the version field in the bug or any of the other details
   on the top section of our bug tracker

Warm Regards,
QA Team

MassPing-NeedInfo-FollowUp