Bug Hunting Session
Bug 87373 - [Mac OS X] Bad text spacing
Summary: [Mac OS X] Bad text spacing
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: graphics stack (show other bugs)
Version:
(earliest affected)
4.4.0.0.beta1
Hardware: Other Mac OS X (All)
: highest major
Assignee: Thorsten Wagner
URL:
Whiteboard: target:5.1.0 target:5.0.0.0.beta2
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Font-Rendering mab4.4
  Show dependency treegraph
 
Reported: 2014-12-16 18:09 UTC by Iandol
Modified: 2018-04-05 22:47 UTC (History)
14 users (show)

See Also:
Crash report or crash signature:


Attachments
screenshot (110.08 KB, image/png)
2014-12-16 18:09 UTC, Iandol
Details
screenshot (54.73 KB, image/png)
2014-12-16 18:12 UTC, Iandol
Details
Test ODT File (13.37 KB, application/vnd.oasis.opendocument.text)
2015-01-30 00:24 UTC, Iandol
Details
Bad kerning as page width scaled to 112% (7.56 KB, image/png)
2015-01-30 00:25 UTC, Iandol
Details
10.10.2, LO 4.4.3 at 110% zoom (37.16 KB, image/jpeg)
2015-01-30 09:58 UTC, retired
Details
OS X_4.4.1 (127.83 KB, image/png)
2015-02-27 09:51 UTC, d
Details
OS X_4.2.8 (124.48 KB, image/png)
2015-02-27 09:52 UTC, d
Details
10.10.2 LO nightly from 2015-03-25 (5.45 KB, image/jpeg)
2015-03-25 20:15 UTC, steve -_-
Details
screenshot of first patch (7.29 KB, image/png)
2015-04-29 17:29 UTC, Iandol
Details
Screenshot from LO with character spacing 3 pt (54.29 KB, image/tiff)
2015-05-03 21:59 UTC, Thorsten Wagner
Details
Screenshot from AOO with character space 3 pt (53.97 KB, image/tiff)
2015-05-03 21:59 UTC, Thorsten Wagner
Details
RTL trailing space (7.66 KB, application/vnd.oasis.opendocument.text)
2015-05-04 04:34 UTC, Khaled Hosny
Details
10.10.3 LO nightly 2015-05-28 (36.91 KB, image/jpeg)
2015-05-28 12:59 UTC, steve -_-
Details
Screenshot from LO 5.0 beta (48.09 KB, image/tiff)
2015-05-29 03:25 UTC, Thorsten Wagner
Details
show issues with aoo (13.21 KB, application/vnd.oasis.opendocument.text)
2015-05-29 08:24 UTC, Norbert Thiebaud
Details
show issues with aoo (20.14 KB, application/vnd.oasis.opendocument.text)
2015-05-29 08:30 UTC, Norbert Thiebaud
Details
Screenshot from AOO 4.2 (125.06 KB, image/tiff)
2015-05-29 19:56 UTC, Thorsten Wagner
Details
Screenshot from AOO 4.2 with marks shown (136.73 KB, image/tiff)
2015-05-29 19:56 UTC, Thorsten Wagner
Details
Screenshot from LO 4.4.3 (127.07 KB, image/tiff)
2015-05-29 19:57 UTC, Thorsten Wagner
Details
Screenshot from LO 4.4.3 with marks shown (159.96 KB, image/tiff)
2015-05-29 19:57 UTC, Thorsten Wagner
Details
Screenshot from LO 5.0 beta (126.60 KB, image/tiff)
2015-05-29 19:58 UTC, Thorsten Wagner
Details
Screenshot from LO 5.0 beta with marks shown (159.81 KB, image/tiff)
2015-05-29 19:58 UTC, Thorsten Wagner
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Iandol 2014-12-16 18:09:27 UTC
Created attachment 110920 [details]
screenshot

