typho log: week #1

✍️ Written on 2022-01-08 in 1813 words.
Part of cs software-development digital-typesetting

Motivation

In 2011, I decided to improve the state of the art of digital typesetting. People struggle with the tools and everyone just seems to get along with half-baked solutions. Back then, I did my bachelor’s degree in CS and neither did I have the skills & knowledge to tackle the problem nor does the university curriculum really help. Anyhow, my education was not limited to university (what was that Mark Twain quote again? 😉) and the challenge is big, but not impossible.

From the beginning, I was skeptic about implementing it in C. One can get rid of memory safety issue and complex bugs, but maintainability is an issue. One needs to have a well-established, memorized mental model to maintain complex C code and I want to reduce the bus factor. Code must speak for itself. I dropped C. And many years later, I discarded my ideas to implement it in python (due to obvious performance/concurrency concerns), took a brief look at Go, but decided to proceed with rust instead in 2018. What I did over the years, was taking notes about usecases and architectural decisions for my digital typesetting project. The original document had about 2600 lines (as of 2021-12-31) where 90% of LOCs were lists where each bullet item is a reference to a project, tweet, or illustrates some idea. Of course, they don’t fit together and everything needs to be structured.

At the end of 2021, my academic endeavours in post-quantum cryptography came to an unfortunate stop and I decided to take a ~4 months timeout only focusing on this project. Now we are at week #1.

Goals and achievements

My goals for week 1 are not fully met, but this is a classic examples of changing requirements. Let me summarize the achievements of week #1:

  • I vastly restructured my notes. I started this in december, but now it is taking shape. I want to release the requirement analysis as soon as possible.

  • I reregistered the domain, I owned several years ago. And I am reinstantiating the typho github organization, I created 7 years ago.

  • I recognized the huge gap between mathematical notation and text (or as I would phrase it: “I recognized how much text typesetting has progressed whereas math typesetting is stuck”).

  • I also learned which gap exists between the Teχ community (more academic and formal) and digital typesetting in general (more pragmatic, care about performance and have web/GUI usecases in mind).

  • I checked that macros can be expanded before string formatting macros apply. As such the basic PO approach is always possible in rust code, but I wonder whether an approach like Fluent makes sense. I need more research.

  • I understood which technologies I need to take a look at (“where I lack expertise”) as started listing them. HarfBuzz and FontForge one example.

  • I systematically went through all crates from the “Text processing” category. Some nonsense, but I want pleasantly surprised overall. CLI tools like uniwhat, fnew, uwc, and rtss can be helpful for my work, but in particular a lot of libraries are provided for typesetting due to the Servo efforts.

  • I, once more, am deeply grateful for the work some awesome people did. I am standing on the shoulders of giants.

At the beginning of the week, I did not expect to be able to work 40h on the project. Why? Because I am still busy with academic duties from my previous job. I got some work done and got stuck with some work. However, as the week progressed and the most important stuff was done, my brain completely picked up the topic and structured its mental model.

Some fundamental resources on modern digital typesetting

One result of restructuring my notes, was rereading the most fundamental articles on modern digital typesetting. It mostly concerns font selection, text shaping, and font rendering as these are technically intricate challenges resulting from various usecases. typho is additionally concerned with markup languages and the frontend users use to write documents. But let me publish the list to get you started on this topic:

Hard decisions

I also want to give examples which kind of questions, I try to answer as part of my project:

  • Everyone capable of writing parsers is considering various domain-specific languages. This can be useful, but I want to take this to the next level. My keyboard layout can generate many Unicode scalars, but not everyone has easy access to scalars like α. So what is a feasible set of characters one can type? Additional question: What can be typed easily on mobile consumer devices?

  • LaTeχ distinguishes itself from other markup language approaches by computability (Turing-completeness in some sense). This (in general) allows Teχ to be used as what we call a template language today (e.g. Django templates). Can we take a markup language approach and properly introduce a “content generation step” which generates the content we care about? One counterexample: What happens if the markup language assigns numbers to an enumerated list and the content generation step prepends an item?

  • Mathematical typesetting is in a shitty state. Many standards like Teχ, MathML and OpenMath do not progress. There are companies like igalia which try to advance the status quo of MathML, but every effort depends on investment from other fields (e.g. preparing the OpenType fonts and encoding the semantics properly). In the end, we just don’t know how to encode representation and semantics of symbolic notation and neither do we have sufficient tools to push mathematical notation to output formats like HTML5 and PDF in an accessible way.

  • It would be neat as part of the FLOSS movement to move away from PDF. But what is a suitable alternative? What is the technical structure of these file formats like DjVu (its a pixmap, BTW)? Which tools need to be written to make it accessible? As a shift away from PDF is not feasible soon, typho will provide a first-tier PDF backend for many years.

Papers on Racket, notation, and documentation

By chance, I had a conversation with Lexis implementing a math typesetting engine. She pointed me to the Scribble paper. Her weblog is written using the Scribble framework. I found some resources related to the fundamental paper. I just want to dump it here:

These resources are tailored towards Racket’s design in general:

typho’s values

I also took some time to write down some values the typho project should carry. I am not sure about its exhaustiveness yet:

  1. Robustness principle: “be conservative in what you do, be liberal in what you accept from others”. The general outline is that I want to map all markup languages into a superset data model of all markup languages. Then the typho pipeline generates output for a feasible set of backend (PDF and HTML5/EPUB) as primary goals.

  2. FLOSS commitment: support closed standards (DOCX, PDF, kf8) if necessary, emphasize open standards (DjVu, ODS, OpenType & TrueType, OpenMath, MathML, DocBook, …). Tools to enable users to typeset documents must be licensed under FLOSS constraints.

  3. typho is meant to unify the community. No writing system must be isolated. No writing system is an optional feature. We want to provide tools for all locales.

  4. All official typho resources are published in English because it serves as pragmatic lingua franca.

  5. A modern CLI with helpful error messages (looking at you, LaTeχ). Properly distinguish between warnings and errors. No silent errors!

  6. We want to implement a standard, not conventions. As such if all other implementations do not follow the standard, but a convention, I will still follow the standard. If such a discrepancy occurs, it is part of typho’s work to engage with all parties involved to adjust implementation/standard in such a way that the community unifies again. Remark: this will require a huge effort in the OpenType space.

  7. Teχ uses an procedural approach towards typesetting (according to macro expansion rules, instructions are derived instrumenting the layout algorithm). We look towards a declarative approach as in markup language to instrument the layout algorithm on a token level. Compare this to the idea of C macros versus LISP/rust macros. This [maybe] improves the option to replace typho with an improved typesetting tool.

  8. typho’s job in typesetting stops where interactivity plays a role. We also do not anticipate animated fonts at any point in time.

  9. The target platforms are Mac OS, Linux, Windows and WASM. The WASM platform poses particular constraints I need to take a look at.

  10. typho should support reproducible builds. Thus we detect and warn the user if timestamps are used in the document. BTW, rust itself satisfies most reproducibility requirements.

The business model still bugs me, but sustainability is important.

Conclusion

typho is a huge effort, but my life dream.