Bug 82692 - U+2027 HYPHENATION POINT sometimes mis-rendered on 4.4 master
Summary: U+2027 HYPHENATION POINT sometimes mis-rendered on 4.4 master
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.4.0.0.alpha0+ Master
Hardware: Other macOS (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: CJK
  Show dependency treegraph
 
Reported: 2014-08-16 06:53 UTC by Matthew Francis
Modified: 2023-06-11 07:53 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Sample word doc showing the issue (35.00 KB, application/msword)
2014-08-16 06:54 UTC, Matthew Francis
Details
ODT exhibiting a slighly different mis-formatting (10.02 KB, application/vnd.oasis.opendocument.text)
2014-08-16 06:55 UTC, Matthew Francis
Details
Image showing the issue as rendered (4.4 master) (48.60 KB, image/png)
2014-08-16 06:57 UTC, Matthew Francis
Details
Image showing the same text in 4.3.0.4 (50.70 KB, image/png)
2014-08-16 06:59 UTC, Matthew Francis
Details
Image showing same text rendered in Word for Mac 2011 (55.66 KB, image/png)
2014-08-16 07:01 UTC, Matthew Francis
Details
Rendering in nightly 2016-11-06 (broken) (47.97 KB, image/png)
2016-11-06 18:13 UTC, eisa01
Details
Renering in nighly 2017-10-25 (57.57 KB, image/png)
2017-11-05 21:12 UTC, eisa01
Details
Rendering in nightly 2018-12-07 (57.42 KB, image/png)
2018-12-08 08:57 UTC, eisa01
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Matthew Francis 2014-08-16 06:53:24 UTC
Observed on OSX 10.9.4 / LO 4.4 master:


See attached files with sample text in various fonts (note that these are MS Word fonts, so font substitution is in effect). The rendering of some of these is a bit off in 4.3.0.4, but much worse in a build from 4.4 master.

The sample text is the same in each case, but notice the incorrect spacing at the end of some of the lines.


Could possibly be related to the following commit?

author	Norbert Thiebaud <nthiebaud@gmail.com>	2014-07-19 14:22:54 (GMT)
committer	Norbert Thiebaud <nthiebaud@gmail.com>	2014-07-20 20:11:00 (GMT)
commit d9d16df299607d0fdbb7067ad1a8f7bccc85abf7 (patch)
tree 25acc532088a7beef70b3f245de7c858f756a114
parent 6ca2d0d6645a697d323593a401ea8b1da02445bf (diff)
vcl quartz: draw 'bullet' manually for better control
Change-Id: If0f6bd93adc5d39fd421bb482833619f85f7a461
Comment 1 Matthew Francis 2014-08-16 06:54:46 UTC
Created attachment 104706 [details]
Sample word doc showing the issue
Comment 2 Matthew Francis 2014-08-16 06:55:51 UTC
Created attachment 104707 [details]
ODT exhibiting a slighly different mis-formatting
Comment 3 Matthew Francis 2014-08-16 06:57:00 UTC
Created attachment 104708 [details]
Image showing the issue as rendered (4.4 master)
Comment 4 Matthew Francis 2014-08-16 06:59:02 UTC
Created attachment 104709 [details]
Image showing the same text in 4.3.0.4

In this case, the spacing looks wrong at the start and end of the lines which have become long, but the middle is at least evenly spaced
Comment 5 Matthew Francis 2014-08-16 07:01:56 UTC
Created attachment 104710 [details]
Image showing same text rendered in Word for Mac 2011
Comment 6 Norbert Thiebaud 2014-08-17 10:22:48 UTC
The problem seems to be related to a sequence of Runs with different directions for the run... we do not manage the transition LTR/RTL properly apparently.
The 'bullet' commit mentioned is not directly at fault, it merely exacerbate the symptoms
Comment 7 Matthew Francis 2014-08-17 11:09:40 UTC
Thanks for taking a look.

All the text in the samples should be LTR? Chinese and Japanese can sometimes be written RTL, but in this case the text ought to be all in one direction...
Comment 8 tommy27 2016-04-16 07:27:02 UTC Comment hidden (obsolete)
Comment 9 eisa01 2016-11-06 18:13:16 UTC
Created attachment 128530 [details]
Rendering in nightly 2016-11-06 (broken)

Still present on master and latest release, rendering has gotten worse

Version: 5.3.0.0.alpha1+
Build ID: 17e9dc436bc6ad8d3a5bbde15d4d47262650aa2c
CPU Threads: 2; OS Version: Mac OS X 10.12; UI Render: default; Layout Engine: old; 
TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2016-11-06_01:25:01
Locale: en-US (en_NO.UTF-8); Calc: group
Comment 10 eisa01 2017-11-05 21:12:36 UTC
Created attachment 137543 [details]
Renering in nighly 2017-10-25

This has gotten better, now the only discrepancy I see with Word is the width of the whitespace between the bullets.

No clue what should be correct

Version: 6.0.0.0.alpha1+
Build ID: 7e03c4eed72452fdfb87341214a21956c08ba969
CPU threads: 2; OS: Mac OS X 10.12.6; UI render: default; 
TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2017-10-25_23:45:02
Locale: en-US (en_US.UTF-8); Calc: group
Comment 11 QA Administrators 2018-11-06 03:56:44 UTC Comment hidden (obsolete)
Comment 12 eisa01 2018-12-08 08:57:54 UTC
Created attachment 147377 [details]
Rendering in nightly 2018-12-07

Now the spacing is varying more again. No clue what should be correct, but it's different from the rendering in Word.

Version: 6.3.0.0.alpha0+
Build ID: beae6c7a7f163daad0d4dea63a3d403af2745fd1
CPU threads: 2; OS: Mac OS X 10.13.6; UI render: default; VCL: osx; 
TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2018-12-06_23:52:29
Locale: en-US (en_US.UTF-8); UI-Language: en-US
Calc: threaded
Comment 13 QA Administrators 2019-12-09 03:39:17 UTC Comment hidden (obsolete)
Comment 14 eisa01 2020-02-15 17:28:42 UTC
I have really no clue what is right here, but at least the rendering is still different from Word

Version: 7.0.0.0.alpha0+
Build ID: 0cb4f304abf6f8dd6b40eb800788d2fe80581813
CPU threads: 4; OS: Mac OS X 10.14.6; UI render: default; VCL: osx; 
Locale: en-US (en_US.UTF-8); UI-Language: en-US
Calc: threaded
Comment 15 QA Administrators 2022-02-15 04:12:02 UTC Comment hidden (obsolete)
Comment 16 eisa01 2023-03-19 08:58:26 UTC
Checking this again, I noticed that there's font substitution going on both in Word and Libreoffice, also in the original report

So I'm not exactly sure what we're testing here?

We would need a new sample using fonts that are not substituted, clearly showing what's wrong or not

Things look normal for the fonts Word substitutes with, and that LO also are able to find (LO substitutes with different fonts)
Comment 17 ⁨خالد حسني⁩ 2023-06-11 07:53:51 UTC
I can’t reproduce this issue, and the linked macOS-specific layout code is long gone.