Serious usability issue with ligatures

[activa]

The ligatures in PragmaPro look great but there's a serious issue when trying to edit text that was rendered as a ligature. It's impossible to place the cursor inside a multi-part ligature and moving the cursor over a ligature has very unexpected results.

For example, when the cursor is to the right of the != ligature, moving one position left doesn't do anything. The cursor is "virtually" positioned after the ! character but it's not visible. This makes editing text that was rendered as a ligature very difficult. Fira Code works as expected in all editors so it's not a problem with the editor

This occurs in all editors that support ligatures.

[ghost]

The reason this happens is because of how the ligatures are implemented in the font. Pragmata Pro uses the liga opentype feature which is the standard feature for ligatures (more here and here) used in pro fonts.

Fira Code used to use liga also but awhile ago they switched to calt (contextual alternates). See here. Technically this is a different feature and although many pro fonts do make some use of contextual alternates, it's not typically used for standard ligatures.

So this behavior is not a bug in Pragmata Pro or anything quite like that but a difference with how editors and terminals handle the two different features.

As you've noticed, it appears many programs currently provide a better editing experience with calt than with liga so the argument could be made that maybe Pragmata Pro should try to switch to using that too or at least provide calt support in addition to liga somehow.

I think Fabrizio may have mentioned something about considering it in one of the other issues on here but I'm not sure where.

[fabrizioschiavi]

Everything wrote by @freebroccolo is correct. What editor do you use @activa ?

[activa]

I use Visual Studio Code, Visual Studio 2015, IntelliJ, Android Studio and Xamarin Studio. All of them have the same issue with PragamatPro ligatures.

PragmataPro is a premium font specifically created for programming, yet it's close to unusable for that purpose while a free font like Fira Code works as expected. I'm very disappointed to have spent over $200 on a font that promised me great ligature support but doesn't deliver.

The way the ligatures in this font work now is completely unusable for me. I've gone back to the PragmataPro font without ligatures for now. Too bad I paid double just to get the ligatures.

The response I see here is pretty disappointing and I'm considering asking for (part of) my money back.

[talios]

On 19 Aug 2016, at 13:32, Philippe Leybaert wrote:

I use Visual Studio Code, Visual Studio 2015, IntelliJ, Android Studio and Xamarin Studio. All of them have the same issue with PragamatPro ligatures.

For IntelliJ at least, if you use the Jetbrains Runtime ( which back ports the Harfbuzz display engine from Java 9 ) then everything works perfectly.

And it also works better than just font ligatures.

Mark Derricutt http://www.theoryinpractice.net http://www.chaliceofblood.net http://plus.google.com/+MarkDerricutt http://twitter.com/talios http://facebook.com/mderricutt

[fabrizioschiavi]

I’m really sorry about your disappoint @activa I think it's time to change liga into calt OpenType feature to avoid all these (similar) issues with editors. The next release will works as Fira Code. Can you wait it?

[tiziano88]

Thanks @fabrizioschiavi , that's great news, I also ended up disabling ligatures because they don't play well in basically any editor, which is a shame. Looking forward to the new version using calt!

[activa]

That's great to hear Fabrizio. Sure I can wait for it. Do you have an ETA? 1 month? 6 months? ...

[fabrizioschiavi]

I hope to be able to release it in September

[activa]

September would be great! Looking forward to it.

[jordwalke]

@fabrizioschiavi - I'd be more than happy to be a beta tester for MacVim! Send me a PM on twitter if you are interested.

[jordwalke]

I'm curious if switching from liga to calt might improve some editor experiences, but degrade others. I'd be happy to make sure it's not the case for MacVim and Atom.

[ghost]

One thing I noticed recently about VSCode is that that when you try to cursor through ligatures, it will show the current individual character within the cursor block. It doesn't reposition the cursor until you reach the end, but at least that gives you a visual indication of some sort.

I don't know if this is something they implemented themselves or if it's a generic facility that can be enabled in Chrome. But in any case, it should be possible to do the same thing in Atom, so that would be at least 2 editors that would have a little bit better editing experience even with liga.

[fabrizioschiavi]

@jordwalke thanks for your offer! I’m very interested.

I just finish to convert liga to calt and all seems works fine Do you enjoy like me the new Terminal ligatures [INFO] [WARNING] [FATAL]?

[talios]

@fabrizioschiavi ZOMG I love those terminal logging ligatures. They look awesome.

[talios]

