[upstream] Font metrics mixed up for RTL insets in a LTR context in Calc

Bug #1793127 reported by Miikka-Markus Alhonen
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
LibreOffice
Fix Released
Medium
libreoffice (Ubuntu)
Triaged
Low
Unassigned

Bug Description

In the attached screenshot, I’ve written an English sentence with an Arabic word in the middle on the first row of a Calc sheet. On the second row, I’ve written the same Arabic word (العربية) by itself. The second row looks as it should but on the first row, some of the characters overlap. The same problem occurs if I surround the isolated Arabic word with parentheses, in which case the cell is automatically aligned to the left. I’m using the default font settings, which in my environment are Liberation Sans for Latin text and DejaVu Sans for Arabic.

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:32:13 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
In , Yousuf 'Jay' Philips (philipz85) wrote :

Created attachment 128245
sample

Steps:
1) Open attached doc
2) Notice the differences between the arabic words in the 2 sentences in the document and the first two sentences in the textbox

Regression as things were better in 4.4.

Version: 5.3.0.0.alpha1+
Build ID: 928776b734c6aa188151bbce048d5bef4486dce7
CPU Threads: 2; OS Version: Linux 3.19; UI Render: default; VCL: gtk2;
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2016-10-23_00:39:08
Locale: en-US (en_US.UTF-8); Calc: group

Revision history for this message
In , Xiscofauli (xiscofauli) wrote :

Confirmed in

Version: 5.3.0.0.alpha0+
Build ID: 8974b0fafb18f9dd3f2c0e175a3255b80e4c249e
CPU Threads: 4; OS Version: Linux 4.2; UI Render: default;
Locale: ca-ES (ca_ES.UTF-8); Calc: group

if it was better in 4.4, worth it to bibisect it

Revision history for this message
In , Xiscofauli (xiscofauli) wrote :

It was stil better in

Version: 5.0.0.0.alpha1+
Build ID: 0db96caf0fcce09b87621c11b584a6d81cc7df86
Locale: ca-ES (ca_ES.UTF-8)

so it needs to be bisected in 51max or 52max.

@raal: Do you want to bibisect it?

Revision history for this message
In , Raal (raal) wrote :
Download full text (3.2 KiB)

393b5a03e8a580103cc31ca4752396032838ecdb is the first bad commit
commit 393b5a03e8a580103cc31ca4752396032838ecdb
Author: Norbert Thiebaud <email address hidden>
Date: Sun Sep 13 18:21:45 2015 -0700

    source sha:41007842ed9bb5d6165792a197769f72dae55a2c
author Martin Hosken <email address hidden> 2015-09-10 03:14:18 (GMT)
committer Martin Hosken <email address hidden> 2015-09-14 01:16:40 (GMT)
commit 41007842ed9bb5d6165792a197769f72dae55a2c (patch)
tree 3db9834122c1a6b43bd2428129629a6f66669978
parent 35fd0cf311d0ab6e647ef8a244f350d8a690e734 (diff)
Refactor graphite integration and update graphite

