[upstream] Automatic cell alignment in Calc breaks with bidi-neutral characters

Bug #1793126 reported by Miikka-Markus Alhonen
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
LibreOffice
Confirmed
Medium
libreoffice (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

Calc seems to assign the alignment of any particular text cell based on the contents of the cell: if the first character is a LTR character, the cell is aligned to the left, and if the first character is RTL, the cell is aligned to the right. This is desirable behavior but it breaks when the first character is neutral, i.e. a character that behaves as RTL in an RTL context and as LTR in a LTR context.

See the attached screenshot where cell A1 "abc" is automatically aligned to the left and cell A2 "ابت" to the right. When I surround these strings with parentheses, which are bidi-neutral characters, in A3 and A4, both are aligned to the left. For some reason, even font metrics break with this assignment, as the last character of the Arabic string overlaps visually with the closing parenthesis (I think this is a separate issue and I’ll file it as such).

In column C, I have copied the contents of column A but changed the directionality setting of cell C4 manually to RTL through Format Cells > Text direction. Here the cell is properly aligned to the right and the closing parenthesis does not overlap with the last character of the string.

According to the Unicode standard, neutral characters should not affect directionality, and that’s what I would expect as a user, too. I think the best solution would be for Calc to skip all neutral characters in the beginning of the string and just consider the first strong character for cell alignment. Even better, Calc could use this heuristics to assign full text directionality for the cell, not just change alignment. Right now, if you start the cell with an RTL character followed by a LTR inset and then continue with RTL again, the substrings are ordered as in a LTR context ("FIRST second THIRD"), not as in true RTL ("THIRD second FIRST").

Description: Ubuntu 18.04.1 LTS
Release: 18.04

  Installed: 1:6.0.3-0ubuntu1
  Candidate: 1:6.0.3-0ubuntu1
  Version table:
 *** 1:6.0.3-0ubuntu1 500
        500 http://mr.archive.ubuntu.com/ubuntu bionic/main amd64 Packages
        100 /var/lib/dpkg/status

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: libreoffice-calc 1:6.0.3-0ubuntu1
ProcVersionSignature: Ubuntu 4.15.0-33.36-generic 4.15.18
Uname: Linux 4.15.0-33-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.3
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Tue Sep 18 11:26:18 2018
InstallationDate: Installed on 2017-02-13 (582 days ago)
InstallationMedia: Ubuntu 16.10 "Yakkety Yak" - Release amd64 (20161012.2)
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=C
 SHELL=/bin/bash
SourcePackage: libreoffice
UpgradeStatus: Upgraded to bionic on 2018-05-31 (109 days ago)

Revision history for this message
Miikka-Markus Alhonen (malhonen) wrote :
Revision history for this message
Miikka-Markus Alhonen (malhonen) wrote :

I submitted a separate report for the font metrics problem at https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1793127

Revision history for this message
Olivier Tilloy (osomon) wrote :

I can reliably reproduce the issue with libreoffice 6.0.3.2 on bionic, and with the 6.1.1.2 snap on cosmic.

@Miikka, would you mind filing an upstream bug report and linking to it here? Thanks!

Changed in libreoffice (Ubuntu):
status: New → Confirmed
Revision history for this message
In , Miikka-Markus Alhonen (malhonen) wrote :

Description:
Calc seems to assign the alignment of any particular text cell based on the contents of the cell: if the first character is a LTR character, the cell is aligned to the left, and if the first character is RTL, the cell is aligned to the right. This is desirable behavior but it breaks when the first character is neutral, i.e. a character that behaves as RTL in an RTL context and as LTR in a LTR context.

See the attached screenshot where cell A1 "abc" is automatically aligned to the left and cell A2 "ابت" to the right. When I surround these strings with parentheses, which are bidi-neutral characters, in A3 and A4, both are aligned to the left. For some reason, even font metrics break with this assignment, as the last character of the Arabic string overlaps visually with the closing parenthesis (I filed this as a separate issue at https://bugs.documentfoundation.org/show_bug.cgi?id=119960).

In column C, I have copied the contents of column A but changed the directionality setting of cell C4 manually to RTL through Format Cells > Text direction. Here the cell is properly aligned to the right and the closing parenthesis does not overlap with the last character of the string.

According to the Unicode standard, neutral characters should not affect directionality, and that’s what I would expect as a user, too. I think the best solution would be for Calc to skip all neutral characters in the beginning of the string and just consider the first strong character for cell alignment. Even better, Calc could use this heuristics to assign full text directionality for the cell, not just change alignment. Right now, if you start the cell with an RTL character followed by a LTR inset and then continue with RTL again, the substrings are ordered as in a LTR context ("FIRST second THIRD"), not as in true RTL ("THIRD second FIRST").

This bug was first reported for LO 6.0.3.2 on Launchpad at https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1793126 . Another user there confirmed the bug on LO 6.0.3.2 and 6.1.1.2.

Steps to Reproduce:
1. In an empty Calc cell with default directionality, write some text in Arabic enclosed in parentheses.

Actual Results:
The cell is automatically aligned to the left.

Expected Results:
The cell should be aligned to the right, as parentheses are bidi-neutral and should not affect directionality at all.

Reproducible: Always

User Profile Reset: No

Additional Info:

Revision history for this message
In , Miikka-Markus Alhonen (malhonen) wrote :

Created attachment 144989
Screenshot of a Calc sheet which shows wrong default alignment

Revision history for this message
Miikka-Markus Alhonen (malhonen) wrote :
Revision history for this message
In , Beluga (beluga) wrote :

Apparently this feature was not yet in 3.3.0, but I can already repro in 3.6.7

Arch Linux 64-bit
LibreOffice 3.3.0
OOO330m19 (Build:6)
tag libreoffice-3.3.0.4

Arch Linux 64-bit
Version 3.6.7.2 (Build ID: e183d5b)

Changed in df-libreoffice:
importance: Unknown → Medium
status: Unknown → Confirmed
Revision history for this message
In , Qa-admin-q (qa-admin-q) wrote :

Dear vaaydayaasra,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.

If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not
appropriate in this case)

If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3
. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword

Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug

summary: - Automatic cell alignment in Calc breaks with bidi-neutral characters
+ [upstream] Automatic cell alignment in Calc breaks with bidi-neutral
+ characters
Revision history for this message
In , Miikka-Markus Alhonen (malhonen) wrote :

Still reproducible on

Version: 6.3.2.2
Build ID: libreoffice-6.3.2.2-snap1
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3;
Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US
Calc: threaded

Revision history for this message
In , Qa-admin-q (qa-admin-q) wrote :

Dear vaaydayaasra,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.

If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not
appropriate in this case)

If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3
. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword

Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug

Revision history for this message
In , Miikka-Markus Alhonen (malhonen) wrote :

Reproducible on:

Version: 7.3.0.3 (x64) / LibreOffice Community
Build ID: 0f246aa12d0eee4a0f7adcefbf7c878fc2238db3
CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win
Locale: fr-FR (fr_FR); UI: fr-FR
Calc: CL

Revision history for this message
In , Qa-admin-q (qa-admin-q) wrote :

Dear vaaydayaasra,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.

If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not
appropriate in this case)

If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3
. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword

Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug

Revision history for this message
In , Miikka-Markus Alhonen (malhonen) wrote :

Still repro on:

Version: 7.6.6.3 (X86_64) / LibreOffice Community
Build ID: 60(Build:3)
CPU threads: 4; OS: Linux 6.5; UI render: default; VCL: gtk3
Locale: fi-FI (fi_FI.UTF-8); UI: fi-FI
Ubuntu package version: 4:7.6.6-0ubuntu0.23.10.1
Calc: threaded

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.