How to set font size when using system.drawing / directWrite.

TLDNR: It's 2017. How to set font weight when using System.Drawing.createfont

Longer version: In GDI32, I would create a device context, fill in the LOGFONT structure including a weight value like 400 500 600, etc., and create a font. The font mapper will run the algorithm that matches my request to the best available matching font on the system and return a descriptor to it.

In the system.drawing section, the font constructor has 13 overloads, but none of them has obvious weight. There is a FontFamily parameter, but the only weighting effect is the addition of the binary "bold" option, which is not the same as setting the desired font weight.

Why it matters: Fonts come in family and weight options. Weight - the thickness of the face or the darkness of the letters. When typing, if I want a bold font, I actually need to get the bold font of the font, assuming it's installed on the machine the code is running on.

What have I done so far? Lots of internet research through Google, SO and MSDN. And looked at all the suggested questions as I wrote this. So far, I haven't found a way forward, and I'm at a point where you know you are asking the wrong questions and are looking for someone to point me in the right direction.

This is possible with GDI - what is system.drawing equiv.

EDIT: This question came from a current project that actually uses directWrite (dw) and not system.drawing. But one of the requirements is to know that the requested font is available. With GDI32 thinking, there seemed to be no obvious solution in dw, so we turned to system.drawing and the question arose.

After some research, prompted by the initial answers to the question, we had a telling moment. It was that the request for fonts in dw is completely different from GDI32. Dw uses font family / weight / width / slope model to match the fonts. It also makes it easier to list the font family variants.

We're starting from the old use case where our data contains the name of the GDI32 font. This is usually the last name, but different font funds use it differently, you can see this if you have an internal font tool like TypeTool - one of the founders may call their bold italic version "MyFont Bold Italic", while while another calls them "MyFont" and leaves the bold italic specifiers in other font parameters.

In the meantime, Windows (at least Windows 10) seems to have updated the way fonts are displayed on install, recognize crappy names, and present them as a family. Apparently MS Office hasn't joined this approach (for example, look at the crappy names in the PowerPoint font picker), but you can see it if you browse the Windows / fonts folder.

This is all very good now, but if you just use the legacy GDI32 font name and try to instantiate the font in dw it will fail. The solution is similar to preprocessing the GDI32 font name to strip the multiplication, width and slant words. Once you do that, the dw will match your font.

This approach seems quite viable in initial testing, plus we can easily revert some ugly defaults like Courier when the font is actually missing, plus we can get an inexpensive list of the members of the font family, so if we wanted to pick a different member if desired no (I know we're leaning towards reinventing the font composer if we go down that road).

Conclusion: The naming of dw names is different from GDI32. The more exotic font names you may have used with GDI32 are not guaranteed to work with dw and need to be massaged in dw format, but it really is possible.

I will later update the result of the above approach.