How can I find what font was actually used for my CreateFont call?

Question

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?

Answer 1

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.

• The face name is available with GetTextFace.
• You can get metrics with GetTextMetrics.
• If the selected font is TrueType or OpenType, you can get additional metrics with GetOutlineTextMetrics.

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.

Answer 2

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.