Extended font weight support?

[Artoria2e5]

Mintty will fail to select a font if its 'Weight' info is neither 'Book' (i.e. Regular) nor 'Bold', and when its lfFaceName, or 'PostScript 'Family Name' in the font, is not changed to show its weight.

So imagine a font 'Foo', with two weights 'Regular' and 'Medium':

PS Fontname: Foo-Regular
PS Family Name: Foo
PS Name For Humans: Foo Regular
OS/2 Weight Class: 400 Regular

---
PS Fontname: Foo-Medium
PS Family Name: Foo
PS Name For Humans: Foo Medium
OS/2 Weight Class: 500 Medium

When the user tries to choose 'Foo Medium', mintty will only record "Foo" as the face name, and since this is not a bold, is_bold is not written either. What mintty ends up doing will be choosing Foo, so Foo Regular in the end. Interestingly, hand-specifying Font=Foo Medium works, although one may really expect the definition of face/family names in lpszFace to be the really same as the one in lfFaceName.

For a real life example, try Inziu Iosevka SC 1.7.5. This font marks its bold weight as demi (be5invis/Iosevka#68), making it not selectable. Font=Inziu Iosevka SC Bold or mintty -o font='Inziu Iosevka SC Bold' gives you the expected image of everything being bold (which is, well, hardly enjoyed by anyone).

[mintty]

Some general remarks first:
The many levels of font weight provided at the Windows API are not matched by the multitude of applications, including MS’s own and even Windows’ own font selection menu.
Therefore the handling is simplified, maybe a little bit too much.
On the other side, the two weights of that font are clearly visually apart and it's not a good idea to assign two close weights to them (400, 500). I would consider that as a font bug, and as it seems, this has meanwhile been fixed.
Having said this, if there were a font with well-assigned 400 and 500 weights, would you want to use these weights with little distinction for normal and bold terminal display?

[mintty]

Code lines involved for configuration (winctrls.c):

  lf.lfWeight = (fs.isbold ? FW_BOLD : 0);
    fs.isbold = (lf.lfWeight == FW_BOLD);

[mintty]

Taking up your case, you might want to use the Medium weight for normal display (and not use the "BoldAsFont" option).
The question is, how to select that? Simply comparing FW_MEDIUM instead of FW_BOLD is not a good idea because there could be other font families where MEDIUM is the "Normal" weight and there is another bolder weight; then the lighter weight would be marked as bold which is not desirable. A list of available weights of the selected font family would help here. I'll look into this, but if it turns out the Windows API doesn't easily provide such a list, I'm not sure implementing this is worth the effort.
Opinions and support welcome...

[mintty]

In the description of the LOGFONT structure (https://technet.microsoft.com/en-us/aa911419), lfWeight, it says "400 is normal and 700 is bold". This indicates that Windows support for more distinct handling of font weights is weak. Thus the actual problem is a genuine Windows issue. I don't feel too compelled to craft a workaround for that. Paches welcome, though.

[mintty]

Previous observations about the Windows font selection menu were not proper; it does actually support more than 2 weights.
I'm in fact close to some enhancement now. If you're still interested, welcome to participate in design.
One thing still puzzles me: If a font is chosen (CreateFont) by specifying width 700 but the family only has 600, will Windows provide the 600 version or generate some derived bold? I don't see a visual distinction.

[Artoria2e5]

From what happens with the "face" 'Foo Medium', it looks like Windows will just choose the 600 version.

[mintty]

Released a number of font configuration improvements in 2.2.4.

[Artoria2e5]

Wow, thanks!

[mintty]

I've uploaded a font weight selection tweak enforcing selected boldness, see
https://cygwin.com/ml/cygwin/2016-04/msg00206.html
I hope it doesn't spoil the previous solution...

[mintty]

Released tweak in 2.3.6 to enforce boldness if selected explicitly.
You may want to check for regression.