DEV Community: Danilo

I turned a photo of my handwriting into a real font, then open-sourced the whole pipeline

Danilo — Fri, 24 Jul 2026 07:54:20 +0000

I wrote my alphabet in a spiral notebook, took one photo in dim light, and got an installable TTF out the other end. My computer now can type in my handwriting. The whole thing is open source (MIT), runs locally, and works as three layers: an npm library, a CLI, and a Claude Code skill on top.

Repo: github.com/danilo-znamerovszkij/draw-your-font
Browser demo: danilo-znamerovszkij.github.io/draw-your-font/

This post is about why I built it and how the pipeline actually works.

Why I built it

I always thought it would be so cool to have a custom font, designed by you. And every time I researched it, the answer was some version of "sure, if you're willing to suffer".

Font editors want you to draw every glyph one by one with a tablet pen, or worse, with your touchpad. The tools that accept a photo of your handwriting are limited, and the main one (Calligraphr) wants $8/month for the full version. A subscription for my own handwriting!

So, how hard could it be to just build it and open source it? Turns out, not that hard. Every piece has been open source for years: sharp for image processing, a JS port of potrace for vectorization, svg2ttf for assembly. Nobody had wired them together into one zero-install package.

On the open-source side the closest thing is builtree/handwrite: Python, and it requires FontForge and potrace installed system-wide. That's a real barrier. Most people who want their handwriting as a font are not going to brew-install a font editor first.

So the gap I aimed at was specific: pure npm, no system dependencies, and tolerant of freeform photos instead of demanding a scanner and a perfectly aligned template. Then I wrapped it in a reusable Claude Code skill that does the heavy lifting: you hand it a photo, it hands you a font.

Make your font

npx skills add danilo-znamerovszkij/draw-your-font

Then drag a photo into Claude Code and say "make my font". That's it. Claude finds your letters in the photo, labels them with vision, builds the font, shows you a preview, and then critiques its own work before you have to.

Finds and labels your letters in a messy photo, and knows a shadow blob from ink.
Critiques its own output. "Your g traced badly" comes with the crop and a suggested fix.
Refines by talking. "Make it rounder", "a bit bolder", "how readable is it?"

The photo goes to the model for labeling only. The geometry never leaves your machine. Node 18+, nothing else.

How it works

Six steps, all deterministic code:

Adaptive threshold. A global threshold dies on real photos, because a page shadow makes half the image darker than the ink in the other half. Thresholding against the local background is why dim light survives.
Blob detection. Connected components find every ink region. The dot on an i gets merged with its stem by proximity.
Labeling. Something has to say "blob 14 is a lowercase g". The skill reads a numbered contact sheet with vision, which is why messy freeform photos work.
Vectorization. Potrace, the same engine inside FontForge and Inkscape. The AI never draws a single curve.
Metrics. The step that separates "font" from "ransom note". Every character gets a vertical band in a shared em square, so your g hangs below the line and your o stays smaller than your O.
Assembly. Outlines plus metrics become TTF, WOFF/WOFF2, and a ready @font-face snippet.

Put it on your website

The TTF is for your laptop. For your website, ask for WOFF2 and you get a web font plus the @font-face snippet.

The headline on the demo page is set in a font I made in minutes, from the exact photo in the demo video: danilo-znamerovszkij.github.io/draw-your-font/

I think this matters more now than it used to. Feeds are full of AI slop. Everything is generated in the same voice and set in the same fonts, page after page, post after post. So a site rendered in your actual handwriting, with the wobble of your real pen in every letter, is a personal touch that's hard to fake. It costs you one photo.

One rough edge

Write freeform and some letters can sit a little higher or lower than they should. If you want a cleaner result, print the built-in template (npx draw-your-font template -o template.pdf) and write in its grid, or just rule a few light pencil lines with an old ruler and write on those. But honestly, freeform works fine. My whole demo is one crooked notebook photo.

The fine print

The skill sits on a plain npm CLI with zero system dependencies, so you can run the whole thing without any AI:

npx draw-your-font make photo.jp![img.png](img.png)g --chars "ABCabc" --name "My Hand"

It's trickier than talking to Claude. You type every character in writing order, and there's no one to catch a bad trace for you. But it's there, and it's fully deterministic. There's also a browser demo that runs the pipeline client-side (potrace compiled to WASM), nothing uploaded.

Dark pen, letters not touching. That's the only real requirement; my own hero photo has spiral binding, a page shadow, and bad light. The font you generate is 100% yours, commercial use included.

If you find it useful, please consider starring the repo so more people can find it. And if you make a font from your own hand, I'd genuinely love to see it.

[Boost]

Danilo — Sat, 31 Jan 2026 19:02:04 +0000

Min/Max Dual-Range Sliders for DaisyUI (Theme-Aware) - DEV Community

DaisyUI has a range component, but it doesn’t support dual-handle (min/max) sliders. That becomes a...

dev.to

Min/Max Dual-Range Sliders for DaisyUI (Theme-Aware)

Danilo — Sat, 31 Jan 2026 19:01:33 +0000

DaisyUI has a range component, but it doesn’t support dual-handle (min/max) sliders.

That becomes a limitation when building things like price filters, faceted search, dashboards, or admin tools.

This isn’t solvable with native HTML or CSS alone. A proper min/max slider requires JavaScript for multiple thumbs, value constraints, keyboard and touch interaction, and accessibility.

Once you accept that JS is required, there’s another issue:

there’s no obvious, DaisyUI-friendly solution.

What typically happens is:

a slider library is introduced (often noUiSlider)
its generated DOM is inspected
styles are overridden to match DaisyUI
that setup gets copied into the next project
slightly differently each time

I’ve done this more than once. It works, but it’s repetitive and not very reusable.

The idea

Instead of repeating that wiring, I packaged it once:

daisy-dual-range

uses noUiSlider for behavior
uses DaisyUI CSS variables for styling
keeps styles scoped (no global overrides)

It’s essentially a small integration layer between the two.

What it provides

dual-handle slider by default
theme-aware via DaisyUI tokens (primary, accent, error, etc.)
visual parity with DaisyUI range inputs
automatic adaptation when the theme changes

Why a wrapper?

You can wire this up manually if you want.
The wrapper exists because:

the choice of slider library isn’t obvious
the DaisyUI ↔ noUiSlider integration is non-trivial
the same setup tends to be re-implemented across projects
Packaging the pattern once reduces that duplication.

Scope

This is intentionally small.
It’s not a DaisyUI core component, a Tailwind plugin, or a framework abstraction, just a focused utility for a missing use case.

If you run into this problem while using DaisyUI, this is one option to consider.

The Practical Guide to Optimizing @font-face

Danilo — Mon, 24 Nov 2025 16:48:07 +0000

Web fonts are one of the easiest places to lose performance—and one of the easiest to fix. Most sites ship multiple formats, oversized files, or unnecessary weights. Here's a compact guide to optimizing your fonts the right way.

1. Use woff2 First (and Preferably Only)

woff2 is the smallest, fastest, and most compressed format.
Unless you must support IE11 (you probably don’t), you can safely drop:

A clean modern declaration looks like:

@font-face {
  font-family: 'Poppins';
  src: url('Poppins.woff2') format('woff2');
  font-weight: 400;
  font-style: normal;
  font-display: swap;
}

If you still support older environments, fallbacks are fine—but keep them minimal:

@font-face {
  font-family: 'Poppins';
  src: url('Poppins.woff2') format('woff2'),
       url('Poppins.woff') format('woff');
  font-weight: 400;
  font-display: swap;
}

2. Only Include the Weights You Actually Use

Many projects include full font families (100–900) when they only use 400 and 600.

Audit your CSS → keep only what you need.

3. Always Use `font-display: swap`

It eliminates invisible text (FOIT) and improves perceived performance.

font-display: swap;

This ensures text renders immediately using a fallback font, then swaps when the custom font loads.

4. Subset Your Fonts

