Add variant curved phi glyph for U+03C6

[jebej]

Currently, Cascadia code displays the same glyph (phi with straight vertical bar) for both U+03D5 and U+03C6. It would be nice if the "curvy phi" glyph was added. Note that there exists confusion as to which glyph should match to which codepoint. For me personally, ideally it should match to latex/unicode-math:

Here's what it looks like in vscode with Cascadia:

The above rendered correctly (in my opinion) by lualatex with unicode-math package:

Raw text, which depending on browser font might or might not render correctly:

\begin{align}
  &\text{U+03D5 (phi):}    & \phi   \, ϕ \\
  &\text{U+03C6 (varphi):} & \varphi\, φ
\end{align}

Interestingly for me in the editor window the glyphs are correct but when rendered they are swapped (i.e. U+03D5 gets the curvy symbol, wrong in my opinion).

[aaronbell]

Thanks for the comment. A couple of points:

1. Cascadia Code only supports uni03C6, which is the standard unicode slot for the phi characters. Any character that you see show up for uni03D5 is a fallback glyph coming from another source. I think that you've confused the two's names as 03D5 is the variant version and 03C6 is the standard.

2. There are different (acceptable) approaches to the design of the phi. The curved variant is more common with more handwritten-centric designs (such as for Cascadia Code Italic where it is used). The 'straight' version in Cascadia Code I think fits better with this design.

All that aside, I'm open to considering the addition of the curved variant under a stylistic set. It probably would make sense to do some sort of more extensive math-centric upgrade to the font at some point, and this would certainly fit into that work item.

[jebej]

Thanks for the quick answer (and thanks for the work on this font)!

1. Cascadia Code only supports uni03C6, which is the standard unicode slot for the phi characters. Any character that you see show up for uni03D5 is a fallback glyph coming from another source. I think that you've confused the two's names as 03D5 is the variant version and 03C6 is the standard.

I see, I didn't realize D5 was a fallback. As I said, there exists a confusion, e.g. see here and on Wikipedia. Whether C6 or D5 is called the "variant" is inconsequential, I was simply labelling according to the latex notation which calls the curved phi varphi. The Unicode standard calls it GREEK SMALL LETTER PHI, while D5 is GREEK PHI SYMBOL, so from that reference none of them are "variants".

If we want to add the curved glyph, it should be mapped to C6, not D5 since D5 must be the stroked one:

If the above makes sense and with the intent of supporting both codepoints with distinct glyphs, it seems that the current glyph could be moved to D5, and C6 should get a new curved symbol.

[aaronbell]

Per the unicode spec C6 is under the "Letters" set, and D5 is under the "Variant Letterforms" set. That's where I am pulling the name. Strange that Latex calls C6 varphi. The Unicode comment stating "showing considerable glyph variation" I believe is in relation to the application of stroke contrast to the letterform, whereas the symbol might have less (though I'd probably design it using the same contrast as the standard version)? I'd have suggested naming them phi and symbolphi. Anyway.

I do appreciate the desire to differentiate the two forms, but I do not intend to change the current C6 form as it is correct for Greek typesetting. That said, I am open to adding a curved variant of C6 that will be accessed via OpenType features (likely with any other math-centric substitutions). I believe LATEX can support those without issue, so that would still enable your use case.

[jebej]

Per the unicode spec C6 is under the "Letters" set, and D5 is under the "Variant Letterforms" set. That's where I am pulling the name. Strange that Latex calls C6 varphi.

I see, thanks.

That said, I am open to adding a curved variant of C6 that will be accessed via OpenType features (likely with any other math-centric substitutions). I believe LATEX can support those without issue, so that would still enable your use case.

My use case is to write code (plain text) with Cascadia Mono and to have both glyphs available. Would that work with the Opentype feature? I suppose that would also require mapping D5 to the existing glyph.

[aaronbell]

Yup! Opentype feature support is dependent on the writing environment, and most offer at least basic support for stylistic sets. What do you use?

[jebej]

The main editor would be VSCode. Does that mean you would select the font to be a hypothetical Cascadia Mono (Math)?

[aaronbell]

In VSCode, you would select Cascadia Mono, and then add a line to your settings.json like:
"editor.fontLigatures": "'calt', 'ss01'",

[jebej]

Got it, thanks again for the discussion. I'll keep monitoring the release notes in case you do end up making the curved glyph (I have absolutely no idea how long it takes to make a glyph)!

[cormullion]

This phi stuff is quite confusing :), and I think the Unicode guidance isn't as clear (to me) as it could be:

at http://unicode.org/reports/tr25/

But that last sentence:

fonts that also intend to support technical use of the Greek letters should use the loopy form to contrast

is probably the reason why coding fonts have generally adopted a curved version of U+03C6, with Consolas being the exception that caused the confusion referred to above.

[jebej]

Thanks for this page. The explanation seems clear to me, it's just that it leaves the choice to implementers on whether to use the curved or straight glyph for C6.

With variants, as mentioned by @aaronbell, it is possible to support both a straight or curved C6, in addition to the always straight D5.

coding fonts have generally adopted a curved version of U+03C6

That would certainly be my preference, but I don't write Greek text! They do mention that the curved form is used more often in text too, though I can't comment on that.

Consolas being the exception that caused the confusion referred to above.

That might be because they were following the earlier standard? It sure would be nice to get it fixed though...

[cormullion]

Yes, the OpenType Stylistic Set or variations features work well in browser-based editors (VS-Code and Atom), it’s the terminal users who’d struggle, since many terminals and emulators are bad at OpenType support. ☹️