git bisect log
# bad: [05d11632892a322664fb52bac90b2598b7fb7544] source sha:5616d22b57a9a5e57d545e912e029162a230829b
# good: [c1efd324c6ad448ac9edb030dc9738b9e6899e4d] source sha:ab465b90f6c6da5595393a0ba73f33a1e71a2b65
git bisect start 'origin/master' 'oldest'
# good: [97526ab777da7e58ce283c05498262ecdd4d6f7f] source sha:4ea70f87f7a2b61eda6e5ab1f48debf6fcfadc1f
git bisect good 97526ab777da7e58ce283c05498262ecdd4d6f7f
# bad: [86fee7ded76d9c2756ccab6aef160a2d7fab0ab6] source sha:1b62841b1859ae3443e2bf1ebe99ec3d6afb6cc2
git bisect bad 86fee7ded76d9c2756ccab6aef160a2d7fab0ab6
# bad: [ecd02a00b3cb479dcecd6a2539e2f4140cd8158f] source sha:f45ac62a20b80033a7f5ccdef4a6c116b6fece24
git bisect bad ecd02a00b3cb479dcecd6a2539e2f4140cd8158f
# bad: [6629f1abc962685b1c83b088dff82517bb2f1691] source sha:5496f2a3ee8e76dda6d1c393308be1e9bbb90d6e
git bisect bad 6629f1abc962685b1c83b088dff82517bb2f1691
# good: [a5f968795bf60a73039ae687b366800b7929f17c] source sha:6917cd98ca6b6fd2d495d0257c7fe50611982d34
git bisect good a5f968795bf60a73039ae687b366800b7929f17c
# good: [368c6e35342202ca22c81feecd66f9073d1e3d8e] source sha:a37535e3ff7be959d9a3aab3399ffbcc89688662
git bisect good 368c6e35342202ca22c81feecd66f9073d1e3d8e
# bad: [ab5f30fb13db2e0dbf317e87f8626cb1dfc8f234] source sha:584d55178d2e390e60355b18bbac4be16fe750dd
git bisect bad ab5f30fb13db2e0dbf317e87f8626cb1dfc8f234
# bad: [31777579f3e0cf27599cdeecd2d54140bb8aa92e] source sha:6532cb0e5ec3a59c248b332e868c4c03c31659f1
git bisect bad 31777579f3e0cf27599cdeecd2d54140bb8aa92e
# bad: [20f8cc90e939167b90170a9ecf1fc143975280ca] source sha:0e916b4143b2c46fec6df25cce6f14b595d5b023
git bisect bad 20f8cc90e939167b90170a9ecf1fc143975280ca
# good: [1db296d58ea920df1c5a23cc35720c4084b1ae63] source sha:47d3e82e4f2c0c06231c952a0cc2456b712da0cc
git bisect good 1db296d58ea920df1c5a23cc35720c4084b1ae63
# good: [bcae2a9e9aeb8394df93fb275b55873d3dbc2829] source sha:168ad25711c0bd6e3a025b083312e3ed2d237933
git bisect good bcae2a9e9aeb8394df93fb275b55873d3dbc2829
# good: [6f8dba2f7237c74c6d627cbcdec2c515b2f6cb0b] source sha:d8160fa8343a395cff0116286dd24894b076c02b
git bisect good 6f8dba2f7237c74c6d627cbcdec2c515b2f6cb0b
# bad: [393b5a03e8a580103cc31ca4752396032838ecdb] source sha:41007842ed9bb5d6165792a197769f72dae55a2c
git bisect bad 393b5a03e8a580103cc31ca4752396032838ecdb
# good: [69568d9d51758db13ffd336e65561c4b72978d33] source sha:35fd0cf311d0ab6e647ef8a244f350d8a690e734
git bisect good 69568d9d51758db13ffd336e65561c4b72978d33
# first bad commit: [393b5a03e8a580103cc31ca4752396032838ecdb] source sha:41007...

Read more...

Revision history for this message
In , Xiscofauli (xiscofauli) wrote :

updating affected version

Revision history for this message
In , Yousuf 'Jay' Philips (philipz85) wrote :

Created attachment 136707
screenshot

Revision history for this message
In , Yousuf 'Jay' Philips (philipz85) wrote :

still present

Version: 6.0.0.0.alpha0+
Build ID: a2a3e06a29077d4274dc15eea28a01afe22e3658
CPU threads: 2; OS: Linux 4.4; UI render: default; VCL: gtk2;
Locale: en-US (en_US.UTF-8); Calc: group

Revision history for this message
Miikka-Markus Alhonen (malhonen) wrote :
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. The issue can be observed in calc, not in writer.

@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:
In the attached screenshot, I’ve written an English sentence with an Arabic word in the middle on the first row of a Calc sheet. On the second row, I’ve written the same Arabic word (العربية) by itself. The second row looks as it should but on the first row, some of the characters overlap. The same problem occurs if I surround the isolated Arabic word with parentheses, in which case the cell is automatically aligned to the left. I’m using the default font settings, which in my environment are Liberation Sans for Latin text and DejaVu Sans for Arabic. The problem only occurs in Calc, not Writer.

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

Steps to Reproduce:
1. In a LTR Calc cell, write some text in English, then Arabic and then English.

Actual Results:
Some of the letters of the Arabic text overlap.

Expected Results:
Arabic should look the same as in an RTL context.

Reproducible: Always

User Profile Reset: No

Additional Info:

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

Created attachment 144988
Screenshot of an Arabic RTL inset in the middle of LTR text

Revision history for this message
Miikka-Markus Alhonen (malhonen) wrote :
Changed in libreoffice (Ubuntu):
status: Confirmed → Triaged
importance: Undecided → Low
Changed in df-libreoffice:
importance: Unknown → Medium
status: Unknown → New
Revision history for this message
In , Beluga (beluga) wrote :

Did some testing and looks like it appeared with the HarfBuzz implementation in 5.3.

Revision history for this message
In , Lior Kaplan (kaplan) wrote :

Can you also reproduce with 6.1.x or master ?

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

** Please read this message in its entirety before responding **

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

Revision history for this message
In , Beluga (beluga) wrote :

