9 Jul
2022
9 Jul
'22
1:20 a.m.
The offending font is NotoColorEmoji.ttf which is present in, e. g.,
google-noto-emoji-color-fonts or noto-fonts-emoji packages available in various
distribution. Attempting to load this font on Windows 10 (with AddFontResourceA() or open
it with default font viewer) fails while currently succeeds on Windows. fontforge also
refuses to open this font. That is because the font is bitmap only but missing bitmap
table.
Some apps (Glyph launcher is an example) try to GetOutlineTextMetrics() on this font and
do not expect that to have an error return (as we currenly do), which leads to crash on
unhandled division by zero exception.
I am attaching a bitmap-only ttf test font (with only one bitmap) which I created with
fontforge to make sure that such font can still be loaded in Wine. This font also loads on
Windows (both with AddFontResourceA() and with default font viewer).
There are other font types which can be legitimately missing EBDT table, but
FT_Load_Sfnt_Table() returns a different error for those and my patch doesn't reject
those fonts.
[test.ttf](/uploads/b41472180b80c2c53f9dcc06055990f0/test.ttf)
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/411
9 Jul
9 Jul
1:20 a.m.
New subject: [PATCH 1/1] win32u: Don't load bitmap only TTF fonts without bitmap table.
From: Paul Gofman <pgofman(a)codeweavers.com>
---
dlls/win32u/freetype.c | 19 ++++++++++++++++++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/dlls/win32u/freetype.c b/dlls/win32u/freetype.c
index f00df7ed86d..4514574ec42 100644
--- a/dlls/win32u/freetype.c
+++ b/dlls/win32u/freetype.c
@@ -254,6 +254,8 @@ MAKE_FUNCPTR(FcStrSetMember);
#define GET_BE_DWORD(x) RtlUlongByteSwap(x)
#endif
+#define MS_EBDT_TAG MS_MAKE_TAG('E','B','D','T')
+
/* 'gasp' flags */
#define GASP_GRIDFIT 0x01
#define GASP_DOGRAY 0x02
@@ -1177,6 +1179,8 @@ static struct unix_face *unix_face_create( const char *unix_name,
void *data_ptr
struct stat st;
DWORD face_count;
int fd, length;
+ FT_Error error;
+ FT_ULong len;
TRACE( "unix_name %s, face_index %u, data_ptr %p, data_size %u, flags
%#x\n",
unix_name, face_index, data_ptr, data_size, flags );
@@ -1268,7 +1272,20 @@ static struct unix_face *unix_face_create( const char *unix_name,
void *data_ptr
This->ntm_flags = get_ntm_flags( This->ft_face );
This->font_version = get_font_version( This->ft_face );
- if (!This->scalable) get_bitmap_size( This->ft_face, &This->size );
+ if (!This->scalable)
+ {
+ error = pFT_Load_Sfnt_Table( This->ft_face, RtlUlongByteSwap(MS_EBDT_TAG),
0, NULL, &len );
+ if (error == FT_Err_Table_Missing)
+ {
+ WARN( "EBDT table is missing in bitmap only font %s.\n",
+ debugstr_w(ft_face_get_family_name( This->ft_face, system_lcid
)));
+ pFT_Done_Face( This->ft_face );
+ free( This );
+ This = NULL;
+ goto done;
+ }
+ get_bitmap_size( This->ft_face, &This->size );
+ }
get_fontsig( This->ft_face, &This->fs );
}
else
--
GitLab
https://gitlab.winehq.org/wine/wine/-/merge_requests/411
11:18 a.m.
I don't think we should reject such fonts. NotoColorEmoji.ttf does have bitmap data,
in a form of CBDT table.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/411#note_3816
1:54 p.m.
Do you think that maybe opentype path can be improved to support it? Or we can otherwise
make GetOutLineGlyphMetrics() work? It seems to me that in current state such font, how we
load it, is unusable, and can only break apps but not be really used.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/411#note_3818
6:05 p.m.
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.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/411#note_3827
11 Jul
11 Jul
2:53 p.m.
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?
27 Jul
27 Jul
4:19 p.m.
On Mon Jul 11 14:53:55 2022 +0000, Ghost User wrote:
Paul Gofman replied on the mailing list:
```
On 7/9/22 13:05, Nikolay Sivov (@nsivov) wrote:
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?
_______________________________________________
wine-gitlab mailing list -- wine-gitlab(a)winehq.org
To unsubscribe send an email to wine-gitlab-leave(a)winehq.org
```
Ok, so what would be a test program for this that imitates what application is
doing? Do you know why application is using this font in a first place? Does it iterate
over all of them? Freetype is indeed capable of handling it, both with or without color,
as ftview shows.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/411#note_5099
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.
4:27 p.m.
On Wed Jul 27 16:19:20 2022 +0000, Nikolay Sivov wrote:
Ok, so what would be a test program for this that
imitates what
application is doing? Do you know why application is using this font in
a first place? Does it iterate over all of them? Freetype is indeed
capable of handling it, both with or without color, as ftview shows.
I didn't
see application actually trying to use it, it just loads it along with a bunch of other
fonts and breaks with division by zero exception when GetOutlineTextMetrics() is not
working (probably just finding the font through some enumeration).
My test program tries to load that ttf file and that doesn't work on Windows, my
initial understanding was that we shouldn't as well if it breaks things. This ttf
apparently can't be used on Windows through Windows functions, if only an app will
load and render it directly without using winapi for that.
An interesting test case would be to see how some real-life bitmap only or color bitmap
only ttf behaves on Windows if it can be loaded, do you have such an example in mind? I
was struggling to find one but could not. Maybe such ttf are not supported on Windows at
all?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/411#note_5101
4:30 p.m.
On Wed Jul 27 16:27:38 2022 +0000, Paul Gofman wrote:
I didn't see application actually trying to use
it, it just loads it
along with a bunch of other fonts and breaks with division by zero
exception when GetOutlineTextMetrics() is not working (probably just
finding the font through some enumeration).
My test program tries to load that ttf file and that doesn't work on
Windows, my initial understanding was that we shouldn't as well if it
breaks things. This ttf apparently can't be used on Windows through
Windows functions, if only an app will load and render it directly
without using winapi for that.
An interesting test case would be to see how some real-life bitmap only
or color bitmap only ttf behaves on Windows if it can be loaded, do you
have such an example in mind? I was struggling to find one but could
not. Maybe such ttf are not supported on Windows at all?
Otherwise, we could
probably just try to implement GetOutlineTextMetrics() somehow for bitmap only fonts if we
need such fonts supported? And then there are probably more missing bits so that font can
be actually rendered through gdi functions.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/411#note_5102
7:47 p.m.
On Wed Jul 27 16:30:00 2022 +0000, Paul Gofman wrote:
Otherwise, we could probably just try to implement
GetOutlineTextMetrics() somehow for bitmap only fonts if we need such
fonts supported? And then there are probably more missing bits so that
font can be actually rendered through gdi functions.
The trick to have it working
on Windows might be to have empty glyf table, example of that is
https://font.gohu.org/gohufont-2.1-otb.tar.gz . They call it OTB, but that's not a
thing in itself, it's a regular sfnt container obviously. It's using EBDT, but
still has glyf table with no outlines.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/411#note_5135
7:48 p.m.
On Wed Jul 27 19:47:07 2022 +0000, Nikolay Sivov wrote:
The trick to have it working on Windows might be to
have empty glyf
table, example of that is https://font.gohu.org/gohufont-2.1-otb.tar.gz
. They call it OTB, but that's not a thing in itself, it's a regular
sfnt container obviously. It's using EBDT, but still has glyf table with
no outlines.
Ah, I found now this
https://github.com/googlefonts/noto-emoji/tree/main/fonts , they have _WindowsCompatible
variant there, with same empty glyf table. Windows is likely to do some validation
that's too strict in practice.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/411#note_5136
28 Jul
28 Jul
2:10 a.m.
On Wed Jul 27 19:48:16 2022 +0000, Nikolay Sivov wrote:
Ah, I found now this
https://github.com/googlefonts/noto-emoji/tree/main/fonts , they have
_WindowsCompatible variant there, with same empty glyf table. Windows is
likely to do some validation that's too strict in practice.
Thanks a lot. I
loaded that font on Windows and saw that:
- it fails GetOutlineTextMetrics() the same way as with Wine;
- being installed, it is enumerated; moreso, it has TMPF_VECTOR, TMPF_TRUETYPE flags in
text metrics structure during enumeration (GetTextMetrics() fails as well though);
The launcher still worked on Windows even with that font installed so I looked at it
further. It turns out this font usage comes from Qt (so currently the font probably breaks
many Qt apps). I looked at the source code here:
https://download.qt.io/archive/qt/5.12/5.12.0/single/. Interesting things mostly happen in
qtbase/src/platformsupport/fontdatabases/windows/qwindowsfontengine.cpp.
After looking at the code I tested GetFontData('cmap' tag) and figured that it
fails on Windows for the font (with the same ERROR_INVALID_HANDLE error code as
GetOutlineTextMetrics, GetTextMertics), while GetFontData currently succeeds on Wine. That
fails for other tables (which are present in the ttf) as well. Failing GetFontData in Wine
helps the launcher.
So it seems to me that once text metrics can't be retrieved for font GetFontData()
also fails. Should we maybe do that?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/411#note_5194
4 Dec
4 Dec
11:42 a.m.
Is there an update on merging this change? One Qt app I use actually throws an
ACCESS_VIOLATION exception before loading the main window without it :frog:
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/411#note_54835
149
days inactive
662
days old
12 comments
5 participants
participants (5)
-
Aida Jonikienė (＠DodoGTA) -
Nikolay Sivov (＠nsivov)
-
Paul Gofman
-
Paul Gofman -
Paul Gofman (＠gofman)