True. The size of the enum could be forced to int by doing this:
On Wed, Sep 20, 2017 at 5:50 PM, Behdad Esfahbod <[email protected]> wrote: > On Wed, Sep 20, 2017 at 2:10 PM, Nicolas Jinchereau < > [email protected]> wrote: > >> What about adding FT_RENDER_MODE_NONE = -1 to FT_Render_Mode_? >> The enum should still be representable by the same size int. >> >> Or maybe a better name than FT_RENDER_MODE_NONE that specifies the >> layout/measurement portion of the rendering only? >> > > But the measured size is dependent on the render mode, no? > > >> >> >> >> >> On Wed, Sep 20, 2017 at 4:08 PM, Alexei Podtelezhnikov < >> [email protected]> wrote: >> >>> > https://www.freetype.org/freetype2/docs/reference/ft2-base_i >>> nterface.html#FT_LOAD_BITMAP_METRICS_ONLY >>> > I proposed expanding FT_LOAD_BITMAP_METRICS_ONLY flag to work for >>> > outline glyphs as well. If I understand correctly this should help >>> > with GPU font atlases, rectangle packing, whatever is the Skia >>> > issue... The stars aligned for the recipients list. >>> >>> Its easier said than done. The renderers do not see all load_flags but >>> only the 4-bit (0-5 actually) render_mode enum. I can pass the >>> FT_LOAD_BITMAP_METRICS_ONLY flag to FT_Render_Glyph at bit 5 or above >>> to force the renderers to bail once the bitmap metrics are set. Can I >>> set a bits in enum? This technically changes the type from >>> FT_Render_Mode to int. Unfortunately, the enum persists deep inside. >>> Any other ideas? >>> >> >> > > > -- > behdad > http://behdad.org/ >
_______________________________________________ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