The beta 2 version of 4.4 has broken font kerning opening the same document. Please see screenshot comparing 4.3.5 and 4.4b2
Comment 1 Iandol 2014-12-16 18:12:35 UTC
Created attachment 110921 [details]
screenshot

try to add correct mime type
Comment 2 Jacques Guilleron 2014-12-19 10:15:18 UTC
Hi Iandol,

I clearly see the issue on your screenshot but I couldn't reproduce with 
LO 4.4.0.0.beta2 build ID: be92f32b8f21603a6b7a75dd645f7475bdee519d Locale : fr_FR
& Windows 7 Home Premium.
If kerning is checked in Caracter > Position, did you try to rename your profile?
Can you also precise your OS?

Jacques
Comment 3 Iandol 2014-12-19 19:28:10 UTC
I'm sorry about the lack of OS information!!!

This is OS X 10.10.1, with LO 4.4.0.0.beta2 Build ID: be92f32b8f21603a6b7a75dd645f7475bdee519d Locale: en_GB

Pair kerning is turned on, and this is a new virgin dev install. I tried to rename my settings and still broken kerning. The broken kerning is more obvious using Times New Roman, but is broken using better designed fonts too...
Comment 4 Iandol 2014-12-28 21:40:28 UTC
Still broken in Version: 4.4.0.1
Build ID: 1ba9640ddd424f1f535c75bf2b86703770b8cf6f
Locale: en_GB
Comment 5 Iandol 2015-01-13 14:00:26 UTC
Still broken in Version: 4.4.0.2
Build ID: a3603970151a6ae2596acd62b70112f4d376b990
Locale: en_GB
Comment 6 Philip Eriksson 2015-01-29 22:10:29 UTC
Confirmed in 4.4.0 release x86_64. Locale sv_SE. OS X 10.10.2.
Comment 7 Iandol 2015-01-29 22:34:04 UTC
Still broken for me in Version: 4.4.0.3 Build ID: de093506bcdc5fafd9023ee680b8c60e3e0645d7 Locale: en_GB

OS X 10.10.2 rMBP 10,1
Comment 8 retired 2015-01-29 23:25:10 UTC
Why is this in NEEDINFO if confirmed by two individual people?
Might be OSX only though when not reproduced on Windows.
OSX 10.10.2, LO 4.4.3 I don't see this. Could you please provide a test file you are seeing this with and the exact font being used.

Does this concern all fonts or only specifiy ones?

NEEDINFO until this is provided. Then please back to unconfirmed.
Comment 9 Iandol 2015-01-30 00:24:23 UTC
Created attachment 112932 [details]
Test ODT File

OK, I've worked out what may be happening. I use "Page Width" for zoom. I notice as I resize the Writer window kerning gets worse and better, as if it is not properly recalculating for the new size. This is with times new roman. I find at around 110-112% where I normally work the kerning is at its worst. Trying the same thing in 4.3.5 and resizing doesn't cause "bad" kerning page widths, neither does Word.
Comment 10 Iandol 2015-01-30 00:25:44 UTC
Created attachment 112933 [details]
Bad kerning as page width scaled to 112%

Bad kerning as page width scaled to 112%
Comment 11 retired 2015-01-30 09:58:16 UTC
Attaching what I am seeing. Iandol please confirm this is the same issue. If it is, this problem has been in LO for quite a while I think.

Setting to NEW.
Comment 12 retired 2015-01-30 09:58:45 UTC
Created attachment 112946 [details]
10.10.2, LO 4.4.3 at 110% zoom
Comment 13 Iandol 2015-01-30 15:30:34 UTC
@foss: yes your screenshot looks very similar to what I'm seeing. I have run 4.3.5 and 4.4.0.3 one after the other and although the bug may be present in 4.3.5 I can't get the same level of broken kerning displayed as I can with 4.4 with the same document and fonts...
Comment 14 Philip Eriksson 2015-01-31 01:22:38 UTC
I never noticed this on 4.3, on any zoom level or font. So if this bug existed it has changed and gotten worse on my system.
Comment 15 retired 2015-02-01 11:41:11 UTC
Since two or more users are saying this has gotten worse or has not been existing in 4.3 adding keyword "regression".
Comment 16 Michael Stahl (CIB) 2015-02-06 15:52:24 UTC
can't see the bug on Linux.

