Thanks for the quick responses. I've managed to render text correctly now using LCD filtering (the new 2.8.1 version). I was able to do it by ignoring the glyph metrics and using the bitmap size itself. This works well enough for now, and the text looks great, but I would like to be able to retrieve final dimensions of the bitmap without actually rendering/allocating anything, so I can calculate the layout of a bitmap-font/texture-atlas, and blit the glyphs afterward. I've been doing this for while and only ran into a problem when I tried the new LCD filtering.
I understand why the padding would be needed, but why wouldn't it be included in the glyph metrics (width/height)? Is there any way to determine the final bitmap size without rendering it, or could it be added in a future version? Thanks, Nick On Mon, Sep 18, 2017 at 11:18 PM, Jan Alexander Steffens < [email protected]> wrote: > On Tue, Sep 19, 2017 at 4:13 AM Nicolas Jinchereau < > [email protected]> wrote: > >> When using FT_LOAD_TARGET_LCD, the size of the rendered bitmap doesn't >> seem to match the size in the metrics. It's usually off by 1~2 units - is >> this normal? >> >> Example: >> >> #include <ft2build.h> >> #include FT_FREETYPE_H >> #include FT_LCD_FILTER_H >> >> int main() >> { >> FT_Library _library; >> FT_Init_FreeType(&_library); >> FT_Library_SetLcdFilter(_library, FT_LCD_FILTER_DEFAULT); >> >> FT_Face face; >> FT_New_Face(_library, "arial.ttf", 0, &face); >> FT_Set_Pixel_Sizes(face, 0, 14); >> >> FT_Int32 flags = 0; >> flags |= FT_LOAD_TARGET_LCD; >> flags |= FT_LOAD_RENDER; >> >> string sample = "0123456789ABCDEFGHIJKLMNOPQRST >> UVWXYZabcdefghijklmnopqrstuvwxyz"; >> >> for(char c : sample) >> { >> FT_Load_Char(face, (int)c, flags); >> cout << (face->glyph->bitmap.width / 3) << " ==? "; >> cout << (face->glyph->metrics.width >> 6) << endl; >> } >> >> FT_Done_Face(face); >> return 0; >> } >> >> Any help with this would be appreciated >> > > I assume you used to build 2.8 and earlier without subpixel rendering. In > that case, FT_LOAD_TARGET_LCD doesn't really do LCD rendering and just > gives you bitmaps three times wider without increasing the resolution. > > With "subpixel rendering" enabled, glyphs are rendered at higher > resolution with LCD filtering which blurs the image horizontally. This > requires up to one pixel (three bitmap columns) of padding at each side. > > With "subpixel rendering" disabled, 2.8.1 now includes a patent-free LCD > rendering technique which does not use filters but effectively multisamples > the outline. It has similar padding requirements. >
_______________________________________________ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
