Tally does not render correctly (match+stile)

[kenmellem]

The tally function which is a combination of match (≡) and slash(/) does not correctly render (≢) as the combined character (similar to not-equal (≠)).

∇ tallyShownAsTwoChars
≢
∇

Sorry if this Issue should be reported elsewhere. Note: this is what is happening on my computer - and everyone in my company using Github Enterprise using Windows. Have not tested on Mac.

[e9gille]

This is a known bug on Windows. It's been reported by Nick Nikolov Adam Brudz somewhere (I'll se if I can find the link). Nothing you can do about it here I'm afraid.

[Alhadis]

That has nothing to do with either of us, and everything to do with the design of that particular glyph in the font GitHub's using for character rendering. I'm seeing it too; note that when inspected in the devtools, the highlighted character appears as one glyph:

Which, on this current machine (macOS), is Consolas.

[e9gille]

here, found it: https://bugs.chromium.org/p/chromium/issues/detail?id=620629#c8 and it's been closed as you can see...

[Alhadis]

Yeah, I suspected it had something to do with font-rendering, which may have actually been a conscious decision from a Chromium developer.

BTW, if you observed a = and / character merging in two different keystrokes, it's possible the editor font is using an OpenType contextual ligature to make two adjacent characters appear to be a single entity.

Ligatures are fun to play with, and I've actually edited my preferred font with "elastic" versions of ← that expand to fill surrounding space:

Look what happens when I remove the spaces:

|not P|  |ntP|
|\ & ¯|  |\&¯|
|≡ ≢ ≤|  |≡≢≤|

A similar effect is being achieved with these sequences:

/= ==
=> <=
-> <-

[e9gille]

That's really interesting. We've talked about (and tried) coding with a proportionate font, but I haven't got used to coding in anything but a monospaced font. The argument was to use a non-mono font in the context of articles, academic papers or the like to make it fit in with the text.

[Alhadis]

I'm a HUGE font/typography nerd. You've come to the right place.

My favourite font for technical documentation is Cambria Math (commercial, but available on all Windows systems). I could easily enhance it for you in an editor if you needed clearer-looking APL glyphs.

[kenmellem]

What about the font Dyalog has - APL385? Could it be an alternative to set this as default for *.apl code?

[e9gille]

I'll check out the Cambria Math font, but it would be good to have a font that could be generally distributed.

I don't know that you can specify a font to be used on GitHub, can you?

[kenmellem]

I don't know that you can specify a font to be used on GitHub, can you?

https://stackoverflow.com/questions/7372428/changing-the-default-github-code-font which of course is not an optimal solution... it is also 3 years old.

[Alhadis]

Nope, sorry. Design-related facets (like font choices) are entirely internal to GitHub's design team. This is the monospace font-stack being used in the site's CSS:

code, pre, tt {
    font-family: SFMono-Regular, Consolas ,Liberation Mono, Menlo, Courier, monospace;
}

Browsers use the first font-face they have available, so the exact font you see depends on what fonts you have installed on your system. Good news, though: if you install Chrome's User CSS extension, you can forcefully change the APL font by adding this snippet of CSS:

pre.highlight-source-apl,
code.highlight-source-apl,
.highlight-source-apl pre,
.highlight-source-apl code{
    font-family: APL385;
}

[kenmellem]

I opened up this issue on my Mac - using Safari - and it renders the glyph correctly. As also proven on the chromium ticket by some user. How can the conclusion on that ticket be correct?

[e9gille]

Interesting, on my Chrome on Mac it rendered tally correctly in Menlo.

Cambria Math tested on RIDE. APL glyphs would definitely need some work:

[Alhadis]

Are you intending to use a proportional font for editing or printing/publication? If it's the former, you won't find too many that look good in a code editor...

Here's my patched editor-font, BTW. In case you were curious (I added and tweaked the APL glyphs myself, IIRC).

[e9gille]

Well, we've explored using it for editing but I find it distracting when things don't line up :) I've tested you font briefly, will try using it while working and will let you know. Looks nice though on first glance.

[Alhadis]

I'm assuming Dyalog's text editing windows don't support OpenType features like ligatures and contextual alternates. Mine does. 😂

Being able to type -> and have it look like an actual arrow is something you tend to miss when it's gone.

[Alhadis]

Anywayyyyyy. The original issue is not only unrelated to this package or GitHub, but something that's completely out of our power. So I'm gonna close this issue: I recommend opening a new ticket to Chromium, and hopefully you get some cold hard rationale WHY "strictly not equal to" is displayed as "equal forward slash".