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 ?
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.
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 have been considering using php like that. It would solve most of my issues. The problem is that I would still like to use static hosts, like netlify or GitHub pages, and they don't support php...In addition I would have to run php on my local machine, where as I would prefer to just edit html with no setup necessary. But if anyone knows a good free host with php support, let me know!
If you are willing to use netlify and are willing to use PHP, what is the inhibition to use a static site generator like Hugo? It is supported by netlify and others. I believe GitHub pages also supports a bunch of static site generators.
I am using 11ty for the blog, and it works great, for now. But there's two reasons I don't like it:
1. I need to have two different versions of my site, dev and prod, which I find very restricting and fragile.
2. I don't like to rely on other people updating their npm packages just so I could publish static content. I've been burned too many times by abandoned npm packages or breaking changes.
Your solution is quite nice and probably as simple as site generators get, but I was thinking of using php just for some simple includes etc. Here's my inspiration post which explains what I'm after, and why generators in general are not the solution (for me): http://ankarstrom.se/~john/articles/html2/
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?
> 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
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.
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.
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 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.
I imagine you'd want to have something that works like a parser generator up front to create the rules. What's not clear to me however is how expressive the rules are.
Yeah. Doing it all manually would take ages and be quite error prone. I did generate all the lookup rules with a script, just didn't think it important enough to mention in the blog post.
And about the lookup rules: they are extremely simple. You can search for a single character at a time, or search from a group ("class") of characters. AFAIK, that's it. But if anyone knows better, I would be happy to be proven wrong.
As an experiment, it is awesome. We should strive to push the limits of technology and try new things. Kudos. I tip my hat to the creativity.
As something practical, the author started with the wrong tool for the job (JavaScript), and then used an even more wrong tool for the same job (The font itself!)
Just use a code editor with Syntax Highlighting! Vim solved this decades ago!
Very interesting read, but don't try this at home.
Edit: Pandora's box is opened, I can see Jira and GitHub rushing to add support for this on their websites starting tomorrow =)
- but the opposite: this one have such potential that you could possibly just use the font with language-specific syntax embeded and forget any other syntax highlighting (to some limits) on web (JS), console (in.. VIM) or wherever - as obsolete (in any program that did not have any syntax highlighting before - just use that font for that language and solved ) ;)
> Just use a code editor with Syntax Highlighting! Vim solved this decades ago!
You are aware that this blog post is about displaying syntax highlighted code on the web? This is literally explained in the first paragraphs of the blog post..
As of now there were four ways of doing that:
1. using an image (which sucks)
2. manually setting the colors (good luck)
3. Generating the syntax highlighting server-side (preferred, but you need a backend that can do it)
4. Generating it client side using JS (waste of energy, takes a time to finish)
And now a font. Depending on the use case this could be a feasible option, although I am just waiting for this to be exploited in some fashion.
I still think computing once styling later is preferable.
This is for publishing web pages talking about code.
The author would like to hand code HTML for such web pages that would present syntax highlighted code to the web page reader, without requiring or resorting to typical js highlighting or screenshots.
None of editing in the terminal, nor an IDE, nor a browser are related to this use case.
However, the highlighting examples do not work with JS disabled (I think because JS is used to load the fonts) so what is the advantage of not using JS for highlighting over calling a JS highlighter on <code> tags?
Maybe this could also be implemented using variable fonts[0]. This would probably make it easier to configure in non-browser environments (once this is better supported by font selectors etc).
There seems to be a bug in Chromium-based browsers where, if you type e.g. `color: blue` in the textarea, it only highlights the r before the colon, rather than the whole property name. If you copy+paste the text instead, it works properly. (Still, that doesn't detract from this being really cool, of course!)
at the end of the example, some of the letters of "div" would be green and some would be white.[1] Adding a class or something changed which letters were green and which white.
This is actually really cool. I can see the usages in textarea and inputs but also even in plain HTML documents for large code formatting. No need for exploding the DOM with tons of spans and other HTML tags, if you can have the hardware accelerated font rendering software take care of everything. I’d imagine that would save lots of memory and CPU.
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.)
In Firefox, 4000 lines of CSS: editing last lines is fast and instant, editing first lines is a bit jumpy refreshing every few edits in 0.2s-1.2s - however undo/redo is quite fast - but not so fast as with last lines, and.. from the first impression, guesses:
-= the highlight is always there, instantly =- (or.. it doesn't a look like a reason for jumpy lines because of redo) - definintly less cycles and memory overhead and I don't see that possible with DOM and JS - the delays could be there only because of inefficient editing operations with no impact of coloring.. and maybe with.. smaller textfragments (or ?) there could be no such delays at all - but simple* coloring coud be always so instant (and easy) ? (yes, I know, so far it may be also limiting and exclusive)
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.)
Interestingly it also seems to work fine on 16.5. Browserstack doesn't have 17.1, perhaps it was broken temporarily? Unless there's some other difference with the version of Browserstack somehow..
Would this work if the font was used in a PDF typeset using LaTeX? (EDIT: when running on top of a TeX engine which can access OpenType, or some other tool (such as InDesign)?)
The design of this blog post is lovely! Despite seemingly having no right to be. It goes against all of my design instincts, but it somehow nails a vibe while remaining pleasant and easy on the eyes. I love it!
I was thinking the same thing. The style reminds me of 90’s computer/game magazines or something… So it looks sort of professional (sans the first letter in the headings) but also whimsy at the same time. Love it.
Great hack. Note that it's approx the same size as baseline highlight.js at ~45kB. However it has the great benefit of functioning in contexts where javascript is disabled, at the cost of runtime configurability and narrower language support.
This is incredibly awesome. Looking forward to seeing this but with a nicer typeface (maybe Inconsolata or JetBrains Mono). I can actually see a lot of uses for this-- just displaying JSON in a nice way easily would be handy.
I wonder if the author has experience with Excel, because some of those substitution "monstrosities" look similar to some monstrosities I've created with Excel formulas! Good work, this is an awesome hack.
150 comments
[ 3.7 ms ] story [ 202 ms ] threadImpossible 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 ?
And.. Introduction to OpenType Programming https://simoncozens.github.io/fonts-and-layout/features.html - about lookups.
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/
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.
1. I need to have two different versions of my site, dev and prod, which I find very restricting and fragile.
2. I don't like to rely on other people updating their npm packages just so I could publish static content. I've been burned too many times by abandoned npm packages or breaking changes.
So you can edit your HTML push and have a simple script to clean it before publishing it.
You can copy my blog is very simple and is generated with PHP
https://github.com/4lb0/blog
Perhaps especially if the sibling comment about embedding a state machine pans out?
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
(E.g. see https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_...)
This is one of the cooler things I've seen in a while!
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
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.
:)
As something practical, the author started with the wrong tool for the job (JavaScript), and then used an even more wrong tool for the same job (The font itself!)
Just use a code editor with Syntax Highlighting! Vim solved this decades ago!
Very interesting read, but don't try this at home.
Edit: Pandora's box is opened, I can see Jira and GitHub rushing to add support for this on their websites starting tomorrow =)
- and then with hardware accelerated font rendering https://news.ycombinator.com/item?id=41251199 ??
( ! ! ! )
I read such code every day in github and similar tools.
You are aware that this blog post is about displaying syntax highlighted code on the web? This is literally explained in the first paragraphs of the blog post..
As of now there were four ways of doing that:
1. using an image (which sucks)
2. manually setting the colors (good luck)
3. Generating the syntax highlighting server-side (preferred, but you need a backend that can do it)
4. Generating it client side using JS (waste of energy, takes a time to finish)
And now a font. Depending on the use case this could be a feasible option, although I am just waiting for this to be exploited in some fashion.
I still think computing once styling later is preferable.
Keyboard shortcuts and auto-complete being important pain points.
The author would like to hand code HTML for such web pages that would present syntax highlighted code to the web page reader, without requiring or resorting to typical js highlighting or screenshots.
None of editing in the terminal, nor an IDE, nor a browser are related to this use case.
https://frontendmasters.com/blog/syntax-highlighting-with-no...
Can be used when syntax highlighting is not available.
[0]: https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_fonts/V...
1. https://imgur.com/a/Ib2R9gh
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.)
-= the highlight is always there, instantly =- (or.. it doesn't a look like a reason for jumpy lines because of redo) - definintly less cycles and memory overhead and I don't see that possible with DOM and JS - the delays could be there only because of inefficient editing operations with no impact of coloring.. and maybe with.. smaller textfragments (or ?) there could be no such delays at all - but simple* coloring coud be always so instant (and easy) ? (yes, I know, so far it may be also limiting and exclusive)
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...
XeLaTeX or LuaLaTeX should be able to do that, though I'm not sure offhand whether they successfully embed color fonts into the output PDF.
I heard about security issues related to fonts and wondered “how in the world”. This helps clarify why.
It simply should not be possible.
Ironically, it is Microsoft which developed CPAL/COLR (at least intially), and this is the least atrocious format across colored suggestions. The other options are SVG-in-OpenType (Adobe/Mozilla; https://helpx.adobe.com/fonts/using/ot-svg-color-fonts.html), PNG-in-OpenType/SBIX (Apple; https://developer.apple.com/fonts/TrueType-Reference-Manual/...), and CustomBitmap-in-OpenType/CBDT (Google; https://fonts.google.com/noto/use).
All of them are now OpenType standards, for better or worse.