TLDNR：2017年。如何在使用System.Drawing.createfont
时设置字体粗细更长的版本：在GDI32下我会创建一个设备上下文，填写LOGFONT结构，包括权重值400,500,600等，并创建字体。字体映射器将运行一个算法，将我的请求与系统上最好的匹配字体相匹配，并返回一个句柄。
在system.drawing下，font constructor有13个重载，但没有一个显着的重量。有一个FontFamily参数，但唯一的权重效果是添加二进制“粗体”选项，这与设置所需的字体粗细不同。
为什么这很重要：字体有家族和体重变体。重量是字母的厚度或黑暗。在排版中，如果我需要半粗体字体，那么我必须得到一个半粗体版本的字体，假设它安装在代码运行的机器上。
到目前为止我做了什么？通过谷歌，SO和MSDN进行了大量基于网络的研究。并在我写这篇文章时查看了所有建议的问题。到目前为止，我还没有找到前进的方向，而且我知道你在问这个错误的问题，并且正在找人帮我指出正确的方向。
在GDI下有可能 - system.drawing等于什么。
编辑：这个问题来自一个实际使用directWrite（dw）的当前项目，而不是system.drawing。但其中一个要求是知道所请求的字体是可用的。使用GDI32-mindset似乎没有明显的解决方案，因此我们转向system.drawing，问题出现了。
在对问题的初步回复评论引发的一些更多研究之后，我们有了一个揭示时刻。这就是在dw中请求字体的方式与GDI32完全不同。 Dw使用字体系列/重量/宽度/斜率字体模型进行字体匹配。它还使字体系列变体枚举变得容易。
我们来自遗留用例，其中我们的数据包含GDI32字体名称。这通常是姓氏，但是各种字体的基础以不同的方式使用它，如果你有像TypeTool这样的字体内部工具，你可以观察到这一点 - 一个基因可能称其为粗体斜体版本'MyFont Bold Italic'而另一个调用他们的'MyFont'并留下粗体斜体说明符在其他字体参数中设置。
与此同时，Windows（至少是Windows 10）似乎更新了它在安装时映射字体的方式，识别出糟糕的名称，然后呈现为一个家庭。 MS Office似乎没有加入这种方法（例如，见证PowerPoint字体选择列表中的糟糕名称），但如果浏览Windows / fonts文件夹，则可以看到它。
现在，这一切都非常好但是如果您只是采用传统的GDI32字体名称并尝试在dw中实例化字体，那么它将失败。该解决方案似乎是预处理GDI32字体名称以切断重量，宽度和斜率枚举字。完成后，dw将匹配您的字体。
这种方法在初始测试中似乎非常可行，而且当字体确实不存在时，我们可以很容易地返回一些丑陋的默认值，例如'Courier'，而且我们可以便宜地获得字体系列成员的列表，如果可以的话我们想要选择另一个成员，如果不存在所需的成员（我知道如果我们沿着这条路走，我们倾向于重新发明字体映射器）。
结论：dw字体命名与GDI32不同。您可能与GDI32一起使用的更具异国情调的字体名称不能保证与dw一起使用，并且需要按摩到dw格式，但它是可行的。
我稍后会更新上述方法的结果。