Built-in syntax highlight

[subframe7536]

https://blog.glyphdrawing.club/font-with-built-in-syntax-highlighting/

Principle

Write a large amount of ligature rules to match keywords and some simple patterns.

Some Thoughts

COLR and CALT tables are used to match and replace colored characters.

It is well performed on html and css, but due to the limitation of ligature, it seems impossible to render complex syntax using regular expression.

Also, COLR table support is poor, especially in desktop application. So maybe the only usage scenario is web?

[matthew-e-brown]

I am rather skeptical... this feels out-of-scope for a font.

As both you and the article mention, it can only support the most basic of syntax, so anything complex will be full of false-positives that will have to be tweaked meticulously: in most scenarios, an external highlighting tool will have to be brought in anyways. That means that the font file will end up bloated with lots of complex ligatures only to serve a very small use-case. Even if this feature is moved to a separate font file, it will make maintaining the font more complicated! 😧

I feel like it would be more worthwhile to spend the effort on perfecting a single, versatile font that works well with dedicated highlighting methods, new or existing.

Although, this is just my gut reaction. I am happy to be convined otherwise. 🙂

[subframe7536]

Yeah, the main pain point is limitation of ligature rules.

For maintenance, I think it is possible to write a build script to generate target ligatures and compile it into the font, or even compile on demand while requested.

[matthew-e-brown]

For maintenance, I think it is possible to write a build script to generate target ligatures and compile it into the font[.]

That is true, but then those scripts will need to be maintained and tested as well. The overhead can definitely be reduced with a script, but there is added complexity no matter what.

A bug report for a rendering issue would now require investigating (a) which glyphs have a problem, (b) the version of the underlying font they're using, (c) which language they're highlighting, and (d) the version of the script that was used to generate the file they're using. Sounds painful! 😮

or even compile on demand while requested.

One of the article's original points is that they "don't want any external scripts to inject things I didn't write myself," which I 100% see the appeal of. But, if I'm going to need an external tool to custom build a fancy font-file, why is thay any better than doing build-time syntax highlighting? If I'm introducing a build step anyways, I would personally prefer to simply use another, tried-and-true method that's guaranteed to highlight correctly. Then my font file can remain a static, cachable asset.

I feel as though I am being a bit of a downer here, but I suppose it can sometimes be helpful for someone to play Devil's Advocate. 😅

---

The main pain point is limitation of ligature rules.

You have much more experience than I do when it comes to OpenType/TrueType formats; I'm curious as to what your thoughts are for making this more viable. If you opened this discussion, I imagine you see some decent potential in the original author's idea. Do you have any potential workarounds in-mind for enabling more complex matching?

[subframe7536]

That is true, but then those scripts will need to be maintained and tested as well. The overhead can definitely be reduced with a script, but there is added complexity no matter what.

A bug report for a rendering issue would now require investigating (a) which glyphs have a problem, (b) the version of the underlying font they're using, (c) which language they're highlighting, and (d) the version of the script that was used to generate the file they're using. Sounds painful! 😮

That's why I just say "possible"😅 I'm not expert in font development, but I think there exists huge complex work underlying...

One of the article's original points is that they "don't want any external scripts to inject things I didn't write myself," which I 100% see the appeal of. But, if I'm going to need an external tool to custom build a fancy font-file, why is thay any better than doing build-time syntax highlighting? If I'm introducing a build step anyways, I would personally prefer to simply use another, tried-and-true method that's guaranteed to highlight correctly. Then my font file can remain a static, cachable asset.

I feel as though I am being a bit of a downer here, but I suppose it can sometimes be helpful for someone to play Devil's Advocate. 😅

I think it can benifit from native rendering of dynamic text, e.g. in web editor or iteractive article. Basically there is two way to implement in my mind:

1. generate the subset font in server, cache and merge hydrionly
2. dynamic generate language styleset in client, loading configuration from server

But neither one seems worth it to replace the current solution, since they are complex and not very valuable.

You have much more experience than I do when it comes to OpenType/TrueType formats; I'm curious as to what your thoughts are for making this more viable. If you opened this discussion, I imagine you see some decent potential in the original author's idea. Do you have any potential workarounds in-mind for enabling more complex matching?

I only learn about OpenType from official specs and docs. So I don't have any further understanding of it right now, maybe it has reached its limitation😂

[gaojin335]

Really like this font. Hopefully a non-hyphenated version will be released. 😹

[subframe7536]

The ligature won't show if you turn off your ligature setting