Created attachment 132368 [details]
How it looked like in previous releases

Created attachment 132369 [details]
How it looks now in 5.3.2.2

Actually believe this is to be expected as font rendering is being refactored. There were a few changes between 5.3.1 and 5.3.2

Also, LO controlled UI scaling was removed at the 5.3 release for support of HiDPI (bug 101646). And OS "scaling" will cause blurry resampling of the bitmap icons.

On Windows builds there is no support for Microsoft ClearType sub-pixel rendering.

Please provide details of your graphics GPU and driver, screen resolution, version of Windows.

Also the "Graphics Output" rendering settings on the Tools -> Options -> View will control the way fonts are rendered. Please repeat your tests and sample with each of the configurations--i.e. Use OpengGL, Use hardware acceleration, or CPU only--with and without anti-aliasing checked.  

Thanks!

Created attachment 132374 [details]
Typeof GPu and its driver

Thanks, I am attaching a screenshot for the GPU details, system is Windows 7 professional with service pack 1.
Screen res is 1680x1050 at the moment, since I am using an external video,  but the problem is the same with the notebook 1366x768.

Finally, I tried all combinations of the Use OpengGL, Use hardware acceleration, or CPU only--with and without anti-aliasing checked switches, obtaining no perceivable visual difference in the UI rendering.

We now use DirectWrite to render text like any modern Windows application, you can change system font rendering if you don’t like the defaults.

Thank for the comment Khaled, what I do not understand is why on my notebook there is NO other application that renders menus and dialog windows text the way it looks in LO 5.3.3.2. Old or new. All other apps used the same "system" font that LO used until 5.3.1.
If it could be useful I can make a list of the many I have checked.... 
right now I am attaching a collage of screen captures for a few of them, compare them against LO 5.3.2.2 and you will see they do NOT look like it.
What am I missing???

Created attachment 132375 [details]
A sample of font rendering in variuos apps UI

I can tell a difference between these screenshots, unfortunately (I have a hidpi screen so your screenshots are all scaled which distorts any difference in font rendering in them), however these all look like old apps that night be still using GDI in a way or another. You should check the likes of Firefox and Chrome who use modern Windows graphics system.

Alas things got even worse, since a few minutes ago realized that impress slide rendering, when showing them full screen, is now much worse than it was, and makes using it to make professional presentation outright unfeasible.
Even large text say size 18 or 20, now looks terribly jagged whereas it was perfect and smooth before.
To show this clearly, I am attaching a collage with the same portion of a slide rendered by LO5.3.2.2 (left side of the image) and by a previous version (right side). 
The result is so much worse now as to be actually non-usable.

Being in need of displaying presentations constantly, I am now forced to downgrade to 5.3.1 urgently. 
As things stand now, I sincerely cannot consider this as FIXED
Sorry

Created attachment 132377 [details]
a side by side comparison of impress slide showing the deterioration of its rendering

OK so you look to be on an old Intel GPU, which won't have OpenGL support in LibreOffice.

IIUC DirectWrite on Windows 7 is flaky compared to its GDI based font rendering, I think makes the glyphs look "scratchy" which can be seen comparing the "Margini del Testo" entry on the View menu of the two samples (attachment 132368 [details] and attachment 132369 [details]).

The effect is real, however this is not unexpected, and really can not be fixed (it is a MS issue) fortunately the project does not do sub-pixel rendering which would be more of a mess.

Created attachment 132378 [details]
Firefox menu UI with good font rendering

As you asked, I have attached firefox 52.0.2 menu rendering, which is to me good and similar to all othetr apps, not to the  menus of LO 5.3.2.2

In any case the main problem now lies in the Impress slide rendering, where IMHO the difference is macroscopic.

I see Stuart, and I could say that I can live with the problem after all...
unfortunately I cannot show presentations the way they are now rendered full screen however.... is this a different issue? any workaround? 

Otherwise I will have to downgrade right now... I have lectures tomorrow and things must look good...

Ouch, just looked at attachment 132377 [details] the Impress font rendering is a mess. Something more is going on -->  NEW but NEEDINFO.

Please run msinfo32.exe and copy paste the first dozen lines of the System Summary panel, and also from its Components -> Display panel.

The impress rendering is bad indeed, DirectWrite shouldn’t cause that AFAIK. No idea what is going on, though.

There you go (sorry for the Italian...):
SYSTEM
Nome SO	Microsoft Windows 7 Professional
Versione	6.1.7601 Service Pack 1 Build 7601
Altre informazioni SO 	Non disponibile
Produttore SO	Microsoft Corporation
Nome sistema	ANDYSCAGNI-PC
Produttore sistema	LENOVO
Modello sistema	20AMS7E100
Tipo sistema	PC basato su x64
Processore	Intel(R) Core(TM) i5-4300U CPU @ 1.90GHz, 2501 Mhz, 2 core, 4 processori logici
Versione/data BIOS	LENOVO GIET76WW (2.26 ), 27/08/2014
Versione SMBIOS	2.7
Directory Windows	C:\Windows
Directory System	C:\Windows\system32
Periferica di avvio	\Device\HarddiskVolume1
Locale	Italia
Hardware Abstraction Layer	Versione = "6.1.7601.17514"
Nome utente	AndyScagni-PC\Andy Scagni
Fuso orario	ora legale Europa occidentale
Memoria fisica installata (RAM)	8,00 GB
Memoria fisica totale	7,69 GB
Memoria fisica disponibile	4,15 GB
Memoria virtuale totale	15,4 GB
Memoria virtuale disponibile	11,6 GB
Spazio file di paging	7,69 GB
File di paging	C:\pagefile.sys

COMPONENTS - DISPLAY

Nome	Realtek Wifi Display VGA Adapter
ID periferica PNP	ROOT\DISPLAY\0000
Tipo scheda	Non disponibile, Realtek Semiconductor Corp. compatibile
Descrizione scheda	Realtek Wifi Display VGA Adapter
RAM scheda	Non disponibile
Driver installati	Non disponibile
Versione driver	1005.2.622.2011
File INF	oem29.inf (sezione RealtekVga)
Piani colore	Non disponibile
Voci tabella colori	4294967296
Risoluzione	1680 x 1050 x 59 hertz
Bit/Pixel	32
Driver	c:\windows\system32\drivers\rtlvvga.sys (1005.2.622.2011, 11,64 KB (11.920 Byte), 21/12/2014 06:49)
	
Nome	Intel(R) HD Graphics Family
ID periferica PNP	PCI\VEN_8086&DEV_0A16&SUBSYS_221417AA&REV_0B\3&E89B380&0&10
Tipo scheda	Intel(R) HD Graphics Family, Intel Corporation compatibile
Descrizione scheda	Intel(R) HD Graphics Family
RAM scheda	(2.080.374.784) Byte
Driver installati	igdumdim64.dll,igd10iumd64.dll,igd10iumd64.dll,igdumdim32,igd10iumd32,igd10iumd32
Versione driver	10.18.10.3412
File INF	oem32.inf (sezione iHSWM_w7)
Piani colore	Non disponibile
Voci tabella colori	Non disponibile
Risoluzione	Non disponibile
Bit/Pixel	Non disponibile
Indirizzo memoria	0xF0000000-0xF03FFFFF
Indirizzo memoria	0xE0000000-0xEFFFFFFF
Porta I/O	0x00004000-0x0000403F
Canale IRQ	IRQ 4294967291
Porta I/O	0x000003B0-0x000003BB
Porta I/O	0x000003C0-0x000003DF
Indirizzo memoria	0xA0000-0xBFFFF
Driver	c:\windows\system32\drivers\igdkmd64.sys (10.18.10.3412, 4,03 MB (4.221.440 Byte), 21/12/2014 06:51)
	
Nome	CyberLink Mirror Driver
ID periferica PNP	ROOT\DISPLAY\0001
Tipo scheda	Non disponibile, CyberLink compatibile
Descrizione scheda	CyberLink Mirror Driver
RAM scheda	Non disponibile
Driver installati	Non disponibile
Versione driver	1.0.0.0
File INF	oem45.inf (sezione CLMirrorDriver)
Piani colore	Non disponibile
Voci tabella colori	Non disponibile
Risoluzione	Non disponibile
Bit/Pixel	Non disponibile
Driver	c:\windows\system32\drivers\clmirrordriver.sys (1.0.0.306, 20,77 KB (21.264 Byte), 05/10/2015 18:56)

I hope you can find out what is going on ... in the meantime I returned to 5.3.1...
thank you for the efforts anyway

Created attachment 132384 [details]
Writer - default rendering

Can not confirm even with the marginal OpenGL support of the VMWare video driver on Windows 7 sp1 32-bit, both 5.3.1.2 and 5.3.2.2 builds render with identical quality with Default rendering and with OpenGL rendering--in Writer and Impress.

Screen clips of side by side (/a admin installs) with and without OpenGL for Writer and Impress.

=-=
Testing Windows 7 sp1 32-bit VM on VMWare 12.5.5 
Version: 5.3.2.2
Build ID: 6cd4f1ef626f15116896b1d8e1398b56da0d0ee1
CPU Threads: 1; OS Version: Windows 6.1; UI Render: default; Layout Engine: new; 
Locale: en-US (en_US); Calc: group

Version: 5.3.1.2
Build ID: e80a0e0fd1875e1696614d24c32df0f95f03deb2
CPU Threads: 1; OS Version: Windows 6.1; UI Render: default; Layout Engine: new; 
Locale: en-US (en_US); Calc: group

OS Name	Microsoft Windows 7 Enterprise
Version	6.1.7601 Service Pack 1 Build 7601
Other OS Description 	Not Available
OS Manufacturer	Microsoft Corporation
System Name	WIN-BSJACHSIFIB
System Manufacturer	VMware, Inc.
System Model	VMware Virtual Platform
System Type	X86-based PC
Processor	Intel(R) Xeon(R) CPU E3-1270 v3 @ 3.50GHz, 3491 Mhz, 1 Core(s), 1 Logical Processor(s)
BIOS Version/Date	Phoenix Technologies LTD 6.00, 7/2/2015
SMBIOS Version	2.7
Windows Directory	C:\Windows
System Directory	C:\Windows\system32
Boot Device	\Device\HarddiskVolume1
Locale	United States
Hardware Abstraction Layer	Version = "6.1.7601.17514"

Name	VMware SVGA 3D
PNP Device ID	PCI\VEN_15AD&DEV_0405&SUBSYS_040515AD&REV_00\3&2B8E0B4B&0&78
Adapter Type	VMware Virtual SVGA 3D Graphics Adapter, VMware, Inc. compatible
Adapter Description	VMware SVGA 3D
Adapter RAM	1.00 GB (1,073,741,824 bytes)
Installed Drivers	vm3dum.dll,vm3dum_10.dll
Driver Version	8.15.1.50
INF File	oem10.inf (VM3D_X86 section)
Color Planes	Not Available
Color Table Entries	4294967296
Resolution	1680 x 1050 x 60 hertz

Created attachment 132385 [details]
Writer - OpenGL rendering

Created attachment 132386 [details]
Impress - default rendering

Created attachment 132387 [details]
Impress - OpenGL rendering

Are you sure you have checked impress FULL SCREEN rendering?? tha one you're showing seems to be a windowed display. I do not remember perfectly, but I did not notice the thing immediately while editing the slides, but only when starting the full screen presentation... Thus the non-full screen display was probably not so different for me too. Please check that the good results you're getting are the same when going full screen too..