@fabrizioschiavi actually, do you only have INFO / WARNING / FATAL ( with [ ]'s? ). Standard java logging tools also have DEBUG and TRACE. Not sure if their []'d tho by default. Still, LOVE them.

[fabrizioschiavi]

Thank you @talios ! I'll add also DEBUG and TRACE. I don't know exactly how editors will embrace this new ligatures but I love them.

[talios]

I for one look forward to seeing them in my terminal for build status and logs :)

[jordwalke]

I wish there was a way to make ligatures render arbitrary text in that same [DEBUG] glyphs.

[jordwalke]

For example, see these screenshots from a Vim plugin deoplete.

Imagine how great this would look if the [o] was rendered in this glyph form.

Also, imagine the [unix] and file changed [+] text being rendered using those same glyphs, in vim-airline.

I think the main challenge is that it's unreasonable to have PragmataPro encode every possible word in the dictionary (and then some). Is there a way for ligatures to work "dynamically" based on the contents between the [ ]?

[fabrizioschiavi]

@jordwalke this can be amazing and I would like to do it but

• are you sure all programmers will enjoy this new "weird" feature?
• this can be enabled using OpenType Stylistic Set 13 ss13; are this feature supported by the must commons editors?

[talios]

Would it be possible to maybe release a set of fonts with AND without these new ligatures? Maybe as an initial "lets try this and get feedback", but if people don't like it they could just use the normal set?

"Great artists are extremely selfish and arrogant things" — Steven Wilson, Porcupine Tree

On Fri, Sep 2, 2016 at 10:52 PM, Fabrizio Schiavi notifications@github.com wrote:

@jordwalke https://github.com/jordwalke this can be amazing and I would like to do it but

• are you sure all programmers will enjoy this new "weird" feature?
• this can be enabled using OpenType Stylistic Set 13 ss13; are this feature supported by the must commons editors?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/fabrizioschiavi/pragmatapro/issues/36#issuecomment-244344860, or mute the thread https://github.com/notifications/unsubscribe-auth/AABKlRPuKR7zps5CvDCx9ufV6DL5HG5Dks5ql__qgaJpZM4JmCJf .

[jordwalke]

Is there a font that already uses ss13 features that I could test in common editors to see how they render?

I definitely think it could/should start out as an option to enable (maybe the font would also be distributed with a Bells and Whistles mode?).

[jordwalke]

It might also be worth coming up with a set of conventions for regular text, that anticipates people building ligature fonts on top of it. That way Vim plugins (such as the autocomplete) can intentionally target ligatures, without rendering some things as ligatures accidentally. For example, plugins can optionally render elements in a certain form to represent various dynamically created shapes. It could express things like square-rounded rectangles ([|text|]), or round-rounded rectangles. I imagine you could also come up with a convention for rendering "buttons". Here's a mock of what that might look like (IANAD I am not a designer):

The terminal could be quite beautiful.

[ghost]

this can be enabled using OpenType Stylistic Set 13 ss13; are this feature supported by the must commons editors?

@fabrizioschiavi most of the new editors based on browser tech should be able to support this since you can simply enable it in a custom CSS stylesheet with font-feature-settings. Atom will definitely work and VSCode as well, although VSCode might require some special setup.

[ghost]

@fabrizioschiavi to give an example that it's possible, here is a screenshot from an editor mode in Atom that uses some of the other existing Pragmata Pro stylistic sets for different parts of the text:

[fabrizioschiavi]

Oh wow! Thanks friends! The next week I'll finish this great new feature, with great pleasure

[fabrizioschiavi]

@talios sure. Only people interested in this feature, enabling ss13 will can see all this. Nothing invasive, always

[tphinney]

From a design perspective, in many cases contextual alternates do not and cannot perform the same functions as ligatures.

High-end apps such as Adobe InDesign have had little or problem displaying cursoring through ligatures for over a decade now. Current Word for Mac does it. I believe it does on Windows as well.

Now, yes, it's extra work for the app to do this. Maybe it's not worth it for some apps. But that doesn't make it a font bug that the app is lame in this regard.

[activa]

@tphinney With all due respect, but that's a stupid remark. PragmataPro is marketed as a programming font, yet there's not a single programming text editor available that supports the ligatures in PragmataPro properly. It may very well be that a proper word processing application supports liga just fine, it's largely irrelevant because the font wasn't intended for use in word processing or other "true" design applications.

I never said it was a bug in PragmataPro. I said it's a usability issue when the font is used in the way it was intended to be used (as a font for programming editors)

[jordwalke]

@activa: I can't speak to the technical points that @tphinney is making but:

@tphinney With all due respect, but that's a stupid remark.

😕

yet there's not a single programming text editor available that supports the ligatures in PragmataPro properly

I might not understand what "properly" means, but I've been enjoying Pragmata Pro in MacVim for a while now. Ligatures also work well in Hyperterm, and I've had moderate success in Atom (the upcoming PragmataPro version should make the Atom experience even better).

[fabrizioschiavi]

I just finished to programming calt At the left: PragmataPro Regular At the right: PragmataPro X Regular Which is better for you?

[activa]

The code on the right is unreadable IMO.

[tiziano88]

Yes, it's crazy like this! How about using some other less common unicode code points to determine beginning and end of those "inverse" blocks?

[fabrizioschiavi]

@activa probably you’ve right but I can’t stop looking at the right @tiziano88 what do you means exactly?

Meanwhile, take a look at the same code in IntelliJ, a bit buggy but interesting

[tiziano88]

@fabrizioschiavi I meant that maybe starting a new block for each ( [ or { is an overkill and would make the code unreadable. Maybe using a different character would allow editors and other tools to only show those highlights where actually needed, though obviously those tools will have to be changed to do so, which may not be very convenient. In the end, I'm starting to think that this functionality should not really be implemented at the font level, but the text viewer or editor should instead take care of it entirely?

[activa]

@tiziano88 I agree, this should be handled by the editor, not the font.

[tiziano88]

Which BTW is exactly what powerline and the likes do; they just use those arrow character from the font, and then use different background / foreground colours to highlight some sections of text.

[fabrizioschiavi]

@tiziano88 eg: pratically if I design a glyph more similar to { instead of <, readability will be improved. I'll do. I love Powerline concept. More Powerline-like poroject please 😄

[tiziano88]

for reference: https://github.com/powerline/powerline#vim-statusline

[fabrizioschiavi]

[talios]

Not sure I like this. It obscures the fact that you're using [] or {} or () - and is quite visually jarring when used EVERYWHERE. I think this might make a lot of lisp/clojure code a little..... hard to grok.

[jordwalke]

I think it's a cool proof of concept and it would be best when used sparingly, not for the actual syntax itself. For example, imagine building an autocomplete/snippet plugin for an IDE. You would temporarily want to render the placeholders of the autocomplete using rounded elements to indicate that they are placeholders etc.

See how xcode does this:

Here's another screenshot of Xcode placeholders during "snippet expansion". The rounded corners and different coloring tells you that you can "tab" through the placeholders:

It's those little touches that make it feel solid/polished.

Even though some of us think it looks ridiculous when applied everywhere, I think it has a ton of potential when applied sparingly and only during certain interactions or select GUI elements like how Xcode does it. That's why the characters that trigger this rendering probably shouldn't be such common ones such as () or [] - instead opting for seldom used unicode points that plugins (such as autocomplete/snippets) can intentionally use.

[ghost]

Not sure I like this. It obscures the fact that you're using [] or {} or () - and is quite visually jarring when used EVERYWHERE.

@fabrizioschiavi suggested he would use a stylistic set so it would only be used if you actually chose to enable that set as a font feature. This is just like the currently included Fraktur and script stylistic sets which are also not enabled by default:

With most of the editors capable of letting you enable a stylistic set, you should also be able control where it's used. In Atom, you can associate specific grammar scopes to use that set which is what I show in my screenshot earlier. So this would allow something closer to what @jordwalke is suggesting – for highlighting certain items or for autocomplete or something.

[IceMan81]

@freebroccolo Which code editors support stylistic sets? Intellij does not.

[IceMan81]

@fabrizioschiavi Are you planning on releasing a trial version that we could try out?

[fabrizioschiavi]

Dear all, I decided to suspend the develop of PragmataPro X (the courageous version) to avoid a lot of future issues with editors. Anyway I don’t have the intention of suspending the goal to improve the design of the coding text. The next PragmataPro version 0.824, in addition to those already existing, will includes the essential “ligatures” for Terminal: [INFO] [WARNING] [FATAL] [ERROR] [TRACE] [DEBUG] [WARN] [ERR] Thanks to all for your precious feedbacks!

[IceMan81]

@fabrizioschiavi Would you be able to publish a version with the calt enabled (instead of a stylistic set) so we could use it editors like Intellij?

[fabrizioschiavi]

@IceMan81 ligatures uses calt since 0.824 so they must works also in IntelliJ without problems. These are my IntelliJ settings in the case you need inspiration