Bug 36448 - Glyph rendering is not crisp, very fuzzy especially on small font sizes.
Summary: Glyph rendering is not crisp, very fuzzy especially on small font sizes.
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.6.0.4 release
Hardware: All macOS (All)
: high major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: macOS-UI-polish Font-Rendering
  Show dependency treegraph
 
Reported: 2011-04-20 18:14 UTC by Dave Yost
Modified: 2014-12-17 15:08 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
Mac Pages text rendering (19.83 KB, image/png)
2011-04-20 18:19 UTC, Dave Yost
Details
Mac LO text rendering (20.27 KB, image/png)
2011-04-20 18:20 UTC, Dave Yost
Details
Font Rendering Screenshot, LibO 3.6.1.1 on MacOS X 10.6.8 (Intel) (340.02 KB, image/png)
2012-08-17 14:27 UTC, Roman Eisele
Details
Font Rendering Screenshot, TextEdit 1.6 on MacOS X 10.6.8 (Intel) (284.87 KB, image/png)
2012-08-17 14:49 UTC, Roman Eisele
Details
Screenshot comparing OS X 10.8 Safari / OO Version 3.6.0.4 (Build ID: 932b512) (134.87 KB, image/png)
2012-08-17 20:32 UTC, Dave Yost
Details
Pages vs LO, Optima font (130.34 KB, image/png)
2012-08-17 21:24 UTC, Dave Yost
Details
SS after CoreText switch (333.13 KB, image/png)
2013-08-02 10:52 UTC, Emir Sarı
Details
SS including TextEdit (360.12 KB, image/png)
2013-08-02 11:46 UTC, Emir Sarı
Details
SS with 13pt. font size (277.83 KB, image/png)
2013-08-02 11:57 UTC, Emir Sarı
Details
comparative display between LO and Pages (75.77 KB, image/png)
2014-11-03 13:54 UTC, Alex Thurgood
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dave Yost 2011-04-20 18:14:18 UTC
Compare the attached screen shots.
LO's text rendering is different and clearly inferior to Pages's text rendering.

Is LO using the latest and greatest Mac OS X API for rendering text?
Comment 1 Dave Yost 2011-04-20 18:19:52 UTC
Created attachment 45899 [details]
Mac Pages text rendering
Comment 2 Dave Yost 2011-04-20 18:20:17 UTC
Created attachment 45900 [details]
Mac LO text rendering
Comment 3 Björn Michaelsen 2011-12-23 12:05:18 UTC
[This is an automated message.]
This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it
started right out as NEW without ever being explicitly confirmed. The bug is
changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back
to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases.
Details on how to test the 3.5.0 beta1 can be found at:
http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1

more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
Comment 4 Florian Reisinger 2012-08-14 14:03:16 UTC
Dear bug submitter!

Due to the fact, that there are a lot of NEEDINFO bugs with no answer within the last six months, we close all of these bugs.

To keep this message short, more infos are available @ https://wiki.documentfoundation.org/QA/NeedinfoClosure#Statement

Thanks for understanding and hopefully updating your bug, so that everything is prepared for developers to fix your problem.

Yours!

Florian
Comment 5 Florian Reisinger 2012-08-14 14:04:11 UTC
Dear bug submitter!

Due to the fact, that there are a lot of NEEDINFO bugs with no answer within the last six months, we close all of these bugs.

To keep this message short, more infos are available @ https://wiki.documentfoundation.org/QA/NeedinfoClosure#Statement

Thanks for understanding and hopefully updating your bug, so that everything is prepared for developers to fix your problem.

Yours!

Florian
Comment 6 Florian Reisinger 2012-08-14 14:08:44 UTC
Dear bug submitter!

Due to the fact, that there are a lot of NEEDINFO bugs with no answer within the last six months, we close all of these bugs.

To keep this message short, more infos are available @ https://wiki.documentfoundation.org/QA/NeedinfoClosure#Statement

Thanks for understanding and hopefully updating your bug, so that everything is prepared for developers to fix your problem.

Yours!