(In reply to Andy from comment #24)
> Are you sure you have checked impress FULL SCREEN rendering?? tha one you're
> showing seems to be a windowed display. I do not remember perfectly, but I
> did not notice the thing immediately while editing the slides, but only when
> starting the full screen presentation... Thus the non-full screen display
> was probably not so different for me too. Please check that the good results
> you're getting are the same when going full screen too..

On this Windows 7 sp1 32-bit VM, in Presentation mode there no difference between font rendering of the 5.3.1 and 5.3.2 builds with OpenGL rendering, GPU Hardware acceleration, or CPU only rendering.

Continue to be unable to confirm, the Harfbuzz based font rendering works for me.

You could try driver update for your Intel HD GPU, beyond that -> UNCONFIRMED

Hi

I reproduce the problem on windows 7/64 & Version: 5.3.2.2
Build ID: 6cd4f1ef626f15116896b1d8e1398b56da0d0ee1
CPU Threads: 2; OS Version: Windows 6.1; UI Render: default; Layout Engine: new; 
Locale: fr-FR (fr_FR); Calc: group

All other applications (including LibreOffice 5.3.1.2 - see below) appear correctly.

Version: 5.3.1.2
Build ID: e80a0e0fd1875e1696614d24c32df0f95f03deb2
CPU Threads: 2; OS Version: Windows 6.1; UI Render: default; Layout Engine: new; 
Locale: fr-FR (fr_FR); Calc: group

Regards
Pierre-Yves

Created attachment 132412 [details]
My Config

Created attachment 132413 [details]
My OpenGL config (xml)

Created attachment 132414 [details]
Screenshot how it looked with 5.3.1.2

Created attachment 132415 [details]
Screenshot how it looked with 5.3.2.2

Created attachment 132421 [details]
default rendering side-by-side

Created attachment 132422 [details]
OpenGL rendering side-by-side

So taking a closer look at this, comparing 5.3.0.3, 5.3.1.2 and 5.3.2.2 side by side--there is no difference with OpenGL rendering.

But when using default rendering, there has been a notable change between 5.3.1.2 and 5.3.2.2 such that the OpenGL and Default font rendering are now equivalent.

Believe what folks limited to default rendering are seeing as "worse font rendering" is simply the change from GDI to DrirectWrite.

In two additional attachments from a Windows 10 Pro 64-bit en-US with nVidia GTX-750 TI (21.21.13.7653), attachment 132421 [details] shows default rendering for 5.3.0.3, 5.3.1.2 and 5.3.2.2 releases. And attachment 132422 [details] shows each with build with OpenGL rendering.

The default rendering font shaping does change between 5.3.1.2 and 5.3.2.2, but note that it now *matches* the OpenGL rendering of 5.3.0.3, 5.3.1.2 and 5.3.2.2

IMHO this is correct--that OpenGL rendering should match the default rendering. It does have a lighter weight, but that may be an issue with our DirectWrite/Direct2D implementation and its behavior on XP, Vista and Win7

Created attachment 132447 [details]
LO 5.3.2.2 on Windows 10 x64 Home, nVidia 310M, FullHD Low DPI LCD

UI fonts looks very ugly in LO 5.3.2.2 (see attachment).
Screenshot from Windows 10 x64 Home, nVidia 310M, FullHD Low DPI LCD.

UI flickers a lot when GL is off.

As for me it is unusable, back to 5.3.1.

(In reply to Serg Bormant from comment #34)
> Created attachment 132447 [details]
> LO 5.3.2.2 on Windows 10 x64 Home, nVidia 310M, FullHD Low DPI LCD
> 
> UI fonts looks very ugly in LO 5.3.2.2 (see attachment).
> Screenshot from Windows 10 x64 Home, nVidia 310M, FullHD Low DPI LCD.
> 

Thanks! The Default, CPU only and OpenGL rendering are equivelent--what we expect.

But could you please post the same clips from your 5.3.1 reinstall. Need to compare the OpenGL result from that against the OpenGL result for 5.3.2, to asses degradation.

As well to see the "change" between Default HW (or CPU only) rendering at 5.3.1 against 5.3.2 on your Windows 10 system.

Created attachment 132455 [details]
LO 5.3.1.2 on Windows 10 x64 Home, nVidia 310M, FullHD Low DPI LCD

> the same clips from your 5.3.1 reinstall. 
> Need to compare the OpenGL result from that against the OpenGL result for 5.3.2, to asses degradation.

The same fragments from LO 5.3.1.2 are attached.

(In reply to Serg Bormant from comment #36)
> > Need to compare the OpenGL result from that against the OpenGL result for 5.3.2, to asses degradation.
> 
> The same fragments from LO 5.3.1.2 are attached.

Thank you. So that set of clips confirms--there is no degradation of the OpenGL rendering, and that at 5.3.2.2 the DriectWrite/Direct2D font shaping is now more fully used with the Default HW and CPU only rendering. Fonts just look different between the two engines.

The flickering of bug 107024 is an unintended consequence, but IMHO this is not a bug as it is by design.

@Khaled, Michael, Tor, * -- content with closing WONTFIX?

(In reply to V Stuart Foote from comment #37)
> content with closing WONTFIX?

Really?

How to get image/behavior as LO 5.3.1.2 with
[v] Use hardware acceleration
[v] Use anti-aliasing

You don't see ugly fonts with FullHD on 13", but try to see LO 5.3.2.2 picture on low DPI LCD -- it is terrible ugly.

(In reply to Serg Bormant from comment #38)
> Really?
> 
> How to get image/behavior as LO 5.3.1.2 with
> [v] Use hardware acceleration
> [v] Use anti-aliasing
> 
> You don't see ugly fonts with FullHD on 13", but try to see LO 5.3.2.2
> picture on low DPI LCD -- it is terrible ugly.

That is the point, you can not. Hence my assessment this is not a bad thing and a WONTFIX of rolling it back, but we'll let the devs decide that ;-)

DirectWrite has more completely replaced comparable GDI calls, and now at 5.3.2.2 the Default and CPU rendering matches the rendering as for OpenGL. That is intended and by design, but there is agreement that the DirectWrite calls need attention. 

It remains to resolve is if the DirectWrite calls can be made more functional for earlier Windows--notably XP, or if support for XP will be dropped. And to determine if a buffering scheme similar to OpenGL must be implemented for the Default rendering to remove the flicker of bug 107024

I can confirm this bug on Windows 8 and 8.1.

On all versions before 5.3.2, default (non-OpenGL) font rendering was crispy, sharp and clear. Since 5.3.2, it looks ugly and blurry. With OpenGL turned on, it *always* looked ugly and blurry (which is why I always left GL turned off).
This experience is exactly the same on at least six different monitors (all of which are traditional non-HiDPI).

The rendering of all other applications (including Windows itself, Firefox, and Thunderbird) is still sharp and clear on the same monitors.

Please fix this bug! Current rendering becomes a pain in the eye after some time and makes it extremely hard to work for a longer time.

*** Bug 107121 has been marked as a duplicate of this bug. ***

*** Bug 107235 has been marked as a duplicate of this bug. ***

Windows 10 x86_64 here, i wholeheartedly agree with comment 40 - Writer became ultimately unusable without subpixel anti-aliasing in 5.3.2.x. I do not necessarily insist on getting exactly the output that LibreOffice used to produce before 5.3.2.x, but i do insist on *some* form of subpixel anti-aliasing (for example, i generally like FreeType2 subpixel rendering more than ClearType; not sure what LibreOffice used to use), especially for the work area.

Hello, I am assessing the problem further:
- on windows 7, lenovo thinkpad 540, I upgraded video drivers today. Display problems with 5.3.2.2 remain unchanged, UI is rendered very ugly, text is Writer is markedly worse than in 5.3.1, full screen odp is totally unusable. openGl settings changes nothing. In this configuration, 5.3.2.2 cannot be used at least for presentation, and I am trying again to downgrade again to 5.3.1. At the moment this is impossible, the 5.3.1. link on the webpage is dead, and all mirrors do not contain 5.3.1 anymore. HELP!!!
- on windows 10 hp notebook, rendering with the two version is exactly the same for menus and writer text, but full screen presentations are again quite bad, not quite as horrible as on win7, but still certainly not ready for prime time...
On the whole, the changes introduced seem to me decidedly negative. And at the moment the unavailability of 5.3.1 is highly problematic.

*** Bug 107382 has been marked as a duplicate of this bug. ***

Created attachment 132822 [details]
LO 5.3.2.2 on Windows 10 Pro x64, Nvidoa Quadro FX 3800

Another example of bad rendering and flickering in menu bar.

(In reply to Andy from comment #50)
> I am sorry to bother, I just wondered if release 5.3.3.1 involves any change
> concerning the problem described here.
> If it does, I will test it eagerly.... otherwise, I'll skip it.
> Thanks for any info!

Hi Andy!
I reviewed the version of LibreOffice 5.3.3.1, and on my computer I found the same problem I had with version 5.3.2.2. Maybe someone else had different result.
In fact, I installed the previous version, 5.3.1.2. I think that soon there will be a new version fixing the problem.

For folks not happy with the OpenGL and Default rendering of Seoge UI (system font from Win 7 -> Win 10) it is a simple process to set a font replacement for Segoe UI which is not well rendered.

Tools -> Options -> Fonts:  "Apply replacement table" checked active,

Select "Segoe UI" for the "From:" entry, and a suitable San-Serif font for "Replace with:", then OK to apply.

"Noto Sans" is a good fit if installed, or the "Open Sans" font (bundled with LibreOffice). "DejaVu Sans" (also bundled) works as well but has smaller metrics than "Segoe UI" and the UI shrinks. The old "Tahoma" font is used for Windows XP and earlier but folks might like that as well.

Until work for bug 107521 can improve DirectWrite rendering and restore more appealing rendering of the native Segoe UI system font (for both OpenGL and Default rendering) these alternate fonts are DirectWrite grayscale rendered by LibreOffice cleaner than the Windows system font Segoe UI.

Moving this to WONTFIX

What do you mean, won't fix?

From the users' perspective, it was fixed before, so LibreOffice has now suddenly become unusable for an undetermined amount of time, because it's impossible to even look at the ting for any amount of time?

Looking at the number of complaints, those are just by users who how to work a bug tracker. If there is no solution by the next release which should better come quick, the average user will just throw up their arms in despair and eventually return to non-free software.

I know that graphics stuff isn't easy to implement, but there should at least be a workaround or a return to the old code until bug 107521 can be fixed.

A possible workaround would be to have the installer take the steps you suggested automatically for the user. Please ping me if you want me to test something on that end.

And this affects Windows 7 too (which I'm on), not just the Segue UI fonts. Yes, I'm on crappy laptop Intel graphics.

Ehm I have the feeling that we do not have a shared awareness of the problem here...
please have a look at my attach "a side by side comparison of impress slide showing the deterioration of its rendering"
It the font substitution solving this and does it bring impress full screen rendering back to its old glory?

To me this is the main point now. That said, if the rendering of Segoe UI has to get worse necessarily, I do not completely understand why and how other fonts used as system font should instead perform marvellously... is it a problem with Segoe UI only???
Please help me to understand,thank you all

Created attachment 133088 [details]
Open Sans, LO 5.3.2.2 on Windows 10 x64 Home, nVidia 310M, FullHD Low DPI LCD

Created attachment 133089 [details]
Noto Sans UI, LO 5.3.2.2 on Windows 10 x64 Home, nVidia 310M, FullHD Low DPI LCD

Created attachment 133090 [details]
Noto Sans, LO 5.3.2.2 on Windows 10 x64 Home, nVidia 310M, FullHD Low DPI LCD

(In reply to V Stuart Foote from comment #53)
> For folks not happy with the OpenGL and Default rendering of Seoge UI
> (system font from Win 7 -> Win 10) it is a simple process to set a font
> replacement for Segoe UI which is not well rendered.
> 
> Tools -> Options -> Fonts:  "Apply replacement table" checked active,
> 
> Select "Segoe UI" for the "From:" entry, and a suitable San-Serif font for
> "Replace with:", then OK to apply.
> 
> "Noto Sans" is a good fit if installed, or the "Open Sans" font (bundled
> with LibreOffice). "DejaVu Sans" (also bundled) works as well but has
> smaller metrics than "Segoe UI" and the UI shrinks. The old "Tahoma" font is
> used for Windows XP and earlier but folks might like that as well.

These are not workaround for ugly UI rendering.
Reinstall 5.3.2.2, apply font replacement, restart LO.
No changes.

LO 5.3.2.2 on Windows 10 x64 Home, nVidia 310M, FullHD Low DPI LCD,
added Open Sans, Noto Sans UI, Noto Sans screenshots.

Back to 5.3.1 here again.

Tone aside; it should be reasonably easy to fix by passing a different parameter (enabling cleartype) to the DirectWrite renderer - in the case that we're not using OGL rendering; ClearType for in-document text rendering is deeply problematic, and is disabled in recent MS Office's as well by default (FWIW) - but in the GDI fallback case this should be fairly simple.

git grep ANTIALIASED_QUALITY

gives the code-site; I suspect we want that sets the quality member on the LOGFONT cf.

https://msdn.microsoft.com/en-us/library/windows/desktop/dd145037(v=vs.85).aspx

we could use CLEARTYPE_QUALITY - but it is unclear to me why the DEFAULT_QUALITY is not this so ... ;-) worth a try perhaps ?

(In reply to Andy from comment #55)
> Ehm I have the feeling that we do not have a shared awareness of the problem
> here...
> please have a look at my attach "a side by side comparison of impress slide
> showing the deterioration of its rendering"
> It the font substitution solving this and does it bring impress full screen
> rendering back to its old glory?
> 
> To me this is the main point now. 

The issue in Impress slide rendered with GPU "Use hardware acceleration" is open as bug 107090 -- likely related to DirectWrite handling but not the issue here.

(In reply to V Stuart Foote from comment #53)
> For folks not happy with the OpenGL and Default rendering of Seoge UI [...]
Sorry, but noone has complained about the rendering of only one font. Instead, my experience was (and still is):

(1.) For all versions up to (and including) 5.3.1, ANY AND ALL font rendering (both UI and in-document) was
(a) sharp and clear when OpenGL was turned off, and
(b) ugly and blurry when OpenGL was turned on.

(2.) Since 5.3.2, ANY AND ALL font rendering (both UI and in-document) has become ugly and blurry regardless of OpenGL being on or off.

This experience is NOT dependent on one or more specific fonts, and it doesn't change with hardware acceleration enabled or disabled. Several comments have already pointed out that font substitution (as you proposed) does not improve anything.

So, whatever changes have been introduced between 5.3.1 and 5.3.2, these didn't improve the ugly and blurry OpenGL font rendering (which was already broken before), but instead substantially degraded non-OpenGL font rendering. In effect, this leaves no more option to get sharp and clear fonts by turning OpenGL off. So I'd strongly suggest to:

- As first aid, restore non-OpenGL font rendering as it was in 5.3.1 in order to quickly make LO at least usable again.

- In the long run, improve OpenGL rendering so that it becomes similarly clear and sharp as non-OpenGL before 5.3.2.

*** Bug 107760 has been marked as a duplicate of this bug. ***

In ms office.
when zoon out ,small text and program menu , dialog etc ,no anti-aliasing.
when zoon in ,biger text anti-aliasing.
Maybe LO can refer to ms office.

Confirmed many times, but to NEW rather than WONTFIX. 

See Michael M's. hint as in comment 60 and what IMHO are structural issues with our DirectWrite implementation as in bug 107521 and where we seem to now have wonky defaults initializing the DirectWrite rendering.

=-ref-=
http://opengrok.libreoffice.org/xref/core/vcl/inc/win/winlayout.hxx#199

Adding comment to confirm same issue on my end (Nvidia 550Ti with latest drivers, Win7 x64, 1680x1050). I had to disable OpenGL via registry hack since 5.1 to make LO even show menus. Now the text is fuzzy and menu flickers with or without HA and AA.

Just here to suggest to give this bug report a more high priority than normal for a more fast assignment. For some people with severe sight problems like me this bug have a big impact for the productivity, pushing me to use other office suite on Windows or turn on a Linux machine in the meanwhile.

Tomaž Vajngerl committed a patch related to this issue.
It has been pushed to "master":

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

tdf#106990 set cleartype setting / force to use GDI render mode

It will be available in 6.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.

Cherry-pick in progress for 5-4; thanks for the report - and to Tomaz for fixing =)

Sorry, what is the meaning of "cherry-picking" in this case? I am a bit clueless sorry again

It means that they are trying to copy the fix over to the version 5 development cycle, so that users can benefit from it faster and won't have to wait for version 6.

Tomaž Vajngerl committed a patch related to this issue.
It has been pushed to "libreoffice-5-4":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=238d6e367b3bcbc14cc7579dda866488a2c7f4c3&h=libreoffice-5-4

tdf#106990 set cleartype setting / force to use GDI render mode

It will be available in 5.4.0.2.

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.

Verified we have the correct behavior, including responding to system settings for use of ClearType.

on Windows 10 Pro 64-bit en-US with
Version: 6.0.0.0.alpha0+
Build ID: 7ab9f12b57b1cb25b8b29f8bcbf006968db6b679
CPU threads: 8; OS: Windows 6.19; UI render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2017-07-07_05:27:37
Locale: en-US (en_US); Calc: CL

side-by-side with yesterdays
Version: 6.0.0.0.alpha0+
Build ID: eda9605ad51c82c4dc7dedcb8910f2384d6cc460
CPU threads: 8; OS: Windows 6.19; UI render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2017-07-06_06:23:13
Locale: en-US (en_US); Calc: CL

With OpenGL rendering disabled, using default w/Hardware acceleration or just CPU for rendering, examine the menubar in Start Center looking at the "O" in open, and "C" in ctrl+ shortcuts.  Also, any open module's menubar the "O", "C" or "G" glyphs.

Hello, I tried release 5.4.0.2 yesterday, with all possible combinations of hardware acceleration, openGL and anti-alias option, but the meno fonts remained unchanged and bad to look at. Sorry... on windows 7 by the way

The 5.4.0.2 rc is posted to the prerelease server for any interested. Corrected DirectWrite rendering is evident, it functions correctly on Win8, 8.1 and 10. But users on XP and Vista may not see much change.

We are interested in what Win7 users report.  

Side-by-side screen clips 5.4.0.1 and earlier vs. 5.4.0.2 and later in different rendering modes (OpenGL, GPU, CPU with and without anti-aliasing) appreciated when critiquing.

=-ref-=
http://dev-builds.libreoffice.org/pre-releases/

Windows 7 here with Intel HD graphics used, AMD Radeon also available. 
I still see the problem in Impress as in Comment 11. Master, default rendering.

(In reply to V Stuart Foote from comment #61)
> The issue in Impress slide rendered with GPU "Use hardware acceleration" is
> open as bug 107090 -- likely related to DirectWrite handling but not the
> issue here.
Only saw this now, sorry.

Windows 10, libo-master64~2017-07-12_08.45.38_LibreOfficeDev_6.0.0.0.alpha0_Win_x64

Use hardware acceleration: yes
Use anti-aliasing: yes
Use OpenGL for all rendering: no

subpixel antialiasing is back and looks as good as ever. There's more flickering when, for example, menu items are highlighted though.

when "Use OpenGL for all rendering" is switched to "yes", subpixel antialiasing disappears, greyscale antialiasing is used instead. Text sharpness in OpenGL mode is *still* better than it used to be in 5.3.2.x, but, obviously, worse than what subpixel antialiasing provides. Looks like it's a feature that we're going to be stuck with for the rest of our lives - either fast GL rendering, or sharp text, but not both.

*** Bug 109086 has been marked as a duplicate of this bug. ***

With reference to the commit in comment 70, I wonder if the following could be a clue why it is causing a regression similar to bug 107166 together with the fix of that bug on some remote desktop connections:
"IDWriteFactory::CreateRenderingParams method

Creates a rendering parameters object with default settings for the primary monitor. Different monitors may have different rendering parameters, for more information see the How to Add Support for Multiple Monitors topic."
https://msdn.microsoft.com/en-us/library/windows/desktop/dd368201(v=vs.85).aspx

Windows 7 64-bit, LibreOffice x64

On my machine, I confirm that 5.3.4.2 was the first version with correct font anti aliasing. Which makes it frustrating that 5.4.0.3 seems to have reverted to pre-5.3.4 bad antialiasing.

Just checked with 5.4.0.3 on Windows 8.1-64:
- Settings: Hardware acceleration, anti-aliasing, no OpenGL
- Result: Absolutely NO improvement compared to 5.3.2.2
- All my previous comments still apply

Given that this issue has been set to "RESOLVED FIXED", is this really the expected result for 5.4.0.3? In other words, Will the fix only be available in 6.x?

Just checked with 5.4.1.2 on Windows 8.1-64:
- Settings: Hardware acceleration, anti-aliasing, no OpenGL
- Result: Absolutely NO improvement compared to 5.3.2.2
- All my previous comments still apply

So this issue obviously isn't fixed, neither in 5.4.0.3 nor in 5.4.1.2 releases. Reopening; could somebody please have a look if it's really unfixed or if it's just me doing something wrong?

I have tried 5.4.1.2, I can confirm the system fonts are looking bad, unfortunately

Created attachment 135976 [details]
samples from 1920x1080 desktop Intel HD 620 GPU

Do not see any problems with rendering. Attached zip shows Windows 10 (Intel HD 620 GPU) at 1920x1080 resolution--LibreOffice 5.4.1.2 main menu above a FireFox 55.0.3 main menu. 

The 3 clips show each of: CPU only rendering, Hardware Acceleration, and OpenGL rendering of the SegoeUI fonts.  There is no noticeable differences between the FireFox and the LibreOffice rendering of the same text.

I do not see the claimed "ugly and blurry" rendering.

Pretty clear this is resolved--Fixed and our restoration of Greycale rendering is having the desired effects.

Created attachment 135977 [details]
Comparison of 5.3.1.2 vs. 5.4.1.2

To demonstrate what I mean, I did another side-by-side comparison of the 5.3.1.2 release ("last known good" before the rendering problems started) and the current 5.4.1.2 release.

The screenshots were taken on the same machine and with identical settings (hardware acceleration ON, anti-aliasing ON, OpenGL OFF). While the difference is quite visible in the UI itself (sharpness of menus and dialog texts), it is almost extreme for in-document rendering.

(BTW: Turning anti-aliasing on or off seems to have no effect in 5.4.1.2 when OpenGL is disabled.)

(In reply to Lenge from comment #88)
> Created attachment 135977 [details]
> Comparison of 5.3.1.2 vs. 5.4.1.2
> 
> To demonstrate what I mean, I did another side-by-side comparison of the
> 5.3.1.2 release ("last known good" before the rendering problems started)
> and the current 5.4.1.2 release.
> 
> The screenshots were taken on the same machine and with identical settings
> (hardware acceleration ON, anti-aliasing ON, OpenGL OFF). While the
> difference is quite visible in the UI itself (sharpness of menus and dialog
> texts), it is almost extreme for in-document rendering.
> 
> (BTW: Turning anti-aliasing on or off seems to have no effect in 5.4.1.2
> when OpenGL is disabled.)

Please disable Hardware Acceleration, so CPU only, and repeat the clip. And the same with OpenGL enabled.

Do CPU only and OpenGL match--leaving just the Hardware Acceleration at issue in rendering canvas, not the UI--which actually is consistent with bug 107090.

Created attachment 135979 [details]
Detailed comparison with more options

Ok, here is a more detailed comparison with options separately enabled/disabled. Caution: The screenshots incorrectly say "5.4.2.1", but "5.4.1.2" is correct!
The results are as follows:

LibreOffice 5.4.1.2 (current release)
a) OpenGL off:
- Rendering is ugly and blurry (both UI and in-document)
- "Hardware acceleration" on/off has no effect
- "Anti-aliasing" on/off has no effect
b) OpenGL on:
- Rendering is slightly different (but still ugly and blurry)
- Horizontal ruler: Different rendering of vertical lines
- "Hardware acceleration" is disabled
- "Anti-aliasing" on/off has no effect

LibreOffice 5.3.1.2 (last known good)
a) OpenGL off:
- Rendering is crispy and sharp (both UI and in-document)
- "Hardware acceleration" on/off has no effect
- "Anti-aliasing" on/off has no effect
b) OpenGL on:
- Rendering is ugly and blurry as in 5.4.1.2 (no extra screenshots)

So the only way to get sharp rendering is to (1) use LO before 5.3.2 and (2) disable OpenGL (which has always been ugly and blurry, as already said in my previous comments).

However, I couldn't observe any specific differences caused by hardware acceleration, anti-aliasing, or between UI and in-document content.

Just tried 5.4.1, the issue is still present.

In my configuration, LO x86 on W10 x64 with an intel HD 3000,
GL is disabled by blacklist and can only be activated if I ignore blacklist.

Anyway, I think we should leave OpenGL out of this bug,
the issue appeared after the change to the default rendering between 5.3.1.2 and 5.3.2 so we only complexify the procedure by testing and comparing with GL enabled.

Hello

Same problem here with any version since 5.3.2

With or without OGL, fonts are fuzzy.

Windows 8.1 & Intel HD Graphics

I have to stay with 5.3.1 version.

I don't understand why setup or options don't propose to disable cleartype greyscale ?????

Sad :(

(In reply to JeffD from comment #93)
> 
> I personally would use the "Still" version of LO, if "Still" meant "stable",
> but the difference between the "Still" and "Fresh" version is that the new
> bugs in the "Fresh" version may be different than the unfixed bugs in the
> "Still" version, and the updates are still frequent in the "Still" version.

Perhaps you'd be more comfortable remaining on the 5.2.7 release, it is EOL but should be stable for you.

http://downloadarchive.documentfoundation.org/libreoffice/old/5.2.7.2/win/

(In reply to V Stuart Foote from comment #94)
> (In reply to JeffD from comment #93)
> > 
> > I personally would use the "Still" version of LO, if "Still" meant "stable",
> > but the difference between the "Still" and "Fresh" version is that the new
> > bugs in the "Fresh" version may be different than the unfixed bugs in the
> > "Still" version, and the updates are still frequent in the "Still" version.
> 
> Perhaps you'd be more comfortable remaining on the 5.2.7 release, it is EOL
> but should be stable for you.
> 
> http://downloadarchive.documentfoundation.org/libreoffice/old/5.2.7.2/win/

Thanks for the suggestion, but I believe that version had the bug that won't retain formatting when pasting RTF, as I mentioned above (bug 101828).  So it seems I have to go back further or just keep swapping one bug for another.

I never thought I'd do this, but I've actually started using AOO after telling everyone else that I thought it was pretty much dead and they should go with LO.

(In reply to JeffD from comment #95)
> I never thought I'd do this, but I've actually started using AOO after
> telling everyone else that I thought it was pretty much dead and they should
> go with LO.

Well good luck with AOO, especially when you attempt any substantive work with OOXML, or any cloud hosted files, or any of the dozens of other unsupported file formats that LibreOffice handles cleanly.

Personally I've dropped use of the 5.3 branch, and would recommend a slide forward onto 5.4 branch where any development effort--drawn from 6.0/master--that will see this resolved would be back-ported. 

LibreOffice continues to work well for me and most others, but YMMV and as you note there are alternatives.

(In reply to V Stuart Foote from comment #96)
> (In reply to JeffD from comment #95)
> 
> Well good luck with AOO, especially when you attempt any substantive work
> with OOXML, or any cloud hosted files, or any of the dozens of other
> unsupported file formats that LibreOffice handles cleanly.
> 
> Personally I've dropped use of the 5.3 branch, and would recommend a slide
> forward onto 5.4 branch where any development effort--drawn from
> 6.0/master--that will see this resolved would be back-ported. 
> 
> LibreOffice continues to work well for me and most others, but YMMV and as
> you note there are alternatives.

Yes, I don't use the cloud and try to stick to native Open Document formats, and apparently "most others" means everyone who doesn't use MS Windows, as, from what I can see, it appears everyone on Windows seems to be affected.

I am sorry to mix things up a bit, but I would like to summarize the main problems I experiences with the modified fonts display technique in latest releases (lo5.3.2 and further). I am doing this because taken togheter they are quite problematic. Everything is based on trails conducted on 2 different windows 7 PC (there is no difference in outcome between the 2):

1)font rendering for all GUI of the suite are ugly and unpolished, and things are a bit worse also for document contens (even if the latter is less  evident than in the GUI rendering - menus, dialog windows etc.)

2) the scrolling of content displayed on a document, especially calc sheets, has slowed down and become jerky. This slowing down makes LO downright unusable when the screen shows a lot of data (see the details I posted in bug 107521), causing scrolling to be around 13 THIRTEEN times slower than with lo5.3.1. At those speed keyboard buffer becomes impossible to control and is extremely difficult to navigate your spreadsheets

3) full screen impress presentations are rendered in a dramatically bad fashion when hardware display accel is enabled. This can be avoided disabling Hardware accel, but I still have to understand what this disabling implies for other functions. Or is a totally useless option?

Please notice that problems 1) and 2) are not mitigated in ANY combination of display settings (hardware accel and opengl. All together , IMHO this problems make for a compelling case supporting the need to solve this.
In terms of critical nature, for power users n. 2 is the worst, and there seems to be NO workaround whatsoever.

(In reply to Andy from comment #98)

> 
> Please notice that problems 1) and 2) are not mitigated in ANY combination
> of display settings (hardware accel and opengl. All together , IMHO this
> problems make for a compelling case supporting the need to solve this.
> In terms of critical nature, for power users n. 2 is the worst, and there
> seems to be NO workaround whatsoever.

If I may add; even if there was some magic combination of settings that made LO usable, I doubt the average user considering switching to a free open source solution and trying LO out for the first time would likely be compelled to search for that magic combination before deciding they need to keep forking out money for a commercial office product.  Their first impression of LO would be that it is a low quality product. Users simply aren't accustomed to products that have such problems on their default settings.

AFAICS the griping about LibreOffice being a volunteer project in the bug is counter-productive when it comes to interesting volunteer developers in fixing it - also by now this bug is far too long to read in any tractable time for a volunteer. I would suggest that we close this bug, and create a series of new issues. 

Ultimately - I'm fairly convinced that Microsoft's new / DirectWrite rendering is a performance horror, and that by far the best approach would be to go to freetype-everywhere. Unfortuantely that is a chunk of work, and leaves us with some serious printing problems - Windows not providing any sensible print / output API unfortunately such as eg. PDF (and XPS hardly counts).

(In reply to Michael Meeks from comment #100)
> ... griping about LibreOffice ... is counter-productive ...
Agreed. Yet as this is a major issue that affects many users, it should be taken seriously. Which in turn means ...

> I would suggest that we close this bug, and create a series of new issues.
... that closing it would be the worst thing to do. While I agree that the discussion here has become quite complex, the plain facts are:

1. This bug exactly describes the problem as it (still) is.
2. It is a major issue that affects many users.
3. It is a regression introduced by a minor version update (5.3.1 to 5.3.2).
4. None of the actions taken so far (subsequent updates, alleged fixes etc.) has improved anything. In short, it has not been fixed in any way.
5. Numerous spin-off issues have already been created that focus on certain follow-up aspects such as DirectWrite improvements.

Closing this bug would only send the message that this thing is not taken seriously. Any subsequent issues would only unnecessarily reproduce all the examinations, examples and attachments that are already here.

> Ultimately - I'm fairly convinced that Microsoft's new / DirectWrite
> rendering is a performance horror, and that by far the best approach would
> be to go to freetype-everywhere. [...]
If that is the case, then the one and only solution to *this* bug is to fully revert any and all rendering to how it was in the 5.3.1 release - and leave it that way until a new solution is (1) available, (2) sufficiently usable, and (3) provides the same level of quality as 5.3.1 default rendering.

(In reply to Pierre C from comment #102)
issue with text rendering to Impress canvas with Hardware Acceleration active is bug 107090 -- not this issue. 

But 'til fixed, can either use OpenGL rendering or use just CPU rendering for your presentations. With CPU only you may need to adjust some of the transitions.

I have no technical knowledge of what is implied, but as things stand at present, I totally agree with Lenge comment n. 101:

"If that is the case, then the one and only solution to *this* bug is to fully revert any and all rendering to how it was in the 5.3.1 release - and leave it that way until a new solution is (1) available, (2) sufficiently usable, and (3) provides the same level of quality as 5.3.1 default rendering."

The whole thing has really been a bad dream. Part of it, users like me cannot grasp what advantages we are benefiting to outbalance all the trouble, anguish and stress in discovering, following and coping with the issue.

Please understand that I do not want to sound negative or polemic at all.

Due to the great number of comments in this report, I've been forced to created a follow-up bug based on the latest constructive comment in here.
Please, in the new report, comment only if the information provided helps to fix the issue, otherwise it's not of much help. Thanks

*** This bug has been marked as a duplicate of bug 112492 ***

Please do not reply on this resolved BZ issue. 

But fyi, for those affected (and unable to run OpenGL).

The patch [1] just applied against a 5.3.7 release-- tdf#112486 Do not force GDI in no OpenGL, restores rendering quality. TDF TinderBox 62 builds available for testing both 32-bit and 64-bit build with the patch [2].

Assuming no issues are identified with this patch it will be included in the final 5.3 release, but _not yet_ in any fashion for the 5.4 or 6.0 builds. 

Please test, but respond on the open bz issue bug 112492, not here.

=-ref-=
[1] http://cgit.freedesktop.org/libreoffice/core/commit/?id=5440837e02dee8bc884e02be697bfd4def621d26&h=libreoffice-5-3

[2] http://dev-builds.libreoffice.org/daily/libreoffice-5-3/

(In reply to Michael Meeks from comment #100)
> AFAICS the griping about LibreOffice being a volunteer project in the bug is
> counter-productive when it comes to interesting volunteer developers in
> fixing it - also by now this bug is far too long to read in any tractable
> time for a volunteer. I would suggest that we close this bug, and create a
> series of new issues. 
> 
> Ultimately - I'm fairly convinced that Microsoft's new / DirectWrite
> rendering is a performance horror, and that by far the best approach would
> be to go to freetype-everywhere. Unfortuantely that is a chunk of work, and
> leaves us with some serious printing problems - Windows not providing any
> sensible print / output API unfortunately such as eg. PDF (and XPS hardly
> counts).

AFAICS, the "griping" was not about LO being a volunteer project, but about the quality of the software.  And as for the "griping" being "counter-productive", it appears that the problem would never have been taken at all seriously otherwise.  But now, after over a year and a half there is at least a workaround, even as other regressions have been as much as promised.

But I'll try to leave it alone now, as I have returned to OpenOffice so I don't have to deal with the continual regressions and be accused of "griping" for expecting a functional product.

Thanks.