On Thu, 5 Nov 2015 13:05:43 +0100 Wojciech Mamrak <[email protected]> wrote:
> > In a result I made it first to convert the RGB glyph to grayscale and > > then to blend it to the background. This way, the transparency is always OK. > > You can return grayscale bitmaps from FT directly, without the > conversion on your side. > The transparency will be OK but remember to use the alpha channel > blending formula this time :) I am writing a GUI library and the user later will choose how FT fonts to be rendered. So, I need to provide support for all possible formats. For the grayscale rendered glyphs, I am using the value as a "intensity", multiplying by it every component of the the drawing color: Crgb = Crgb * Gray and then making the standard alpha blending of so computed color and the background. Everything seems to work fine... Now I am using the same algorithm for LCD rendered glyphs, only computing the gray value by a little bit weird equation: Gray = (R + 2*G + B)/4 and the result is also pretty good. > > > But the big question is "Do I need subpixel antialiased fonts so badly?" :) > > This question holds if you intend to compose and display some images > on the screen (which is always opaque). Then it depends on font size, > font itself, targeted device (e.g. resolution, pixel layout), etc. If > you intend to save images with transparency, the only versatile option > is grayscale antialiased text. Generating SVG images, which are > composed "at runtime", assuming rendering engine supports > subpixel-antialiased text, is another option. > It depends greatly on the use cases of the library. But as long as it is not finished yet, I can say only that it is intended to be used for GUI creation on x86 computers, working under different OSes. -- http://fresh.flatassembler.net http://asm32.info John Found <[email protected]> _______________________________________________ Freetype mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype
