One small note: the post seems slightly confused about the use of OpenType features, as it calls for:
font-feature-settings: "colr", "calt";
but there's no 'colr' feature tag in the font's OpenType layout tables, so that's meaningless here.
I suppose this was intended to "activate" the color glyph table (COLR) in the font; but that isn't an OpenType layout feature that would be controlled by font-feature-settings, and doesn't need to be "turned on" like this.
(In addition, the 'calt' feature is (according to the spec[1]) supposed to be active by default, so it shouldn't be necessary to explicitly set it either. And indeed, the font works for me in both Firefox and Chrome without this rule; sadly Safari doesn't seem to handle it.)
This is a horrible, horrible hack and it's terrifying and I am aghast at how amazing this is. Such a wonderful abuse of OpenType contextual alternatives. Well done and thank you for sharing!!
What makes it a horrible hack, as opposed to proper use of documented capabilities at a scale slightly larger than usual?
Putting animated SVG in a font [1] is a horrible hack; this one is benign.
A somehow larger stretch would be a font with a built-in spell checker, with a wavy underline under every letter that only disappears under correctly spelled words.
"Putting animated SVG in a font [1] is a horrible hack"
Agreed, that is even more horrible. And probably just for performance reason alone should never ever get close to a real world product. Still, quite neat.
I think the author has underestimated the power of the substitution rules - it looks like it should be possible to drag a state machine along, hence recognise any regular language.
Something like the following should handle quoted strings (untested and needs every character to be listed out in the definitions of @Char, @CharQuoted and @NonQuoteQuoted):
sub Quote @Char' by @CharQuoted;
sub Backslash.quoted Backslash' by Backslash.quoted2;
sub Backslash.quoted Quote' by Quote.escaped;
sub [@NonQuoteQuoted Quote.escaped Backslash.quoted2] @Char' by @CharQuoted;
I don't know if context can be carried between different lines.
Here's a tested version that, given text containing only lower case letters, backslash and double quote, capitalizes the letters between quotes and handles escaping reasonably. (works with NotoSans-Regular.ttf)
@Char = [a-z quotedbl backslash];
@CharQuoted = [A-Z quotesingle slash];
@NonQuoteQuoted = [A-Z slash];
@Escaped = [asterisk dollar];
feature liga {
lookup xa {
sub quotedbl @Char' by @CharQuoted;
sub slash backslash' by dollar;
sub slash quotedbl' by asterisk;
sub [@NonQuoteQuoted asterisk dollar] @Char' by @CharQuoted;
} xa;
} liga;
feature liga {
lookup xb {
sub quotesingle' by quotedbl;
sub slash' by backslash;
sub dollar' by backslash;
sub asterisk' by quotedbl;
} xb;
} liga;
Impossible before. It can't be less invasive: _original text stays intact_ - no wrapping tags.. no JS.. just works with userContent.css.. - simply another dimension.
> I'm also not an OpenType expert, so I'm sure the substitution logics could be improved upon. I'm open to sharing the modified source file to anyone interested. If you have any ideas, suggestions or feedback, let me know. You can reach me at hlotvonen@gmail.com.
- so, how far can it be improved then ?!
- what other font editors moreover to Glyph (mac only) have good support for advanced contextual alternates ?
Thank you! (I'm the author)
I'm also very curious to know if there's some nifty way of improving the lookup logic. What I did was kind of a brute force method, but on the other hand, the CALT "language" is very limited.
For font editors, Glyphs is the industry standard, and, as far as I know, there are not many good alternatives. There's FontForge, but its contextual alternate editing seems even more confusing: https://fontforge.org/docs/ui/dialogs/contextchain.html
Just today I found out about a new browser based font editor, fontra, but it looks like editing OpenType features is still on its roadmap. Maybe something to keep an eye on though. https://fontra.xyz/
I wonder, if looking at the actual diffs of the before/after font it wouldn't be possible to write a compiler of sorts, taking a grammar, a font and a color scheme - outputting a custom font with highlighting for the grammar?
Perhaps especially if the sibling comment about embedding a state machine pans out?
Fascinating. TIL about `override-colors` in CSS. Now if we can automate the generation of color alternates and run it through a bunch of TextMate grammars to generate a font, this could be even more awesome.
> what other font editors moreover to Glyph (mac only) have good support for advanced contextual alternates ?
any font editor that supports writing opentype feature code manually. glyphs for mac won’t really help you here: while glyphs will do its best to autogenerate as much opentype for you as it can, it doesn’t do much (anything?) for calt features
Really a minor nitpick, but "It's as fast as plain text, because it is plain text" is definitely not true. Evaluating all these rules when shaping the text is not gonna be cheap, and if you overuse this type of font your end users' CPUs will probably be screaming. As would anyone who's implemented parts of the OpenType spec from scratch before. Worse still, this doesn't just impact rendering, since the output of shaping determines how big elements in the document are, so things like scrolling and window resizing and text selection can all lag.
Really fun to see a font that can do this though. Never would've expected it.
You are probably right, but I would like to see some actual benchmarks and tests. Unfortunately I didn't have time to do them myself yet, but I am curious what the difference between this, a basic font, and a highlighter script would be for a very large document.
It's definitely going to be significantly slower as a result of all the contextual lookups.
To get an idea, I repeatedly duplicated the CSS in the "tiny sandbox" until there were nearly 20,000 lines there, and then profiled the operation of changing the font-size by 1px in Firefox. Reflowing the textbox took about 1.6 seconds.
With `font-feature-settings: "calt" off` applied, so that the contextual lookups aren't being run, a font-size change for that same textbox content reflows in about 100 milliseconds.
(I don't have actual timings for the same example in Chrome, but subjectively, with "calt" disabled, the resize is near-instant, whereas with it enabled, it's quite laggy, similar to Firefox.)
I find it amusing that the motivation for creating a complex font program that supports syntax highlighting internally is the desire to avoid a complex syntax highlighter JavaScript library. The complexity is still there; it's just been moved around.
Edit: Perhaps this is a reminder that custom fonts are a potential attack vector for security-sensitive websites since font rendering runs highly-complex programs, probably in a language that isn't memory safe.
This makes me curious; have there ever been security exploits that utilized the font rendering as an actual attack vector? To me it feels like font rendering should be pure (in the functional sense) and thus have no side-effects, but of course that doesn't mean anything in practice.
I think it is more that it doesn’t load any resources automatically from external sites, a common way to share visitor information with third parties without JavaScript. For me it’s a sensible way to earn trust .
There are many third party links that you can click on, which does align with the original ethos of the web.
It does, right? I imagine you would be map syntax highlighting rules and colour themes over to this convention in order to generate a new set of glyphs. I'm sure it isn't trivial but it could likely remove or at least alleviate one of the cons listed in the article.
This is one of the cooler things I've seen in a while!
Definitely! For example, Glyphs has a decent python scripting API which could be used to automate the whole process. I used it for automatically assigning each layer the correct color attribute to save me some clicks. And I also generated all the calt lookup rules from a list of keywords.
I wonder if you can load a font from base64 string like you can with images. Then, one may write a pure js library which generates such font from a set of rules on the fly. Catered to a specific use case.
One small note: the post seems slightly confused about the use of OpenType features, as it calls for:
but there's no 'colr' feature tag in the font's OpenType layout tables, so that's meaningless here.I suppose this was intended to "activate" the color glyph table (COLR) in the font; but that isn't an OpenType layout feature that would be controlled by font-feature-settings, and doesn't need to be "turned on" like this.
(In addition, the 'calt' feature is (according to the spec[1]) supposed to be active by default, so it shouldn't be necessary to explicitly set it either. And indeed, the font works for me in both Firefox and Chrome without this rule; sadly Safari doesn't seem to handle it.)
[1] https://learn.microsoft.com/en-gb/typography/opentype/spec/f...
Deleted Comment
Putting animated SVG in a font [1] is a horrible hack; this one is benign.
A somehow larger stretch would be a font with a built-in spell checker, with a wavy underline under every letter that only disappears under correctly spelled words.
[1]: https://codepen.io/glukcodepen/pen/xQORev
Agreed, that is even more horrible. And probably just for performance reason alone should never ever get close to a real world product. Still, quite neat.
https://news.ycombinator.com/item?id=40766791
Impossible before. It can't be less invasive: _original text stays intact_ - no wrapping tags.. no JS.. just works with userContent.css.. - simply another dimension.
> I'm also not an OpenType expert, so I'm sure the substitution logics could be improved upon. I'm open to sharing the modified source file to anyone interested. If you have any ideas, suggestions or feedback, let me know. You can reach me at hlotvonen@gmail.com.
- so, how far can it be improved then ?!
- what other font editors moreover to Glyph (mac only) have good support for advanced contextual alternates ?
For font editors, Glyphs is the industry standard, and, as far as I know, there are not many good alternatives. There's FontForge, but its contextual alternate editing seems even more confusing: https://fontforge.org/docs/ui/dialogs/contextchain.html
Just today I found out about a new browser based font editor, fontra, but it looks like editing OpenType features is still on its roadmap. Maybe something to keep an eye on though. https://fontra.xyz/
Perhaps especially if the sibling comment about embedding a state machine pans out?
You asked what it takes to make a blog.
I have a html front page, tag pages and posts. All static.
There is a pretty short php page that takes an existing post or the dummy, chops off everything in front and behind the text.
The tag cloud sits under it. Clicking a tag injects it under the text.
When saved the top and bottom html are reatached and the title <h2> is copied into the <title> tag.
It then creates or overwrites the static html document.
It finds tags in the html and inserts a link to the new article into the tag and index pages.
Load, split, join and save is actually less complicated than sql and faster:)
Deleting tags and blogpostings is done manually.
Besides editpost.php there is a bookmarklet to inject quotes with links and youtube embeds.
And.. Introduction to OpenType Programming https://simoncozens.github.io/fonts-and-layout/features.html - about lookups.
any font editor that supports writing opentype feature code manually. glyphs for mac won’t really help you here: while glyphs will do its best to autogenerate as much opentype for you as it can, it doesn’t do much (anything?) for calt features
Deleted Comment
Really fun to see a font that can do this though. Never would've expected it.
To get an idea, I repeatedly duplicated the CSS in the "tiny sandbox" until there were nearly 20,000 lines there, and then profiled the operation of changing the font-size by 1px in Firefox. Reflowing the textbox took about 1.6 seconds.
With `font-feature-settings: "calt" off` applied, so that the contextual lookups aren't being run, a font-size change for that same textbox content reflows in about 100 milliseconds.
(I don't have actual timings for the same example in Chrome, but subjectively, with "calt" disabled, the resize is near-instant, whereas with it enabled, it's quite laggy, similar to Firefox.)
Edit: Perhaps this is a reminder that custom fonts are a potential attack vector for security-sensitive websites since font rendering runs highly-complex programs, probably in a language that isn't memory safe.
As you have guessed, this used a rendering feature that was not pure.
There are many third party links that you can click on, which does align with the original ethos of the web.
> This site doesn't use cookies or <link> to any third party site.
:)
This is one of the cooler things I've seen in a while!