DEV Community: hw lu

How Unicode Bubble Text Generators Work (and Where They Break)

hw lu — Fri, 02 Oct 2026 13:51:32 +0000

Bubble text looks like a font effect, but a copy-and-paste generator does not render a font at all. It replaces ordinary Latin letters with existing Unicode characters such as Ⓑ, ⓑ, 🅑, 🄱, and ⒝.

That distinction changes almost every implementation decision. The result must remain real text, unsupported characters need a safe fallback, and each operating system is free to draw the same code point differently.

I recently built a small browser-only generator around those constraints. Here is how the conversion works, where Unicode makes the job easy, and where the character set becomes uneven.

Bubble text is character substitution

A CSS font family can change how text looks on one page, but copying that text normally gives the original letters. A Unicode bubble generator changes the characters themselves:

Bubble 123
Ⓑⓤⓑⓑⓛⓔ ①②③

Because the output is text, it can be selected, copied, searched, and pasted into compatible fields. There is no canvas, SVG, image upload, or font file involved.

Map code points instead of storing giant lookup objects

Several useful Unicode ranges are contiguous. Circled capital A begins at U+24B6, while the ASCII capital A begins at U+0041. The difference between those values can be used as an offset for the whole A–Z range.

const CIRCLED_UPPER = 0x24b6 - 0x41
const CIRCLED_LOWER = 0x24d0 - 0x61

function isUpper(cp: number) {
  return cp >= 0x41 && cp <= 0x5a
}

function toCircled(cp: number, original: string) {
  if (isUpper(cp)) {
    return String.fromCodePoint(cp + CIRCLED_UPPER)
  }

  if (cp >= 0x61 && cp <= 0x7a) {
    return String.fromCodePoint(cp + CIRCLED_LOWER)
  }

  return original
}

This is smaller and easier to audit than maintaining a large object containing every letter. It also makes the boundaries explicit: only characters inside the supported ranges are transformed.

Iterate by code point, not UTF-16 code unit

JavaScript strings use UTF-16 internally. Indexing with a classic numeric loop can split characters outside the Basic Multilingual Plane into surrogate halves.

A for...of loop iterates by Unicode code point, which makes it a safer default:

function convertWith(text: string, map: CharMap) {
  let output = ""

  for (const character of text) {
    const codePoint = character.codePointAt(0)
    output += codePoint === undefined
      ? character
      : map(codePoint, character)
  }

  return output
}

Even when the generator only transforms A–Z, users will paste emoji, punctuation, accented letters, and characters from other scripts. Iterating safely prevents those inputs from being damaged.

Unicode style ranges are not symmetrical

The tricky part is that each visual family supports a different set of characters.

Circled letters include uppercase and lowercase Latin letters.
Negative circled letters are uppercase, so lowercase input must be folded to uppercase if that style is selected.
Squared letters are also uppercase-only.
Parenthesized letters use lowercase forms.
Circled and dark circled digits have different ranges.
Parenthesized digits cover 1–9, while zero has no matching character in that set.
Squared digits are not available as a matching sequence, so the original digit should pass through.

That means a style cannot be represented only by a single offset. Each style needs a small mapping policy for case folding, letters, digits, and fallback behavior.

Preserve characters you cannot convert

A generator should never silently delete or guess unsupported input. If a user types café, a squared-uppercase style can convert the supported letters and preserve the rest:

café → 🄲🄰🄵é

The same rule keeps spaces, punctuation, emoji, and non-Latin scripts intact. Partial conversion is predictable; destructive conversion is not.

Show every result at once

I originally considered a style dropdown, but the output is easier to choose when all variants are visible together. For each keystroke, the interface runs the same input through six mapping functions and renders six rows:

const rows = styles.map((style) => ({
  id: style.id,
  label: style.label,
  output: style.convert(input),
}))

The data set is tiny, so there is no reason to add a server request or generation queue. The whole interaction can remain local to the browser.

Each row gets its own Copy button. navigator.clipboard.writeText() is enough for modern secure contexts, but the call should still be wrapped in try/catch because clipboard permission or browser policy can reject it.

Compatibility is part of the product

Unicode defines characters, not an identical visual appearance everywhere. A circled letter may have different spacing, weight, or proportions on macOS, Windows, Android, and individual apps. Some username fields also reject unusual Unicode even when normal messages accept it.

A responsible UI should say this clearly:

The result is Unicode text, not a downloadable font.
Appearance can vary by device and app.
Some fields may reject the characters.
Important information should remain in ordinary text.
Users should test the result in its final destination.

This is more useful than promising that decorative text works everywhere.

The result

I used these rules in GummyType's Bubble Text Generator. It produces six copy-and-paste styles, preserves unsupported characters, and keeps conversion inside the browser.

The implementation is small, but it is a useful example of a broader rule: when a tool transforms text, the edge cases are part of the feature. Unicode ranges, case behavior, digits, fallback policy, clipboard errors, and platform rendering all deserve explicit decisions.

Takeaways

Bubble text generators substitute Unicode characters; they do not apply fonts.
Contiguous Unicode ranges make offset-based mapping practical.
Each style still needs its own case and digit policy.
Iterate by code point and preserve unsupported input.
Generate locally and show variants together when the data set is small.
Treat compatibility limitations as product information, not footnotes.

Small text tools become much more reliable when their boundaries are designed as carefully as their happy path.

How I Built a Browser-Only Bubble Text Generator with SVG and Canvas

hw lu — Mon, 17 Aug 2026 01:30:13 +0000

Visual text generators look simple from the outside: type a phrase, choose a style, and download an image.

The implementation gets more interesting when the whole pipeline has to stay in the browser. The preview must match the exported PNG, fonts must render consistently across devices, transparent margins should be cropped, and changing a slider should not make the layout jump.

I recently built a small browser-based text-art generator to explore that problem. This post explains the architecture and the details that took the most work.

What I wanted the tool to do

The product requirements were intentionally narrow:

Accept a short phrase, including line breaks and mixed case
Offer three visibly different font shapes
Apply eight finishes such as glossy, sugar, holographic, chrome, neon, and sticker
Let the user change the font size and color
Preview changes immediately
Export a watermark-free PNG
Keep the phrase and rendering work inside the browser
Avoid accounts, uploads, and a server-side image API

The last requirement shaped almost every technical decision.

The rendering pipeline

The editor is a Client Component in a Next.js App Router project. React owns the controls, but the artwork itself is created by a pure TypeScript function.

The pipeline looks like this:

React controls
  -> SVG string
  -> SVG Blob
  -> HTML Image
  -> Canvas raster
  -> alpha-bound scan
  -> cropped PNG Blob

Keeping SVG generation in a pure function made it easier to test every combination without a browser. The browser-specific work is limited to font loading, text measurement, preview rasterization, and downloading.

Why SVG was a good fit

SVG gives text effects a useful middle ground between plain CSS and a full graphics engine.

Each finish is built from three text layers:

An outer stroke and shadow
The main gradient-filled text
A thin highlight shifted slightly upward and left

A simplified version looks like this:

<g text-anchor="middle" dominant-baseline="middle">
  <text
    fill="url(#gummyFill)"
    stroke="#8a174e"
    paint-order="stroke fill"
    filter="url(#softShadow)">
    HELLO
  </text>

  <text
    fill="url(#gummyFill)"
    stroke="#ff4fa3"
    paint-order="stroke fill">
    HELLO
  </text>

  <text
    fill="none"
    stroke="#ffffff"
    transform="translate(-2 -4)">
    HELLO
  </text>
</g>

The styles share the same renderer. Only a finish profile changes the gradient definitions, texture filter, stroke policy, and outer filter.

That is important because it prevents style logic from being scattered across the codebase. Adding a new finish means defining one complete rendering profile rather than updating several conditionals.

Making fonts consistent across devices

