Add additional characters to Consolas Font #588

@be5invis commented on GitHub (Mar 12, 2019):

cc. @sindresorhus The list above comes from your figures lib.

@be5invis commented on GitHub (Mar 12, 2019): cc. @sindresorhus The list above comes from your `figures` lib.

claunia commented

@sindresorhus commented on GitHub (Mar 12, 2019):

It shouldn't just include symbols from my figures package, it should include all Unicode characters.

@sindresorhus commented on GitHub (Mar 12, 2019): It shouldn't just include symbols from my [`figures`](https://github.com/sindresorhus/figures) package, it should include **all** Unicode characters.

claunia commented

@be5invis commented on GitHub (Mar 12, 2019):

@sindresorhus
There are 87,887 ideographs currently in Unicode. You need all of them too?
We need a boundary, and characters beyond that boundary should be handled by font fallback / font linking / whatever.

What Consolas should cover:

Characters that used as symbols that used by modern OSS programs in CLI.
These characters should follow Consolas' design and metrics, and properly aligned with existing Consoals characters.

What Consolas should NOT cover:

Characters and punctuations of scripts that beyond Latin, Greek and Cyrillic, especailly characters need complex shaping (like Arabic).
These characters should be handled with font fallback.

@be5invis commented on GitHub (Mar 12, 2019): @sindresorhus There are 87,887 ideographs currently in Unicode. You need all of them too? We need a boundary, and characters beyond that boundary should be handled by font fallback / font linking / whatever. What Consolas should cover: - Characters that used as symbols that used by modern OSS programs in CLI. - These characters should follow Consolas' design and metrics, and properly aligned with existing Consoals characters. What Consolas should NOT cover: - Characters and punctuations of scripts that beyond Latin, Greek and Cyrillic, especailly characters need complex shaping (like Arabic). - These characters should be handled with font fallback.

claunia commented

@sindresorhus commented on GitHub (Mar 12, 2019):

There are 87,887 ideographs currently in Unicode. You need all of them too?

I don't need them all, but it shouldn't be limited to an arbitrarily chosen subset.

should be handled by font fallback / font linking / whatever.

This is more important IMHO. As a developer, I just want all Unicode characters to be available in some form. I don't care which font it is.

@sindresorhus commented on GitHub (Mar 12, 2019): > There are 87,887 ideographs currently in Unicode. You need all of them too? I don't need them all, but it shouldn't be limited to an arbitrarily chosen subset. > should be handled by font fallback / font linking / whatever. This is more important IMHO. As a developer, I just want all Unicode characters to be available in some form. I don't care which font it is.

claunia commented

@be5invis commented on GitHub (Mar 12, 2019):

@sindresorhus
I added a note that it is not a complete list.
Font fallback is not a simple task. Trust me, I maintain one, and it used >2000 lines of C++ to cover all the edge cases.

@be5invis commented on GitHub (Mar 12, 2019): @sindresorhus I added a note that it is not a complete list. Font fallback is not a simple task. Trust me, I maintain one, and it used >2000 lines of C++ to cover all the edge cases.

claunia commented

@zadjii-msft commented on GitHub (Mar 12, 2019):

I don't believe our team owns Consolas, nor am I really sure any team owns Consolas. I do know that our team certainly doesn't have the resources to make changes to a font ourselves, but I can sic @bitcrazed on trying to find a person to make updates to Consolas.

This is now the "Make Improvements to Consolas" thread

@zadjii-msft commented on GitHub (Mar 12, 2019): I don't believe our team owns Consolas, nor am I really sure any team owns Consolas. I do know that our team certainly doesn't have the resources to make changes to a font ourselves, but I can sic @bitcrazed on trying to find a person to make updates to Consolas. This is now the "Make Improvements to Consolas" thread

claunia commented

@be5invis commented on GitHub (Mar 13, 2019):

May also include full block elements support (U+2580--U+259F)

@be5invis commented on GitHub (Mar 13, 2019): May also include full block elements support (U+2580--U+259F)

claunia commented

@E3V3A commented on GitHub (Mar 28, 2019):

@be5invis

Just a few notes about the box characters:

See:

My experiments have show that:

2585, # Look best but is not part of cp437 and thus font dependent & not widely available
2580, 25A0, 2588 # IBM-437

def print_legend():
    #cc = u'\u2585' # Unicode Character for a "5/8th box"           # (U+2585) is not part of IBM-437
    #cc = u'\u2588' # Unicode Character for a "full box"            # (U+2588) is part of IBM-437
    #cc = u'\u25A0' # Unicode Character for a "black square"        # (U+25A0) is part of IBM-437
    cc = u'\u2580'  # Unicode Character for a "Upper half block"    # (U+2580) is part of IBM-437

The other "boxes" was not even considered, as they either didn't render anything like what one would expect from a "box", or it was placed too high/low within the character frame.

Running the following in a PWSH using Deja Vu Sans Mono, yield:

As you can see \u2587 renders as a rectangle in most windows consoles, and not like a box as in the GitHub using a browser (shown in OP.) So if you're going to add 2587 you should probably consider adding 2585, 2580, 25A0 as well, to make sure people actually can print a box when intended.

@E3V3A commented on GitHub (Mar 28, 2019): @be5invis Just a few notes about the *box* characters: See: * https://github.com/PowerShell/PowerShell/issues/8409 * https://en.wikipedia.org/wiki/Code_page_437 * https://en.wikipedia.org/wiki/Box-drawing_character * https://en.wikipedia.org/wiki/Block_Elements My experiments have show that: * 2585, # Look best but is not part of cp437 and thus font dependent & not widely available * 2580, 25A0, 2588 # IBM-437 ```python def print_legend(): #cc = u'\u2585' # Unicode Character for a "5/8th box" # (U+2585) is not part of IBM-437 #cc = u'\u2588' # Unicode Character for a "full box" # (U+2588) is part of IBM-437 #cc = u'\u25A0' # Unicode Character for a "black square" # (U+25A0) is part of IBM-437 cc = u'\u2580' # Unicode Character for a "Upper half block" # (U+2580) is part of IBM-437 ``` The other "boxes" was not even considered, as they either didn't render anything like what one would expect from a "box", or it was placed too high/low within the character frame. Running the following in a PWSH using `Deja Vu Sans Mono`, yield: ![pwsh_2019-03-28_10-12-36](https://user-images.githubusercontent.com/194392/55141145-a7161380-5131-11e9-94f3-3540a09f3be6.png) As you can see `\u2587` renders as a rectangle in most windows consoles, and not like a box as in the GitHub using a browser (shown in OP.) So if you're going to add 2587 you should probably consider adding `2585, 2580, 25A0` as well, to make sure people actually can print a box when intended.

claunia commented

@miniksa commented on GitHub (May 18, 2019):

This will probably not be necessary if Terminal is used or if DX is turned on in conhost since it will have font fallback.

@miniksa commented on GitHub (May 18, 2019): This will probably not be necessary if Terminal is used or if DX is turned on in conhost since it will have font fallback.

claunia commented

@eryksun commented on GitHub (May 18, 2019):

@miniksa, IIRC, conhost sort of works with manual font linking configured for Consolas in "HKLM\Software\Microsoft\Windows NT\CurrentVersion\FontLink\SystemLink". But last I checked the rendering seems to gets widths wrong, and the result is erratic. I suppose it's because it's based on the selected font instead of the linked font. Is there any way to improve the result with font linking?

@eryksun commented on GitHub (May 18, 2019): @miniksa, IIRC, conhost sort of works with manual font linking configured for Consolas in "HKLM\Software\Microsoft\Windows NT\CurrentVersion\FontLink\SystemLink". But last I checked the rendering seems to gets widths wrong, and the result is erratic. I suppose it's because it's based on the selected font instead of the linked font. Is there any way to improve the result with font linking?

claunia commented

@miniksa commented on GitHub (May 18, 2019):

A major point of moving to the Terminal and to the DX renderer is to not fix/update the GDI one anymore. So while it is always possible to improve it, it would be out of scope for what we're trying to achieve.

@miniksa commented on GitHub (May 18, 2019): A major point of moving to the Terminal and to the DX renderer is to not fix/update the GDI one anymore. So while it is always *possible* to improve it, it would be out of scope for what we're trying to achieve.

claunia commented

@eryksun commented on GitHub (May 18, 2019):

To clarify, I was wondering whether there's a way to tweak the configuration to get a better result, particularly in older Windows 7 systems. I know there's no chance to see font rendering improvements in the conhost window, at least not for a long while to come. You mentioned in another post that you might switch conhost to the DX renderer, but I won't get my hopes up for that.

@eryksun commented on GitHub (May 18, 2019): To clarify, I was wondering whether there's a way to tweak the configuration to get a better result, particularly in older Windows 7 systems. I know there's no chance to see font rendering improvements in the conhost window, at least not for a long while to come. You mentioned in another post that you might switch conhost to the DX renderer, but I won't get my hopes up for that.

claunia commented

@miniksa commented on GitHub (May 18, 2019):

I probably will change conhost to the DX one once it stabilizes and I feel like I have the capacity to accept bugs on it.

I also have no advice for Windows 7. It's dead as of January 2020. It's time to accept that and move on.

@miniksa commented on GitHub (May 18, 2019): I probably will change conhost to the DX one once it stabilizes and I feel like I have the capacity to accept bugs on it. I also have no advice for Windows 7. It's dead as of January 2020. It's time to accept that and move on.

claunia commented

@musm commented on GitHub (Dec 28, 2020):

Any chance we could also add ∅ ?

@musm commented on GitHub (Dec 28, 2020): Any chance we could also add `∅` ?

claunia commented

@DHowett commented on GitHub (Dec 30, 2020):

To Consolas? No.

@DHowett commented on GitHub (Dec 30, 2020): To Consolas? No.

claunia commented

@mdtauk commented on GitHub (Dec 30, 2020):

Cascadia Code/Mono is the font being targeted going forward, so you should direct your needs to that Repo

@mdtauk commented on GitHub (Dec 30, 2020): Cascadia Code/Mono is the font being targeted going forward, so you should direct your needs to that Repo

claunia commented