On 7/9/22 13:05, Nikolay Sivov (@nsivov) wrote:
Which one is the opentype path? Or rather, where exactly does GetOutlineTextMetrics() break when EBDT is missing? I didn't follow closely "recent" (year or two) changes in gdi32/win32u font handling. My guess is that freetype is capable to return grayscale bitmap for color png, rgba, or whatever format CBDT provides, is that correct? If it works this way, metrics data should be functionally equivalent between CBLC and EBLC tables.
By "opentype path" I mean the path initialized in unix_face_create() (win32u/freetype.c) if opentype_get_ttc_sfnt_v1, opentype_get_tt_name_v0 and opentype_get_properties succeeds and when it doesn't use freetype library. GetOutlineTextMetrics() always return 0 for fonts marked as not scalable (happens for bitmap only fonts in "freetype" path). In fact, I guess it is possible that current handling of any bitmap-only ttf font is problematic, but those fonts seem to be exceptionally rare and in fact I could not immediately find just any public font like that.
With the font in question it is not just that GetOutlineTextMetrics() returns 0, I tried using this font for rendering emojis in Wine with static control and it doesn't display anything. My understanding that such a font is currently non-functional in Wine. I actually started this patch from trying to understand how to make it functional instead of rejecting, but I feel like I am missing the grounds on which I can test the behaviour to think of fixing it: this specific font doesn't load on Windows, doesn't load with fontforge on Linux and doesn't seem to work in Wine currently. Do you have any ideas what can be the basis for correct behaviour here? Or maybe it would still make sense not load the fonts we can't properly handle now anyway?