Screen font anti-aliasing does not work in Windows if anti-aliasing is set in the settings. This error or (missing feature) affects all LibreOffice components (Writer, Impress etc).
In addition to the poor quality of the text rendering, LO impress changes the spaces between the characters if you click in a text object or switch to another slide in presentation mode. I classified this bug (or feature request if not implemented) as important because this degrades the overall acceptance of LO (cf. e.g the good anti-aliasing in MS Office).
Text rendering seems to have improved in LO V3.5.4.2 (tested with Windows 7 Prof. 64bit) but is still not perfect. There are no more changes of character spaces when moving from one slide to another in LO Impress presentations. But there are still "anomalies" in text rendering when using slide show effects (font rendering is changed somewhat from bold to normal just after finishing of the slide show effect).
Created attachment 79419 [details] screenshot of Win7 in a VM with AA (and cleartype) working nicely ...
This bug appears too unclear to me to be a MAB; for me AA works nicely on Windows (and ~always has). Can you confirm that this still fails to work with 3.6 - and can you give much more iformation: What version of Windows ? what fonts are you using ? which component are you using ? can you attach a document that is affected ? Thanks ! :-)
Created attachment 79546 [details] screenshot comparison of AA comparison of AA on and off and PDF output(how I think it's supposed to look). Done on Windows7 as fullscreen presentation. AA/noAA means antialiasing switched on/off in Impress settings. noDPI means it is run without DPI scaling otherwise it is run on with 133% DPI scaling and compatibility flag "Disable display scaling on high DPI" set. AA1 - extra horrible result on chosen fonts. AA2 - more standard Arial fonts.
I did some coparison on LibreOffice 4. I had this issue as long as I can remeber, but I will try on 3 version if requested. On closer look I noticed there is some attempt at AA(it is not just black and white pixel values), but result for AA switched on and off is exactly the same and exported PDF gives much superior visual quality(I use Foxit to display).
When I think about it, it is actually not AA problem but the same as bug 36426.
Hello Stefan, *, does your comment 7 mean, that this one can be closed as a duplicate? If so, I will close it (or better: If you could close it as a duplicate". Sorry for the inconvenience Thomas.
Hello Thomas, sorry for that confusion, it is probably not duplicate. It does fit the description of the OP in that bug, but it's too vague to be sure and screenshots there(by another poster) are completely different from my issue. to Stefan: It would be nice if you could confirm, that you have the same issue as I based on the attachement from me, if you are still with us. Otherwise I should probably make a new bug report for it. ! Also I found out that switching ClearType off fixes my problem with font rendering quality(of user content, but UI fonts gets ugly). (So it is only Windows related). And there remains the bug or intent that unchecking the "Use Anti-Aliasing" option does not turn off font antialiasing.
There are several problems with font rendering with LO even with the latest version 4.0.4.2 (tested on WIN 7 Pro 64bit): - antialiasing is worse than with MS Powerpoint (feature optimization required) - turning on/off antialiasing in LO makes no difference (bug) - with LO impress there is a visible antialising/optimization process on changing slides which looks bad (bug/optimization required) - font spacing is not even which looks also bad (seems to be the problem described in bug 36426) I've attached a demo presentation where you can see the font rendering problems on turning slides. I
Created attachment 82119 [details] LO presentation which shows font rendering probems
The font rendering problem occurs mainly with LO impress (on turning slides). With LO Writer no font spacing problem occurs but the bug with turning on/off antialising is the same: it has no effect on the fonts except on lines (underscore).
Created attachment 82120 [details] Uneven character spacing Spaces between each character varies.
Created attachment 82121 [details] Even Character spacing with MS Powerpoint For comparision: Even Character spacing with MS Powerpoint 2010. No character touches another as with LO impress.
The font rendering problem only occurs on Windows. On e.g. Ubuntu everything is fine!
** 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 on a currently supported version of LibreOffice (4.4.1 or later) https://www.libreoffice.org/download/ *If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior *If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) 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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-04-01
Yup, still the same, the same... my previous visual comparison in attachement is still relevant. But now text won't show in fullscreen with hardware acceleration enabled at all. Windows 7 Professional x64 SP1, LibreOffice 4.4.1.2 cs_CZ
Created attachment 121672 [details] Jaggies
Hi I am new here. I am failing to get my text to anti-alias. I have recently downloaded LibreOffice 4.4.7.2 Build ID: f3153a8b245191196a4b6b9abd1d0da16eead600 Locale: en_GB Here is my hardware: Motherboard: Intel DP55WB (MA TX) Processor: Intel Core I5 750 2.66GHz RAM: 8GB = (2GB 1066 DDR3 Memory) x4 modules Hard disk: SSD 300GB, "INTEL SSDSA2CW300G3 ATA Device" Graphics card: ATI Radeon HD 5770 - S/n: 7 78656 05291 8 Operating system: Windows7 Pro 64Bit My Windows “Clear Type” is on. And in LibreOffice Writer Tools > Options > View > Graphics Output > “Use anti-aliasing” is ticked. Without anti-aliasing text starts to become hard to read and looks basically hideous. There is absolutely no way I am going to tolerate that in a word processor. Even my web browsers – ALL my browers – are doing better that that!
Created attachment 121681 [details] Screenshot Win10x64 LibreOffice 5.0.4.2 Reproducible: Win10x64 Version: 5.0.4.2 (x64)Build ID: 2b9802c1994aa0b7dc6079e128979269cf95bc78-GL Version: 5.1.0.1 (x64) Build ID: bcace328aabc4c8c10b56daa87da0a2ee6579b5a Threads 4; Ver: Windows 6.19; Render: GL; Version: 5.2.0.0.alpha0+ Build ID: b4082bed2de12cd576a06a9f456a71101809f3ed CPU Threads: 4; OS Version: Windows 6.2; UI Render: GL; TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2016-01-02_00:47:38
Created attachment 121802 [details] three screenshots I found some oddities which may help debugging. I just installed 5.0.4.2 and found that the anti-aliasing option doesn't enable anti-aliasing, like everyone else here (my system: Win7, 4690k cpu, nvidia 750 ti). I eventually found a Windows option called ClearType which seemed to enable anti-aliasing within LO Writer, as well as elsewhere in Windows. The interesting bit is after turning it back off, some things stayed anti-aliased in Writer. In this reverted state ("reverted cleartype.png") The font preview dropdown had most fonts anti-aliased, but only some that were anti-aliased here were aliased in the document.
*** Bug 97426 has been marked as a duplicate of this bug. ***
Libreoffice: 5.1.0.3 Windows: 7x64 The font anti-aliasing issue is resolved if I turn off clear-type. But then everything else in the windows ui looks awful.
Sabyan, you shouldn't change the version field to a newer release -- it's for the earliest version affected. You can add comments about it still being present though.
Sorry, I somehow overlooked it.
5.1.0 is simply not usable (Windows 7 64-bit with ClearType enabled): http://i.imgur.com/7Dmui9B.png 5.0.4 (for comparison): http://i.imgur.com/tdJTw9b.png
*** Bug 97812 has been marked as a duplicate of this bug. ***
This shouldn’t be a problem with DirectWrite (the original issue was filed as a complaint against ClearType). Please don’t reopen.
The rendering is still substandard for me though. And the "anti-aliasing" switch still has no effect.
You must enable OpenGL rendering and use a version of Windows supporting DirectWrite; otherwise LibreOffice will fall back to ClearType.
Oh, that works. Still, how's that "WORKSFORME"? That's WONTFIX. At the very least, the options are very confusing. And ClearType technology works just fine in any other application (and without any reliance on OGL).
I am on Windows 10 x86_64 and I just updated from LibreOffice 4.4.4 to 5.2.0.4, and the font rendering of the menus started looking quite bad (but still readable). Since no one has presented the solution in a clear and concise manner, I'll try. SOLUTION: In the Tools menu, select Options. Expand the LibreOffice category and select View. UNCHECK "Use OpenGL for all rendering" and "Force OpenGL even if blacklisted". Then CHECK "Use hardware acceleration" and "Use anti-aliasing.".
(In reply to g4827387 from comment #32) > SOLUTION: In the Tools menu, select Options. Expand the LibreOffice > category and select View. UNCHECK "Use OpenGL for all rendering" and "Force > OpenGL even if blacklisted". Then CHECK "Use hardware acceleration" and > "Use anti-aliasing.". This still doesn't work for me on Windows 7 64 bit. With the above settings, I only get anti aliased fonts in Writer if I have Cleartype *disabled* in Windows Control Panel (in which case all fonts in every other part of Windows look terrible)!
(In reply to rclark from comment #33) > This still doesn't work for me on Windows 7 64 bit. With the above settings, > I only get anti aliased fonts in Writer if I have Cleartype *disabled* in > Windows Control Panel (in which case all fonts in every other part of > Windows look terrible)! I should add that I'm using version 5.1.5.2 and it happens with several different fonts.
Created attachment 128027 [details] Antialiasing is incomplete This should provide additional information about the antialias problem in Windows. The above line is from LibreOffice. The dark line below is from Powerpoint. Same font (Oswald). LO shows antialiasing, but little and it makes the height of characters seem wrong.
I have found that antialiasing of LO is not working fine on Windows 10 with Clear Type. I use 5.2.2 (latest release), unchecked Open GL (It doesn't work with Surface) and checked antialiasing and hardware acceleration. As the attachment above shows, LO attempts some antialiasing but this is not properly computed and the height of fonts is mismatched. Powerpoint in the same machine with the same level of antialiasing in Cleartype produces more consistent borders and the font looks ok.
Can everybody please install the latest master: http://dev-builds.libreoffice.org/daily/master/Win-x86@62-merge-TDF/current/ Then in the Windows command line: SET SAL_USE_COMMON_LAYOUT=1 and in the same command line run the latest master build you installed (type/copy the whole path to the soffice.exe) Set to NEEDINFO. Change to RESOLVED WORKSFORME, if the problem went away.
Dear Bug Submitter, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping-20171204
Dear Bug Submitter, Please read this message in its entirety before proceeding. Your bug report is being closed as INSUFFICIENTDATA due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of our bug tracker Warm Regards, QA Team MassPing-NeedInfo-20180102
(In reply to Buovjaga from comment #37) > Can everybody please install the latest master: > http://dev-builds.libreoffice.org/daily/master/Win-x86@62-merge-TDF/current/ > > Then in the Windows command line: > SET SAL_USE_COMMON_LAYOUT=1 > > and in the same command line run the latest master build you installed > (type/copy the whole path to the soffice.exe) > > Set to NEEDINFO. > Change to RESOLVED WORKSFORME, if the problem went away. Windows 7 64-bit, LibreOffice 6.1.2 This command did not work. Font antialiasing is still entirely nonfunctional regardless of which boxes are checked or unchecked in the display options. At this point, the only way I can get functional antialiasing in LibreOffice is by disabling OpenGL and launching the program through MacType.
To take the screenshot and solve the screen related issue by follow this link https://fixconnectionsbluetoothaudiodeviceswirelessdisplayswindows10.net . Here is the best and easy answer in step wise and i am sue it will be helpful for you.
Created attachment 146163 [details] Comparison between menu rendering on Audacity, Firefox and Libreoffice (Windows 10) Can confirm that text rendering on Windows 10 is pretty bad. Here's an attachment comparing menu font rendering on Audacity, Firefox and LibreOffice. I'm on Versione: 6.1.2.1 (x64) Build ID: 65905a128db06ba48db947242809d14d3f9a93fe Thread CPU: 8; SO: Windows 10.0; Resa interfaccia: GL; Versione locale: it-IT (it_IT); Calc: CL
Font antialiasing still does not work with 6.1.3.2 on Windows. It does not seem to be graphics hardware problem because it happens on Intel GPU and Radeon GPU. It does not happen on the same hardware and settings, if the OS is Linux. It does not happen if "Use OpenGL for all rendering" is disabled. But if that is disabled, scrolling flickers (especially some dialogue boxes) badly.
Created attachment 151145 [details] Test of AA using japanese kana with different scaling levels I have the same or at least a similar issue. I've attached example screenshots of a file I created yesterday to test a font. Explanation: - The pictures in the "600pc"-folder were taken with a 600% zoom in LO. - The pictures in the main folder were taken at 100%. - The name indicates, which features were turned _ON_. (Hardware acceleration on/off, AA on/off, OpenGL on/off) I found that the font rendering really depends on the size of the font and the scaling of the page. With only 100% zoom the best results always had OpenGL disabled. As soon as OpenGL was enabled the smaller font sizes were completely horrible. So at 100% zoom from the ranking is like this: Best--------------------------------------------------------------------------------------------------------->Worst AA enabled+OpenGL disabled AA+OpenGL enabled AA disabled+OpenGL enabled But at 600% it looks completely different. When OpenGL is enabled it looks much better than with disabled OpenGL. Without any knowledge on how the rendering is actually done it seems as if the internal resolution with OpenGL is lower than without. Is subpixel rendering disabled in this case and/or hinting? Additional information: I have LO 6.2.3.2 installed. The font I wanted to test (and that was used for the screenshots) was BabelStone Han v12.1.4( http://www.babelstone.co.uk/Fonts/Han.html Download: http://www.babelstone.co.uk/Fonts/Download/BabelStoneHan.zip ). I'm running Windows 10 x64 17763.404 and have a Radeon RX580 8GB. The installed graphics driver is the latest 19.4.3 release. Final words: LO's rendering in Windows is not on par with other software like MS Office, Mozilla Firefox etc. It seems those issue(s) with the rendering on Windows have a long history. This really prevents adoption of a software. When somebody wants to give LO and FOSS a try and opens any file on Windows they will immediately be scared away by the bad font rendering. An office suite is about that: Text. Writing, formating and displaying it. Imho I think fixing the Windows rendering should be the top priority. Who cares about 10% shorter loading times of docx files, if the rendering is always bad?! Also: The latest comment has been made months ago again and no updates since then. Is nobody interested in this? (I'm not a programmer so I can't do it myself.)
(In reply to NovarthaWoW from comment #44) > Also: The latest comment has been made months ago again and no updates since > then. Is nobody interested in this? (I'm not a programmer so I can't do it > myself.) Improving this sort of stuff requires expertise that not every programmer has. Of course it would get fixed, if some entity with money would contract a company to do the work. I don't know, if we have any purely volunteer programmer, who would be able to do something about this. As a non-programmer, there are lots of things you can do to make the lives of programmers easier. If you can dedicate time for LibreOffice in general, you can start here: https://wiki.documentfoundation.org/QA/GetInvolved#Quick_start_guide_for_beginners Please get in touch with us: https://wiki.documentfoundation.org/QA/IRC You could also ask "am I able to recruit some programmer who can work on this?"
Seems fine to me now, except when OpenGL is enabled. Maybe it is only a matter of forbidding OpenGL support on Windows (at least till we recruit that superprogrammer).
PS: It is not obvious what the options even do. Certainly not for average user. There's some room for improvement there too.
OK, I retested a bit (with Impress 6.2.3.2). The Windows High DPI (150 %) setting seems OK enough. I think it is bit blurry though... With no option the text gets AA with subpixel technique. The HW accelleration option does nothing wrt output. The antialiasing option does nothing with text (text is AA even if off). It changes some graphic elements though. Enabling the OpenGL option breaks things. It tries to (single color; non-subpixel) antialias it, but it seems it does it wrong. It looks like it does not use the vector fonts correctly. Or the AA does not work in y direction or something. If I export it as PDF, my reader also whole-pixel antialias, but it still looks right.
Created attachment 161217 [details] Screenshots comparing 6.4.4 and 7.0 displaying Japanese documents This bug seems to be fixed in 7.0. Japanese documents are displayed in 6.4.4 and 7.0. Hiragana is thinner in 6.4.4, but 7.0 is clearer.
(In reply to Jun Nogata from comment #49) > This bug seems to be fixed in 7.0. Setting to NEEDINFO. Can you reproduce? Should it be WORKSFORME now?