Home/ Questions/Q 8026859
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-04T23:37:23+00:00

I’ve found some slightly odd, and more importantly, inconsistent behavior from Win32 ChooseFont() API.

  • 0

I’ve found some slightly odd, and more importantly, inconsistent behavior from Win32 ChooseFont() API.

LOGFONT lf = { 0 };
strcopy(lf.lfFaceName, m_face_name);
const int ppi = GetDeviceCaps(pView, LOGPIXELSY);
lf.lfHeight = -MulDiv(m_font_height, ppi, 72);
CFontDialog fd(&lf);
if (fd.DoModal() != IDOK)
    return;
m_face_name = fd.GetFaceName();
m_font_height = lf.lfHeight;

Assuming that the first time though, face name is “Segoe UI”, this works.

But if the user changes the dialog to be “Segoe UI”, “Light”, “9”, (face, style, height), and we go through the above a second time, then the font choose common dialog fails to select “Segoe UI” as the face name. Instead, I get the Font: field as blank.

This is not a problem if the user selects a style of “Regular”, “Italic”, “Bold”, “Bold Italic”, as those are stored in the style bits, and don’t munge the name. I discard them for the second run, because I’m ignoring them (I would disable Font Style: if there were a way to easily do so – I don’t wish to subclass CFontDialog for this – that’s a whole ‘nother level of time & effort that this moment doesn’t allow for).

I’ve tried creating a font based on the previous specifics from the dialog, and then tried pulling the LOGFONT back out of that. No dice.

Similarly, I’ve tried querying the dialog for the FontStyle() – but that returns blank – so nothing to strip from the font name here…

This just seems like a bug with MS’s dialog – it tells me one thing, but then cannot use it’s own output to correctly initialize itself the second time through (granted, I’m only persisting some, not all, of the LOGFONT in this situation).

Does anyone know WTH is up with this? Or an approach I might use to (short of hard coding looking for ” Light” on the end of a font name – YUCK!)?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Developments in font design has significantly outstripped the legacy api’s ability to keep up. OpenType happened, for one. There are additional font styles beyond what LOGFONT can support. For Segoe UI, properties that control boldness can be Light and Semibold. For other fonts, font stretch is another property, common ones are Condensed and Expanded. With the font being able to implement a dedicated font file to make these styles look good and not depend on synthesizing the style from an existing font as it was done in the olden days. Review the WPF FontStretch and FontWeight enumeration types for possible values.

    These are properties that LOGFONT can’t express. There’s a compatibility hack to deal with this, type face names get mapped. So “Segoe UI” with a style of “Light” becomes “Segoe UI Light”. And the Windows font mapper will pick the right true-type font file from such a name. What however doesn’t work is initialize LOGFONT.lfFaceName with “Segoe UI Light”. Not actually sure why, it was probably avoided to not have to deal with the ambiguity. Or just plain flubbed. A possible workaround is to recognize these appended style names in the font face name, but that’s not perfect either.

    GDI is running out of gas. Much like User32.

    • 0