I know this isn't the most constructive comment, but as a South Park fan, I will never not call this font NAMBLA[0]. I know what the nabla symbol is, I know it's completely unrelated. But it's just too damn close.
Yeah I feel like "recall" is being confused with "recognize" here. I'm sure any programming who's been at it for more than a year would also recognize the Rust, Swift, Kotlin, and probably even Elixir logos. But I agree that Python and Java are some of the easiest I can recall despite not having worked regularly with either of those languages in the past year
In my headcanon Duke is a personified Ouija board planche. Just like the planche is the go-between for the user and the Ouija board, Duke is the go-between for the user and the tablet computer for which Java was originally designed.
It might be a bit of a stretch, but he was originally more than a mascot but a "software agent" through which the user's actions were carried out, a sort of more active version of Clippy.
Myles @ WebKit seems to raise some excellent points, but I'm not up on browser internals. The criticism seem very much in line with my understanding of motives and incentives within Google, which leads to much duplication of effort.
The Nabla web page makes it seem like "Finally! Color fonts!" while Myles @ WebKit makes it clear that "Many OT-SVG fonts already exist," which seems true[0].
Sigh. I wish people viewed Google more accurately as breakers of web interoperability instead of praising the relentless Chrome hegemony.
Not really? COLRv1 only officially landed in OpenType 1.9 with some changes slated for 1.9.1 - OpenType is a consortium consisting of many players, none of them implementing things until the spec is actually official.
Except, of course, when it's some company's own suggestion: MS will early-implement support for new features they themselves propose, Adobe will early-implement support for new features they themselves propose, and in this case Google's engineers had it implemented before it was officially accepted because they proposed it.
Mozilla (and everyone else) waited until the draft become part of the spec, then had to spend the time implement a (non-trivially complex) new rendering pipeline, and make sure that works properly. COLRv1 fonts should work perfectly fine as of Firefox 107.
I'm running a build of 106 and it already appears to support much of COLRv1, the gradients in this font show up. Most of the website's sliders are disabled, though.
To be fair, opera is "yet another chromium", like edge and brave, so whenever Chrome adds support for something and upstreams it, all of those get it "for free".
Firefox 106 seems to handle the font just fine. I also see the gradients, they claim to not work on Firefox yet. But yeah, that line at the bottom is a bit weird...
The fact that some of the letters are at different "depths" makes this hard on my eyes, since it gives an "impossible geometry" look. For three different depths, see Y (forward), N (middle), and M (back). Look at the bottom of the character. This seems to come from a requirement that the top and bottom of each letter is on the same horizontal line.
They're not at different depths. Lowercase y and lowercase g reach under the baseline, and so the corners you're looking at appear, in the projection, to be at a lower height than, say, lowercase s. I don't see anything about uppercase m that makes it appear in a different position.
The horizontal line of the T goes down to the bottom left of the O. How can this be, since the bottom of the T would be in the middle of the bottom edge of the O, if they experienced the same transformation?
The Y has a different baseline than the T, which also doesn't make sense. They are both a centered vertical line, so they should be the same.
Maybe I'm just completely wrong. But, my eyes are used to boring perspective projections, rather than whatever this is, which is probably why it looks so wrong to me.
You're assuming that all letters have been rotated along an axis that goes through their leftmost edge. That's not necessarily true. Uppercase T and Y have been rotated along an axis roughly centered on their width.
I'm actually not making that assumption. I think it would be easier for my eyes if they did have the same transformation, but they clearly don't. My problem is that it's an impossible transformation!
If you place a piece of paper on your screen, as a horizontal reference line, you'll see the bottom (vertical) portion of the T is aligned with the left of the I. It extends all the way down. The top left of the T is also aligned with the left of the I. I don't see how this is possible.
The only way this is possible is if T has a longer horizontal line, which why it looks odd to me, a sort of "duck or woman" effect alternating between "is it left or center aligned", depending on if you look at the top or bottom, with the usual assumption that the characters would have the same height.
You're right, but I guess it would have looked even weirder to have the bottom of some letters at a very different height on the screen depending on their shape.
In principle, although the controls don't seem to be working for me at the moment (in either Firefox or Chrome). I guess it's a work-in-progress... (or maybe it's just me).
COLRv1 is also supported in Firefox 107 (currently in beta).
(Though in this case, the fact that the font also contains SVG glyphs gets in the way. Setting gfx.font_rendering.opentype_svg.enabled to false in about:config lets you see the COLRv1 glyphs.)
Cool font, the topmost two banner examples are a little big for optimal legibility on my monitor though, and zooming in/out doesn't change the size (it does for the lower ones, though). Because it expands past my normal reading FOV I keep seeing it as "I Some Try" instead of "Isometry".
Looks like the controls now work, but the font variability ones don't do anything. I assume this is due to actual lack of support of the features by Firefox.
[0]: https://en.wikipedia.org/wiki/North_American_Man/Boy_Love_As...