> I hope you realize that text layout is more complex than just stacking bitmaps side by side.
Yes, I do take bearing, advance, and kerning into account when rendering the text. > On my side, I don't quite understand why this preallocation is > beneficial. Can you please explain the advantages? I'm not sure what you're referring to by 'preallocation' - Are you asking about what the point is of creating a font atlas at all? A font atlas <http://wdobbie.com/post/gpu-text-rendering-with-vector-textures/> is needed for efficient GPU-based text rendering. There has been some success in drawing glyphs on the GPU <http://sluglibrary.com/>, but drawing glyphs as vectors is still *a lot* more expensive than a bitmap font. For real-time rendering where performance matters more than precisely-rendered text or a complete character-set, a font-atlas is a good trade. >Perhaps we might consider some tweaks to FreeType API if it is indeed compelling. I need a way to get the bitmap size without have to create and render a glyph. Previously, the glyph metrics worked for this, but they do not work for LCD filtered glyphs. So my proposition would be to make the bitmap dimensions available without passing FT_LOAD_RENDER: 1) Add 3 additional fields to *FT_GlyphSlotRec_* FT_Bitmap bitmap; // existing FT_Int bitmap_left; // existing FT_Int bitmap_top; // existing FT_Int bitmap_width; //* NEW* FT_Int bitmap_height; // *NEW* FT_Int bitmap_pitch; // *NEW* 2) Add a new flag *FT_LOAD_COMPUTE_BITMAP_DIMENSIONS *to compute bitmap dimensions without having to render the glyph. So basically, the relevant code could be factored out of *ft_smooth_render_generic *and used to calculate the bitmap dimensions any time a *FT_GlyphSlotRec_ *was created while *FT_LOAD_COMPUTE_BITMAP_DIMENSIONS *was provided. Finally, I should be able to do this: FT_Load_Char(face, code, FT_LOAD_TARGET_LCD | FT_LOAD_NO_BITMAP | FT_LOAD_COMPUTE_BITMAP_DIMENSIONS); int w = face.glyph.bitmap_width; int h = face.glyph.bitmap_height; // ... Thanks, Nick On Tue, Sep 19, 2017 at 9:48 AM, Alexei Podtelezhnikov <[email protected]> wrote: > On Tue, Sep 19, 2017 at 2:44 AM, Nicolas Jinchereau > <[email protected]> wrote: > > I scraped some code from ft_smooth_render_generic in ftsmooth.c. > >... > > Aside from those two things, it seems to work, and the example below > gives > > matching results for precalculated and final size of the bitmap. > > I hope you realize that text layout is more complex than just stacking > bitmaps side by side. There could be gaps and overlaps between > bitmaps. For example, the padded LCD bitmaps do overlap more often. > > Skia is also doing the bitmap preallocation and borrows the code from > FreeType to calculate the size. Just like you, they now need to fix > this API-non-compliant interface with FreeType when FreeType's > technology has evolved. Do you see the problem? On my side, I don't > quite understand why this preallocation is beneficial. Can you please > explain the advantages? Perhaps we might consider some tweaks to > FreeType API if it is indeed compelling. > > Thank you, > Alexei >
_______________________________________________ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
