You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Some symbols don't really belong in fonts, especially when the support for them is cherry-picked from a larger set by request/preference. Most notably glyphs that have emoji coverage, as these will prevent the use of fallbacks to a system or user assigned/preferred font for covering those glyphs(monochromatic or colour).
As the font does not provide a replacement of such a large set(understandable), it makes little sense to keep them in the font as they will take priority and not be replaced, which can lead to inconsistent style/mix of fonts. Non-issue, if you're specifically using each of those glyphs/emoji for a given purpose in an editor, but if any unsupported ones are encountered, then there's not much that can be done to get consistency.
Here's an example of cases in VSCode, and this other issue specifically discusses a "Heavy Checkmark" glyph/emoji, that turns out to be one of the few included in Sarasa Gothic as the cause, preventing the user from having consistent presentation style for the checkmark and cross(neither of which are included in SCP afaik, although there is the regular checkmark, and the heavy and cross were requested in a related issue).
Related issues touch on a few cases of users being confused and thinking SCP was at fault, which most of the time, it wasn't(one time it was when it added a Coffee glyph). I've had it render the 263A smilely face as a fallback for sans-serif despite being a monospace font, and when a colour emoji font should have been used as fallback instead. I've addressed that since on the system side(other fonts have this same issue), but it'd be nice if there were a variant of the font that excluded them.
One of the related issues requests Music glyphs, another APL, and so forth. If the additions aren't really specific to the SCP style, it's mostly adding them and ensuring they have a fixed width to maintain a monospace font, along with ensuring those glyphs are used for when a user has less control over what font is used for fallback(Windows?).
Like Google has done with Noto fonts(and like what was suggested in the Music symbols request), splitting such glyphs out to their own fonts makes them composable elsewhere. I'm not sure if Google rebranded SCP under a Noto font name, but Source Han Code JP and later Source Han Mono have taken SCP and adjusted it(along with removing some glyphs?). If users were to want glyphs in those fonts that SCP gets, that's additional work to accomodate for, or if the user wanted to swap SCP for a different programming font family entirely, but keep the glyph style/coverage, that's not as easily doable.
Just to be clear, I'm not requesting the font drop the current symbol support(since I'm sure that'd probably upset existing users who enjoy them, or aren't able to assign fallbacks). But an official variant without them would be appreciated.
PR for 79 math symbols(not as big of a concern personally since the main issues encountered are usually with emoji, that said on Linux math symbols are treated as their own font family in fontconfig, and defined as a language Zmth/und-zmth in Unicode via ISO 15924).
The text was updated successfully, but these errors were encountered:
Some symbols don't really belong in fonts, especially when the support for them is cherry-picked from a larger set by request/preference. Most notably glyphs that have emoji coverage, as these will prevent the use of fallbacks to a system or user assigned/preferred font for covering those glyphs(monochromatic or colour).
As the font does not provide a replacement of such a large set(understandable), it makes little sense to keep them in the font as they will take priority and not be replaced, which can lead to inconsistent style/mix of fonts. Non-issue, if you're specifically using each of those glyphs/emoji for a given purpose in an editor, but if any unsupported ones are encountered, then there's not much that can be done to get consistency.
Here's an example of cases in VSCode, and this other issue specifically discusses a "Heavy Checkmark" glyph/emoji, that turns out to be one of the few included in Sarasa Gothic as the cause, preventing the user from having consistent presentation style for the checkmark and cross(neither of which are included in SCP afaik, although there is the regular checkmark, and the heavy and cross were requested in a related issue).
Related issues touch on a few cases of users being confused and thinking SCP was at fault, which most of the time, it wasn't(one time it was when it added a Coffee glyph). I've had it render the 263A smilely face as a fallback for sans-serif despite being a monospace font, and when a colour emoji font should have been used as fallback instead. I've addressed that since on the system side(other fonts have this same issue), but it'd be nice if there were a variant of the font that excluded them.
One of the related issues requests Music glyphs, another APL, and so forth. If the additions aren't really specific to the SCP style, it's mostly adding them and ensuring they have a fixed width to maintain a monospace font, along with ensuring those glyphs are used for when a user has less control over what font is used for fallback(Windows?).
Like Google has done with Noto fonts(and like what was suggested in the Music symbols request), splitting such glyphs out to their own fonts makes them composable elsewhere. I'm not sure if Google rebranded SCP under a Noto font name, but Source Han Code JP and later Source Han Mono have taken SCP and adjusted it(along with removing some glyphs?). If users were to want glyphs in those fonts that SCP gets, that's additional work to accomodate for, or if the user wanted to swap SCP for a different programming font family entirely, but keep the glyph style/coverage, that's not as easily doable.
Just to be clear, I'm not requesting the font drop the current symbol support(since I'm sure that'd probably upset existing users who enjoy them, or aren't able to assign fallbacks). But an official variant without them would be appreciated.
Related(Mix of request to support glyphs and issues/confusion they cause, all from this repo):
#114
#49
#208
#143
#101
#172
#16
Powerline issue with April 2019 update about future support perhaps leaving PUA
PR for 79 math symbols(not as big of a concern personally since the main issues encountered are usually with emoji, that said on Linux math symbols are treated as their own font family in fontconfig, and defined as a language
Zmth
/und-zmth
in Unicode via ISO 15924).The text was updated successfully, but these errors were encountered: