2015-02-02 10:46 GMT+01:00 Igor Stasenko <siguctua@gmail.com>:
On 2 February 2015 at 01:06, Nicolai Hess <nicolaihess@web.de> wrote:
Ok, the best I could do:
Sadly, it only works because I changed the default lcd_filter from cairo. in cairo 1.7. was a public API for the lcd_filter. since 1.8 this API is private again (the code for the different filter settings is still there). You can choose between FT_LCD_FILTER_NONE FT_LCD_FILTER_LEGACY FT_LCD_FILTER_LIGHT FT_LCD_FILTER_DEFAULT
the default is FT_LCD_FILTER_LEGACY but for this (so far, the best) result I used FT_LCD_FILTER_DEFAULT But there is no public API for this function anymore, so I had to change the code.
We have to discuss how we proceed.
The problems: font rendering looks ugly ( at least for small font size like for menus, lists and codepanes) font rendering looks different on windows and linux
possible solutions: change build options for Freetype on Windos (enable FT_CONFIG_OPTION_SUBPIXEL_RENDERING, potential patent infringement?) change default filter (patching cairo source)
or we leave everything as it is. I do not know, and I'm starting to lose all interest.
I guess, to understand what happens, best would be to write a small C app, that does the rendering.. and see what goes where. Something doesn't works there.. but i was unable to figure what or why.
I doubt that changing freetype library build settings is right way to deal with issue, because a) both cairo/freetype used on linux out of the box
But I think freetype on linux has this config enabled (and in fact, the rendering looks different on windows and linux until I changed that option for windows) and I read somewhere, that ubunut(or other distributions?) patched cairo, just to get this filter setting api back.
b) many many apps, using these libs to render with subpixel quality.
This is what drives me crazy, doing text rendering right, is difficult yes, but this is the reason why we are using dedicated libraries.
-- Best regards, Igor Stasenko.