Relying on system font stacks caused an early problem. A rounded font and a chunky font can look different on one desktop and collapse to similar fallback fonts on another device.

I fixed that by bundling the font files with the application.

When a user selects a shape, the browser:

Fetches the matching TTF file
Waits for the browser font to load
Converts the file to a data URL
Embeds it into the generated SVG with @font-face

That makes the SVG self-contained before it is rasterized. The preview and the downloaded PNG therefore use the same font data instead of depending on whatever fonts happen to be installed on the device.

Measuring text before sizing the canvas

Character count is not a reliable width measurement. A string full of W characters can be much wider than a string of i characters with the same length.

The renderer uses CanvasRenderingContext2D.measureText with the selected family, weight, style, size, and letter spacing. The widest line determines the SVG canvas width.

The canvas is then sized around the measured artwork:

const widestLine = Math.max(
  fontSize,
  ...lines.map((line) => measureLine(line, fontSize)),
)

const padding = Math.max(24, fontSize * 0.22)
const width = Math.round(widestLine + padding * 2)
const height = Math.round(
  lines.length * fontSize * 0.94 + padding * 2,
)

This avoids two opposite problems:

Long phrases getting clipped
Short phrases being exported inside a huge fixed square

It also means a larger font size produces a genuinely larger PNG instead of merely scaling the same fixed canvas.

Keeping the preview stable

A tightly sized export is useful, but a tightly sized live preview can be distracting. The preview frame would change width on every keystroke and every font-size adjustment.

I use two SVG renders from the same source options:

The preview SVG uses a frame sized for the maximum font size
The download SVG is sized tightly around the selected font size

The text effect is identical, but the preview has a stable visual frame. The exported file remains compact.

The preview raster is capped at a smaller resolution for responsiveness, while export can use a larger maximum side. Neither path upscales the artwork beyond its natural dimensions.

Auto-cropping the PNG

After loading the SVG into an Image element, the browser draws it onto a temporary canvas. For transparent exports, the code reads the alpha channel and finds the first and last nontransparent pixel on each axis.

A safe margin is added to those bounds so shadows and glow effects are not cut off. The selected rectangle is then copied to a second canvas and encoded as PNG.

This step is skipped when the user chooses a solid or gradient background, because the background intentionally fills the entire canvas.

The same rasterization function is used by both preview and download. Sharing that path prevents the common bug where the editor looks correct but the saved file has different spacing or clipping.

Small details that mattered

A few less obvious issues were worth handling explicitly.

SVG whitespace

Regular spaces can be collapsed or stripped when SVG text is rasterized. Replacing user-entered spaces with non-breaking spaces keeps single and repeated spaces visible.

Stale asynchronous previews

Rendering is asynchronous. If a user types quickly, an older render can finish after a newer one. Each effect cleanup marks its render inactive so stale results cannot replace the latest preview.

Object URL cleanup

Every generated preview creates an object URL. The previous URL is revoked when a new preview replaces it, and the current URL is revoked when the component unmounts.

Input limits

The editor accepts short display text rather than paragraphs. A small character limit keeps the interface focused and prevents extreme canvas dimensions.

The result

The finished tool is GummyType. It creates bubble, Y2K, and chrome-style word graphics, and everything described above runs locally in the browser.

If you are more interested in shaping the letterforms than the rendering pipeline, I also wrote a step-by-step guide to making bubble letters by hand and with free browser tools.

The project reminded me that a small visual tool can still contain several interesting browser-engineering problems: font portability, SVG composition, accurate measurement, asynchronous rendering, raster export, and memory cleanup.

What I would add next

The current version deliberately keeps the workflow simple. Possible future improvements include:

More font shapes without making the control panel overwhelming
SVG export for users who need editable artwork
Reusable presets for common visual styles
Better keyboard controls and accessibility feedback
More export backgrounds and layout templates

For now, the most useful constraint has been keeping the tool focused: short text in, finished image out, with no server rendering step in between.

If you have built a browser-based image or SVG tool, I would be interested to hear which rendering edge cases caused the most trouble for you.

How to Create Charts from CSV Files Without Excel

hw lu — Tue, 09 Jun 2026 05:48:32 +0000

CSV files are everywhere: analytics exports, sales reports, product usage logs, survey results, finance data, and database dumps. But turning a CSV into a quick chart can still feel heavier than it should.

Most people open Excel or Google Sheets, clean the data, select a chart type, adjust the axes, export an image, and then paste it into a report or slide deck. That works, but it is not always the fastest path when you just need a simple line chart, bar chart, or scatter plot.

This post walks through a lightweight workflow for creating charts from CSV files without starting a full spreadsheet project.

When a spreadsheet is more than you need

Spreadsheets are great when you need formulas, pivot tables, collaboration, or manual editing. But for quick visualization, they can add friction:

You have to import the file correctly.
Numeric columns may be treated as text.
Dates may be parsed differently depending on locale.
Exporting a clean chart image takes extra steps.
The file may contain data you do not want to upload to a shared workspace.

If the task is just "show me how this CSV changes over time," a smaller workflow is often enough.

A simple CSV-to-chart workflow

The most reliable workflow is:

Start with a clean CSV file.
Pick the column for the X axis.
Pick one or more numeric columns for the Y axis.
Choose a chart type.
Export the chart as PNG or SVG.

That is enough for many common cases:

Monthly revenue by region
Product usage over time
Survey responses by category
Error counts per release
CSV exports from internal tools
Simple comparisons across numeric columns

For example, a file like this can become a line chart quickly:

month,visits,signups,paid_users
2026-01,1200,84,12
2026-02,1480,101,18
2026-03,1760,133,21
2026-04,1690,126,24

Use month as the X axis, then plot visits, signups, or paid_users as Y values.

Common issues to check before charting

If a CSV does not chart correctly, the problem is usually in the data shape rather than the chart tool.

1. Numbers are stored as text

Values like $1,200, 1,200 users, or ~1200 may not be treated as numbers. Remove symbols and units before charting.

2. There are extra header rows

CSV exports from reporting tools often include a title row, notes, or metadata before the actual header. The first row should usually be the column names.

3. Dates are inconsistent

Try to keep dates in a consistent format such as YYYY-MM-DD or YYYY-MM. This makes the X axis easier to read and sort.

4. The data is too aggregated or not aggregated enough

If you need "sales by region per month," make sure each row has a clear month and region, or aggregate the data first in a spreadsheet or script.

Tool options

There are several good ways to make charts from CSV data:

Google Sheets or Excel if you need editing, formulas, or pivot tables.
Python with pandas and matplotlib if you want a reproducible code workflow.
Observable or notebooks if you want interactive analysis.
Datawrapper if you need polished charts for publishing.
A lightweight browser tool if you just need a quick chart export.

I built one of those lightweight browser tools called CSV Graph:

https://csv.qingyanglabs.com/

It lets you paste or upload CSV data, choose columns, create line, bar, or scatter charts, and export the result as PNG or SVG. It is intentionally simple: no sign-up, no dashboard setup, and no AI-generated numbers. The goal is to make the chart from the data you actually provide.

When not to use a lightweight chart tool

A simple CSV chart tool is not the right fit for every job.

Use a spreadsheet, BI tool, or notebook when you need:

Pivot tables
Joins across multiple files
Complex formulas
Scheduled reports
Permissions and team dashboards
Very large datasets

But if you only need to turn a CSV export into a clean chart for a report, issue, README, slide, or quick analysis, a small browser-based workflow can save time.

Final thought

CSV is simple, but visualizing it should be simple too. Before opening a full spreadsheet or asking an AI tool to generate a chart from a prompt, try the deterministic path first: inspect the CSV, pick the columns, make the chart, export the result.

That keeps the numbers honest and the workflow fast.

You can also find CSV Graph on Product Hunt:
https://www.producthunt.com/products/csv-graph?launch=csv-graph