http://bugs.winehq.org/show_bug.cgi?id=33117
Bug #: 33117 Summary: Can't load Bach41.ttf with CreateFontIndirect under Wine - this works fine in Windows Product: Wine Version: unspecified Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: forums@robertinventor.com Classification: Unclassified
Created attachment 43794 --> http://bugs.winehq.org/attachment.cgi?id=43794 Bach41 True Type Musicological Font
The code is simple:
Basically I'm just using hFont=CreateFontIndirect(&lfTest); with strcpy(lfTest.lfFaceName,"Bach");
When I select this font into an example hdc, then use GetTextFace(..) to check which font was selected, then it reports that it found Martlett. Under Windows it finds the Bach font.
Why can't it find the Bach font, and why does it find Marlett instead?
It seems to be installed okay in my version of Wine since it shows up fine in the font dialog launched from within my program (using ChooseFont).
It displays the characters fine within that dialog too.
But I can't seem to use it within my application under Wine.
Also - may be related - if I try to set the font for a selection of text in a rich text field to the Bach font, again this doesn't work in Wine though it works fine in Windows.
Everything is fine in Windows.
I also tried using AddFontResourceEx(szFontPFile,FR_PRIVATE,0); - but wasn't able to load it from
I attach the Bach41.ttf font as an attachment.
Thanks for your help. I have been puzzling over this for several days now and can't find a solution, but as you see, I have reduced the issue to a few lines of code, which should help.
Here is the actual source code I used for testing this bug:
---------------------------------------------------- /** Extract from the code: (where SpecialDebugLogLine() just outputs a time stamped version of the line to a file). **/ #define ONE_K 1024
void TestCreateFontIndirectFor(char *szfont,int ichar_set) { LOGFONT lfTest; HFONT hFont=NULL,hFontWas=NULL; char szt[ONE_K]; char szfont_found[ONE_K]; HDC hdc=GetDC(NULL); memset(&lfTest,0,sizeof(lfTest)); lfTest.lfHeight=12; lfTest.lfCharSet=ichar_set; strcpy(lfTest.lfFaceName,szfont); hFont=CreateFontIndirect(&lfTest); hFontWas=SelectObject(hdc,hFont); GetTextFace(hdc,1024,szfont_found); sprintf (szt,"***Test of CreateFontIndirect for %s***\n" "Font found: %s\n\n",szfont,szfont_found ); SpecialDebugLogLine(szt); SelectObject(hdc,hFontWas); DeleteObject(hFont); hFont=NULL; ReleaseDC(NULL,hdc); }
void TestCreateFontIndirect(void) { SpecialDebugLogLine("\n\n****TestCreateFontIndirect****\n\n"); TestCreateFontIndirectFor("Courier",0); TestCreateFontIndirectFor("Arial",0); TestCreateFontIndirectFor("Bach",SYMBOL_CHARSET); }
/** and the output from Wine is:
****TestCreateFontIndirect****
2.06.41 AM March 04, 2013 (2746.3):***Test of CreateFontIndirect for Courier*** Font found: Courier
2.06.41 AM March 04, 2013 (2746.32):***Test of CreateFontIndirect for Arial*** Font found: Arial
2.06.41 AM March 04, 2013 (2746.34):***Test of CreateFontIndirect for Bach*** Font found: Marlett
2.06.41 AM March 04, 2013 (2746.35):
Test of AddFontResourceEx for CreateFontIndirect*** 2.06.41 AM March 04, 2013 (2746.35):***Test of CreateFontIndirect for Bach*** Font found: Marlett **/
http://bugs.winehq.org/show_bug.cgi?id=33117
--- Comment #1 from Robert Walker forums@robertinventor.com 2013-03-03 20:58:01 CST --- Sorry for the incomplete line:
"I also tried using AddFontResourceEx(szFontPFile,FR_PRIVATE,0); - but wasn't able to load it from "
That's something I did try but for some reason it wasn't able to find the proc AddFontResourceEx in gdi32.dll - maybe a dll version issue, haven't followed up that yet.
Anyway it was just an attempt at a work around, and didn't really expect that to work. Can try it again if you advise it though.
http://bugs.winehq.org/show_bug.cgi?id=33117
--- Comment #2 from Robert Walker forums@robertinventor.com 2013-03-03 21:06:46 CST --- Oh, the wine versions tested are 1.4.1 and 1.5.5
http://bugs.winehq.org/show_bug.cgi?id=33117
--- Comment #3 from Alexandre Julliard julliard@winehq.org 2013-03-04 05:05:44 CST --- (In reply to comment #0)
Why can't it find the Bach font, and why does it find Marlett instead?
Because you are asking for SYMBOL_CHARSET and Bach doesn't have that charset. It should work fine if you request ANSI_CHARSET instead. Of course that doesn't explain why it would behave different on Windows.
http://bugs.winehq.org/show_bug.cgi?id=33117
Robert Walker forums@robertinventor.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |FIXED
--- Comment #4 from Robert Walker forums@robertinventor.com 2013-03-04 05:36:01 CST --- Brilliant, that's fixed it!
I would never have thought of that. But can understand why it isn't done as a symbol font, because of its musicological use, and it does actually have the upper and lowercase letters in the appropriate positions so you can use it for text as well (though I usually use it only for musical notes).
That's completely fixed it for my app, including the rich text control as well.
Also has dealt with an issue where the app was really slow to start up under Wine, like a minute or more - it must have been repeatedly trying to find the font or some such.
Cheers, thanks so much!
I've marked this as resolved.
http://bugs.winehq.org/show_bug.cgi?id=33117
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |UNCONFIRMED Resolution|FIXED |
--- Comment #5 from Alexandre Julliard julliard@winehq.org 2013-03-04 05:44:18 CST --- It's not really fixed, as long as it differs from Windows.
http://bugs.winehq.org/show_bug.cgi?id=33117
--- Comment #6 from Robert Walker forums@robertinventor.com 2013-03-04 05:56:14 CST --- That's true. I've changed the status back to unconfirmed.
Also, sorry, back again, spoke too soon. But this may give more information to help with understanding what is different.
It works fine under Wine with the ANSI_CHARSET.
But Windows requires the SYMBOL_CHARSET for this font. When I set it to ANSI_CHARSET in Windows it returns the wrong font.
With the code I posted above, I tried:
SpecialDebugLogLine("\n\nUsing SYMBOL_CHARSET for Bach\n\n"); TestCreateFontIndirectFor("Bach",SYMBOL_CHARSET); SpecialDebugLogLine("\n\nUsing ANSI_CHARSET for Bach\n\n"); TestCreateFontIndirectFor("Bach",ANSI_CHARSET);
This is the output in Windows:
" Using SYMBOL_CHARSET for Bach
***Test of CreateFontIndirect for Bach*** Font found: Bach
Using ANSI_CHARSET for Bach
***Test of CreateFontIndirect for Bach*** Font found: Small Fonts "
For now I've fixed it for my program by using lfFont.lfCharSet=is_Wine?ANSI_CHARSET:SYMBOL_CHARSET;
Any ideas why Windows would see it as a symbol font while Wine sees it as an Ansi font?
http://bugs.winehq.org/show_bug.cgi?id=33117
--- Comment #7 from Robert Walker forums@robertinventor.com 2013-03-04 05:58:52 CST --- BTW I can remove the is_Wine condition here by doing a test to check to see if the returned face name is "Bach" and if not try the other charset.
But that of course is still just a work around even if technically it makes may executable able to run without querying whether it is running under Wine.
http://bugs.winehq.org/show_bug.cgi?id=33117
--- Comment #8 from Robert Walker forums@robertinventor.com 2013-03-04 11:43:17 CST --- Here is another observation which may help.
I have just tried EnumFontFamiliesEx to find the character set of the font. On Windows it finds the Bach character set as 2 (for symbol). On Wine it finds it as 0.
Another font that differs between Wine and Windows is Arial Unicode MS which I use to display unicode characters.
On Windows it's character set is 0 On Wine it is 136.
Same issue, you get the wrong font selected if you use the wrong character set, gets Arial selected instead (the old non unicode version of Arial).
int EnumFontFindCharSet ( ENUMLOGFONTEX *lpelfe, // pointer to logical-font data NEWTEXTMETRICEX *lpntme, // pointer to physical-font data int FontType, // type of font LPARAM lParam // application-defined data ) { return lpelfe->elfLogFont.lfCharSet; }
int iCharSetForFontByEnum(LOGFONT lfFont) { // see: http://msdn.microsoft.com/en-us/library/windows/desktop/dd162620(v=vs.85).as... // If set to DEFAULT_CHARSET, the function enumerates all uniquely-named fonts in all character sets. int iCharSet=0; LOGFONT lfT=lfFont; HDC hdc=GetDC(NULL); lfT.lfCharSet=DEFAULT_CHARSET; iCharSet=EnumFontFamiliesEx(hdc,&lfT,(FONTENUMPROC) EnumFontFindCharSet,0L,0L); ReleaseDC(NULL,hdc); return iCharSet; }
I've also realised while coding this, that this approach is a way to guarantee that you get a named font if you don't know what its character set is.
You might think that it is enough to just set the character set to DEFAULT_CHARSET but that sets it to the default character set for your computer (not the default character set for the font name) when used in CreateFontIndirect and so doesn't help here, and is normally not recommended.
The use of DEFAULT_CHARSET to enumerate over all the available fonts is restricted to this particular use in EnumFontFamiliesEx as far as I know.
http://bugs.winehq.org/show_bug.cgi?id=33117
--- Comment #9 from Robert Walker forums@robertinventor.com 2013-03-04 11:56:33 CST --- 136 apparently is CHINESEBIG5_CHARSET = 0x00000088
It also works on Windows for "Arial Unicode MS" - but not sure that means much as it might just be because I don't have any CHINESEBIG5_CHARSET fonts installed on my computer.
As an experiment, I tried it with CHINESEBIG5_CHARSET-1 and that also worked though SYMBOL_CHARSET gave me WingDings as expected.
http://bugs.winehq.org/show_bug.cgi?id=33117
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |gdi32 Version|unspecified |1.4.1
https://bugs.winehq.org/show_bug.cgi?id=33117
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Can't load Bach41.ttf with |Can't load Bach41.ttf with |CreateFontIndirect under |CreateFontIndirect |Wine - this works fine in | |Windows |
--- Comment #10 from Austin English austinenglish@gmail.com --- Is this still an issue in current (1.7.36 or newer) wine?
https://bugs.winehq.org/show_bug.cgi?id=33117
Joachim P. joachim.priesner.bugs@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |joachim.priesner.bugs@web.d | |e
--- Comment #11 from Joachim P. joachim.priesner.bugs@web.de --- Yes, the issue persists in Wine 1.7.51. I used a different font (capella3, also a musicological font), but the issue is the same: on Wine, the font is only found when using ANSI_CHARSET; on Windows, the font is only found when using SYMBOL_CHARSET. In the respective other case, a replacement font is returned instead.
https://bugs.winehq.org/show_bug.cgi?id=33117
Dmitry Timoshkov dmitry@baikal.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever confirmed|0 |1
--- Comment #12 from Dmitry Timoshkov dmitry@baikal.ru --- That's true that there is no symbol charmap in the attached font, but glyphs in the font have the range f020-f0ff which clearly indicates a symbol font. Probably Windows detects that and uses symbol charset for the font in that case.
https://bugs.winehq.org/show_bug.cgi?id=33117
--- Comment #13 from Dmitry Timoshkov dmitry@baikal.ru --- https://www.winehq.org/pipermail/wine-patches/2015-November/144641.html should fix this bug.
https://bugs.winehq.org/show_bug.cgi?id=33117
Dmitry Timoshkov dmitry@baikal.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |STAGED Staged patchset| |https://github.com/wine-com | |pholio/wine-staging/blob/ma | |ster/patches/gdi32-Symbol_T | |ruetype_Font/0001-gdi32-Imp | |rove-detection-of-symbol-ch | |arset-for-old-tr.patch
https://bugs.winehq.org/show_bug.cgi?id=33117
Sebastian Lackner sebastian@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |erich.e.hoover@wine-staging | |.com, michael@fds-team.de, | |sebastian@fds-team.de Staged patchset|https://github.com/wine-com |https://github.com/wine-com |pholio/wine-staging/blob/ma |pholio/wine-staging/tree/ma |ster/patches/gdi32-Symbol_T |ster/patches/gdi32-Symbol_T |ruetype_Font/0001-gdi32-Imp |ruetype_Font |rove-detection-of-symbol-ch | |arset-for-old-tr.patch |
https://bugs.winehq.org/show_bug.cgi?id=33117
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch
https://bugs.winehq.org/show_bug.cgi?id=33117
--- Comment #14 from Nikolay Sivov bunglehead@gmail.com --- Any plans to resend?
https://bugs.winehq.org/show_bug.cgi?id=33117
Nikolay Sivov bunglehead@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |anhaupt@gmx.ch
--- Comment #15 from Nikolay Sivov bunglehead@gmail.com --- *** Bug 12377 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=33117
André H. nerv@dawncrow.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Staged patchset|https://github.com/wine-com |https://github.com/wine-sta |pholio/wine-staging/tree/ma |ging/wine-staging/tree/mast |ster/patches/gdi32-Symbol_T |er/patches/gdi32-Symbol_Tru |ruetype_Font |etype_Font CC| |nerv@dawncrow.de
https://bugs.winehq.org/show_bug.cgi?id=33117
Dmitry Timoshkov dmitry@baikal.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|STAGED |RESOLVED Fixed by SHA1| |57c44885e57dee810814bb9bdf3 | |9f53cb8250d93 Resolution|--- |FIXED
--- Comment #16 from Dmitry Timoshkov dmitry@baikal.ru --- Committed as 57c44885e57dee810814bb9bdf39f53cb8250d93.
https://bugs.winehq.org/show_bug.cgi?id=33117
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #17 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 4.0-rc1.
https://bugs.winehq.org/show_bug.cgi?id=33117
Michael Stefaniuc mstefani@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |3.0.x
https://bugs.winehq.org/show_bug.cgi?id=33117
Michael Stefaniuc mstefani@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|3.0.x |---
--- Comment #18 from Michael Stefaniuc mstefani@winehq.org --- Removing the 3.0.x milestone from bug fixes included in 3.0.5.
https://bugs.winehq.org/show_bug.cgi?id=33117
Béla Gyebrószki gyebro69@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gyebro69@gmail.com
--- Comment #19 from Béla Gyebrószki gyebro69@gmail.com --- *** Bug 22207 has been marked as a duplicate of this bug. ***