tonsky / FiraCode

Free monospaced font with programming ligatures
SIL Open Font License 1.1
76.17k stars 3.08k forks source link

Hyphen based ligatures don't work in WPF #259

Open citizenmatt opened 7 years ago

citizenmatt commented 7 years ago

This is related to the issues people have reported with Visual Studio where ligatures that contain a hyphen, such as -> or <!-- don't work in Visual Studio.

It actually looks like this might be a generic WPF issue, rather than just Visual Studio.

I created a dummy WPF application that simply included a TextBlock, Label and FlowDocumentReader. The TextBlock and Label will display ligatures correctly, apart from those containing hyphens (e.g. ->). Strangely, the FlowDocumentReader works as expected.

screen shot 2016-08-29 at 10 51 33 am

I tried to debug the Visual Studio editor, and as best as I could follow, it's not the editor that's doing the work to display ligatures - it comes automagically from WPF and Windows. It looks like the editor is using Windows' native "Line Services" and for some reason, this component is treating the hyphen as a separate character, rather than as part of a run - and so it gets rendered separately, and not converted into a ligature. Hyphenation appears to be disabled in the Visual Studio editor code, and it's definitely disabled in the TextBlock and Label in my dummy application.

I've no idea now what's going wrong, and I strongly suspect this is a WPF/Windows issue and not something that could be fixed in the font, but I'm hoping that we get a nice friendly WPF expert wandering past who can help out.

Could it be something stupid like Windows doesn't recognise "hyphen" in the ligatures?

Anyone got any ideas?

clairernovotny commented 7 years ago

This isn't Windows, it's WPF. If you try in a UWP app, it renders correctly. I asked folks at VS to look into it and here's what they found so far:

Looks line LineServices (a low-level component that WPF uses to help format text) treats ‘-‘ specially, presumably for the line-breaking algorithm. With the result that it’s never placed in the same glyph run as normal characters like ‘>’. So by the time DWrite sees the text, it looks like GlyphRun(“--") GlyphRun(“> >= ==> 3/4"), and DWrite doesn’t recognize the ligature that changes ‘-->’ into the right-arrow glyph.

citizenmatt commented 7 years ago

Nice one - very useful info! Is there any indication of a fix being worked on?

saul commented 7 years ago

@onovotny have you received any word from the guys at VS that this is being worked on?

slang25 commented 7 years ago

@onovotny are you able to use your influence to bring this up with them another time. I think there's about a month before VS2017 changes are frozen, it would be sweet if they can get this sorted in time, sounds like they are onto the root cause.

Porges commented 7 years ago

Here's a relevant UserVoice suggestion to get this fixed: https://visualstudio.uservoice.com/forums/121579-visual-studio-2015/suggestions/12983895-fix-ligatures

anjelo commented 7 years ago

Update from the Visual Studio dev community: https://developercommunity.visualstudio.com/content/problem/44061/some-programming-ligatures-do-not-work.html

saul commented 7 years ago

That's a real shame :(

jogibear9988 commented 7 years ago

I've also added a connect issue: https://connect.microsoft.com/VisualStudio/feedback/details/3133502/ligatures-dont-work-correctly-in-wpf

sgrottel commented 5 years ago

Btw, it's also the same with VS 2019 preview.

slang25 commented 5 years ago

I've just got the notification that the issue is a "wont fix" :(

clairernovotny commented 5 years ago

@slang25 I would wait until WPF for .NET Core 3 is fully open sourced.

slang25 commented 5 years ago

That's a very good point!

limbusdev commented 5 years ago

Persists in Visual Studio 2019.1

lifeforce-dev commented 4 years ago

Bummer :( maybe one day it will come out of Won't Fix.

HolisticDeveloper commented 4 years ago

I overlooked this when scanning the history of this issue so I thought I would post an explicit comment. The issue is now tracked in the WPF team's GitHub issues: https://github.com/dotnet/wpf/issues/109