Skip to content

LCD·OLED 폰트 생성기 (비트맵 → C 배열 변환)

텍스트·이미지를 SSD1306·SH1106·ST7920·Adafruit GFX용 C 배열로 변환하는 온라인 도구. 12×12/16×16 도트 폰트, PCtoLCD2002 4가지 스캔 방식, 기존 배열 해석 지원.

트래킹 없음 브라우저 실행 무료
모든 처리는 브라우저 안에서 이루어지며, 텍스트와 이미지는 이 기기를 벗어나지 않습니다.

SSD1306 / SSD1309 / SH1106 / ST7565 페이지 메모리 및 MicroPython framebuf.MONO_VLSB와 같은 배치입니다. 바이트를 디스플레이에 그대로 쓰면 됩니다.

미리보기

픽셀을 클릭하면 켜짐/꺼짐이 전환됩니다.
    글리프 4개 · 64바이트
    참고: 모든 스캔 방향으로 본 문자 中 (16 × 16)

    켜진 픽셀 = 1, GNU Unifont 글리프입니다. 가지고 있는 배열과 이 바이트를 비교하면 어떤 설정으로 생성했는지 알 수 있습니다.

    스캔 방향 비트 순서 바이트 (16진수)
    행 단위 (가로 바이트) MSB 우선 — 첫 픽셀을 bit 7에 01 00 01 00 01 00 01 00 3F F8 21 08 21 08 21 08 21 08 21 08 3F F8 21 08 01 00 01 00 01 00 01 00
    행 단위 (가로 바이트) LSB 우선 — 첫 픽셀을 bit 0에 80 00 80 00 80 00 80 00 FC 1F 84 10 84 10 84 10 84 10 84 10 FC 1F 84 10 80 00 80 00 80 00 80 00
    열 단위 (세로 바이트) MSB 우선 — 첫 픽셀을 bit 7에 00 00 00 00 0F F0 08 20 08 20 08 20 08 20 FF FF 08 20 08 20 08 20 08 20 0F F0 00 00 00 00 00 00
    열 단위 (세로 바이트) LSB 우선 — 첫 픽셀을 bit 0에 00 00 00 00 F0 0F 10 04 10 04 10 04 10 04 FF FF 10 04 10 04 10 04 10 04 F0 0F 00 00 00 00 00 00
    페이지별 열 단위 (세로 바이트, SSD1306 페이지 순서) MSB 우선 — 첫 픽셀을 bit 7에 00 00 0F 08 08 08 08 FF 08 08 08 08 0F 00 00 00 00 00 F0 20 20 20 20 FF 20 20 20 20 F0 00 00 00
    페이지별 열 단위 (세로 바이트, SSD1306 페이지 순서) LSB 우선 — 첫 픽셀을 bit 0에 00 00 F0 10 10 10 10 FF 10 10 10 10 F0 00 00 00 00 00 0F 04 04 04 04 FF 04 04 04 04 0F 00 00 00
    띠별 행 단위 (가로 바이트, 폭 8픽셀 띠) MSB 우선 — 첫 픽셀을 bit 7에 01 01 01 01 3F 21 21 21 21 21 3F 21 01 01 01 01 00 00 00 00 F8 08 08 08 08 08 F8 08 00 00 00 00
    띠별 행 단위 (가로 바이트, 폭 8픽셀 띠) LSB 우선 — 첫 픽셀을 bit 0에 80 80 80 80 FC 84 84 84 84 84 FC 84 80 80 80 80 00 00 00 00 1F 10 10 10 10 10 1F 10 00 00 00 00

    도트 폰트: GNU Unifont(16 px)와 Fusion Pixel Font(12 px), 둘 다 SIL Open Font License 1.1을 따릅니다. 라이선스 전문

    스캔 방향과 비트 순서의 8가지 조합 모두를 독립적인 참조 구현과 바이트 단위로 대조했으며, 프리셋은 SSD1306, SH1106, ST7565 데이터시트와 Adafruit GFX, U8g2, LVGL, MicroPython 소스 코드를 기준으로 검증했습니다. — Go Tools 팀 · Oct 3, 2026

    Go Tools 엔지니어링 팀이 제작하고 검증했습니다.

    빠른 답변

    SSD1306 OLED에는 어떤 설정이 필요한가요?

    페이지별 열 단위 · LSB 우선 바이트를 디스플레이 메모리에 직접 쓴다면 페이지별 열 단위, LSB 우선, 켜진 픽셀 = 1입니다.

    Adafruit GFX drawBitmap()에는 어떤 설정이 필요한가요?

    행 단위 · MSB 우선 행 단위, MSB 우선, 켜진 픽셀 = 1이며, 각 행은 바이트 경계까지 채웁니다.

    16 × 16 글자는 몇 바이트인가요?

    32바이트 어떤 스캔 방향이든 32바이트입니다. 12 × 12는 24바이트, 8 × 16 ASCII 문자는 16바이트입니다.

    PCtoLCD2002의 顺向과 逆向은 무슨 뜻인가요?

    逆向 = LSB 우선 顺向 = MSB 우선(첫 픽셀이 bit 7), 逆向 = LSB 우선(첫 픽셀이 bit 0)입니다.

    폰트 비트맵(取模)이란 무엇인가요?

    SSD1306, SH1106, ST7565 같은 그래픽 OLED·LCD 컨트롤러는 대부분 폰트를 내장하고 있지 않습니다. 글자를 표시하려면 펌웨어가 켜짐/꺼짐 픽셀로 이루어진 작은 격자를 디스플레이 메모리에 복사합니다. 픽셀 하나가 1비트, 8픽셀이 1바이트입니다. 글리프를 이런 바이트로 변환하는 작업을 중국어 임베디드 튜토리얼에서는 '取模'라고 부르며, Windows 프로그램 PCtoLCD2002가 오랫동안 이 일을 맡아 왔습니다.

    하지만 바이트만으로는 부족합니다. 같은 16 × 16 글자도 담는 방식이 네 가지(행 단위, 열 단위, 페이지별 열 단위, 띠별 행 단위)이고, 각 방식마다 첫 픽셀을 bit 7에 둘지 bit 0에 둘지 정할 수 있습니다. 같은 글리프를 나타내는 바이트열이 8가지가 되고, 디스플레이가 제대로 그리는 것은 그중 하나뿐입니다. 튜토리얼에서 복사한 폰트가 좌우 반전되거나 반으로 갈라지거나 회전되어 보이는 일이 잦은 이유가 여기에 있습니다.

    // 中 (16x16), pages of columns, LSB first, lit = 1 — SSD1306 page order
    const unsigned char zhong[32] = {
      0x00,0x00,0xF0,0x10,0x10,0x10,0x10,0xFF,0x10,0x10,0x10,0x10,0xF0,0x00,0x00,0x00,
      0x00,0x00,0x0F,0x04,0x04,0x04,0x04,0xFF,0x04,0x04,0x04,0x04,0x0F,0x00,0x00,0x00
    };
    // First 16 bytes = page 0 (rows 0-7), one byte per column, bit 0 = top row

    이 생성기의 기능

    픽셀 단위로 정확한 12 × 12·16 × 16 한자

    브라우저 폰트는 안티에일리어싱이 적용된 윤곽선 폰트입니다. 송체(명조 계열)를 12 px에서 이진화하면 中의 가로획이 아예 사라집니다. 그래서 이 도구는 실제 비트맵 폰트를 내장했습니다. 16 × 16 폰트는 GB2312의 6,763자를 모두 담고 있고, 12 × 12 폰트에는 희귀 한자 143자가 빠져 있어 이 글자들은 시스템 폰트로 대신 그리고 따로 표시합니다.

    PCtoLCD2002의 네 가지 스캔 방식과 두 가지 비트 순서

    행 단위, 열 단위, 페이지별 열 단위, 띠별 행 단위를 각각 MSB 우선 또는 LSB 우선, 켜진 픽셀 = 1 또는 0과 조합할 수 있습니다. 이름은 PCtoLCD2002를 따르고, 그 의미는 SSD1306 데이터시트와 흔히 쓰는 OLED 예제 프로젝트에 맞춰 확인했으므로 기존 프로젝트에서 쓰던 설정을 그대로 고르면 됩니다.

    무엇과 맞는지 알려 주는 프리셋

    SSD1306, Adafruit GFX, XBM 중 하나를 고르면 옵션이 자동으로 설정됩니다. 옵션을 직접 바꾸면 그 바이트 순서를 읽는 디스플레이와 라이브러리를 알려 주고, 해당하는 것이 없으면 없다고 표시합니다.

    가지고 있는 배열 해석

    출처를 모르는 폰트 배열을 붙여넣으면 스캔 방향과 비트 순서의 8가지 해석을 모두 나란히 그립니다. 제대로 읽히는 것이 곧 설정이며, 클릭 한 번으로 적용됩니다.

    제대로 된 디더링을 갖춘 이미지 → 비트맵 변환

    로고, 아이콘, 사진을 디스플레이 크기에 맞춰 축소한 뒤 임계값, Floyd–Steinberg, Atkinson 디더링 중 하나로 변환합니다. 투명한 부분은 배경으로 처리하며 임계값은 모든 모드에서 적용됩니다.

    프로젝트에 바로 넣을 수 있는 출력

    /*"中",0*/ 주석이 붙은 C51 스타일 2차원 배열, 오프셋이 포함된 Arduino PROGMEM, MicroPython bytearray 딕셔너리, A51 DB 줄, 일반 16진수를 지원합니다. 생성된 C 코드는 -Wall -Wextra -pedantic 옵션으로도 경고 없이 컴파일됩니다.

    변환 예시

    SSD1306 OLED용 中 (16 × 16, 페이지별 열 단위, LSB 우선)

    中
    00 00 F0 10 10 10 10 FF 10 10 10 10 F0 00 00 00 00 00 0F 04 04 04 04 FF 04 04 04 04 0F 00 00 00

    32바이트입니다. 페이지 0(0~7행)의 16개 열 다음에 페이지 1(8~15행)의 16개 열이 이어집니다. 7번 열의 0xFF는 모든 비트가 1로, 세로획이 두 페이지의 8개 행을 모두 관통한다는 뜻입니다.

    같은 中을 Adafruit GFX drawBitmap용으로 (행 단위, MSB 우선)

    中
    01 00 01 00 01 00 01 00 3F F8 21 08 21 08 21 08 21 08 21 08 3F F8 21 08 01 00 01 00 01 00 01 00

    행마다 2바이트씩 16행입니다. 0x01 0x00은 가운데 세로획만 있는 행입니다. 가장 왼쪽 픽셀이 첫 바이트의 bit 7이므로 7번 열의 픽셀은 bit 0에 들어갑니다. 이 바이트를 SSD1306 페이지 쓰기에 넘기면 화면이 엉망이 됩니다. 글리프는 같아도 담는 방식이 다르기 때문입니다.

    16픽셀 폰트의 반각 A (8 × 16)

    A
    00 00 00 00 18 24 24 42 42 7E 42 42 42 42 00 00

    ASCII 문자는 반각 폭입니다. 8 × 16은 16바이트이며 행 단위로 스캔하면 한 행에 1바이트입니다. 드라이버가 모든 글리프를 16 × 16으로 가정한다면 '반각 문자(A–Z, 0–9)도 전체 셀 폭 사용'에 체크하세요.

    12 × 12가 18바이트가 아니라 24바이트인 이유

    中 (12 × 12, 행 단위, MSB 우선)
    00 00 04 00 04 00 FF E0 84 20 84 20 84 20 FF E0 04 00 04 00 04 00 04 00

    12픽셀짜리 행마다 2바이트가 필요하고, 둘째 바이트의 마지막 4비트는 패딩입니다. 12행 × 2바이트 = 24. 모든 디스플레이 라이브러리가 한 행을 (width + 7) / 8바이트로 다루므로, 비트를 더 촘촘히 담으면 모든 라이브러리에서 깨집니다.

    LCD·OLED용 폰트 데이터 생성 방법

    1. 1

      문자 입력 또는 이미지 끌어다 놓기

      텍스트는 실제 도트 폰트로 그립니다. 12 × 12(Fusion Pixel) 또는 16 × 16(GNU Unifont)이며 ASCII는 반각 폭입니다. 로고나 아이콘은 이미지 탭으로 전환해 128 × 64 같은 출력 크기를 지정합니다.

    2. 2

      대상 디스플레이·라이브러리 선택

      SSD1306 / SH1106 / ST7565 계열은 페이지 순서의 세로 바이트에 맨 위 픽셀이 bit 0입니다. Adafruit GFX, TFT_eSPI, U8g2 drawBitmap, LVGL 계열은 가로 바이트에 왼쪽 픽셀이 bit 7입니다. XBM / U8g2 drawXBM 계열은 같은 가로 바이트지만 왼쪽 픽셀이 bit 0입니다.

    3. 3

      미리보기 확인, 필요하면 픽셀 수정

      미리보기에는 실제로 인코딩되는 비트맵이 그대로 표시됩니다. 픽셀을 클릭하면 켜짐/꺼짐이 전환되고, 이동 입력란으로 글리프 위치를 조금씩 옮길 수 있습니다.

    4. 4

      복사 또는 다운로드

      C(PCtoLCD2002 C51 스타일), Arduino PROGMEM, MicroPython bytearray, A51 어셈블리, 일반 16진수 중에서 고릅니다. 출력 첫 줄에 스캔 방향, 비트 순서, 글리프 크기가 기록되므로 배열 자체가 설명서 역할을 합니다.

    글자 깨짐: 증상 → 잘못된 설정

    8픽셀마다 좌우가 반전됨

    가로 바이트의 비트 순서가 틀렸습니다. Adafruit GFX drawBitmap()은 MSB 우선, XBM과 U8g2 drawXBM()은 LSB 우선이 필요합니다.

    ✗ 오류
    U8g2 drawXBM()에 MSB 우선 바이트 전달
    ✓ 정상
    drawXBM() → XBM 프리셋 (행 단위, LSB 우선)

    8행마다 위아래가 뒤집힘

    세로 바이트의 비트 순서가 틀렸습니다. SSD1306 계열 컨트롤러는 D0을 맨 위 행에 두므로 LSB 우선이 필요합니다.

    ✗ 오류
    페이지별 열 단위, MSB 우선 → SSD1306
    ✓ 정상
    페이지별 열 단위, LSB 우선 → SSD1306

    위아래 절반이 뒤섞임

    열 단위와 페이지별 열 단위를 혼동했습니다. 두 방식은 높이 8픽셀 이하 글리프에서만 같은 바이트가 나오고, 16픽셀에서는 바이트 순서가 달라집니다.

    ✗ 오류
    열 단위 → SSD1306 페이지 쓰기
    ✓ 정상
    페이지별 열 단위 → SSD1306 페이지 쓰기

    대각선으로 뒤집히거나 색이 반전됨

    대각선으로 뒤집혔다면 가로 바이트를 세로 바이트로(또는 그 반대로) 읽은 것입니다. 켜진 배경에 어두운 글자가 보인다면 디스플레이는 켜진 픽셀 = 1을 기대하는데 켜진 픽셀 = 0을 고른 것입니다.

    ✗ 오류
    행 단위 바이트를 SSD1306 페이지로 전송
    ✓ 정상
    배열을 디코더 탭에 붙여넣고 제대로 읽히는 미리보기 선택

    이럴 때 필요합니다

    0.96인치 SSD1306 OLED에 한자 표시
    STM32나 8051 계열 보드에서 온도 값, 메뉴, 상태 표시줄을 한자로 띄울 때 씁니다. 16 × 16 폰트와 SSD1306 프리셋을 고르고, 예제 프로젝트에 이미 있는 oled_font.h에 배열을 붙여넣으세요.
    Arduino·ESP32 디스플레이의 부팅 로고
    PNG 로고를 끌어다 놓고 128 × 64로 설정한 뒤 Adafruit GFX 프리셋을 골라 display.drawBitmap(0, 0, logo, 128, 64, WHITE)를 호출합니다.
    LVGL·U8g2 UI용 아이콘과 단위 기호
    배터리, Wi-Fi, °C 기호를 1비트 이미지로 변환합니다. 가로 바이트·MSB 우선이 필요하면 Adafruit GFX / LVGL 프리셋을, U8g2 drawXBM()이라면 XBM 프리셋을 사용하세요.
    Mac이나 Linux에서 작업할 때
    PCtoLCD2002와 고전적인 字模提取 도구는 Windows 프로그램입니다. 이 도구는 최신 브라우저라면 어디서나 동작하며 설치가 필요 없습니다.
    인수받은 프로젝트 역분석
    이전 개발자가 메모 하나 없이 Hzk[][32] 배열만 남겼다면, 디코더에 붙여넣어 어떤 설정으로 생성했는지 먼저 알아낸 다음 같은 형식으로 새 글자를 추가하면 됩니다.

    네 가지 스캔 방향의 동작 원리

    행 단위 (가로 바이트)
    위쪽 행부터 차례로 읽고, 한 행 안에서는 이웃한 8개 픽셀을 왼쪽부터 한 바이트에 담습니다. 16픽셀 행은 2바이트입니다. Adafruit GFX drawBitmap(), U8g2 drawBitmap(), XBM 파일, ST7920 GDRAM, LVGL 1비트 이미지가 이 배치를 씁니다.
    페이지별 열 단위 (세로 바이트) — SSD1306 순서
    글리프를 높이 8행짜리 페이지로 나눕니다. 페이지마다 왼쪽부터 열을 읽고, 각 바이트에 그 열의 8개 픽셀을 담습니다. SSD1306, SH1106, ST7565의 GDDRAM과 같은 구조이며, 데이터시트에 데이터 비트 D0이 맨 위 행에 기록된다고 명시되어 있습니다. 따라서 맞는 비트 순서는 LSB 우선입니다.
    열 단위, 그리고 띠별 행 단위
    열 단위는 한 열을 모든 페이지에 걸쳐 위에서 아래로 읽은 뒤 오른쪽 열로 넘어가며, SSD1306의 수직 어드레싱 모드에 대응합니다. 띠별 행 단위는 폭 8픽셀짜리 띠 하나의 모든 행을 읽고 다음 띠로 넘어갑니다. 주요 라이브러리는 이 방식을 쓰지 않지만 오래된 PCtoLCD2002 프로젝트에는 남아 있습니다. 두 방식 모두 글리프 높이(또는 폭)가 8픽셀 이하일 때만 짝이 되는 방식과 결과가 같기 때문에, 8 × 8로만 테스트하면 혼동을 알아채지 못합니다.
    비트 순서와 켜진 픽셀 값
    MSB 우선은 처음 읽은 픽셀(가장 왼쪽 또는 가장 위)을 bit 7에, LSB 우선은 bit 0에 둡니다. PCtoLCD2002에서는 이를 顺向(순방향, MSB 우선)과 逆向(역방향, LSB 우선)이라고 표기합니다. 켜진 픽셀 = 1(阴码)은 OLED, TFT drawBitmap(), LVGL A1이 기대하는 값이고, 켜진 픽셀 = 0(阳码)은 0을 켜짐으로 정의하는 드라이버에서만 씁니다.
    크기가 8의 배수가 아닐 때의 패딩
    각 행(가로 바이트) 또는 각 페이지(세로 바이트)는 따로따로 바이트 경계까지 채워지며, 패딩 비트는 0입니다. 페이지별 열 단위에서 12픽셀 글리프라면 둘째 페이지에 4행 분량의 패딩이 들어갑니다. 페이지 전체를 쓰는 드라이버는 글리프 아래 4행을 지워 버립니다. 이 경우에 해당하면 도구가 경고를 표시합니다.

    한 번에 제대로 표시하는 요령

    프리셋은 화면이 아니라 그리기 함수 기준으로
    Adafruit_SSD1306으로 구동하는 SSD1306은 drawBitmap()을 거치므로, 컨트롤러 자체 메모리가 세로 방향이어도 가로 바이트·MSB 우선 데이터가 필요합니다. 코드가 호출하는 함수에 맞는 프리셋을 고르세요.
    12 px와 16 px에는 도트 폰트를
    윤곽선 폰트는 약 20 px 미만에서 이진화하면 획이 빠집니다. Fusion Pixel 12와 Unifont 16은 픽셀 격자에 맞춰 그린 폰트이고, 2배 옵션을 쓰면 24 × 24와 32 × 32도 깔끔하게 나옵니다.
    헤더 주석은 지우지 마세요
    출력 첫 줄에는 스캔 방향, 비트 순서, 크기가 기록됩니다. 여섯 달 뒤에는 그 배열을 어떻게 생성했는지 알려 주는 유일한 기록이 됩니다.
    비대칭 글자로 테스트
    中, 田, H처럼 대칭인 글리프는 반전 오류를 감춥니다. 먼저 F, 7, 乙로 시험해 보고, 제대로 읽히면 모든 옵션이 맞는 것입니다.
    화면 전체 반전은 드라이버에서 해결
    폰트뿐 아니라 화면 전체가 좌우 반전되거나 위아래가 뒤집혔다면, 초기화 시퀀스의 세그먼트 리맵(A0h/A1h)과 COM 스캔 방향(C0h/C8h)을 변경하세요. 폰트 설정을 바꾸면 다른 코드만 망가집니다.

    자주 묻는 질문

    SSD1306이나 SH1106 OLED에는 어떤 설정을 써야 하나요?
    코드가 폰트 바이트를 디스플레이에 직접 쓴다면(8051·STM32 예제 대부분) 페이지별 열 단위, LSB 우선, 켜진 픽셀 = 1, 즉 SSD1306 프리셋입니다. Adafruit_SSD1306이나 U8g2 drawBitmap()으로 그린다면 Adafruit GFX 프리셋을 쓰세요. 이 함수들은 가로 바이트·MSB 우선 데이터를 읽어 내부에서 직접 변환하기 때문입니다.
    글자가 반전되거나 뒤집히거나 뒤죽박죽으로 나옵니다. 무엇이 문제인가요?
    증상마다 원인이 되는 설정이 하나씩 있습니다. 8픽셀마다 좌우 반전: 가로 바이트의 비트 순서 오류. 8행마다 위아래 뒤집힘: 세로 바이트의 비트 순서 오류. 위아래 절반이 뒤섞임: 열 단위와 페이지별 열 단위 혼동. 대각선으로 뒤집힘: 가로 바이트와 세로 바이트 혼동. 색 반전: 켜진 픽셀 = 1과 = 0이 바뀜. 글자뿐 아니라 화면 전체가 반전되었다면 드라이버의 초기화 시퀀스를 고치세요.
    12 × 12가 18바이트가 아니라 24바이트인 이유는 무엇인가요?
    각 행(또는 8행짜리 각 페이지)이 따로따로 바이트 경계까지 채워지기 때문입니다. 12픽셀에는 2바이트가 필요하고 12행 × 2 = 24입니다. 디스플레이 라이브러리는 한 행을 (width + 7) / 8바이트로 다루므로, 18바이트로 촘촘히 담은 글리프는 어떤 라이브러리에서도 잘못 읽힙니다.
    12픽셀 텍스트를 그리면 OLED에서 아래 줄이 지워지는 이유는 무엇인가요?
    페이지별 열 단위에서는 12픽셀 글리프가 한 페이지 전체와 다음 페이지의 절반을 차지하고, 둘째 페이지의 나머지 4비트는 0으로 채운 패딩입니다. 페이지 전체를 쓰는 드라이버는 그 4행을 지웁니다. 픽셀을 하나씩 설정하는 프레임 버퍼를 거쳐 그리거나, 빈 행이 다른 내용과 겹치지 않는 위치에 12픽셀 텍스트를 배치하세요.
    Mac에서 PCtoLCD2002 대신 쓸 수 있나요?
    예. 최신 브라우저라면 어디서나 동작하고, 같은 네 가지 스캔 방식과 두 가지 비트 순서, 켜진 픽셀 = 1 / = 0을 지원합니다. C 출력은 /*"字",0*/ 주석이 붙은 PCtoLCD2002 C51 스타일을 따르므로 Hzk[][32] 형태 배열을 쓰는 프로젝트에 그대로 붙여넣을 수 있습니다. 다만 폰트 라이브러리 파일 전체나 인덱스는 생성하지 않습니다. 글리프 모양은 Windows의 SimSun(송체)이 아니라 GNU Unifont와 Fusion Pixel에서 가져오므로, PCtoLCD2002로 만든 배열과 바이트 단위로 일치하지 않습니다. 둘을 섞지 말고 표 전체를 여기서 다시 생성하세요. 이 사이트는 PCtoLCD2002나 그 제작자와 관련이 없으며, 공식 웹 버전이 아니고 프로그램 다운로드도 제공하지 않습니다.
    시스템 폰트 대신 도트 폰트를 쓰는 이유는 무엇인가요?
    시스템 폰트는 안티에일리어싱으로 그리는 윤곽선 폰트이고, 브라우저에서는 안티에일리어싱을 끌 수 없습니다. 12픽셀이나 16픽셀에서 그 회색 가장자리를 이진화하면 가는 획이 사라집니다. 12픽셀 송체(명조 계열)에서는 中의 가로획이 통째로 없어질 정도입니다. GNU Unifont(16 px)와 Fusion Pixel(12 px)은 픽셀 격자에 맞춰 디자인되어 잃는 획이 없습니다. 더 큰 크기에서는 시스템 폰트도 쓸 수 있습니다. 흑체(고딕 계열)는 약 24 px부터 무난하지만, 송체는 그 크기에서도 획이 빠질 수 있습니다.
    도트 폰트는 어떤 문자를 지원하나요?
    GB2312 전체(간체 한자 6,763자와 전각 문장 부호), 출력 가능한 ASCII, 악센트가 붙은 라틴 문자(é, ß, ł, ş, ő), 그리스 문자, 키릴 문자, 일본어 가나, 그리고 ℃·화살표·괘선 같은 자주 쓰는 기호입니다. Fusion Pixel 12 px에는 일부 드문 문자와 기호가 빠져 있습니다. 한글 음절은 도트 폰트에 포함되어 있지 않습니다. 한글과 GB2312 밖의 한자(번체자, 일본식 한자 다수)는 대신 시스템 폰트로 근사해서 그리고 미리보기 아래에 목록으로 표시하므로, 어떤 글리프를 확인해야 하는지 알 수 있습니다. 시스템 폰트는 약 20 px 미만에서 획이 끊기거나 뭉칠 수 있으니, 한글을 넣을 때는 미리보기에서 픽셀을 꼭 확인하세요.
    로고나 아이콘을 C 배열로 변환하려면 어떻게 하나요?
    이미지 탭을 열어 파일을 끌어다 놓고 디스플레이 크기(0.96인치 OLED라면 128 × 64)를 지정한 뒤 '영역 안에 맞춤(비율 유지)'을 그대로 둡니다. 어두운 픽셀이 켜진 픽셀이 됩니다. 어두운 배경에 밝은 그림이라면 반전에 체크하세요. 로고와 글자는 디더링 없이, 사진은 Floyd–Steinberg나 Atkinson을 사용합니다.
    기존 폰트 배열이 어떻게 생성되었는지 알아내려면 어떻게 하나요?
    '기존 배열 미리보기' 탭에 붙여넣으세요. 주석은 무시되며 C, Arduino, A51, MicroPython 문법을 모두 받아들입니다. 바이트 수로 글리프 크기를 추정하고 스캔 방향과 비트 순서의 8가지 조합을 모두 그립니다. 제대로 읽히는 것이 바로 그 설정이며, '이 설정 사용'을 누르면 생성기에 적용됩니다.
    입력한 텍스트나 이미지가 업로드되나요?
    아닙니다. 글리프 렌더링과 인코딩은 브라우저 안에서 이루어집니다. 도트 폰트는 이 사이트에서 한 번 내려받을 뿐이며, 입력하거나 끌어다 놓은 내용은 어디로도 전송되지 않습니다.