Florian
Comment 7 Florian Reisinger 2012-08-14 14:10:45 UTC
Dear bug submitter!

Due to the fact, that there are a lot of NEEDINFO bugs with no answer within the last six months, we close all of these bugs.

To keep this message short, more infos are available @ https://wiki.documentfoundation.org/QA/NeedinfoClosure#Statement

Thanks for understanding and hopefully updating your bug, so that everything is prepared for developers to fix your problem.

Yours!

Florian
Comment 8 Florian Reisinger 2012-08-16 11:06:26 UTC
Does this error still exist..
Comment 9 Roman Eisele 2012-08-17 13:45:51 UTC
(In reply to comment #8)
> Does this error still exist..

I will investigate this ...
Comment 10 Roman Eisele 2012-08-17 14:27:10 UTC
Created attachment 65696 [details]
Font Rendering Screenshot, LibO 3.6.1.1 on MacOS X 10.6.8 (Intel)
Comment 11 Roman Eisele 2012-08-17 14:49:37 UTC
Created attachment 65699 [details]
Font Rendering Screenshot, TextEdit 1.6 on MacOS X 10.6.8 (Intel)


I have attached two new screenshots comparing the rendering of different text fonts in LibreOffice 3.6.1.1 and Apple TextEdit 1.6, both on MacOS X 10.6.8 (Intel). So everybody can do the comparison himself/herself.

However, there is an important difficulty to create really meaningful screenshots for comparison: at least on my machine (which has got a high-resolution display with >= 120ppi), the view zoom setting is handled very differently between LibreOffice and TextEdit -- 100% in LibreOffice is nearly twice the size of 100% in TextEdit. Therefore I had to use some approximation: 100% zoom and 12pt text size in LibreOffice ~ 200% zoom and 11pt text size in TextEdit.

Be aware that comparison at pixel level will be not really fair because of this little difference; we should concentrate on the comparison at the normal use level, i.e. without zooming into the images. This menas: What is the overall impression of the text rendering by both applications? Is the text more legible or clearer or more beautiful in the one or in the other?

Doing a comparison by this guidelines, I would answer to the original bug description:

(In reply to comment #0)
> LO's text rendering is different and clearly inferior to Pages's
> text rendering.

IMHO LibO’s text rendering is now (LibO 3.6.1.1) definitely different to Pages’ text rendering, but it is not clearly inferior. It may even be a matter of fact which text rendering seems the better one. If you zoom into both screenshots, I would consider the text rendering of TextEdit as sharper and clearer, and maybe the same is true at 100% zoom size, but IMHO the difference is not very important.

> Is LO using the latest and greatest Mac OS X API for rendering text?

I don’t think so (at least it did not use the current API some time ago), and this will definitely cause some problems, but IMHO the text rendering is NOT a big problem. Please don’t forget that we have to support MacOS X 10.4, 10.5, 10.6, 10.7, and now 10.8 ... we can’t just switch, e.g., to MacOS X > 10.7 only stuff ...
Comment 12 Roman Eisele 2012-08-17 14:53:19 UTC
In consequence of my results given in comment #11, I change the status of this bug report to RESOLVED/WORKSFORME, because IMHO the text rendering of LibreOffice 3.6.1.1 on MacOS X (10.6) is not (anymore) _clearly_ inferior to Apple’s one.

Everybody, feel free to reopen this bug report if you find good (!) evidence that LibreOffice’ text rendering is still clearly inferior to Apple’s ;-)
Comment 13 Dave Yost 2012-08-17 20:32:24 UTC
Created attachment 65706 [details]
Screenshot comparing OS X 10.8 Safari / OO Version 3.6.0.4 (Build ID: 932b512)

The fuzz at the bottom of each character is one thing you should clearly be able to see.
Comment 14 Roman Eisele 2012-08-17 20:55:33 UTC
(In reply to comment #13)
> The fuzz at the bottom of each character is one thing you should clearly be
> able to see.

I suspect that "you should clearly be able to see" could be considered as an offence, but let us consider it as polite expression.

Yes, I am "able to see" what you call "fuzz", and you can see the same thing on my own screenshot, and I already saw it there. But believe it or not, I still don’t think that this makes LibO’s text rendering "_clearly_ inferior to
Apple’s one" (my comment #12; you should have noticed the emphasis on _clearly_, haven’t you?). Anti-aliasing is a matter of taste, of course.

But de gustibus not est disputandum, and therefore it is OK that you have opened this bug report again. Now let us hope that some developer finds time to fix this issue ... i.e. to improve the text rendering. I just fear that there are more important bugs ;-)
Comment 15 Dave Yost 2012-08-17 21:13:59 UTC
No offense, just stating fact, trying to report a problem: LO text rendering on Mac is below-standard quality. I submit that most Mac users used to the visual quality of text in apps on the Mac notice that text in LibreOffice doesn't look as good. Certainly anyone who appreciates high visual quality finds it a substandard-quality experience. For me, writing is taxing enough without having to be annoyed by the look of what I'm writing.
Comment 16 Dave Yost 2012-08-17 21:14:59 UTC
Comment on attachment 65706 [details]
Screenshot comparing OS X 10.8 Safari / OO Version 3.6.0.4 (Build ID: 932b512)

Sorry, meant LO, not OO.
Comment 17 Dave Yost 2012-08-17 21:24:30 UTC
Created attachment 65713 [details]
Pages vs LO, Optima font

Pages 4.2 (1008) on OS X 10.8.0 vs LO 3.6.0.4 (Build ID: 932b512)
In this example, it's not just the bottoms of characters that are fuzzy.
The rendering artifacts vary with the y position of the baseline and the size.
Comment 18 Roman Eisele 2012-08-18 08:16:51 UTC
@Thorsten Behrens:
You are our MacOS expert, therefore I insert your address into the CC list of this report. Please take a look at it.

Two hints:

(1)  I am not sure if we should consider this report as a bug report (because the text rendering of LibreOffice is inconsistent with and inferior to the rendering in native MacOS X applications; IIRC, there was a similar bug report for Linux/Cairo rendering) or as an enhancement request (because there is no guarantee that LibreOffice uses native text rendering on every platform).

-> If you want, I can turn this into an enhancement request and adapt the Summary to reflect this change.

(2)  IIRC, some time ago a developer has made some preliminary changes to the text rendering code for Aqua on the master branch, in order to make it easier to change to a newer text rendering engine. It's a pity, but I can’t remember the developer’s name and can’t find his commits.

-> If you could give me a hint regarding this developer, I will CC him about this report -- maybe he will take it ...


Thank you very much in advance!
Comment 19 Alex Thurgood 2012-08-19 09:23:33 UTC
I would not set this as works for me either, having tested 3.6.0.4 on my 10.8 OSX the other day, I was very disappointed with the way that text is now "fuzzed" (not to mention SVG display problems), and thus went back to 3.3.4, where the problem is markedly less apparent. 

There is a visual difference, probably due to the hinting and rendering code which at least in part (if not fully, I'm not conversant with the way it actually works) uses Apple's old rendering API, which is now deprecated on Lion and Mountain Lion (and possibly was also on Snow Leopard, but it didn't bother me too much there).

No one will adopt LO on Mac if the rendering is crap, when all the other apps display "beautifully" (I deliberately put that word in quotation marks, as it is very much a personal adjective). Certainly, why would anyone move to 3.6, when rendering is noticeably different between that version and a previous version (in my case 3.3.4 and even 3.5.5).

The difference in environment in my case appears to be the upgrade from OSX 10.6.8 (Snow Leopard) to 10.7 (Lion), and then to 10.8 (Mountain Lion).

The problem will need to be addressed, and until it is, people who might be tempted into using LO, will shy away from it, and diss it at the same time.

Obviously, this requires resources, and someone who knows how to code in Objective-C using Cocoa on a recent version of OSX. Also, it doesn't help that Apple now appears to have upped its release rate for new OS versions, but we aren't any better in that respect.

If I get some time today or tomorrow, I will try and post a screenshot comparison of the same business document I opened on 3.6.0.4 and its comparison when I switched back to 3.3.4.


Alex
Comment 20 Roman Eisele 2012-08-19 09:53:01 UTC
(In reply to comment #19)
> The difference in environment in my case appears to be the upgrade from OSX
> 10.6.8 (Snow Leopard) to 10.7 (Lion), and then to 10.8 (Mountain Lion).

Ah -- this may explain why I regard this problem as minor: I still (need to) use 10.6.8 (Snow Leopard). If the rendering went worse with 10.7 or 10.8, I can understand that this is a more serious problem for people who use these newer MacOS X versions.

> [...] having tested 3.6.0.4 on my 10.8 OSX the other day, I was very
> disappointed with the way that text is now "fuzzed", and thus went back
> to 3.3.4, where the problem is markedly less apparent. 
> 
> If I get some time today or tomorrow, I will try and post a screenshot
> comparison of the same business document I opened on 3.6.0.4 and its comparison
> when I switched back to 3.3.4.

If text rendering really is worse in LibO 3.6.x than in previous versions, please add the "regression" keyword. This will also make the importance of this issue more obvious: regressions tend to get more attention by the developers (and *should* get more attention, of course!).
Comment 21 Roman Eisele 2012-08-19 09:54:17 UTC
(Reset assignee to default -- it does not make much sense to assign a bug report to the original reporter, when it is no more in NEEDINFO status.)
Comment 22 Emir Sarı 2013-08-02 10:52:59 UTC
Created attachment 83528 [details]
SS after CoreText switch

What do you think?
Comment 23 Emir Sarı 2013-08-02 11:46:09 UTC
Created attachment 83531 [details]
SS including TextEdit

My opinion on this one - there is much improvement comparing with the previous screenshots, but text  rendering still seems a bit blurry. I also checked with TextEdit which also uses CoreText, the rendering is nearly identical to Pages, though TextEdit tends to render fonts a bit thinner - but not blurry.
Comment 24 Emir Sarı 2013-08-02 11:57:02 UTC
Created attachment 83533 [details]
SS with 13pt. font size

And with this screenshot it looks worse, LO rendering is clearly blurrier than the other two.
Comment 25 ⁨خالد حسني⁩ 2013-08-02 13:33:28 UTC
May be I’m getting old, but I see nothing “clear” in any of these, screenshots. Apple rendering looks bad to me either way. I just switched on the Mac machine and after a while if using Linux, I couldn’t stand Apple’s default font rendering anymore and had to disable LCD smoothing to make it more palatable (though worse in other aspects).
Comment 26 Handyman 2013-08-16 04:19:12 UTC
I see no improvement. Text still fuzzy in LO v4.1, but very clear in NeoOffice.
Comment 27 Emir Sarı 2013-11-10 16:55:04 UTC
I also still can confirm that glyphs, especially the bottom sides are very fuzzy. 

-4.2.0 Alpha 1
Comment 28 Emir Sarı 2014-07-24 22:57:42 UTC
Increasing importance to high, since LibreOffice/AOO is the only GUI word processor left on Mac platform, which has inferior/bad text rendering. Literally every other word processor/text editor out there has crisp clear text rendering, except LibreOffice/AOO. 

Other Mac users would agree I presume.
Comment 29 Joel Madero 2014-11-02 16:07:25 UTC
Never independently confirmed by our QA team - UNCONFIRMED is the appropriate status.
Comment 30 Alex Thurgood 2014-11-03 13:53:48 UTC
Scrrenshot of same text in LO dev 440 alpha and Pages OSX 10.10

IMO, the display in LibreOffice looks better
Comment 31 Alex Thurgood 2014-11-03 13:54:35 UTC
Created attachment 108838 [details]
comparative display between LO and Pages
Comment 32 Alex Thurgood 2014-11-03 13:55:32 UTC
LO is on left, Pages on right
Comment 33 Alex Thurgood 2014-12-17 15:08:43 UTC
Setting as wfm - no further comments since I posted my comparison.