This page lists picoblog entries for the most recent year. For past entries, consult the picoblog archive.
I forgot to post about this earlier, but there’s something unfortunate I discovered about Affinity Designer 2. It turns out if you import an SVG with arc commands (i.e. A or a commands) within a <path>, it will delete them and replace them with approximations using Bezier curves (i.e. C or c commands). This is terrible and makes it very hard to use Affinity Designer 2 as anything other than a “first-pass” editor—something you use to get the rough shape of your initial SVG, but not to perform the final touches. Effectively, if your SVG needs to use arcs, the moment you add those arcs into the file you can no longer go back to using Affinity Designer 2 to edit it further.
Maybe one day we’ll have good tools for editing and authoring SVG files directly. I’ve started using GodSVG to do the “final touch up” phase of SVG editing, but it’s a very laggy piece of software with few quality-of-life features. It’s in alpha, too. This feels like an area for which designers, as a profession, would already have excellent tools? If those tools exist, it’s baffling to me that I’ve been unable to find them. If those tools don’t exist, it’s baffling to me that no one has built them.
I’ve made a new SVG icon based around Euler curves. This was a pretty intense multi-hour project, and I feel as though I’ve learned a ton during it. I can now comfortably optimize my own SVGs by hand, without the use of SVGO. I was able to get the icon with 0.03 kB of what SVGO could provide, all with my own two hands.
Good lord. Someone needs to get an alternative vector graphics file type standardized for browsers. I know I’ve said that before, but after this experience? It feels more true than ever.
Well, shoot. It appears I was wrong (again) about New Computer Modern. I’d selected the variant of the font called NewCM10-Book.otf, which does indeed compress down to around 300 kB as a WOFF2 file. But I should have probably selected the variant of the font called NewCMMath-Book.otf, which compresses down to around 600 kB as a WOFF2 file. That’s… significantly worse.
I think I might need to rethink my approach to printing math on the web. These font files are simply too large to include. Not only do they waste a ton of bandwidth, they also will take so much time to load that I expect serious pop-in to occur if there is any MathML Core located near the top of my .html files. And pop-in is exactly the problem I’m trying to avoid by using built-time MathML Core generation instead of something like Temml or Mathjax!
This problem space deserves some serious research and I just don’t have time to dive into it right now. I have too much other work on my plate. It’s definitely a task for future me.
I’ve successfully submitted a paper to NeurIPS! It feels lovely.
I’ve successfully compressed and subsetted all the fonts for the site. They’re still a little large for my comfort—Open Sans in particular seems to use an extraordinary amount of space for its variable axes, to a degree that I’ve not before seen with a variable font. As in, about 70% of its file size is consumed by variable axis data. After converting to WOFF2 and aggressive subsetting, it ended up being 73.6 kB. That’s uncomfortably high for a font that needs to be ready almost immediately upon page load.
I swapped to New Computer Modern (not subsetted) and the Light variant of Jetbrains Mono (subsetted, no ligatures) for my math and code fonts, respectively. Those I was actually able to get down to reasonable sizes. Jetbrains Mono is 14.4 kB, and New Computer Modern is 289.7 kB.
Frankly, New Computer Modern needs to be large. It’s trying to render so many math Unicode characters that I knew it was going to be a big payload ahead of time, so I’m just happy it was under 300 kB. Furthermore, Jetbrains Mono going to 14.4 kB is fantastic; I use that font frequently on the site, so seeing its payload become that small is excellent.
Overall, this was a success but for Open Sans. Goodness, there must be a way to acquire the same beautiful font but without such an agonizing runtime cost! I use the variable font axes extensively on the site, and want to use them in even more places. But with such an expensive font, I’m starting to wonder if there aren’t better options.
I’ve successfully made the table of contents for my miniblog pages look nice! I made a custom SVG to replicate the U+168D0 Unicode character, which in keeping with the theme of this site is a character from an unfamiliar-to-English-speakers set of graphemes. It expands and contracts exactly as I’d hoped it would.
The SVG is 2.57 kB, and the original template for the U+168D0 character I found was 10.4 kB. It took a lot of optimization work in Affinity Designer 2, but I eventually got it to look nearly identical to the original with a ton of manual polishing and reduced it to 5.05 kB, and then SVGO took it down to 2.57. Weirdly, SVGO didn’t optimize the 8 arms of the U+168D0 symbol into one singular path, so the SVG contains 8 paths and 3 circles in total, whereas I think you could probably optimize it down to 3 circles and 1 path if you were really trying.
I also could have improved the nodes for each path and made their locations lower resolution, but I chose not to because that kind of optimization work on a pre-existing SVG template is hard. If I did go all out and try that, I could probably get the final product down to 1.5 kB or so, but I think at some point it’s worth noticing that your optimization work gets you diminishing returns and calling it a day. 2.57 kB is something I can be proud of.
The table of contents overall could be revised significantly to make it look and function even better, but the current draft is satisfactory to me. I’m happy with what I’ve created. For the purposes of publication, it’s ready to go.
After a long time away, I’m returning to working on this website! There are a ton of things I need to complete before it’s ready for publication, and I want to complete them as soon as possible.
Having this website almost ready but not exactly ready for so long has felt like an ever-present itch. It’s always in the back of my mind, poking me to complete it someday.
My current plans:
Update the animated ToC menu to be lower latency. Benchmark it in Edge while I’m at it to see how CPU-intensive it is.
Make the formatting on the ToC actually work when the screen is at smaller widths. It… doesn’t look great, currently. I left this project in a half-finished state when I was last working on it, and I’m struggling to pick up the pieces where I left off and remember what my past self was doing.
At long last, edit the main font for the site to have better capital “I” characters, and convert is into a WOFF2 format. I think I (almost) have the expertise needed to do this.
Make an SVG icon for the ToC menu, instead of the current unicode text character “𖣐” I’m using, which seems not necessarily supported by default in all browsers with their default fonts.
If I’m feeling up to it, rework the entire layout of the content so that it doesn’t rely on negative margins for <section> elements. It’s not very elegant at present.
Later, if I have time, I’d like to go back and rework my data format for the compendium pages, because the current version doesn’t extend well to all the cases I want to handle. I’d like to improve its presentation, too.
I wonder what the distribution of human heights is?
I know it’s not an additively stable distribution. People always say “heights are normally distributed,” but they’re obviously only claiming that a normal distribution is an approximation. Heights can’t go negative, and normal distributions can. Furthermore, any additively stable distribution that does prohibit negative values (e.g. the Lévy distribution) also has an extraordinarily thick upper tail, which is also inconsistent with the statistical pattern of human heights.
So my best guess is that we need to instead widen our scope to infinitely divisible distributions, which is a much wider class than additively stable distributions. But it’s a huge class; it even includes things like lognormal distributions, which I’d naively expect to only have multiplicative-invariance-related properties, not additive-invariance-related ones, y’know?
I’ve never seen anyone give me a concrete example of a distribution that fits the empirical pattern of human heights and that also possesses the nice, mathematical properties we’d expect from something that is clearly a polygenetic trait and where the individual influences of genes on that trait are additive. And of course, that’s assuming we rule out any correlations between what genes someone is likely to have due to evolutionary pressures (i.e. if you have heights that are too high are low you die, producing anti-correlations between individual genes that positively impact height).
My hunch is that it would like vaguely Poisson-esque, but where the maximum size of each Bernoulli used to construct the Poisson isn’t the same, and instead falls along some continuum. That would produce a continuous distribution of heights, rather than a discrete one. But it wouldn’t make heights bounded, which I suspect the true distribution of human heights probably would be. At the minimum, its tail should be far thinner than that of the Poisson distribution.
Hooray, it’s a new year! And I’ve updated my pico/microblog pages accordingly.