#2356 DirectWrite and GDI cannot handle special font faces

[Markus Nißl]

Scintilla's implementation of DirectWrite does not support font faces as the passed-in font name which makes it impossible to use certain font faces as APIs are missing to supply style (e.g. oblique) and stretch (e.g. expanded) next to the existing font attribute weight.

The default lexer weight of 400 also prevents GDI from rendering fonts with weights beyond the supported normal, semibold and bold weights, like "Iosevka ExtraLight" which demands 200.

A new supported font weight of 0 is required to make Scintilla configure both GDI and DirectWrite correctly.

Merge request 36 addresses these issues.

Related: Feature Request 1452

[Zufu Liu]

See [bugs:#2080], it works, but you need to pass the font family name "Iosevka" when using DirectWrite and typeface name "Iosevka ExtraLight" when using GDI, both require weight 200 (pass the integer directly even not in FontWeight enumeration).

[Markus Nißl]

it works, but you need to ...

I should have been more precise and have written: "Scintilla's implementation of DirectWrite does not support font faces out of the box or in an easy manner."

In many cases you can make the font faces to work, but with DirectWrite and GDI. But as explained in the thread on my merge request 36, if you don't use ChooseFont(), you will have a hard time determining the correct weight.

With Scintilla's current implementation you can get "Iosevka ExtraLight" to work with DirectWrite, but neither "Iosevka Oblique" nor "Iosevka Extended".

[Markus Nißl]

Any thoughts from Neil on this?

Please see also the discussion on merge request 36.

[Neil Hodgson]

This isn't cross platform and I can't see how to reasonably implement it on macOS or GTK.

Adding additional font attributes for stretch and style that can be implemented cross platform appears a better approach to me.

[Markus Nißl]

This isn't cross platform and I can't see how to reasonably implement it on macOS or GTK.

I wouldn't necessarily see this as a cross platform feature, but first and foremost as a fix to make fonts with all their font faces finally available to Scintilla on Windows.

My suggested approach to fix this on Windows is to go for FontWeight::Default as the default value for the weight field. To make the code compatible on other platforms, one needed to overwrite the weight field with FontWeight::Normal (in case the value was FontWeight::Default) before invoking the platform specific font creation code.

This approach will both not break existing code and allow for an implementation in future, in case needed.

Adding additional font attributes for stretch and style that can be implemented cross platform appears a better approach to me.

1. My suggested approach is way less work to fix the issue on Windows. I don't know if other platforms actually suffer from the same shortcoming, so why go for more work if it can be fixed way quicker and easier?!

2. There are a couple of bug reports for applications that use Scintilla where users and developers complain that certain fonts don't work with Scintilla. My approach works out of the box. No new APIs need to be implemented by applications to correctly tell Scintilla the font with the desired weight (a big issue right now in case of DirectWrite). Selecting a special style like oblique was neither possible with GDI.

3. Adding new font attribute APIs later is still possible.

[Neil Hodgson]

This uses the same CreateTextFormat API as the current code with some adjusted parameters. The application can adjust these parameters itself using IDWriteGdiInterop requiring fewer changes to Scintilla.

[Markus Nißl]

The application can adjust these parameters itself using IDWriteGdiInterop

Would you please explain your reasoning of being in favor of an approach where every developer needs to understand implementation details of Scintilla/DirectWrite over a solution that simply works out of the box like it does for GDI and other platforms?

requiring fewer changes to Scintilla.

Adding additional font attributes for stretch and style require way more changes to Scintilla.

[Neil Hodgson]

Would you please explain your reasoning of being in favor of an approach where every developer needs to understand implementation details of Scintilla/DirectWrite

You are overstating your case.

[Markus Nißl]

My merge request 36 fixes the three following bugs:

1. Calling SCI_STYLESETFONT with font face "Cascadia Mono SemiLight" works just fine with GDI. Switching the technology to DirectWrite breaks this.

2. As pointed out by Zufu Liu, FontDirectWrite::HFont() is unable to correctly recreate the font due to too little information. My patch fixes this.

3. Neither GDI nor DirectWrite are able to create a font with oblique style.

The application can adjust these parameters itself using IDWriteGdiInterop

This manual approach only works for point 1.

You are overstating your case.

I'm just puzzled by the fact that a well implemented bug fix patch that enhances both the developer and user experience receives that little appreciation.

[Neil Hodgson]

1. GDI and DirectWrite differ and its not a bug for that to be visible.

2. Not implementing DirectWrite for list box text is the underlying problem here and leads to other issues. HFONT conversion should eventually disappear.

3. Not supporting oblique is not a bug. Supporting oblique would be a sensible feature request if anyone actually wanted it.

I'm just puzzled by the fact that a well implemented bug fix patch that enhances both the developer and user experience receives that little appreciation.

This is mainly a feature addition. Characterising it as a bug fix is not reasonable.

[Markus Nißl]

This is mainly a feature addition. Characterising it as a bug fix is not reasonable.

IMHO my patch addresses bugs/faults/shortcomings because there are many bug reports and user complaints that are affected by them. I ran into these issues myself which was the reason to come up with this patch.

Feel free to think of them as feature requests if that makes more sense to you.

So allow me to rephrase: I'm puzzled by the facts ...

• that a well implemented patch that enhances both the developer and user experience receives that little appreciation.
• that you prefer to unload working out font properties to developers instead of handling it a central place which would remove the issue once for all for good.
• that you rather stick with shortcomings in the long run before you (or whoever) finally addresses them instead of fixing them now in a good way which does not hinder anybody to address them in a more sophisticated way later on.

[Neil Hodgson]

I will not be engaging further as this seems unproductive.

[Markus Nißl]

Not giving a true reason that justifies the rejection of an enhancing patch is disappointing.

I will not be engaging further as this seems unproductive.

Backing out of the discussing with a lame excuse is disrespectful.

[Zufu Liu]

Marked as fixed as font stretch [feature-requests:#1452] is implemented.