[HN Gopher] Font with Built-In Syntax Highlighting
___________________________________________________________________
Font with Built-In Syntax Highlighting
Author : microflash
Score : 97 points
Date : 2024-08-14 12:12 UTC (10 hours ago)
(HTM) web link (blog.glyphdrawing.club)
(TXT) w3m dump (blog.glyphdrawing.club)
| thro1 wrote:
| 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
| 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_ ?
| thro1 wrote:
| Found some discussion about it:
| https://typo.social/@gdc/112959308500800771 .
|
| And.. _Introduction to OpenType Programming_
| https://simoncozens.github.io/fonts-and-layout/features.html -
| about lookups.
| microflash wrote:
| 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.
| california-og wrote:
| 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/
| luminarious wrote:
| 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.
| thriftwy wrote:
| 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.
| ComputerGuru wrote:
| You can load a font that way on the web, I believe.
| steve_adams_86 wrote:
| 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!
| california-og wrote:
| 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.
| ashton314 wrote:
| 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!!
| nine_k wrote:
| 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.
|
| [1]: https://codepen.io/glukcodepen/pen/xQORev
| dotancohen wrote:
| If you read to the end, the page footer has this nice message:
| > This site doesn't use cookies or link to any third party site.
|
| I love this. Thank you!
| ComputerGuru wrote:
| What's wrong with linking to third party sites? That's against
| the original ethos of the web!
| phil-martin wrote:
| 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.
| california-og wrote:
| Ah, I think I meant to write that the site doesn't load
| anything from third parties, but apparently had a slight
| brain fart.
| PaulHoule wrote:
| 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.
| california-og wrote:
| 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.
| california-og wrote:
| 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.
| Shorel wrote:
| 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 =)
| ayhanfuat wrote:
| How does a code editor solve syntax highlighting on the web?
| thro1 wrote:
| - 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 ;)
|
| (!)
| atoav wrote:
| > 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.
| 29athrowaway wrote:
| Cannot be themed or customized without regenerating the font.
|
| Can be used when syntax highlighting is not available.
| california-og wrote:
| I was informed that the color palette _can_ be changed with
| `override-colors` css rule, but havent had time to update the
| blog post yet.
| Timon3 wrote:
| 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).
|
| [0]: https://developer.mozilla.org/en-
| US/docs/Web/CSS/CSS_fonts/V...
| russfink wrote:
| I'd make a font with a colored red squiggle over the apostrophe,
| because so many people misuse apostrophe's. Cough.
| twiss wrote:
| 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!)
| extheat wrote:
| 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.
| kevingadd wrote:
| 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.
| california-og wrote:
| 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.
| steeeeeve wrote:
| This is the coolest thing I've seen in a very long time.
| jfk13 wrote:
| What a fun hack!
|
| 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.)
|
| [1] https://learn.microsoft.com/en-
| gb/typography/opentype/spec/f...
___________________________________________________________________
(page generated 2024-08-14 23:00 UTC)