microsoft / cascadia-code

This is a fun, new monospaced font that includes programming ligatures and is designed to enhance the modern look and feel of the Windows Terminal.
Other
25.8k stars 802 forks source link

At 14px sub/super script numbers 1, 2, 4, and 7 do not appear to be horizontally aligned correctly and are slightly higher than the other numbers #257

Closed rbeesley closed 4 years ago

rbeesley commented 4 years ago

Environment

Cascadia Code version number: 1911.210
Application (with version) used to display text: VS Code (1.44.2)
OS platform and version: Windows 10 (19613.1005)
Screen resolution (i.e. 220dpi): 1920x1080@141dpi (although this issue seems to be device independent)

Any other software?

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.

aaronbell commented 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?

rbeesley commented 4 years ago

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.

aaronbell commented 4 years ago

@rbeesley Could you test the below font file (Cascadia Code TEST Regular)and see if it resolves your issue?

CascadiaCodeTEST-ship.ttf.zip

If not, can you please attach a screenshot? Thanks!

rbeesley commented 4 years ago

Correct: Consolas: 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 Cascadia Code PL: Cascadia Code PL Cascadia Code TEST: 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. Difference between Cascadia Code and Cascadia Code TEST

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: Difference of Cascadia Code TEST to Cascadia Code TEST

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.

aaronbell commented 4 years ago

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!