Corruption on Archlinux

[vodik]

Hey, so I saw your article today and thought I'd give this font a shot. However, trying it on Archlinux I see glyphs getting mixed up. Here's a code snippet with Envy Code R: vs Monoid . I see * and x and = and ≤ getting mixed up. Additionally (not visible in the screenshot), '<' displays as a space.

Another guy on the #archlinux IRC channel also gave it a shot and he sees similar problems. https://i.imgur.com/Mvjsf0W.png

This is the PKGBUILD I used (from AUR). Not sure if this is a correct way to build the font, but even if I replace the build line to python3 ./build.py and package all the resulting ttf files, I see the same problems. The patch just replaces a few instances of xrange with range to get the thing to run.

[chase]

I have no idea why that PKGBUILD is trying to build the font when the latest version is always available from https://cdn.rawgit.com/larsenwork/monoid/release/Monoid.ttf.zip

That's a lot of useless work to achieve something our build script does automatically.

Could you try using the TTF from that zip file?

[vodik]

Okay, looking at a few more applications, maybe I shouldn't be surprised gvim can't handle it correctly. So some additional observations:

• emacs works perfectly but doesn't attempt ligatures
• libreoffice and gedit both get the ligatures but screw up spacing and also get the * -> x wrong:

[vodik]

Sure, on it

[vodik]

Only difference I see with the font in the zip file is that * now shows up correctly: . Same in gvim, but the problems with equality ligatures persists.

[chase]

@larsenwork This definitely seems to be a regression caused by ligatures.

[larsenwork]

hmm...it's technically not the ligatures but the contextual alternates that seem to cause on archlinux. I'll fire up my linux vm later today and try a couple of things. @chase do you think it could be possible to add a disable liga+calt option to the script?

[chase]

The thing is, the contextual alternates were not an issue before ligatures were added. I use Arch Linux myself. I could certainly try, but again, it'll have to wait until the weekend.

[larsenwork]

@chase the contextual alternates are used together with ligatures and were added at the same time. https://medium.com/@larsenwork/ligatures-coding-fonts-5375ab47ef8e#ca6e

[chase]

Ah, shows how much I know about fonts and typography, hahaha. I thought contextual alternates were just the glyph.alt in the font, didn't realize there was such a feature.

[larsenwork]

That's stylistic alternates - whole different thing (although we're using those too) :wink:

[chase]

For what it is worth, XFT and font rendering in general is pretty behind the times in Linux land.

[larsenwork]

@vodik could you try one of the "nocalt" zips here: https://github.com/larsenwork/monoid/tree/release

If that one works (it should be without the ligatures) the try whatever version you prefer from here: http://larsenwork.com/monoid/ (they all have ligatures+calt enabled).

[vodik]

Its improved, good job and it certainly looks better. Here are my findings:

• The nocalt font worked perfectly but I saw no replacements (I take it calt stands for contextual alternatives, so thats probably expected)
• Installing the font from your website looked a lot better in general

However:

I picked to have the 'l', seems like it doesn't work with the bold font (and noticeable in the other screenshots where it arises (see while in gedit).

Worked perfectly in gedit but spacing is a bit weird

(Not a big deal, imho the space around <= is too much)

Ligatures still screwed up in gvim:

For context:

    size_t sep = strcspn(val, "=");
    if (val[sep] == '\0')
        return;

and

    while (l < &b[bytes_r]) {
        size_t nl = strcspn(l, "\n");

        l[nl] = 0;
        parse_agentdata_line(l, data);
        l += nl + 1;
    }

to help understand the more problematic rendering, but in general the rendering is improved. Looks like its only < and = that are incorrectly rendered.

I see the same problems directly in gnome terminal

[larsenwork]

The "l" is simply because bold is only 90% finished. The <= is that still the nocalt version? "Liga" ligatures are only used for the social icons - the rest is created using calt. https://medium.com/@larsenwork/ligatures-coding-fonts-5375ab47ef8e#4be8

[larsenwork]

@vodik I agree about ≤≥≠ - they'll be wider in next update

They would be prettier if the were narrower but I can't do that since I don't want any jumping (I turn off ligatures on my cursor line) https://twitter.com/larsenwork/status/620877504421756928/photo/1

[larsenwork]

@vodik ping :smile:

[vodik]

@larsenwork haven't forgotten, just been kept busy. I'll have something for you Sunday.

[bitwave]

maybe this helps :)

https://aur.archlinux.org/packages/ttf-monoid/

[plgruener]

I can confirm, there's a Problem with gVim/Vim (Terminal) (tested under Ubuntu/Linux). Hasklig and FiraCode do also state that. (Maybe adjust the issue-title ?)

EDIT: same Problem as described above by vodik. < gets invisible, = gets the ligature of <=, >= gets totally screwed up. some other ligatures don't work at all. in image: < > = <= >= != !== -> =>

[larsenwork]

@plgruener What's the problem you're experiencing in Linux terminals? Screenshots/description...

[plgruener]

I've updated the previous comment.

[larsenwork]

Does this also happen in the nocalt version?

[ajpaulson]

I also got this issue on Ubuntu with a US keymap - I did not test it inside an editor, I saw the issue in Sakura term and Gnome terminal.

[larsenwork]

@ajpaulson also for nocalt version?

[plgruener]

No, nocalt version seems to work fine.

[larsenwork]

Ok, for this issue to be fixed I'm afraid you have to raise with whoever's behind the linux terminals to add proper opentype support - the features I'm using are called "liga" and "calt"

[ajpaulson]

Can confirm that NoCalt works correctly - I haven't seen this happen with any other font. Are you the only font creator making use of 'liga' and 'calt'?

[larsenwork]

For monospaced fonts I'm pretty sure no one else uses "calt" "liga" is used by other fonts with ligatures. The problems reported are all related to calt.

[larsenwork]

And I can't do what I do using only liga :smile:

[ajpaulson]

I think it may be a libvte issue actually - Gnome terminal and Sakura both use libvte.

I tested on Xterm and URXVT (neither of which use libvte) both of these worked ok.

edit I take it that typing <= should call the alternative ≤ to be displayed? If so I can't get that to work.

[larsenwork]

Great: https://github.com/GNOME/vte

If you have the time then please add your findings to the readme editor support section :smile:

[larsenwork]

@ajpaulson please make new comments instead of edits (they don't pop up in my feed :wink:)

When you say <= doesn't work - is that in Xterm or Sakura?

[ajpaulson]

Apologies - I didn't know edits didn't notify.

When I tried in Xterm and URxvt (where the standard Calt version of the font showed correctly), entering <= just remained as it was - I'm beginning to suspect that full support for Calt and Liga in opentype fonts is a little lacking in general.

[larsenwork]

Cheers

So some (most) ligatures work but not all? Or none at all?

[ajpaulson]

I think I totally misunderstood - I though you were using calt as a way to replace <= with ≤

Inputting ≤ via an alt code shows the correct ligature.

[larsenwork]

No, that is exactly what I'm doing. <= should look like a wider ≤

[ajpaulson]

Then this is not working in Xterm or URxvt - it seems that Calt is not fully supported in most terminal emulators on Linux (libvte based ones being the majority and not supporting at all).

some insight into the state of OpenType GSUB feature support is hinted at in this SO post from last august: http://stackoverflow.com/questions/24673444/which-opentype-gsub-features-does-qt-4-8-support

[larsenwork]

@ajpaulson cheers, It'd be :bowtie: if you update the readme with your findings.

Closing this as the corruption seems gone (at least when using nocalt version)

[vodik]

Well looks like someone beat me to this (sorry for the delay), but yeah, downloading the latest version of this font from your site indeed works 100% as intended. Can't see anything misrendering between gvim, gnome-terminal or gedit.

Thanks for the work!

[plgruener]

@larsenwork whatever you changed in v.56, the "wrong" ligatures in gvim are gone now, so it looks like the nocalt-version – except for the = which are longer now (same length as + and -). But that's not really an issue.

[larsenwork]

Cheers. The narrow "=" before was a bug.

[vodik]

Actually, there is something, don't know if it should be a separate bug. >=<= renders correctly but <=>= doesn't.

[larsenwork]

can quickly be fixed...shouldn't they both be "un-ligaturised", or?

[vodik]

The second you enter <=>, the ≤ reverts back. Add another = and the second bit becomes a ligature.

Probably the best behaviour is to unligaturise since if someone writes >==, the probably expect to see >== and not ≥=