since this happens apparently on Mac OS X only, it's probably a bug in VCL.
Comment 17 Matthew Francis 2015-02-14 00:44:17 UTC
There's no OSX bibisect coverage available from 4.3 on

-> Whiteboard:notBibisectable
Comment 18 Paul Oranje 2015-02-21 17:36:50 UTC
Regression noticed between LO 4.3.6 and 4.4.0.3 on Mac OS X 10.10.
Comment 19 d 2015-02-27 09:50:36 UTC
Bug is still in LibreOffice 4.4.1.2 under OS X...

Windows and Linux is not affected...

Zoomlevel, used Font and OS X-Version is unnecessary...

last right working version under OS X is LibreOffice 4.2.8

look at attached screenshots: 4.4.1 and 4.2.8
Comment 20 d 2015-02-27 09:51:56 UTC
Created attachment 113736 [details]
OS X_4.4.1
Comment 21 d 2015-02-27 09:52:26 UTC
Created attachment 113737 [details]
OS X_4.2.8
Comment 22 steve -_- 2015-03-25 20:15:49 UTC
Created attachment 114353 [details]
10.10.2 LO nightly from 2015-03-25
Comment 23 Matthew Francis 2015-03-27 02:37:56 UTC
This seems to have begun at the below commit.
Adding Cc: to nthiebaud@gmail.com; Any chance you could take a look at this? Thanks

(bug 84382 is also related to this commit)

commit 4a0cb642f18b674f37db8e9bd30942740df08e4c
Author: Norbert Thiebaud <nthiebaud@gmail.com>
Date:   Sun Jul 20 07:49:45 2014 +0200

    vcl quartz: Add support back for DXArray tweaking
    
    The CoreText implementation dropped the support of DXArray
    more exactly ignored the values provided in it.
    And try to approximate the result by assuming that
    all it does is full justification... which is not quite right
    
    This ut the feature back, buy handing the glyph drawing
    directly, rather than defering to CoreText CTLineDraw
    to control the position of each Glyph
    
    Change-Id: Ibe0cfe789d3be441c012d8ac1104d939204a591c
Comment 24 Khaled Hosny 2015-04-22 19:37:48 UTC
This is probably a general VCL bug, since the DXArray stuff is just completely broken by design, and I do see bad text spacing on Linux all the time, though not as bad as the screen shots shown here. My guess is this is caused by accumulated rounding errors since Core Text using floating point and subpixel positioning while VCL does not.
Comment 25 Thorsten Wagner 2015-04-22 20:28:32 UTC
AOO 4.1.1 doesn't contain this bug. As the problem is very annoying I suggest comparing related stuff with AOO.
Comment 26 Joel Madero 2015-04-22 23:56:53 UTC
While AOO might not have *this particular bug* it has quite a few other bugs that the commit fixed so reverting that would bring back a series of other problems that QA would have to determine if "on balance" it's worth. For just one example the feature that allow extra/les spacing between character (in the Char format) is broken.. and in general anything the _require_ DXArray to work, is broken on MAc

Where does this leave us? Well ideally someone will have to dig into this commit and the section of code to figure out how to resolve this issue without bringing back all of the problems that it fixed.

Norbert has said he's available to discuss with a developer who is willing to look into it to give some code pointers and to explain why it's pretty hard to resolve. Feel free to poke him directly (at the email provided by Mathew Francis)

If someone wants to test we should get an uploaded OSX version with the commit reverted.

@Robinson - can we get this on the QA call for next time? Norbert is happy to revert but said it would definitely cause some pain (and it's up to QA to determine if on balance it's worth doing)
Comment 27 Thorsten Wagner 2015-04-23 07:49:35 UTC
Yesterday evening I've done a litte bit investigation and found some improvements to produce much better results. At first sight I don't see any more kerning differeces between AOO and LibreOffice now.

I still have to do some refactoring and will provide a patch during next week. The patch will preserve the changes which already have been done.

@ Joel: Thanks for your hint to Norbert, I will ask him to doublecheck.
Comment 28 Thorsten Wagner 2015-04-26 11:11:54 UTC
patch submitted for review
Comment 29 Commit Notification 2015-04-27 21:15:04 UTC
Thorsten Wagner committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=bec8fc58a827c220b3f28462ae127cc1c571d1bf

Fix tdf#87373: Kerning broken on OS X

It will be available in 5.0.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 30 Iandol 2015-04-29 17:29:00 UTC
Created attachment 115194 [details]
screenshot of first patch

First of, many many thanks Thorsten for patching this. As far as I can see this is still not entirely fixed in the current nightly. I was wondering if part of this problem depends on using a HiDPI display mode. I still see substantial jumps of characters laterally as I resize the window and wonder if the calculations are still being done on "pixels"? I will check on my older 2010 MBP which is non-retina.

Screenshot from:

Version: 5.0.0.0.alpha1+
Build ID: 2932d2db599c09ecce3faa2d627e9ee4f251183a
TinderBox: MacOSX-10.10@61, Branch:master, Time: 2015-04-29_01:47:02
Locale: en_GB.UTF-8
Comment 31 Robinson Tryon (qubit) 2015-04-29 18:28:16 UTC
(In reply to Joel Madero from comment #26)
> @Robinson - can we get this on the QA call for next time? 

Yep, added.

> Norbert is happy
> to revert but said it would definitely cause some pain (and it's up to QA to
> determine if on balance it's worth doing)

It'd be great to get an update re: comment 27, etc.., before next Wednesday, to get a good picture of what's remains of this bug.
Comment 32 Thorsten Wagner 2015-04-30 23:36:23 UTC
(In reply to Iandol from comment #30)
> Created attachment 115194 [details]
> screenshot of first patch
> 
> First of, many many thanks Thorsten for patching this. As far as I can see
> this is still not entirely fixed in the current nightly. I was wondering if
> part of this problem depends on using a HiDPI display mode. I still see
> substantial jumps of characters laterally as I resize the window and wonder
> if the calculations are still being done on "pixels"? I will check on my
> older 2010 MBP which is non-retina.
> 
> Screenshot from:
> 
> Version: 5.0.0.0.alpha1+
> Build ID: 2932d2db599c09ecce3faa2d627e9ee4f251183a
> TinderBox: MacOSX-10.10@61, Branch:master, Time: 2015-04-29_01:47:02
> Locale: en_GB.UTF-8

Iandol, how did you created your screenshot? It would be very nice to get some details to reproduce the behaviour shown.
Comment 33 steve -_- 2015-05-01 05:52:36 UTC
In a brief test here, things have improved I think. Will watch this in the coming days and provide feedback if more kerning issues persist.

Version: 5.0.0.0.alpha1+
Build ID: 0ecf20cd185813327613c01bc6cbff9721cef1f1
TinderBox: MacOSX-10.10@61, Branch:master, Time: 2015-05-01_05:18:36
Locale: de-DE (de.UTF-8)
Comment 34 steve -_- 2015-05-01 05:58:13 UTC
Since Thorsten is working on this, assigning you. If this is not ok, please un-assign yourself.

Looks fixed for me in all occasions that had issues previously.
Comment 35 Iandol 2015-05-01 08:38:28 UTC
(In reply to Thorsten Wagner from comment #32)
> Iandol, how did you created your screenshot? It would be very nice to get
> some details to reproduce the behaviour shown.

Dear Thorsten,

I was using standard 1440x900 HiDPI mode on a rMBP, downloaded the nightly, used the attached Test ODT file, and turned ON View->Zoom->Page Width.

Resizing the window the glyphs jump around laterally and at some window widths the glyphs are kerned worse than at others. This behaviour improves (i.e. kerning is better), when I use 2880x1800, which was why I assumed part of this is due to HiDPI. Running the nightly side-by-side to 4.4.3.1 and I think there is nevertheless an improvement.
Comment 36 Thorsten Wagner 2015-05-01 21:55:38 UTC
I'm able to reproduce. Remaining problem is visible on non retina displays too.
Comment 37 Thorsten Wagner 2015-05-03 20:45:26 UTC
The remaining problem seems to disappear if private method "ApplyDXArry" is completely removed within "ctlayout.cxx".

@ Norbert: Are you able to tell the use case for "ApplyDXArray" to reproduce the behaviour with/without "ApplyDXArray"?
Comment 38 Norbert Thiebaud 2015-05-03 21:08:07 UTC
(In reply to Thorsten Wagner from comment #37)
> The remaining problem seems to disappear if private method "ApplyDXArry" is
> completely removed within "ctlayout.cxx".
> 
> @ Norbert: Are you able to tell the use case for "ApplyDXArray" to reproduce
> the behaviour with/without "ApplyDXArray"?

I already did told you:
_one_ use case is expended spacing of chars (in Char format, position, spacing / extended / <n> points

but that is just one.
git grep DrawTextArray is a quick way to find others

Note: ther are 2 DXArray.. the external one which should be in LogicPixel (long)
and the internal one that is in DeviceCoordinate (double)
the Logic Pixel _should_ be in ~ 1/100 to 1/50 of a screen pixel, so rounding should not be that visible.. and the DeviceCoordinate one is in double and should not be rounded at all.

Maybe that rule is not respected somewhere and some unwanted rounding occurs at the DeviceCoordinate level.

It is also possible that we still are lacking DeviceCoordinate support for other things like X,Y position of the framing box or of the 'start point' used to position the text to draw...
Comment 39 Thorsten Wagner 2015-05-03 21:59:00 UTC
Created attachment 115292 [details]
Screenshot from LO with character spacing 3 pt
Comment 40 Thorsten Wagner 2015-05-03 21:59:30 UTC
Created attachment 115293 [details]
Screenshot from AOO with character space 3 pt
Comment 41 Thorsten Wagner 2015-05-03 21:59:53 UTC
@ Norbert:

Yes you told, but please find attached screenshots from LO and AOO with a character spacing of 3 pt. I don't see substantial differences.
Comment 42 Norbert Thiebaud 2015-05-03 22:02:54 UTC
(In reply to Thorsten Wagner from comment #41)
> @ Norbert:
> 
> Yes you told, but please find attached screenshots from LO and AOO with a
> character spacing of 3 pt. I don't see substantial differences.

try with 1pt with a lo version _before_ your recent patch
Comment 43 Khaled Hosny 2015-05-04 04:34:27 UTC
Created attachment 115295 [details]
RTL trailing space

This change broke handling of trailing space in RTL text (see the attached document). Since it is not fixing what it is supposed to fix, I think the commit should be reverted for now until a better solution comes up.
Comment 44 Norbert Thiebaud 2015-05-04 04:51:02 UTC
(In reply to Khaled Hosny from comment #43)
> Created attachment 115295 [details]
> RTL trailing space
> 
> This change broke handling of trailing space in RTL text (see the attached
> document). Since it is not fixing what it is supposed to fix, I think the
> commit should be reverted for now until a better solution comes up.

Khaled, Ok. Feel free to push a revert.
Comment 45 Commit Notification 2015-05-04 05:07:00 UTC
Khaled Hosny committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=1f059a591966b69e8943cefa1169a1b6526e2199

Revert "Fix tdf#87373: Kerning broken on OS X"

It will be available in 5.0.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 46 Thorsten Wagner 2015-05-04 23:17:26 UTC
A rework of the patch has been uploaded to Gerrit. Patch includes in +/- 1 pixel filter only now. RTL text seems to be handled correctly, different character spacing as well - please retest.

There are remaining issues, but the current kerning should be improved as a first step.
Comment 47 Thorsten Wagner 2015-05-05 22:26:38 UTC
Restoring the following code at the end of mathod "FillDXArray" within file "ctlayout.cxx" seems to solve the remaining problems while preserving RTL text as well as custom character spacing:

// convert the sub-pixel accurate array into classic pDXArray integers
float fWidthSum = 0.0;
sal_Int32 nOldDX = 0;
for( int i = 0; i < mnCharCount; ++i)
{
    const sal_Int32 nNewDX = rint( fWidthSum += aWidthVector[i]);
    pDXArray[i] = nNewDX - nOldDX;
    nOldDX = nNewDX;
}

Before "aWidthVector" is used instead of "pDXArray". The code avoids cummulated rounding differences, but fills pDXArray with integers.

@ Norbert: It would be very nice to get this approach doublechecked. If it looks good I will submit an additional patch to Gerrit.
Comment 48 Thorsten Wagner 2015-05-12 21:48:00 UTC
Uploaded complete patch to Gerrit
Comment 49 Frank Fuchs 2015-05-21 10:57:24 UTC
The LibO 5.0 beta 1 commit log shows this bug to be fixed.
However, after installing LibO 5.0 beta 1, I cannot detect any visible change to the text spacing (compared to LibO 4.4.3.2) - it is still bad.
And the previous comment to this bug does not show a commit to the 5.0 branch, only that the fixes were provided to Gerit.
Tested on Mac OS X 10.10.3 on a MacBook Pro 15" Retina.
Can someone please check whether the fixes from Thorsten are really checked-in?
Comment 50 Commit Notification 2015-05-24 16:18:39 UTC
Thorsten Wagner committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=187af9b0c09f6ba57e994a25a756f0994beae7e5

tdf#87373: Bad text spacing on OS X

It will be available in 5.0.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 51 Commit Notification 2015-05-25 01:04:19 UTC
Thorsten Wagner committed a patch related to this issue.
It has been pushed to "libreoffice-5-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=02fe9b00f9e779d69189dc011c82dce32c0446fc&h=libreoffice-5-0

tdf#87373: Bad text spacing on OS X

It will be available in 5.0.0.0.beta2.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 52 Frank Fuchs 2015-05-26 07:01:33 UTC
Thorsten,

would it be possible for you to also commit your patches to the LibO 4.4 branch before the 4.4.4 RCs?
Comment 53 steve -_- 2015-05-28 08:45:51 UTC
So with the patches in 5.x did anybody verify this is fixed?
http://dev-builds.libreoffice.org/daily/master/MacOSX-x86_64@49-TDF/
Comment 54 steve -_- 2015-05-28 12:58:41 UTC
LO Version: 5.1.0.0.alpha1+
Build ID: 487880b6882ec01c1b4679eae60bec484272a86b
TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2015-05-28_05:01:42
Locale: de-DE (de.UTF-8)

OSX 10.10.3

Think this is still a problem (attaching screenshot).
Comment 55 steve -_- 2015-05-28 12:59:05 UTC
Created attachment 116105 [details]
10.10.3 LO nightly 2015-05-28
Comment 56 Thorsten Wagner 2015-05-29 03:24:56 UTC
(In reply to steve -_- from comment #55)
> Created attachment 116105 [details]
> 10.10.3 LO nightly 2015-05-28

Steve, I'm not able to reproduce your screenshot. Please find attached a screenshot showing the result with LO from master as well as with LO 5.0 beta, both compiled from GIT repository.
Comment 57 Thorsten Wagner 2015-05-29 03:25:31 UTC
Created attachment 116116 [details]
Screenshot from LO 5.0 beta
Comment 58 Norbert Thiebaud 2015-05-29 03:41:32 UTC
(In reply to Thorsten Wagner from comment #57)
> Created attachment 116116 [details]
> Screenshot from LO 5.0 beta

that was no on a retina display was it ?
Comment 59 Thorsten Wagner 2015-05-29 03:47:01 UTC
(In reply to Norbert Thiebaud from comment #58)
> (In reply to Thorsten Wagner from comment #57)
> > Created attachment 116116 [details]
> > Screenshot from LO 5.0 beta
> 
> that was no on a retina display was it ?

yes; are there problems with retina displays? I'm unable to doublecheck this during the next days.
Comment 60 Norbert Thiebaud 2015-05-29 04:36:44 UTC
(In reply to Thorsten Wagner from comment #59)
> (In reply to Norbert Thiebaud from comment #58)
> > (In reply to Thorsten Wagner from comment #57)
> > > Created attachment 116116 [details]
> > > Screenshot from LO 5.0 beta
> > 
> > that was no on a retina display was it ?
> 
> yes; are there problems with retina displays? I'm unable to doublecheck this
> during the next days.

well Steve screenshot seems to be from a retina display.. that would explain why he sees it and you do not

bear in mind that reverting to 'int' rounding for DeviceCoordinate
works well on normal display where 1 point = 1 pixel
but on retina display 1 point = 4 pixel 2x2
so there _are_ character that would normally be at a .5 point
but the .5 is rounded up or down
when one char get rounded down a sub-pixel and the next get rounded up you get a full point jitter that may become visible.

DeviceCoordinate should be double non rounded .. LogicalCorrdinate is 100 times physical so rounding after scaling to that should be only 0.01 point jitter.

The problem core of the problem is the whole concept of DXArray. writer (or any other module for that matter) should really not touch it at all, and any adjustment needed should be done by vcl.
It _is_ a hard problem, that won't be solved by just trying to bring back a different set of bug from AOO.

Since that won't be solved properly anytime soon, I'm happy with whatever you guys feels is the less of two evils.. but tweaking the rounding will _not_ fix it all.

iow DXArray should be private
Comment 61 steve -_- 2015-05-29 06:02:26 UTC
Hi Thorsten, Norbert. My mac here is a non retina mac so that makes things more complicated I guess.

Thorsten, if it is helpful, mail me directly and we can do a screensharing session. xcode is installed here so feel free to debug on this system here.
Comment 62 Thorsten Wagner 2015-05-29 07:46:34 UTC
@ Norbert: I don't remember any retina problems with AOO, but I will doublecheck the patch with retina once I have my retina Mac available again.

@ Steve: I'm very busy right now, so I suggest debugging on Sunday. Screen sharing isn't possible because it is blocked by my firewall due to security reasons. I'll come back to you.
Comment 63 Norbert Thiebaud 2015-05-29 08:24:49 UTC
Created attachment 116124 [details]
show issues with aoo

open the attachement with AOO and notice the caret position is wrong at place (that come from ignoring DXArray when drawing the text, so DXArray and text are out of sync)
notice also how the text wiggle as you type.

Also notice how turning on and off the 'show marks' actually alter the layout.

I tested with 4.4.2.2 (which I have installed and is before all the recent 'tweaking', and it behave _much_ better.
Comment 64 Norbert Thiebaud 2015-05-29 08:30:52 UTC
Created attachment 116125 [details]
show issues with aoo

richer version, that show more bugs
Comment 65 Thorsten Wagner 2015-05-29 19:55:25 UTC
(In reply to Norbert Thiebaud from comment #63)
> Created attachment 116124 [details]
> show issues with aoo
> 
> open the attachement with AOO and notice the caret position is wrong at
> place (that come from ignoring DXArray when drawing the text, so DXArray and
> text are out of sync)
> notice also how the text wiggle as you type.
> 
> Also notice how turning on and off the 'show marks' actually alter the
> layout.
> 
> I tested with 4.4.2.2 (which I have installed and is before all the recent
> 'tweaking', and it behave _much_ better.

I attached some screenshots from AOO 4.2, LO 4.4 (without patches), and LO 5.0 beta (with patches):

(1) I do see layout differences between AOO and LO.

(2) I do see layout changes when turnig marks on and off with AOO.

(3) I don't see differences between LO 4.4 and LO 5.0 beta.
Comment 66 Thorsten Wagner 2015-05-29 19:56:17 UTC
Created attachment 116147 [details]
Screenshot from AOO 4.2
Comment 67 Thorsten Wagner 2015-05-29 19:56:46 UTC
Created attachment 116148 [details]
Screenshot from AOO 4.2 with marks shown
Comment 68 Thorsten Wagner 2015-05-29 19:57:11 UTC
Created attachment 116149 [details]
Screenshot from LO 4.4.3
Comment 69 Thorsten Wagner 2015-05-29 19:57:39 UTC
Created attachment 116150 [details]
Screenshot from LO 4.4.3 with marks shown
Comment 70 Thorsten Wagner 2015-05-29 19:58:05 UTC
Created attachment 116151 [details]
Screenshot from LO 5.0 beta
Comment 71 Thorsten Wagner 2015-05-29 19:58:32 UTC
Created attachment 116152 [details]
Screenshot from LO 5.0 beta with marks shown
Comment 72 Thorsten Wagner 2015-05-31 14:08:05 UTC
(In reply to Thorsten Wagner from comment #62)
> @ Norbert: I don't remember any retina problems with AOO, but I will
> doublecheck the patch with retina once I have my retina Mac available again.
> 
> @ Steve: I'm very busy right now, so I suggest debugging on Sunday. Screen
> sharing isn't possible because it is blocked by my firewall due to security
> reasons. I'll come back to you.

Steve, I'm able to reproduce the problem now: It seems to depend on screen resolution. What resolution do you use?

Nevertheless, I suggest keeping the patches. The overall behaviour is much better than before - from my point of view.
Comment 73 Iandol 2015-06-01 09:47:41 UTC
I think in general this is slightly better on Retina displays. My way of triggering this is to use "Page Width" zoom and resize the window and I still get bad kerning at certain zoom levels but it seems to occur less than the non-patched builds. 

I tested using below build on a Retina Macbook Pro 10,1 @1440x900HiDPI mode on OS X 10.4.4 public beta:

Version: 5.0.0.0.beta1+
Build ID: 3c0149457d19b5641e65e19620dd7771643adb8b
TinderBox: MacOSX-x86_64@49-TDF, Branch:libreoffice-5-0, Time: 2015-05-29_08:35:02
Locale: en-GB (en_GB.UTF-8)
Comment 74 steve -_- 2015-06-02 06:01:47 UTC
@Thorsten using non retina MacBookPro with 1680x1050.
As for reproduction: def related to zoom level and it seems to be worst at around 110% for me. I know all very vague and that's what  makes this problem so hard to keep track of.
My feeling is, kerning has indeed improved with the patches. Not sure how to proceed here. Guess that's for UX / Devs to decide.
Thorsten thanks for your efforts!
Comment 75 steve -_- 2015-10-08 14:15:17 UTC
At the danger of taking a severe beating of the initial reports and cc: humans, setting this to fixed.

Things have dramatically improved since the first report of this problem. So let's close this bug (which is getting a bit hard to understand and read anyhow) and leave it be.

Any remaining issues will not be ignored, but it would be great to get those reported in new bug reports. That way things will move in the right direction much quicker.

thanks for understanding.
Comment 76 Robinson Tryon (qubit) 2015-12-17 08:41:47 UTC Comment hidden (obsolete)