Argonaut Projects' Blog

Building a text layout engine in Haskell

For about two months now, I have been building Balkón, a Haskell library for inline text layout to become part of the Argonaut Stack.

Text Rendering Corrections

Quick note today after having gone back & fixed Typograffiti to work for more text than my demo.

Analytics thoughts

NOTE This is a personal blogpost from Adrian Cochrane, the opinions expressed within are not necessarily endorsed by other contributors to the Argonaut project. And yes, I wrote this one quickly.

Project Services

In developing Haphaestus the sites which gives me the most trouble to support are the silos creatives feel expected to publish on. As such it is in my vested interest to question the value of these silos, leading me to self-hosting our own codeforge.

Writing Language Bindings

I may be striving for simplicity in my browserengine development, but I will not do so at the cost of inclusivity. As such I’ve spent the past couple months (alongside coordinating a growing project) developing pure-functional language bindings for the best available font libraries covering the widest breadth of written langauges. Namely FontConfig & Harfbuzz. Excellent bindings already existed for LibICU, and I wrapped FreeType in an OpenGL-accelerated renderer.

Haphaestus has NLnet Funding!

I am excited to announce: Haphaestus TV web browser has received NLnet funding!

Anonymous/Archived Retweet Regarding Web Complexity

Anonymously retweeting a Twitter thread, which despite its truth got harassed into deletion:

International Day Against DRM

As an upstart browserengine it is my privilege to promise on this International Day Against DRM 2022: Haphaestus will never support Encrypted Media Extensions or any other form of DRM.

Operator Parsing in Haskell

Plenty has happened since I last blogged here, including banging my head against Haskell’s text rendering libraries (hoped to be blogging about that…) & rejigging my plans for Rhapsode & similar browser engines. Now I’m actively taking steps towards turning Rhapsode into a decent browser you can install as an app from your package repositories, as opposed to a browser engine waiting for others to build upon. As part of that I’m commisioning art to have something to display onscreen!

Introducing Amphiarao!

I’ve now implemented the core featureset of (save for a HURL crash which badly needs addressing) a Rhapsode bug-compatible webpage debugger, compatible with Selenium & whatever your favourite web browser is. Even Rhapsode, once I’ve implemented forms for it (coming soon)! All the features Selenium expects are implemented, though where they’re not supported by Rhapsode I wrote noops.

Voice Input Supported in Rhapsode 5!

Not only can Rhapsode read pages aloud to you via eSpeak NG and it’s own CSS engine, but now you can speak aloud to it via Voice2JSON! All without trusting or relying upon any internet services, except ofcourse for bogstandard webservers to download your requested information from. Thereby completing my vision for Rhapsode’s reading experience!

Why (Mostly-)Standard HTTP/HTML/optional CSS?

Modern web browsers are massively complex beasts, implementing an evergrowing mountain of supposedly-open standards few can keep up with. So why do I think I can do better whilst adhering to the same standards? Why do I think that’s valuable?

How Does CSS Work?

Rendering a webpage in Rhapsode takes little more than applying a useragent stylesheet to decide how the page’s semantics should be communicated. In addition to any installed userstyles and optionally author styles.

Why an Auditory Browser?

I thought I might start a blog to discuss how and why Rhapsode works the way it does. And what better place to start than “why is Rhapsode an auditory web browser?”