athens font rendering and subpixel antialiasing
Anyone knows, why the text rendering with athens (cairo) looks slightly different than the freetypeplugin one? attached is a screenshot, left side athen right side (morphic) freetypeplugin. It "looks" like the cairo freetype fontrendering uses CAIRO_ANTIALIAS_GRAY, no colored subpixel antialiasing. But the font options do define antialiase subpixel and a subpixel ordering RGB. This is on windows 7 with the latest vm, does it look different on other Systems? nicolai
Weird⦠Both FT plugin and Athens use same library (even same instance)⦠but could be something on how cairo threats them what makes a difference, I suppose. Esteban
On 11 Jan 2015, at 18:43, Nicolai Hess <nicolaihess@web.de> wrote:
Anyone knows, why the text rendering with athens (cairo) looks slightly different than the freetypeplugin one?
attached is a screenshot, left side athen right side (morphic) freetypeplugin.
It "looks" like the cairo freetype fontrendering uses CAIRO_ANTIALIAS_GRAY, no colored subpixel antialiasing. But the font options do define antialiase subpixel and a subpixel ordering RGB.
This is on windows 7 with the latest vm, does it look different on other Systems?
nicolai
<athens_subpixel.png>
No idea, but it would be great to improve the situation with the Cairo integration. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Jan 11, 2015, at 6:43 PM, Nicolai Hess <nicolaihess@web.de> wrote:
Anyone knows, why the text rendering with athens (cairo) looks slightly different than the freetypeplugin one?
attached is a screenshot, left side athen right side (morphic) freetypeplugin.
It "looks" like the cairo freetype fontrendering uses CAIRO_ANTIALIAS_GRAY, no colored subpixel antialiasing. But the font options do define antialiase subpixel and a subpixel ordering RGB.
This is on windows 7 with the latest vm, does it look different on other Systems?
nicolai
<athens_subpixel.png>
Igor once explained to me that FreeType has the possibility to degrade fonts when the family does not provide it. Cairo does not have this possibility. Esteban I'm sure that the same code is used. FreeType is much more advanced than Cairo when it is about fonts. Stef Le 11/1/15 22:43, Nicolai Hess a écrit :
Anyone knows, why the text rendering with athens (cairo) looks slightly different than the freetypeplugin one?
attached is a screenshot, left side athen right side (morphic) freetypeplugin.
It "looks" like the cairo freetype fontrendering uses CAIRO_ANTIALIAS_GRAY, no colored subpixel antialiasing. But the font options do define antialiase subpixel and a subpixel ordering RGB.
This is on windows 7 with the latest vm, does it look different on other Systems?
nicolai
2015-01-12 19:19 GMT+01:00 stepharo <stepharo@free.fr>:
Igor once explained to me that FreeType has the possibility to degrade fonts when the family does not provide it. Cairo does not have this possibility. Esteban I'm sure that the same code is used. FreeType is much more advanced than Cairo when it is about fonts.
There is a setting for the freetype plugin: Monitor type LCD/CRT. If I change this to CRT, the freetypelugin font rendering looks more like the cairo on, no colored antialiasing. (freetype plugin ones still look a little bit better, a bit more "bold").
Stef
Le 11/1/15 22:43, Nicolai Hess a écrit :
Anyone knows, why the text rendering with athens (cairo) looks slightly
different than the freetypeplugin one?
attached is a screenshot, left side athen right side (morphic) freetypeplugin.
It "looks" like the cairo freetype fontrendering uses CAIRO_ANTIALIAS_GRAY, no colored subpixel antialiasing. But the font options do define antialiase subpixel and a subpixel ordering RGB.
This is on windows 7 with the latest vm, does it look different on other Systems?
nicolai
Le 12/1/15 19:19, stepharo a écrit :
Igor once explained to me that FreeType has the possibility to degrade fonts when the family does not provide it. Cairo does not have this possibility. Esteban I'm sure that the same code is used. FreeType is much more advanced than Cairo when it is about fonts. Esteban are you sure that the same code is used? Because I would have thought the opposite.
Stef
Le 11/1/15 22:43, Nicolai Hess a écrit :
Anyone knows, why the text rendering with athens (cairo) looks slightly different than the freetypeplugin one?
attached is a screenshot, left side athen right side (morphic) freetypeplugin.
It "looks" like the cairo freetype fontrendering uses CAIRO_ANTIALIAS_GRAY, no colored subpixel antialiasing. But the font options do define antialiase subpixel and a subpixel ordering RGB.
This is on windows 7 with the latest vm, does it look different on other Systems?
nicolai
On 13 Jan 2015, at 13:48, stepharo <stepharo@free.fr> wrote:
Le 12/1/15 19:19, stepharo a écrit :
Igor once explained to me that FreeType has the possibility to degrade fonts when the family does not provide it. Cairo does not have this possibility. Esteban I'm sure that the same code is used. FreeType is much more advanced than Cairo when it is about fonts. Esteban are you sure that the same code is used? Because I would have thought the opposite.
AFAIK, Cairo uses freetype library for rendering fonts. Thatâs why Igor spent some time making sure that freetype library is not loaded twice (one for the plugin and one other for athens). So, it should be the same external library, but probably not the same Pharo code. Esteban
Stef
Le 11/1/15 22:43, Nicolai Hess a écrit :
Anyone knows, why the text rendering with athens (cairo) looks slightly different than the freetypeplugin one?
attached is a screenshot, left side athen right side (morphic) freetypeplugin.
It "looks" like the cairo freetype fontrendering uses CAIRO_ANTIALIAS_GRAY, no colored subpixel antialiasing. But the font options do define antialiase subpixel and a subpixel ordering RGB.
This is on windows 7 with the latest vm, does it look different on other Systems?
nicolai
It looks like this gray-scale vs. colored subpixel antialiasing is an issue on windows. I did the same test on linux (Ubuntu 14.04) (screenshot attached). But still, the font rendering with the freetype plugin (morphic way) looks better than the athens one. any ideas/help?
On 25 Jan 2015, at 9:38 , Nicolai Hess <nicolaihess@web.de> wrote:
It looks like this gray-scale vs. colored subpixel antialiasing is an issue on windows. I did the same test on linux (Ubuntu 14.04) (screenshot attached). But still, the font rendering with the freetype plugin (morphic way) looks better than the athens one.
any ideas/help?
<world_menu_athens.png><world_menu_morphic.png>
Looks like 2 major differences to me; - No kerning (custom distance between character pairs, not defined solely by glyph size, o - r pair is pretty obvious) Not familiar with the athens path, in FreeTypeFonts this is handled image-side. - 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. Cheers, Henry
2015-01-26 11:35 GMT+01:00 Henrik Johansen <henrik.s.johansen@veloxit.no>:
On 25 Jan 2015, at 9:38 , Nicolai Hess <nicolaihess@web.de> wrote:
It looks like this gray-scale vs. colored subpixel antialiasing is an issue on windows. I did the same test on linux (Ubuntu 14.04) (screenshot attached). But still, the font rendering with the freetype plugin (morphic way) looks better than the athens one.
any ideas/help?
<world_menu_athens.png><world_menu_morphic.png>
Looks like 2 major differences to me; - No kerning (custom distance between character pairs, not defined solely by glyph size, o - r pair is pretty obvious) Not familiar with the athens path, in FreeTypeFonts this is handled image-side.
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 :)
Cheers, Henry
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
**** 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 <stepharo@free.fr>:
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
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 <nicolaihess@web.de>:
**** 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 <stepharo@free.fr>:
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
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 b) many many apps, using these libs to render with subpixel quality. -- Best regards, Igor Stasenko.
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.
On 2 February 2015 at 12:31, Nicolai Hess <nicolaihess@web.de> wrote:
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.
Then, my guess, making it work on linux would be the first step. Changing build options for building cairo/freetype libs for our VMs is not a big deal then, as long as we will know how to do things properly.
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
On 02 Feb 2015, at 01:06, Nicolai Hess <nicolaihess@web.de> wrote:
I do not know, and I'm starting to lose all interest.
Nicolai, Please don't give up. You are doing great work and we are all *very* impressed with your attitude/drive/motivation, especially since you are covering such a wide range of subjects. I know that the hard thing right now is that you do not find enough sparring partners (that goes for others tackling different issues as well). Sven
Another idea would be to create a freetype face instance by directly calling freetype library, avoiding any interference with freetype plugin and in-image code for it etc. Because i suspecting there's something with the way it handles options/font matrix etc, that at some point got overridden, while cairo expecting it to be unchanged. -- Best regards, Igor Stasenko.
On Mon, Feb 2, 2015 at 10:51 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 02 Feb 2015, at 01:06, Nicolai Hess <nicolaihess@web.de> wrote:
I do not know, and I'm starting to lose all interest.
Nicolai,
Please don't give up.
Yeah, don't. You rock.
You are doing great work and we are all *very* impressed with your attitude/drive/motivation, especially since you are covering such a wide range of subjects. I know that the hard thing right now is that you do not find enough sparring partners (that goes for others tackling different issues as well).
Sven
Phil
2015-02-02 11:13 GMT+01:00 phil@highoctane.be <phil@highoctane.be>:
On Mon, Feb 2, 2015 at 10:51 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 02 Feb 2015, at 01:06, Nicolai Hess <nicolaihess@web.de> wrote:
I do not know, and I'm starting to lose all interest.
Nicolai,
Please don't give up.
Yeah, don't. You rock.
:) Thanks
You are doing great work and we are all *very* impressed with your attitude/drive/motivation, especially since you are covering such a wide range of subjects. I know that the hard thing right now is that you do not find enough sparring partners (that goes for others tackling different issues as well).
Sven
Phil
+ 10000 ^ 10000 Stef Le 2/2/15 10:51, Sven Van Caekenberghe a écrit :
On 02 Feb 2015, at 01:06, Nicolai Hess <nicolaihess@web.de> wrote:
I do not know, and I'm starting to lose all interest. Nicolai,
Please don't give up.
You are doing great work and we are all *very* impressed with your attitude/drive/motivation, especially since you are covering such a wide range of subjects. I know that the hard thing right now is that you do not find enough sparring partners (that goes for others tackling different issues as well).
Sven
On 02 Feb 2015, at 11:40, stepharo <stepharo@free.fr> wrote:
+ 10000 ^ 10000
You mean, + 10000 ** 10000, right ;-)
Stef Le 2/2/15 10:51, Sven Van Caekenberghe a écrit :
On 02 Feb 2015, at 01:06, Nicolai Hess <nicolaihess@web.de> wrote:
I do not know, and I'm starting to lose all interest. Nicolai,
Please don't give up.
You are doing great work and we are all *very* impressed with your attitude/drive/motivation, especially since you are covering such a wide range of subjects. I know that the hard thing right now is that you do not find enough sparring partners (that goes for others tackling different issues as well).
Sven
On Mon, Feb 2, 2015 at 8:06 AM, 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).
In trying to learn some background info, this found article [1] seems good, from which I learn: * Freely scalable it must be free from character drift. I guess this is what we want ? * Three main types of font rendering: * Hinting trades accuracy for consistency, and as a consequence of this, hinted text _accumulates character drift_ with hinted glyphs, often possessing different metrics to their un-hinted counterparts. So I guess we don't use hinting, which implies not freely scalable ? * Anti-aliasing results in output which is accurate but blurred, trading contrast for consistency and accuracy. * Sub-pixel-rendering exploits the physical geometry of LCD screens to increase the horizontal resolution of the device. Needs to be filtered to avoid color fringing and is incompatible with aggressive hinting strategies. * Sub-pixel-positioning is a generalisation of anti-aliasing and/or sub-pixel-rendering to allow for more accurate glyph placement, and is incompatible with aggressive hinting strategies. That article [1] advises: * For sub-pixel-rendering to function correctly it is necessary to enable the patent encumbered LCD filtering API. Many distributions, including Debian, do this already and is generally not a problem. * Versions of Cairo before the 1.10 release use their own intra-pixel filter. As of 2009 there are two sets of patches available that update legacy releases of Cairo to use an FIR inter-pixel filter. The first set pre-dates the filtering interface in FreeType and uses a custom FIR filter with the coefficients outlined in Gib98. The second set of patches, by David Turner, take advantage of the FreeType filtering interface. * It is recommended that distributions upgrade to Cairo 1.10 where at all possible. Here [2] is a post on that. So btw, what version of Cario are we using? I see latest is version 1.12.18. [1] https://freddie.witherden.org/pages/font-rasterisation/#spo07 [2] http://lists.cairographics.org/archives/cairo/2010-January/018859.html
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 <nicolaihess@web.de>:
**** 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 <stepharo@free.fr>:
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
On 2 February 2015 at 11:23, Ben Coman <btc@openinworld.com> wrote:
On Mon, Feb 2, 2015 at 8:06 AM, 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).
In trying to learn some background info, this found article [1] seems good, from which I learn:
* Freely scalable it must be free from character drift.
I guess this is what we want ?
* Three main types of font rendering:
* Hinting trades accuracy for consistency, and as a consequence of this, hinted text _accumulates character drift_ with hinted glyphs, often possessing different metrics to their un-hinted counterparts.
So I guess we don't use hinting, which implies not freely scalable ?
* Anti-aliasing results in output which is accurate but blurred, trading contrast for consistency and accuracy.
* Sub-pixel-rendering exploits the physical geometry of LCD screens to increase the horizontal resolution of the device. Needs to be filtered to avoid color fringing and is incompatible with aggressive hinting strategies.
* Sub-pixel-positioning is a generalisation of anti-aliasing and/or sub-pixel-rendering to allow for more accurate glyph placement, and is incompatible with aggressive hinting strategies.
That article [1] advises:
* For sub-pixel-rendering to function correctly it is necessary to enable the patent encumbered LCD filtering API. Many distributions, including Debian, do this already and is generally not a problem.
* Versions of Cairo before the 1.10 release use their own intra-pixel filter. As of 2009 there are two sets of patches available that update legacy releases of Cairo to use an FIR inter-pixel filter. The first set pre-dates the filtering interface in FreeType and uses a custom FIR filter with the coefficients outlined in Gib98. The second set of patches, by David Turner, take advantage of the FreeType filtering interface.
* It is recommended that distributions upgrade to Cairo 1.10 where at all possible. Here [2] is a post on that.
So btw, what version of Cario are we using? I see latest is version 1.12.18.
CMCairo>>downloadURL ^ 'http://www.cairographics.org/releases/cairo-1.12.14.tar.xz'
[1] https://freddie.witherden.org/pages/font-rasterisation/#spo07 [2] http://lists.cairographics.org/archives/cairo/2010-January/018859.html
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 <nicolaihess@web.de>:
**** 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 <stepharo@free.fr>:
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
-- Best regards, Igor Stasenko.
2015-02-02 11:23 GMT+01:00 Ben Coman <btc@openinworld.com>:
On Mon, Feb 2, 2015 at 8:06 AM, 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).
In trying to learn some background info, this found article [1] seems good, from which I learn:
* Freely scalable it must be free from character drift.
I guess this is what we want ?
* Three main types of font rendering:
* Hinting trades accuracy for consistency, and as a consequence of this, hinted text _accumulates character drift_ with hinted glyphs, often possessing different metrics to their un-hinted counterparts.
So I guess we don't use hinting, which implies not freely scalable ?
* Anti-aliasing results in output which is accurate but blurred, trading contrast for consistency and accuracy.
* Sub-pixel-rendering exploits the physical geometry of LCD screens to increase the horizontal resolution of the device. Needs to be filtered to avoid color fringing and is incompatible with aggressive hinting strategies.
Yes, in the freetypeplugin settings, you can switch between Monitortype LCD and CRT
* Sub-pixel-positioning is a generalisation of anti-aliasing and/or sub-pixel-rendering to allow for more accurate glyph placement, and is incompatible with aggressive hinting strategies.
Yes, in the freetypeplugin settings, you can change the hinting style Light/Normal/Full. With Full-Hinting there is no subpixelantialising anymore. Similiar options are available for cairo/freetype. The settings for Monitortype and hinting have an influence on the rendering in the freetype library *and* the postprocessing that is done in pharos FreeTypePlugin. The same for FreeType and Cairo
That article [1] advises:
* For sub-pixel-rendering to function correctly it is necessary to enable the patent encumbered LCD filtering API. Many distributions, including Debian, do this already and is generally not a problem.
* Versions of Cairo before the 1.10 release use their own intra-pixel filter. As of 2009 there are two sets of patches available that update legacy releases of Cairo to use an FIR inter-pixel filter. The first set pre-dates the filtering interface in FreeType and uses a custom FIR filter with the coefficients outlined in Gib98. The second set of patches, by David Turner, take advantage of the FreeType filtering interface.
* It is recommended that distributions upgrade to Cairo 1.10 where at all possible. Here [2] is a post on that.
So btw, what version of Cario are we using? I see latest is version 1.12.18.
[1] https://freddie.witherden.org/pages/font-rasterisation/#spo07 [2] http://lists.cairographics.org/archives/cairo/2010-January/018859.html
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 <nicolaihess@web.de>:
**** 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 <stepharo@free.fr>:
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
participants (9)
-
Alexandre Bergel -
Ben Coman -
Esteban Lorenzano -
Henrik Johansen -
Igor Stasenko -
Nicolai Hess -
phil＠highoctane.be -
stepharo -
Sven Van Caekenberghe