14

In Windows, the CreateFontIndirect() call can silently substitute compatible fonts if the requested font is not requested. The GetObject() call does not reflect this substitution; it returns the same LOGFONT passed in. How can I find what font was actually created? Alternately, how can I force Windows to only return the exact font requested?

bdonlan
  • 224,562
  • 31
  • 268
  • 324
  • You need to use the Uniscribe API for this kind of control. – Hans Passant Aug 22 '11 at 23:52
  • 1
    @Hans, unfortunately this is deep in the middle of some fairly hairy legacy code. Refactoring it to use Uniscribe would be a ... difficult task, not helped in the least by the lack of tests and documentation. If there's some kidn of undocumented GDI call to get this kind of info from a HFONT, it would be better than nothing :) – bdonlan Aug 22 '11 at 23:57

2 Answers2

16

In Windows, the CreateFontIndirect() call can silently substitute compatible fonts if the requested font is not requested. The GetObject() call does not reflect this substitution; it returns the same LOGFONT passed in.

It's not CreateFontIndirect that's doing the substitution. The substitution happens when the font is selected into the DC. CreateFontIndirect just gives you a handle to an internal copy of the LOGFONT. That's why GetObject gives you the same LOGFONT back.

How can I find what font was actually created?

If you select the HFONT into the target DC, you can then ask the DC for the information about the font that was actually chosen as the best match to the LOGFONT.

That essentially tells you what font was actually created.

Aside:

When doing something like print preview, you can start with a LOGFONT, select it into the printer DC (or IC), grab the details of the actual font (printers often substitute fonts), and then create a new LOGFONT that's more representative of the actual font. Select that into the screen DC, and--with appropriate size conversions--do a pretty good match of what the user will actually get.

Adrian McCarthy
  • 45,555
  • 16
  • 123
  • 175
  • 2
    It is worth to note that `GetTextFace` does not necessarily return the same name even if the font selected is as requested. For example, if you pass `MS Gothic` to `CreateFont`, `GetTextFace` might return `ＭＳ ゴシック` or `MS Gothic` depends on the locale settings. – raymai97 Jul 01 '17 at 00:20
1

To get the appropriate font on different language versions of the OS, call EnumFontFamiliesEx with the desired font characteristics in the LOGFONT structure, then retrieve the appropriate typeface name and create the font using CreateFont or CreateFontIndirect.

While it's not a universal way to get the actual font name from an HFONT, you can check beforehand what CreateFontIndirect would (most likely) return.

Judging from how MSDN suggest this as a good solution for getting a font family from the attributes it seems like the way Windows internally performs the substitution.

pezcode
  • 5,490
  • 2
  • 24
  • 37
  • I suspect the question is really about font substitutions due to the selection of fonts available on the target output device rather than font-linking or font-fallback for various language/script issues. – Adrian McCarthy Aug 25 '11 at 16:00
  • @Adrian McCarthy, I guess the first part of the comment is misleading. The important part is that EnumFontFamiliesEx can be used to enum fonts that match the criteria given in a LOGFONT. Applies to lfCharSet just like any other member. – pezcode Aug 25 '11 at 22:20
  • EnumFontFamiliesEx looks only at some of the fields in the LOGFONT. The actual font mapper looks at everything. The only way to know for sure which font gets selected is to select it into the DC and they query it. – Adrian McCarthy Aug 26 '11 at 21:12