![]() |
|
![]() |
| 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.. |
![]() |
| 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!! |
![]() |
| Kudos * 1000 ! ! !
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 [email protected]. - 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/ |
![]() |
| If you read to the end, the page footer has this nice message:
I love this. Thank you! |
![]() |
| This seems like something that could be automated with code? It feels like a genuinely useful way of solving highlighting for most common use cases. |
![]() |
| It's.. The Font with Built-In Syntax Highlighting.. ;) -
and has a playground with dark background; COLR, BTW:
( https://www.high-logic.com/font-editor/fontcreator/tutorials... ) |
![]() |
| 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. |
![]() |
| 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)?) |
![]() |
| Would LaTeX apply the 'calt' lookups? I don't think so.
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. |
![]() |
| Another issue you'd run into, I suspect, is that in practice text engines/editors/etc will often repaint only fragments of the content, and so the syntax highlighter would not necessarily see all the context it needs.
E.g. if you have a comment that starts with "/*" and ends several lines later with "*/", but the editor decides to just redraw a line in the middle, the highlighter won't "know" to use the comment color as the text-drawing operation won't include the delimiters. (This issue already exists in a small way, as mentioned in https://news.ycombinator.com/item?id=41251114, but it'd only get worse as the syntax highlighter becomes more sophisticated.) |
![]() |
| This is amazing and seems to just work, the only gotcha I see is that you'd need different versions of the font for different background colors |
![]() |
| I'm not the person you're replying to, but it looks like it's possible to carry around a finite state machine, hence get the power of regular expressions (with caveats). I made an example that should highlight quoted text: https://news.ycombinator.com/item?id=41254638
It doesn't check that there's a closing quote, but it should work for highlighting syntactically valid code (once you fix my mistakes). I don't see a way for a character to affect others arbitrarily far back unless some fancier features like ignoring certain classes can be abused. |
![]() |
| I really like the idea of the hack, but I couldn't bring myself to actually load the webpage - thinking of crazy font-code exfiltrating all of my emails that have ligatures. |
![]() |
| Readability isn't the problem, but people could get confused.
Especially because some keywords are usual words like in or with. But still great idea nevertheless. |
![]() |
| It certainly heavily limits the usability, but there’s plenty of use cases where there’s not much free text. Comment highlighting would still be an issue though |
![]() |
| Love how crazy this is. Small nit that shouldn't take away from the enjoyment - one downside not mentioned is that brackets aren't colour-coded based on depth, something I find very useful in my IDE. |
![]() |
| Really cool. Your demo would have been even better if you add contenteditable on there so the user can edit and see how it works:
|
![]() |
| Really awesome work, @california-og!
I would love to see separate fonts for HTML, CSS, and JS only, as I would want to use it for lightweight HTML highlighting in textareas in a CMS. |
![]() |
| BTW, I'm not sure why it says adding syntax highlighting to a |
![]() |
| very cool!
does anyone know the original target of this OpenType feature? Struggling to imagine where it would fit apart from code highlighting |
![]() |
| That this can even be done is absolutely atrocious.
I heard about security issues related to fonts and wondered “how in the world”. This helps clarify why. It simply should not be possible. |
![]() |
| - 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 ) ;)
- and then with hardware accelerated font rendering https://news.ycombinator.com/item?id=41251199 ?? ( ! ! ! ) |
![]() |
| Yes, and I still believe editing text is painful on a browser and this is just putting lipstick on a pig.
Keyboard shortcuts and auto-complete being important pain points. |
![]() |
| I’d make a font with a colored red squiggle over the apostrophe, because so many people misuse apostrophe’s. Cough. |
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...