I WILL stay on Microsoft Windows because text rendering is still unbeaten. This outweights the possibly many advantages of Linux systems because text is seen so often, and plaintext manipulation is an important tool and should feel like actual plaintext. The 4×4 oversampling rate also makes the renderer actually feel like the GDI renderer that uses 4×4 oversampling. Some people might find a sense of nostalgic feel in that specific render.
/* Sorry, but you are talking nonsense. FreeType was developed especially to run on embedded systems! In particular, the rasterizers (both the B/W and the A/A one) do work with systems that have just a very small amount of memory. */
So, you're saying the FreeType guys implemented algorithms that trade time for memory. Still not an excuse for how directly finding the area is overcomplicated. Imagine how many calculations would be required to find out what area a given curve has, let alone many curves. /* Well, yes. IIRC, however, rendering B/W at a much larger resolution followed by applying a filter is *slower* than FreeType's approach of directly computing the pixel coverage. */ I wasn't suggesting 256Ã256 oversampling rates. I was suggesting a 4Ã4 oversampling. It consists of finding boolean values of whether each of the 16 points are inside the outline (borders also count as in) and then taking the average. It's not what you're making out to be, like applying a filter is some monstrosity when it's really taking the average of sixteen values that are either 0 or 1. How two-dimensional area calculation can be as fast as the average of sixteen single point checks is beyond me. Please, implement the 4Ã4 oversampling for the peace-of-mind. The way FreeType works really makes me keep using Microsoft Windows with its GDI renderer that I find the best for general-purpose. /* There is no drop-out control in A/A mode, since it's kind-of useless. */ In the theoretical box filter (which should remain theoretical) the drop-out control is a degenerate case, but in 4Ã4 oversampling, it would do the exact same thing as it does with the bilevel renderer (which is a single point check in the middle of the pixel). /* FreeType doesn't support the (crippled) mode of having A/A only along one axis. */ As classic GDI rendering does not use this, it shouldn't be there by default, however in the ClearType mode (and FreeType appears to have a mode that simulates this) it's an essential part of the renderer. Not as a standalone mode, but only when the fonts specifically disable vertical anti-aliasing. The two modes in the classic GDI renderer: Bilevel renderer - it is 1Ã1 oversampling Grayscale renderer â 4Ã4 oversampling The two modes in the ClearType GDI renderer: ClearType with anti-aliasing â 6Ã5 oversampling, horizontal instructions round to 1÷16, horizontal deltas and vertical post-IUP deltas ignored ClearType with disabled vertical anti-aliasing â 6Ã1 oversampling, horizontal instructions round to 1÷16, horizontal deltas and vertical post-IUP deltas ignored However, there is also a setting in ClearType that the font may enable, it is called the native ClearType mode and it no longer ignores deltas (the horizontal rounding remains 1÷16). Warning for font creation, for general-purpose hinting making deltas in bilevel and grayscale rendering (obvious main targets as they utilize full hinting) would interfere with ClearType. /* Sigh. Werner */ The 4Ã4 oversampling renderer is peace-of-mind and the FreeType guys should really add it. /* Thanks, but it is not clear to me what this has to do with FreeType. Ditto for 'Unicode parsing' and the like. What you describe has to be handled (at least) one level higher. For example, FreeType doesn't have any concept of a 'line'. Instead you specify a glyph index for a given font, and the library renders the glyph into a buffer, nothing else. */ This low level handling is also really worrying. Text rendering must probably be collectively handled by many projects. If you don't even give FreeType access to the gasp table (which is pretty much a part of hinting, as it affects rendering and the ttfautohint hinting and dehinting both overwrite it) it means text renderers using FreeType but completely different projects than it then have to themselves know the TrueType format to get to know what render mode to use, which is a real mess. You have to ask a LOT of guys, to then be able to get desired (lack of) features such as scanline rule (lines of text are determined by rounded values of WinAscent and WinDescent and may not overlap) and naive text parsing (the tab character moves to next multiple of 8 of a certain width, the glyph widths are integer, only U+000D U+000A is a newline, all other characters and character combinations are their respective raw glyph). It's really messy, and it will take a while before this behaves in a stable manner. Because of such a community behind Unix text rendering I will probably stay on Microsoft Windows for a really long time to come.
