Is there an easy way to upload custom font for theme

Hi! I’m, surprise (!) customizing my theme and would like to upload a custom font to the theme. Is there an easy way to do that?

I tried the “naive” way of simply creating a template /static/css/fonts/charter_regular.woff2 and copying the contents of the woff2 file in there, but needless to say this didn’t work.

Is there any workaround I miss?

And yes, I’m aware that Charter is available on Mac/iOS, but it isn’t anywhere else, and I would like the site to be consistent.

Any help appreciated.

How are you referencing it in your CSS?

Also, I’d probably just put in static/fonts

Thanks for your reply Jason.

I reference via @font-face in my CSS.
The CSS file is in static/css/ and the font-files would be in static/css/fonts.

My question is how I get the actual font files, for example charter_regular.woff2 into said static/css/fonts folder. There doesn’t seem to be an obvious way to upload a file. Unless I’m missing something.

My first guess was simply opening the font file on the desktop in a text editor and then paste the contents into a newly created “template” under the title static/css/fonts/charter_regular.woff2 . Doesn’t seem to work though.

Via CSS the the @font-file thingy

@font-face {
font-family: charter;
font-style: normal;
font-weight: normal;
font-stretch: normal;
src: url(‘fonts/charter_regular.woff2’) format(‘woff2’);
}

And to clarify: I’m using the Micro.Blog web-interface.

(also: it should be obvious by now that I’m , that I’m no developer :rofl:)

Unfortunately, I don’t think there’s an easy way to do that. @manton would have to add support for uploading binary files to a theme. Four workarounds I can think of:

  1. Move your custom theme to a git repository hosted on GitHub. That way, you could add any file you want.
  2. Serve the font as a Base64 encoded data URL.
  3. See if you can find a hosted alternative for the font you want to use.
  4. Pretend that the font file is an image and upload it via Micro.blog’s regular upload functionality. It will end up at a URL like https://www.svenseebeck.me/uploads/2022/23931724ed.woff that you can reference from your CSS file.

The last alternative is probably the easiest for a non-developer if you can’t find a hosted option. But it’s a bit hacky. Probably don’t tell @manton if you choose that route. :sweat_smile:

Actually uploading font files in the Uploads section is totally fine, so no need to hide it from me. :slightly_smiling_face: Because I’m not sure it’s documented anywhere, the following file extensions are allowed in uploads:

jpg
mp3
m4a
m4v
mov
mp4
png
gif
webp
svg
pdf
ttf
woff
woff2
eot
xml
txt
js
css

Most of these are allowed in themes too, as long as it’s added in a GitHub repository first and then cloned to Micro.blog. Micro.blog can’t edit the .woff file, but it should preserve it, and then you can add additional text templates.

1 Like

Good to know, thanks. :innocent:

Given that uploading a font results in HTML like <img src="https://example.micro.blog/uploads/2022/123b221e4ec.woff" width="150" height="150" style="width: auto;" loading="lazy"> beeing rendered, I though you just expected image files to be uploaded.

By the way, I cannot upload .woff files from the iOS client (they are greyed out during file selection). Web and macOS work fine, though.

Oops, that must be a bug including the Copy button. Thanks!

This was my confusion-- I clone from GitHub so I knew you can just put this in the static folder. This makes sense though!

Thanks a lot @sod and @manton! I didn’t thought the upload would actually work.

I will give solution 2 a try first first, since I can put that into my CSS and I have seen themes (and wondered what is is) using data URL’s. I just found this tool (Woff2Base: Convert .woff2 to accurate Base64 css.) which might do that even easier. But since I haven’t had a coffee yet I will wait before I mess things up :rofl:

The Base64 worked smoothly thanks a lot for the tip! This opens a whole new range of possibilities I’m afraid :rofl:

1 Like

@sod @manton Through already conversing about this on Micro.blog, I’m curious if there’s a difference between uploading to GitHub and cloning into the theme that way, versus base64 encoding the font within the CSS. Is one option better than the other in terms of performance and caching?

Performance purists will probably argue that:

  • Base64 should be avoided as it has a high overhead cost. File size ends up roughly 33 % larger when Base64-encoded.
  • Embedding the font into the CSS file is a bad idea, as they are render-blocking resources. The browser won’t render any content before it’s finished loading and parsing the CSS.

On the other hand, one might counter that:

  • If the CSS file is served to the browser with gzip compression, the overhead cost will not be that high.
  • Yeah, sure, it’s render-blocking, but at least we avoid a flash of unstyled text.

And, believe me, the above arguments and counterarguments are just scratching the surface. :blush:

Most professional web developers would go with external fonts in most cases. That said, sometimes it makes sense, given the circumstances, to serve resources as data URL:s.

In the end, does it matter? Well, it matters a great deal for popular commercial websites (like google.com). But, for a personal blog, probably not that much.

1 Like

I think, and take that from a non-developer standpoint, that I can easily live with that :rofl:

First of all FOUT freaks me out. I had this plenty with fonts hosted by Adobe (haven’t used that service in a while and can’t remember the name anymore) and I gladly live without it.

Sure the file size increases, in my case from 6kb to 88kb, which is a rather large increase, then again, for shits and giggles I downloaded the CSS of my old blog off of Wordpress and that alone is 330kb and it is only one of possibly 15-20 css files that have gotten loaded (twenty-twenty css is about 128kb and the Jetpack one 88 which also includes one icon-font as I just figured). But comparing with WP is probably not a good choice, but still.

So, meaning, the 88kb aren’t so bad for the few visitors of my site that aren’t me :see_no_evil:

Yeah, you absolutely made the right decision for your use case. :blush:

Such a great explanation, thanks so much for this! I might trial this out and do a page load comparison between the two. I have noticed the flash of unstyled text on my blog (which uses uploaded fonts) so admittedly it would be nice not to have that appear if the overall speed isn’t affected noticeably.

Is that nit picky? Yes.
Is it the height of nerdiness? Also yes. :laughing: