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
Created attachment 110921 [details] screenshot try to add correct mime type
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
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...
Still broken in Version: 4.4.0.1 Build ID: 1ba9640ddd424f1f535c75bf2b86703770b8cf6f Locale: en_GB
Still broken in Version: 4.4.0.2 Build ID: a3603970151a6ae2596acd62b70112f4d376b990 Locale: en_GB
Confirmed in 4.4.0 release x86_64. Locale sv_SE. OS X 10.10.2.
Still broken for me in Version: 4.4.0.3 Build ID: de093506bcdc5fafd9023ee680b8c60e3e0645d7 Locale: en_GB OS X 10.10.2 rMBP 10,1
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.
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.
Created attachment 112933 [details] Bad kerning as page width scaled to 112% Bad kerning as page width scaled to 112%
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.
Created attachment 112946 [details] 10.10.2, LO 4.4.3 at 110% zoom
@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...
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.
Since two or more users are saying this has gotten worse or has not been existing in 4.3 adding keyword "regression".
can't see the bug on Linux. since this happens apparently on Mac OS X only, it's probably a bug in VCL.
There's no OSX bibisect coverage available from 4.3 on -> Whiteboard:notBibisectable
Regression noticed between LO 4.3.6 and 4.4.0.3 on Mac OS X 10.10.
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
Created attachment 113736 [details] OS X_4.4.1
Created attachment 113737 [details] OS X_4.2.8
Created attachment 114353 [details] 10.10.2 LO nightly from 2015-03-25
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
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.
AOO 4.1.1 doesn't contain this bug. As the problem is very annoying I suggest comparing related stuff with AOO.
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)
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.
patch submitted for review
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.
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
(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.
(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.
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)
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.
(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.
I'm able to reproduce. Remaining problem is visible on non retina displays too.
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"?
(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...
Created attachment 115292 [details] Screenshot from LO with character spacing 3 pt
Created attachment 115293 [details] Screenshot from AOO with character space 3 pt
@ 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.
(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
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.
(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.
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.
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.
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.
Uploaded complete patch to Gerrit
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?
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.
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.
Thorsten, would it be possible for you to also commit your patches to the LibO 4.4 branch before the 4.4.4 RCs?
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/
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).
Created attachment 116105 [details] 10.10.3 LO nightly 2015-05-28
(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.
Created attachment 116116 [details] Screenshot from LO 5.0 beta
(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 ?
(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.
(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
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.
@ 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.
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.
Created attachment 116125 [details] show issues with aoo richer version, that show more bugs
(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.
Created attachment 116147 [details] Screenshot from AOO 4.2
Created attachment 116148 [details] Screenshot from AOO 4.2 with marks shown
Created attachment 116149 [details] Screenshot from LO 4.4.3
Created attachment 116150 [details] Screenshot from LO 4.4.3 with marks shown
Created attachment 116151 [details] Screenshot from LO 5.0 beta
Created attachment 116152 [details] Screenshot from LO 5.0 beta with marks shown
(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.
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)
@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!
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.
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]