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. nicolai 2015-02-01 19:38 GMT+01:00 Nicolai Hess <[email protected]>: > **** patents! > > Hours, and days digging in the code for font rendering with cairo. > I tried to find out why this "colored" subpixel antialising is not working > although > all option settings are set (in cairo) and in the source code of cairo the > FT_SetLCDFilter > call is really used! But the output does is just the same as with > CAIRO_ANTIALIAS_GRAY, > > ... until I found THIS in the freetype config: > > /* Uncomment the line below if you want to activate sub-pixel rendering */ > /* (a.k.a. LCD rendering, or ClearType) in this build of the library. */ > /* */ > /* Note that this feature is covered by several Microsoft patents */ > /* and should not be activated in any default build of the library. */ > /* */ > /* This macro has no impact on the FreeType API, only on its */ > /* _implementation_. For example, using FT_RENDER_MODE_LCD when calling */ > /* FT_Render_Glyph still generates a bitmap that is 3 times wider than */ > /* the original size in case this macro isn't defined; however, each */ > /* triplet of subpixels has R=G=B. */ > > > > > ARGH! > > It still does not look as good as with the pharos freetypeplugin, but AT > LEAST it looks > equally on windows and linux , yeh. > > > attached are three screenshots comparing > the different athens drawings with the freetypeplugin > athens on linux vs ftplugin > athens on windows vs ftplugin > athens on windows with enabled FT_CONFIG_SUBPIXEL_RENDERING vs ftplugin > > > > > > > > > > > > 2015-01-31 10:18 GMT+01:00 stepharo <[email protected]>: > >> >> In athens, there are "hints" you can set. >> (CairoFontOptions/hintMetricsOff/hintMetricsOn/hintStyleFull ....) >> I played a bit with different settings. Changing this settings change >> the output, but I can not get it to look >> like with the freetype plugin. I understand that this can not look >> equally, because the FreeTypePlugin and caire work differently, >> but the athens result looks bad compared with the other one. >> >> >> >>> - Pixel fitting. (The aliasing going on at the top of characters) Put >>> Hinting: None in FreeType advanced features, and you will probably see >>> something similar to the Athens rendering. >>> >> >> Yes, we can change the freetypeplugin setting and cairofontoption >> setting to make the output look equally - ugly :) >> >> >> Nicolai >> >> Igor explained to me that FreeType offers a degenerated mode that when >> the font does have the information for bold, kerning,.... >> computes a "guessed and approximated" default. Cairo does not offer this >> api else Athens would use it. >> So what would be interesting is to test using font having all the >> information to see if Cairo display well the fonts. >> >> Stef >> > >