Most font files include far more glyphs than you need:

Cyrillic
Arabic
Vietnamese
Symbols
Full Unicode ranges

If your site uses only Latin characters, subsetting can reduce file sizes by up to 70–90%.

Two great tools:

4.1. Transfonter: https://transfonter.org/

(Upload → subset → download optimized woff2)

4.2. Google Webfonts Helper: https://gwfh.mranftl.com/fonts

(Self-host Google Fonts + get correctly pre-built subsets)

5. Inline Preload for Critical Fonts

For your main UI font, consider preloading:

Final Checklist

Use woff2 (and fallback to woff)
Remove eot, svg, and ttf unless required
Keep only the weights you use
Always include font-display: swap
Subset using Transfonter or Google Webfonts Helper
Preload critical fonts

Small changes → big wins. Typography stays beautiful, performance gets faster, and you ship fewer kilobytes.

Improving Core Web Vitals: LCP Trick

Danilo — Mon, 17 Nov 2025 17:50:18 +0000

Ranking high on Google directly depends on your Core Web Vitals.

For me, one of the most impactful thing was this:

Preload your LCP

Determine what your Largest Contentful Paint element is, and add <link rel="preload" href="...">

Sunburst Chart in JS | ECharts x D3 x Plotly

Danilo — Tue, 11 Nov 2025 14:56:49 +0000

I just wanted to plot my data on a sunburst chart. I assumed choosing a library would be one ChatGPT question away... but it wasn't. There were at least a dozen of alternatives to consider.

Spoiler alert: I went with Apache Echarts. Here's why.

1. D3.js - the safe choice

D3.js is the most popular and familiar option. I’ve used it before. But could it handle a sunburst chart cleanly?

I found a demo here, but it seemed too complex with generating the arc, computing the layout, etc, it didn’t feel like the obvious choice for this project.

2. Plotly - ChatGPT's recommendation

Plotly does support sunburst charts, but the transitions and label visibility looked too clumsy:

3. ECharts 👑

Apache Echarts is free, simple to use, and the default demos already looked great. The data structure is clean and intuitive, smooth transitions, minimal config required. It was the clear winner.

Quick proof of concept — Claude + ECharts

Before setting up the full project (I wrote earlier about choosing Vite), I wanted a quick proof of concept.

So I pasted the data into Claude and said:
“Using ECharts, visualize this data as a sunburst chart.”

After 2 minutes I had a functioning sunburst chart with my data.

Of course, the real project needed more refinement, customization, and performance work.
But having a working prototype in minutes made the choice obvious.

Data format:

const baseData = [
  {
    name: 'Parent 1',
    children: [
      {
        name: 'Child 1',
        children: [
          { name: 'Grandchild 1', value: 1 },
          { name: 'Grandchild 2', value: 1 },
          ...
        ]
      },
  ...
]

To see the final result: the repo

🚀 Best Frontend Performance Guide I was going through my old bookmarks, and this article is honestly still one of the best resources on frontend performance https://www.smashingmagazine.com/2021/01/front-end-performance-2021-free-pdf-checklist/

Danilo — Mon, 10 Nov 2025 11:04:40 +0000

Front-End Performance Checklist 2021 (PDF, Apple Pages, MS Word) — Smashing Magazine

Let’s make 2021... fast! An annual front-end performance checklist, with everything you need to know to create fast experiences on the web today, from metrics to tooling and CSS/JavaScript techniques.

smashingmagazine.com

Clamp CSS in 2025 | Why I Stopped Writing Media Queries For Small Tweaks

Danilo — Thu, 06 Nov 2025 14:06:55 +0000

Media queries still work.

But they’re not always the best tool when it comes to small layout changes.

I ran into this while building a popup that needed to shrink smoothly between 750px and 950px. I added three media queries. It felt clunky.

That’s when I gave clamp() another look.

Turns out, clamp() lets you describe responsive behavior in one line. It’s supported by 96% of browsers and works for any CSS property that accepts a unit (font, spacing, etc.)

The syntax looks like this:

font-size: clamp(16px, 2vw, 32px);

or if you're using rem

font-size: clamp(1rem, 2vw, 2rem);

This means:

Never go below 16px
Never exceed 32px
In between, scale based on viewport width

It’s simple, except tuning the values feels awkward. The “preferred” value must be a fluid unit like vw or vmin, and the curve is linear between min and max.

There are many small tools, I personally like this one to preview and fine-tune clamp expressions: https://design.dev/tools/clamp-generator/

Why You Should Try Vite For Your Next Project (and Forget About Webpack)

Danilo — Tue, 04 Nov 2025 12:21:18 +0000

For years, I lived in Webpack configs. Every small project felt like booting a factory for one cup of coffee. Then I tried Vite. Two minutes later, I had a working setup. No waiting. No dependency hell.

At its core, frontend isn’t about frameworks. It’s about rendering data into something humans can see, understand, and interact with. For my project, a simple data visualization app, I didn’t need another layer of abstraction. I still wanted a few modern comforts: code splitting, hot reload, fast bundling, minified JS. But not if it meant fighting config files for half a day.

The stack:

Vite — instant startup, zero config, ES modules by default
TypeScript — strong typing, fewer surprises
SCSS — clean syntax, mixins, control

What impressed me most was how production-ready Vite is right out of the box. I generally agree that you should use the stack you’re comfortable with, but Webpack was never about comfort to begin with.

Every few years, frontend tools get heavier than the code they build. From that perspective, Vite feels like a breath of fresh air. For future small projects — experiments, visualizers, ideas — this is the tool I’ll reach for again.

🔗 Project repo: github.com/danilo-znamerovszkij/c-atlas

Export Chrome tabs as plain text or JSON (tiny tool I made)

Danilo — Sun, 20 Jul 2025 17:48:04 +0000

I had too many Chrome tabs open (100+), and I wanted to ask ChatGPT to help me prioritize.
But I couldn’t easily copy them all.

So I made a tiny Chrome extension that dumps all open tabs — titles and URLs — in plain text or JSON.
Click → copy → done.

It’s super minimal. Just helped me get the list out fast.

Open source here: https://github.com/danilo-znamerovszkij/TabsDump ⭐

Figma MCP Server Guide

Danilo — Fri, 21 Mar 2025 16:04:29 +0000

This guide walks you through a complete Figma → MCP Server workflow so you can streamline your design-to-code pipeline.

Step 1: Get Your API Token

Figma won’t let MCP fetch designs unless you provide an API key.

Open Figma → Settings → Security → Personal Access Tokens
Generate a new token
Copy it somewhere safe—you’ll need it shortly

Step 2: Run MCP Server

Once you have your token, start the server by running:

npx figma-developer-mcp --figma-api-key=YOUR_FIGMA_API_KEY

Step 3: Connect MCP Server with Cursor

If you're using Cursor for AI-assisted development, add this to your settings:

{
  "mcpServers": {
    "figma-developer-mcp": {
      "type": "sse",
      "url": "http://localhost:3333/sse",
      "env": {
        "FIGMA_API_KEY": "YOUR_FIGMA_API_KEY"
      }
    }
  }
}

Step 4: Verify the Connection

Open Cursor and check if the MCP Server is recognized.
If everything is set up correctly, you should see successful API calls when you request a design.

Step 5: Install Live Preview Plugin

To see real-time HTML previews, install the Live Preview plugin in VSCode.

Open VSCode
Go to Extensions
Search for Live Preview
Install and activate it

Now you can view live updates as you implement your email markup!

Debug JS events with monitorEvents

Danilo — Thu, 02 Nov 2023 15:35:04 +0000

It can be challenging sometimes to debug events, because of how many browsers and devices there are, so I wanted to share one underrated feature called monitorEvents that can track events on specific elements in the document.

Log all events firing on the body element

monitorEvents(document.body)

Log all mouse events on the body

monitorEvents(document.body, 'mouse')

Log all events on all input elements

monitorEvents(document.body.querySelectorAll('input'))