Hey everybody-
I seem to be consistantly running into troubles with Freetype and Greenville. I suspect the problem stems from Freetype trying to render the glyph with too many shades of grey, and I *SERIOUSLY NEED* somebody to fix it.
Here is a more technical view of the situation, and the problem:
The TrueType hinting system allows each pixel to be subdivided into sub-units. There are 81 subunits per pixel, in a 9x9 grid, with the center being the origin point. So, it looks something like this:
87654321012345678 7XXXXXXXXXXXXXXXX 6XXXXXXXXXXXXXXXX 5XXXXXXXXXXXXXXXX 4XXXXXXXXXXXXXXXX 3XXXXXXXXXXXXXXXX 2XXXXXXXXXXXXXXXX 1XXXXXXXXXXXXXXXX 0XXXXXXXXXXXXXXXX 1XXXXXXXXXXXXXXXX 2XXXXXXXXXXXXXXXX 3XXXXXXXXXXXXXXXX 4XXXXXXXXXXXXXXXX 5XXXXXXXXXXXXXXXX 6XXXXXXXXXXXXXXXX 7XXXXXXXXXXXXXXXX 8XXXXXXXXXXXXXXXX
That represents the total number of subunits, and their coordinate placements within 1 pixel.
The windows rasterizer determines the 'shade' the pixel will get, based on % of coverage this pixel gets from the outline, as does freetype. The problem shows up, because The windows type rasterizer only renders 16 shades, including Black and White, while the Freetype one renders 256 shades.
There are only 81 units, however.
What does this mean? It means that under freetype as it currently stands, if even *ONE* pixel subunit is covered by an outline, it will render as a shade of grey--- While the exact same pixel, with the windows rasterizer, will render as 'white' instead.
This is because "white" is 1/256th coverage, and there are only 81 subunits-- Essentially meaning that in order to get 'white' out of freetype, the pixel cannot be touched *AT ALL* by the glyph outline.
On the windows rasterizer, there are only 16 shades of grey, so up to 1/16th of the area can be covered, and still rendered as 'white'-- or 5 subunits covered.
This is why the windows rasterizer produces crisper images than Freetype.
I don't know how to fix this behavior in Freetype, and *SERIOUSLY* need said behavior changed, As soon as possible.
Thank you.
__________________________________ Do you Yahoo!? The all-new My Yahoo! - Get yours free! http://my.yahoo.com
Hi I am reading the freetype doc. you can change it from 256 shades of grey to 16 shades of grey. That meain the hole freetype need to be recomping
in some where in \freetype\include\freetype\config\ you got follow files ftoption.h and ftmodule.h
that controll the hole setting for freetype. I am not a expert on freetype. I maby complete wrong, but I think we can change the T1_MAX_SUBRS_CALLS value in ftoption.h to 4 instead for 16
Look at all setting there if it some thing I miss. Magnus (GreatLord)
Citerar Wierd Wierd wierd_w@yahoo.com:
Hey everybody-
I seem to be consistantly running into troubles with Freetype and Greenville. I suspect the problem stems from Freetype trying to render the glyph with too many shades of grey, and I *SERIOUSLY NEED* somebody to fix it.
Here is a more technical view of the situation, and the problem:
The TrueType hinting system allows each pixel to be subdivided into sub-units. There are 81 subunits per pixel, in a 9x9 grid, with the center being the origin point. So, it looks something like this:
87654321012345678 7XXXXXXXXXXXXXXXX 6XXXXXXXXXXXXXXXX 5XXXXXXXXXXXXXXXX 4XXXXXXXXXXXXXXXX 3XXXXXXXXXXXXXXXX 2XXXXXXXXXXXXXXXX 1XXXXXXXXXXXXXXXX 0XXXXXXXXXXXXXXXX 1XXXXXXXXXXXXXXXX 2XXXXXXXXXXXXXXXX 3XXXXXXXXXXXXXXXX 4XXXXXXXXXXXXXXXX 5XXXXXXXXXXXXXXXX 6XXXXXXXXXXXXXXXX 7XXXXXXXXXXXXXXXX 8XXXXXXXXXXXXXXXX
That represents the total number of subunits, and their coordinate placements within 1 pixel.
The windows rasterizer determines the 'shade' the pixel will get, based on % of coverage this pixel gets from the outline, as does freetype. The problem shows up, because The windows type rasterizer only renders 16 shades, including Black and White, while the Freetype one renders 256 shades.
There are only 81 units, however.
What does this mean? It means that under freetype as it currently stands, if even *ONE* pixel subunit is covered by an outline, it will render as a shade of grey--- While the exact same pixel, with the windows rasterizer, will render as 'white' instead.
This is because "white" is 1/256th coverage, and there are only 81 subunits-- Essentially meaning that in order to get 'white' out of freetype, the pixel cannot be touched *AT ALL* by the glyph outline.
On the windows rasterizer, there are only 16 shades of grey, so up to 1/16th of the area can be covered, and still rendered as 'white'-- or 5 subunits covered.
This is why the windows rasterizer produces crisper images than Freetype.
I don't know how to fix this behavior in Freetype, and *SERIOUSLY* need said behavior changed, As soon as possible.
Thank you.
Do you Yahoo!? The all-new My Yahoo! - Get yours free! http://my.yahoo.com
Ros-dev mailing list Ros-dev@reactos.com http://reactos.com:8080/mailman/listinfo/ros-dev
Just to let you know...I've already made experimental patch yesterday and showed it to Wierd_W. It modifies only one line in ftgrays.c.
Regards, Filip
----- PŮVODNÍ ZPRÁVA ----- Od: magnus@itkonsult-olsen.com Komu: "ReactOS Development List" ros-dev@reactos.com Předmět: Re: [ros-dev] Greenville: The story of Freetype VS the Datum: 19.11.2004 - 10:28:32
Hi I am reading the freetype doc. you can change it from 256 shades of grey to 16 shades of grey. That meain the hole freetype need to be recomping
in some where in \freetype\include\freetype\config\ you got follow files ftoption.h and ftmodule.h
that controll the hole setting for freetype. I am not a expert on freetype. I maby complete wrong, but I think we can change the T1_MAX_SUBRS_CALLS value in
ftoption.h > to 4 instead for 16
Look at all setting there if it some thing I miss. Magnus (GreatLord)
Citerar Wierd Wierd wierd_w@yahoo.com:
Hey everybody-
I seem to be consistantly running into troubles with Freetype and Greenville. I suspect the problem stems from Freetype trying to render the glyph with too many shades of grey, and I *SERIOUSLY NEED* somebody to fix it.
Here is a more technical view of the situation, and the problem:
The TrueType hinting system allows each pixel to be subdivided into sub-units. There are 81 subunits per pixel, in a 9x9 grid, with the center being the origin point. So, it looks something like this:
87654321012345678 7XXXXXXXXXXXXXXXX 6XXXXXXXXXXXXXXXX 5XXXXXXXXXXXXXXXX 4XXXXXXXXXXXXXXXX 3XXXXXXXXXXXXXXXX 2XXXXXXXXXXXXXXXX 1XXXXXXXXXXXXXXXX 0XXXXXXXXXXXXXXXX 1XXXXXXXXXXXXXXXX 2XXXXXXXXXXXXXXXX 3XXXXXXXXXXXXXXXX 4XXXXXXXXXXXXXXXX 5XXXXXXXXXXXXXXXX 6XXXXXXXXXXXXXXXX 7XXXXXXXXXXXXXXXX 8XXXXXXXXXXXXXXXX
That represents the total number of subunits, and their coordinate placements within 1 pixel.
The windows rasterizer determines the 'shade' the pixel will get, based on % of coverage this pixel gets from the outline, as does freetype. The problem shows up, because The windows type rasterizer only renders 16 shades, including Black and White, while the Freetype one renders 256 shades.
There are only 81 units, however.
What does this mean? It means that under freetype as it currently stands, if even *ONE* pixel subunit is covered by an outline, it will render as a shade of grey--- While the exact same pixel, with the windows rasterizer, will render as 'white' instead.
This is because "white" is 1/256th coverage, and there are only 81 subunits-- Essentially meaning that in order to get 'white' out of freetype, the pixel cannot be touched *AT ALL* by the glyph outline.
On the windows rasterizer, there are only 16 shades of grey, so up to 1/16th of the area can be covered, and still rendered as 'white'-- or 5 subunits covered.
This is why the windows rasterizer produces crisper images than Freetype.
I don't know how to fix this behavior in Freetype, and *SERIOUSLY* need said behavior changed, As soon as possible.
Thank you.
Do you Yahoo!? The all-new My Yahoo! - Get yours free! http://my.yahoo.com
Ros-dev mailing list Ros-dev@reactos.com http://reactos.com:8080/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.com http://reactos.com:8080/mailman/listinfo/ros-dev
Question: How many levels of grey do other TTF rasterisers (e.g. the one Apple has) use?