Closed rbeesley closed 4 years ago
Thanks! This is a font rendering issue, and unfortunately can be challenging to sort out as it is dependent on font hinting, app rendering mode, screen resolution, and OS scaling.
Before I do my investigation, can you tell me what your OS scaling factor is?
100%, no scaling. I should also point out that this is probably not a high priority. The difference is maybe a pixel and possibly subpixel alignment. It's just that at the default font size for VS Code I initially thought the alignment shifts were intentional, and the bug I thought I was going to write was that oldstyle figures were probably inappropriate for sub/super script. When I realized they were probably hinting problems, I thought it was still right to log the bug and didn't see one in the bug history, but it has very minor impact and if I weren't looking at them in source code, I probably wouldn't have discovered this. It's a low impact issue but also worth documenting in case there are other problems which surface at this rendering size.
@rbeesley Could you test the below font file (Cascadia Code TEST Regular)and see if it resolves your issue?
If not, can you please attach a screenshot? Thanks!
Correct: Consolas:
The problem I described can be seen at line 163 in the source. 1, 2, 4, and 7 appear to be shifted up slightly. This problem is consistent in Cascadia Code, Cascadia Code PL, Cascadia Code TEST, and even derived fonts like CaskaydiaCove Nerd Font, and Delugia Nerd Font, the last of which is where I actually first saw this, then confirmed it was a problem sourced in Cascadia Code.
Incorrect: Cascadia Code: Cascadia Code PL: Cascadia Code TEST:
Interestingly, although there doesn't seem to be a difference between the subscript characters between Cascadia Code and Cascadia Code TEST, there is a difference with how they align throughout.
I noticed there was a slight shift up of all the characters when I switched to Cascadia Code TEST. I figured the buffer had just moved slightly so I brought it into Paint.NET and ran a difference. To account for any buffer alignment problem, I placed the cursor on line 136 in the source moved the buffer so that it was offscreen, then pressed the up arrow to move to line 135. I did this for both Cascade Code and Cascadia Code TEST, and I then repeated the method again for both fonts. A difference of the two Cascadia Code captures and a difference of the two Cascadia Code TEST captures shows that the fonts are the same between both sets of tests. There is a noticeable difference between the Cascadia Code and the Cascadia Code TEST fonts.
Difference of Cascadia Code TEST to Cascadia Code TEST with a screen capture of Cascadia Code in between:
I didn't make a capture difference of Cascadia Code PL, but just as a visual inspection you can see that it looks the same as Cascadia Code, based on where line 135 is intersecting with the top of the window buffer. The slight artifact in "Commonly Used" visible on both differences was because I clicked in that region while trying to relocate my cursor and to deselect anything, but it should not be considered to be a problem with what you are having me check.
Thank you for the indepth response! I'd actually misunderstood what you were saying—the pictures make it much more clear.
So the way the font is set up, the superscripts are locked to control points. Those have been set correctly at the top of the cap height. And then the subscripts are component versions of the superscripts that have been shifted down. Strangely, the offsets for the subscripts were set inconsistently in the hinting instructions. I've gone through and corrected them.
Will upload a new PR with this. Thanks!
Environment
Steps to reproduce
Open VS Code and set the Font for the editor to Cascadia Code. 14 pixels is the default size for a VS Code editor window. Copy and paste the sub/super script numbers in the editor.
Expected behavior
The sub/super script numbers should render at the same relevant foot and head heights as the standard numbers, at larger font sizes.
Actual behavior
At 14px, subscript numbers (₀,₁,₂,₃,₄,₅,₆,₇,₈,₉) and superscript numbers (⁰,¹,²,³,⁴,⁵,⁶,⁷,⁸,⁹) appear to render with an appearance similar to oldstyle figures. Using 0 as the baseline, the heads and feet of 1, 2, 4, and 7 appear to align above baseline while 3, 5, 6, 8, and 9 appear to be on the same baseline. Closer inspection at a higher point size, shows that this is this inconsistent with oldstyle figures in how the ascenders and descenders are supposed to be rendered, therefore they are not oldstyle figures after all, but it doesn't change the fact that the rendering looks inconsistent at this point size compared with how they look at a larger point size.