From: Mosaab Alzoubi moceap@hotmail.com
--- dlls/win32u/font.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/dlls/win32u/font.c b/dlls/win32u/font.c index 7fc4a01eb64..c5a393e9a95 100644 --- a/dlls/win32u/font.c +++ b/dlls/win32u/font.c @@ -412,7 +412,7 @@ static const struct nls_update_font_list /* Arabic */ { 1256, 720, "vgaoem.fon", "vgaf1256.fon", "vgas1256.fon", "coue1256.fon", "sere1256.fon", "smae1256.fon", "ssee1256.fon", "ssef1256.fon", - "Microsoft Sans Serif","Times New Roman", + "Tahoma","Times New Roman", "Fixedsys,178", "System,178", "Courier New,178", "MS Serif,178", "Small Fonts,178", "MS Sans Serif,178", "MS Sans Serif,178", "MS Serif,178"
This is essentially a revert of commit f5ec65ad8ebe which was apparently written with the author's help.
I suspect the issue is that we don't have different entries for "MS Shell Dlg" and "MS Shell Dlg 2". In non-CJK locales these should be "Microsoft Sans Serif" and "Tahoma" respectively. Most of our dialog templates should first be updated to use "MS Shell Dlg 2".
The problem not in Arabic characters in (Microsoft Sans Serif) but in mixed ones. Essentially Microsoft-Sans-Serif is token from the system, so this problem may be shown in some systems not others.
So the best scenario to solve this issue from my opinion that making it system-independent. This can be done by accepting this patch.
Someone reply if it should be rebased by OP.