I ported my Latin declensions chart from PlotDevice (which was Mac-only and thus not accessible to people without Macs) to HTML/CSS.
Some notes:
My goal with this was to make a chart that’s modifiable as easily as possible without building a full chart-generation app.
Because this HTML and CSS is intended for print and not at all for the responsive web, there are a few ways I did things that I probably wouldn’t have used on a web project.
I considered using on-page JavaScript to generate the table HTML, since right now there’s a lot of duplication, but I opted to stick with straight HTML to make it easier for non-technical people to modify.
The column widths are manually set so that things line up across tables. I could have done one big table instead, but the editing ergonomics would have been substantially worse.
Chrome still can’t print lines less than 1pt in width, so I used Firefox to export the PDF.
I wish custom properties worked in @page. I also plan to eventually refactor this so that more of the CSS is configurable via custom properties. (At this point it’s just column widths/gaps and colors.)
This 3.0 version of the chart changes the font from Museo Sans / Minion Pro to EB Garamond, so that the font is freely available. (EB Garamond also feels more appropriate to Latin than Museo Sans.)
A short followup to what I wrote last year about Press, my abandoned typesetting engine project: I’m now fully convinced that the web platform is where I want to do typesetting. It’s open, programmatic, and capable. Source files are plain text, easy to version control, and fairly future-proof. And even though it’s not WYSIWYG — at least not the way I’m using it — it’s much more comfortable for me as a working environment.
For non-book work (charts, some kinds of documents), I’ve found that browsers already support everything I need (like @page). That’s how I’ve done all my recent genealogy design work, and it’s how I’ll do any language charts I make going forward. And for things like books where browser support isn’t quite there yet, Paged.js works well (and will presumably be phased out once browser support gets better).
Not to mention how nice it is for both print and digital workflows (EPUB, web) to all use the same technologies. I also love that the web is cross-platform. Something I ran into when I was making charts with PlotDevice (which is Mac-only) was that people on Windows couldn’t modify the charts even when I gave them the source. That’s not a problem with the web.
I’ve even started using the web platform for less webby things like making wallpaper for my phone:
Here’s the HTML (the 375×812px size is the CSS resolution of my iPhone 12 Mini — RIP — and also keep in mind that this was for a one-off never to see the light of day, so I took the liberty of cutting a few corners):
<!DOCTYPE html>
<html>
<head>
<meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=no" />
<link rel="stylesheet" href="style.css" />
</head>
<body>
<div class="background">
<svg id="darknoise" viewBox="0 0 375 812" xmlns="http://www.w3.org/2000/svg">
<filter id="noiseFilter">
<feTurbulence baseFrequency="0.5" numOctaves="8" />
</filter>
<rect width="100%" height="100%" filter="url(#noiseFilter)" />
</svg>
<svg id="lightnoise" viewBox="0 0 375 812" xmlns="http://www.w3.org/2000/svg">
<filter id="noiseFilter2">
<feTurbulence seed="485" baseFrequency="0.005" numOctaves="12" />
</filter>
<rect width="100%" height="100%" filter="url(#noiseFilter2)" />
</svg>
</div>
<div class="quote">Come unto me, all ye that labour and are heavy laden, and I will give you rest.</div>
<div class="reference">Matthew 11:28</div>
</body>
</html>
It’s not the world’s most amazing wallpaper or anything, but I’m still pleased that I was able to make something I’m reasonably happy with using technologies I love. (I could have also used WebGL shaders or Canvas. Lots of options!)
Update on Press (the PDF compiler). I haven’t worked on it at all lately, but I wanted to document its current state for history’s sake, and as part of working in public. (I’ve also been sitting on this post for over a year.)
Back in 2017 I did end up re-architecting Press to use Low Ink as an intermediate page description language. In the process, Low Ink changed from a JSON-based idea to this:
It was intended to be a fairly low-level wrapper on the PDF format, with the idea being that other libraries/apps would provide more ergonomic abstractions on top of it.
I initially used Python because Press started out as a library, but with the pivot to a compiler model, I think Go or Rust would probably end up being a better choice (Rust would make integrating HarfBuzz a bit easier, at any rate).
Potential improvements
To my 2021 eyes, the language design isn’t particularly elegant. I like that the parameters are named (clarity), but for most of the commands there aren’t actually that many parameters, because many of the settings that would normally be parameters are separate commands. For parameters that are clearly unambiguous, the names hamper readability. For example, I think something like this might be better:
:line 0,0 to 1080,0
:fillcolor #345
I’ve also thought that push and pop could potentially be clearer as curly braces, and that the initial colons aren’t really necessary:
{
translate 0,1040
strokecolor #999
linewidth 0.25pt
line 0,0 to 1080,0
stroke
{
fillcolor #999
font 14pt helv
text 1085,-3 "ascender"
}
}
The future
My initial reason for building Press was to have an easy, programmable cross-platform way to create language chart PDFs (so I could move away from PlotDevice/DrawBot), and what I’ve realized (acknowledging that I haven’t really been making language charts in recent years) is that there are some other, better options now.
One that seems decent is SVG, converted to PDF by way of Inkscape. Initial tests here seem like it would probably work fine.
Another promising option that I admittedly haven’t looked into very much yet is Paged.js. HTML and CSS are already great for declarative typesetting, and the more I’ve thought about programmatic typesetting, the more this model seems to be the future I’d want to work with (and not just because of parity with web, though that makes it much more compelling).
tl;dr I don’t see myself continuing on with Press, so we may as well call a mortem on it.
Just posted some note paper PDFs which I made in PlotDevice. There’s lined paper — 30 lines/page up to 130 lines/page (for those who write really, really small) — and graph paper — 10×10 up to 140×140.
After a break of several months, I’m getting back to working on Press. Status is pretty much the same as last time I posted about it. (It’s actually even a little more behind than that, since I had HarfBuzz Python bindings working then, but now — after upgrading to macOS Sierra — I’m running into issues with PyGObject’s introspection module. I may end up having to write my own HarfBuzz bindings with CFFI. We’ll see.)
The high-level roadmap right now: get font embedding to work correctly, add support for embedding images (which should be fairly easy, I think), integrate ICU for language analysis and HarfBuzz for shaping, and add color space support.
As of now, I plan to use Press for making language charts (which I’ve been using PlotDevice for) and picture books. Once it’s to the point where I can do that, then I’ll start on Ink (low-level typesetting engine, intended for typesetting books, and higher-level rule-based engine for making it easier to work with).
As mentioned on Twitter, I’ve decided to write my own typesetting engine, called Ink. Apparently I’m crazy.
The details are still very much in the air, but here are some quick notes:
Written in Rust (for speed)
Programmatic (sort of like TeX)
Scripting language for extensibility (JavaScript or Lua or Python)
Intended for use in typesetting book interiors, covers, and charts
Possibly some kind of template/data division
Full OpenType feature support (shaping via HarfBuzz)
Custom PDF generation library (inkpdf)
Reasons for doing this insane thing:
PlotDevice only runs on OS X and I want the source of my language charts to be usable on other platforms.
I’d like to open source the books I typeset, so InDesign isn’t a great solution.
TeX is powerful and well-seasoned and all, but it’s not exactly pleasant or easy to work with, especially for the kind of stuff I do.
I’ll learn a lot and have fun while I’m at it.
The initial roadmap, not necessarily in order:
Write inkpdf in Python (which I think will be a better fit for the charts anyway)
Get familiar with HarfBuzz
Learn Rust
Port inkpdf to Rust
Plan out the Ink language (I’ve started on this and it’s looking promising)
Figure out how scripting is going to work and embed the interpreter
I’ll document the process on this blog, of course. First steps: reading the PDF spec and figuring out how to make PDFs by hand.
(For those who’ve been reading for a while, Ink was also the name of my static blog engine. That’s now ink-static, and at some point I’ll either retire it completely or change the name to something unrelated.)
