New artwork: I Am a Child of God V. A reference to the Primary song. The rectangles represent (bottom to top), a child, its mortal parents, and our Heavenly Parents. (Figured it was time to do a more abstract version of this idea. It ended up also alluding to Hearts of the Children IV and Hearts of the Children V.)
My process for this style, for what it’s worth: mock up the design in Figma, export an SVG, open it in Inkscape, use the roughen and simplify filters, export a PNG, open it in Procreate, select the rectangles, paint the streaks within the rectangles, export a PNG, texture in Affinity Photo as usual.
New artwork: Strait Is the Gate. A new take on Narrow Is the Way. Also, Inkscape’s roughen and simplify filters are nicer to work with than SVG filters (which often have some weird rendering issues in the bottom right of shapes, at least when using Inkscape to render them).
Some dinky pixel art experiments, exploring what it looks like when you add texture and make them look kind of like mosaic tiles. (I’m sure someone else has already done this, but I haven’t, so here we are.) Also, this isn’t great pixel art, just to be clear.
For this first experiment, I made the squares in Figma and set the colors there, which was pretty laborious. Exported to SVG and added turbulence/displacement filters to get some variation. When exporting to PNG via Inkscape, I ran into the perennial issue where the filters sometimes only work on the top and left sides of the shape. (Someday I’ll figure out what’s going on there, since the filters look fine in Finder via Quick Look. In this case, from a distance, it still kind of looks okay.) Finally, I added some textures in Affinity Photo with opacity set to around 20% and blend mode set to soft light or overlay.
Second experiment: making things easier. I made a 48x48 image in Procreate Pocket on my phone and painted the scene using the oil paint brush. (Which is why the eyes are crazy and there isn’t a ton of definition on the characters. Like I said, not great pixel art.) I then wrote a quick command-line script (JS/Node) to take a PNG and export an SVG where each pixel of the PNG is a <rect> in SVG. Way faster than making the squares in Figma. The script shrinks each square a little and adds some jitter to the points as well. And I changed the background color to be more ground-like. Exported to PNG and textured as in the first experiment.
Some ideas for future exploration:
More subdivision on the tiles, for a little more geometric variety
Programmatically export masks from the SVG so that each tile can look more different from its neighbors, texturally (a masked tile would be next to an unmasked one, basically, with some randomness thrown in)
Rounding the edges of the tiles a little
Rendering the tiles in Blender (either with heightfields or by generating actual geometry with Python), ideally with some procedural texturing
I’m experimenting with a slightly new style here, masking the notes (after adding noise to the outlines with SVG filters and then eroding/dilating with Imagemagick) and painting inside the mask in Procreate. (And then texturing it in Affinity Photo as usual.)
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!)
Lately I’ve been playing around with making meaningless decorative pieces in Blender, using displacement maps with (for the most part) procedural heightfields. For these I’ve generally textured the heightfield in Affinity Photo and sometimes also textured a separate color map. Looking forward to doing more work in this vein.
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.
Lately I’ve been playing around with implementing genealogy sparklines on the web. Still very much a work in progress, but I’m trying to do more working in public, so here’s the messy current status (and at some point I’ll post the actual HTML/CSS):
Ruby test
Implementation notes:
The sparklines use inline SVG
This test uses the <ruby> and <rt> tags, with ruby-position set to under and ruby-align set to start (though only Firefox supports it so it’s not sadly viable for actual use yet)
I don’t really like that it makes the leading uneven (lines that have ruby vs. lines that don’t)
Design notes:
Rather than having solid squares at the births and deaths, I’ve gone for vertical lines so they’re less obtrusive (and have also considered just getting rid of the vertical lines, though I haven’t tried it out yet)
Circles are simple so I went with them for marriages and children
Absolute positioning test
Implementation notes:
The names are wrapped in span tags with position: relative set, and the SVG gets position: absolute. Fairly simple.
Even leading!
There’s some wonkiness right now when the span is at the beginning of a line (the sparkline shows up at the end of the previous line), haven’t tried very hard to fix it yet