(In reply to Lior Kaplan from comment #3)
> Can you also reproduce with 6.1.x or master ?

Original report was for 6.1.1. I confirm with master

Arch Linux 64-bit
Version: 6.2.0.0.alpha0+
Build ID: b752a93acff31c824bcec4233a8dd9bee014ca7d
CPU threads: 8; OS: Linux 4.18; UI render: default; VCL: gtk3_kde5;
Locale: fi-FI (fi_FI.UTF-8); Calc: threaded
Built on 12 October 2018

Changed in df-libreoffice:
status: New → 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: - Font metrics mixed up for RTL insets in a LTR context in Calc
+ [upstream] Font metrics mixed up for RTL insets in a LTR context in Calc
Revision history for this message
In , Miikka-Markus Alhonen (malhonen) wrote :

I tested this again with LO 6.3.2.2 installed on Ubuntu as a snap. Now font metrics are still mixed up in the main view while I am typing and permanently on the formula line. When I finish typing and press Enter, the main display shows the characters correctly. So part of the problem is fixed, part is remaining.

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 , Miikka-Markus Alhonen (malhonen) wrote :

Created attachment 155033
Screenshot on LO 6.3.2.2

The first line in the main view looks correct; the second line, which I'm still typing at the moment of this screenshot, is incorrect. The formula line is incorrect, too.

Revision history for this message
In , Ilmari-lauhakangas (ilmari-lauhakangas) wrote :

Still confirmed

Arch Linux 64-bit
Version: 7.1.0.0.alpha0+
Build ID: 09c24681a3414092fde50ec0f617c9f7c79e8a61
CPU threads: 8; OS: Linux 5.8; UI render: default; VCL: kf5
Locale: fi-FI (fi_FI.UTF-8); UI: en-US
Calc: threaded
Built on 30 September 2020

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 :

Tested again on LibreOffice 7.3.0.3 on Windows 10. Now the formula line looks good but all LTR cells in the main view have font metrics mixed up, whether I'm currently typing them or not. For some reason, cells starting with a RTL character that Calc automatically aligns to the right behave as they should, although they're still not truly RTL, as the order of mixed LTR/RTL elements is wrong. See the attached screenshot.

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 , Miikka-Markus Alhonen (malhonen) wrote :

Created attachment 178599
Screenshot on 7.3.0.3

Revision history for this message
In , Khaled-n (khaled-n) wrote :

*** Bug 150395 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Khaled-n (khaled-n) wrote :
Revision history for this message
In , Libreoffice-commits (libreoffice-commits) wrote :

Khaled Hosny committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/895843ad466954b63f6f99a1b6319b7813d0dbe1

tdf#103492: Messed Arabic letter spacing in text starting with LTR character(s)

It will be available in 7.5.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.

Revision history for this message
In , Libreoffice-commits (libreoffice-commits) wrote :

Khaled Hosny committed a patch related to this issue.
It has been pushed to "libreoffice-7-4":

https://git.libreoffice.org/core/commit/8e2928ec42f2daf66c81b818a10efc99c1a14e89

tdf#103492: Messed Arabic letter spacing in text starting with LTR character(s)

It will be available in 7.4.1.

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.

Revision history for this message
In , Libreoffice-commits (libreoffice-commits) wrote :

Xisco Fauli committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/c1446da82b999349e1a09fed3420bd1c38d7b38c

tdf#103492: vcl_pdfexport: Add unittest

It will be available in 7.5.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.

Revision history for this message
In , Xiscofauli (xiscofauli) wrote :

*** Bug 150544 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Khaled-n (khaled-n) wrote :

*** Bug 149889 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Khaled-n (khaled-n) wrote :

*** This bug has been marked as a duplicate of bug 103492 ***

Revision history for this message
In , Khaled-n (khaled-n) wrote :

*** Bug 119960 has been marked as a duplicate of this bug. ***

Changed in df-libreoffice:
status: Confirmed → Invalid
Changed in df-libreoffice:
importance: Medium → Unknown
status: Invalid → Unknown
Changed in df-libreoffice:
importance: Unknown → Medium
status: Unknown → Fix Released
Revision history for this message
In , Stephane-guillou-i (stephane-guillou-i) wrote :

Fix verified:

Version: 7.5.0.0.alpha1+ (X86_64) / LibreOffice Community
Build ID: da3dd48eaf9086f8ab28d6a6655f9a638e51433a
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: threaded

Revision history for this message
In , Libreoffice-commits (libreoffice-commits) wrote :

Chris Sherlock committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/9b5964cf5931d7c09e4fd624d68595891c2afb58

vcl: add unit test for cached glyphs based on tdf#103492

It will be available in 24.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.

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.