DEV Community: Hisa Araki

GS1 Sunrise 2027 Might Not Fit Your Thermal Printer

Hisa Araki — Thu, 05 Nov 2026 10:42:19 +0000

GS1 Sunrise 2027 is the industry's push to get retail POS systems scanning 2D barcodes (GS1 QR Code / GS1 DataMatrix) by the end of 2027. It's not a mandate, but the upside is real: a single 2D symbol can carry a GTIN plus attribute data like lot number and expiry date, instead of a bare 1D barcode that can't.

During the transition, though, the 2D symbol has to be dual-marked alongside the existing 1D barcode (EAN-13/UPC). And if your printer is a common 203 dpi thermal printer, that requirement runs into a wall faster than you'd expect.

The 203 dpi printer can't quite hit the minimum 2D size

GS1's General Specifications set the minimum X-dimension for a 2D symbol at retail POS at 0.396 mm. A 203 dpi printer can only print in whole dots (1 dot = 0.125 mm):

Dots	Size
3 dots	0.375 mm
4 dots	0.500 mm

3 dots (0.375 mm) falls just short of the 0.396 mm minimum, so 4 dots becomes the effective minimum. Meanwhile the 1D barcode (EAN-13) is locked to 3 dots (0.375 mm, 113.7% magnification) — it can't be scaled down further without going out of spec.

That small shortfall has an outsized effect on label size.

Side by side, it doesn't fit on a 50 mm label

GS1's placement guideline also has a "50 mm rule": the 2D symbol has to sit within 50 mm of the center of the linear barcode. That part's achievable at 4 dots. The real problem is label area.

At 203 dpi / 4 dots:

EAN-13 + GS1 QR (V4): side by side, 62.9 × 29.5 mm
EAN-13 + GS1 DataMatrix (20×20): side by side, 53.4 × 29.5 mm

Common 50 mm-wide retail labels simply can't fit either combination side by side — even the smallest DataMatrix (GTIN only, 16×16) comes out to 51.4 mm. Stack them vertically instead, and the width problem goes away, but now you need 40–50 mm of height, which eats almost all the space left for product name, price, and expiry text.

Verification testing hasn't covered 203 dpi

GS1 Japan published read-performance verification results in October 2025 — but the printers tested were 300/305/360 dpi only. The printer resolution that's actually dominant on the ground in Japan was never tested.

We wrote up the math as a technical note

We dug into this quantitatively and published a technical note:

Short version of the conclusions:

203 dpi + GS1 DataMatrix is the realistic option for the Japanese market: side-by-side placement is physically impossible, but a stacked layout satisfies both the 50 mm rule and a 50 mm-wide label — on labels of 50×40 mm or smaller, though, the codes alone nearly fill the label.
Whether rectangular DataMatrix (e.g. 12×36) is an acceptable retail-POS format is the deciding factor for small labels.
Moving to 300 dpi resolves the compliance issue, but side-by-side placement with QR is still difficult even then.

We've rolled seven open questions from this (how the 203 dpi minimum should be treated, whether 203 dpi gets included in verification testing, how the 50 mm rule is formally measured, etc.) into inquiries to both GS1 Japan and GS1 Global Office.

We're also building a library for this

In parallel, we're building BarBridge, a Rust core that generates GS1-compliant 1D/2D barcode pairs, automatically computing the largest compliant print size that still fits a given footprint — callable from Python, C/C++, C#, VB.NET, Java, PHP, and Node.js over a C ABI.

If you're dealing with 203 dpi label design, or have run into the same constraint, I'd like to hear about it — comments and corrections welcome.

BarBridge: a Rust core for GS1 Sunrise 2027 barcode pairs, callable from 7 languages over a C ABI

Hisa Araki — Sun, 01 Nov 2026 14:00:41 +0000

TL;DR

I built and published BarBridge, a language-independent Rust core that generates GS1-compliant 1D+2D barcode pairs for the upcoming GS1 Sunrise 2027 transition. The core exposes a minimal C ABI, and today I finished publishing ready-to-run samples in 7 languages across 6 platform targets (Windows/macOS/Linux × x64/ARM64), plus a dual MIT/Apache-2.0 license.

Repo: https://github.com/acrossreport/barbridge

The problem: GS1 Sunrise 2027

In 2027, GS1 is moving retail POS barcode practice away from 1D-only symbols (EAN/UPC, etc.) toward pairing them with 2D symbols (GS1 QR Code / GS1 DataMatrix). The 2D symbol can carry attribute data — lot number, expiration date — alongside the GTIN, which is great for traceability. But during the transition, retailers and manufacturers need to print both symbol types together, correctly sized and laid out.

That means, for every label:

Keep the barcode's X-dimension (module width) inside GS1's allowed range
Compute the largest GS1-compliant size that still fits a target footprint (e.g. 50mm × 50mm)
Arrange the 1D and 2D symbols together (side-by-side or stacked) for the same GTIN

Reimplementing that math per printer vendor or per language is exactly the kind of thing that quietly drifts out of spec over time. So I pulled it into a single core.

From an ACR feature to a standalone library

BarBridge didn't start as its own project. The first version of this GS1 pairing logic was built as an optional feature inside ACR, our receipt/label rendering engine, specifically to get ahead of GS1 Sunrise 2027 support there. But the moment I got it working, it was obvious the same logic — GS1 size optimization, 1D+2D layout, pairing — had nothing ACR-specific about it. Any POS, ERP, or label-printing tool facing the same 2027 transition would need the exact same math. So instead of keeping it locked inside ACR, I pulled it out and rebuilt it as BarBridge, a standalone Rust core with its own C ABI, so it could be adopted independently of whatever rendering stack a given tool already uses.

Architecture: one Rust core, one C ABI boundary

request_json (string)
      │
      ▼
barbridge_render_png()   ← Rust core: GS1 size optimization + layout + rendering
      │
      ▼
PNG bytes (caller-owned buffer)

The exposed surface is intentionally small:

Function	Description
`barbridge_render_png(request_json, &out_data, &out_len)`	Renders a GS1 1D+2D pair (or a single symbol) to PNG bytes in memory
`barbridge_bytes_free(data, len)`	Frees the returned buffer (always call it)
`barbridge_last_error()`	Human-readable reason for the last failure

Request example:

{
  "data": "(01)04901234567894(10)LOT42(17)271231",
  "mode": "pair",
  "matrix": "data_matrix",
  "arrangement": "auto",
  "max_width_mm": 50,
  "max_height_mm": 50,
  "dpi": 600
}

data accepts either a GS1 AI element string ((01)GTIN(10)LOT…) or a bare GTIN-8/12/13/14. mode is pair (default), linear (1D only), or matrix (2D only).

Everything happens in memory — no temp files, no subprocess, no external CLI tool. The caller's process owns the output buffer, so there's no process-spawn overhead when embedding this in a server or batch pipeline. A WebAssembly build for the browser is planned too.

Today's work: samples for 7 languages × 6 platforms

The bulk of today's push was finishing a consistent sample set so anyone can see exactly how to call the library from their stack of choice, without reading the core source:

barbridge/
├── barbridge.h             # C ABI header (C/C++, cgo, ...)
├── windows-x64/
├── windows-arm64/
├── linux-x64/
├── linux-arm64/
├── macos-arm64/
└── macos-x64/
    ├── native/              barbridge.dll / libbarbridge.so / libbarbridge.dylib
    ├── common/request.json  # shared sample GS1 data
    ├── c/
    ├── python/              ctypes, standard library only
    ├── csharp/              P/Invoke, `dotnet run`
    ├── vb/                  P/Invoke, `dotnet run`
    ├── java/                JNA, `mvn package`
    ├── php/                 built-in FFI extension (PHP 7.4+)
    └── nodejs/              koffi (prebuilt binary, no build toolchain)

Language	Binding	Run
Python	`ctypes` (stdlib only)	`python render_sample.py`
C / C++	link against `barbridge.dll.lib` / `.so` / `.dylib`	see header comment in `render_sample.c`
C#	P/Invoke	`dotnet run`
VB.NET	P/Invoke	`dotnet run`
Java	JNA	`mvn package && java -jar target/barbridge-sample-jar-with-dependencies.jar`
PHP	built-in `FFI` extension	`php render_sample.php`
Node.js	`koffi`	`npm install && node render_sample.js`

Every sample follows the same four steps: read ../common/request.json, call barbridge_render_png, write output.png, free the buffer. Seeing the FFI boilerplate side-by-side across ctypes/P-Invoke/JNA/koffi/PHP-FFI was honestly useful just for my own sanity-checking of the C ABI design — if one binding felt awkward, that was a signal the header needed adjusting, not the sample.

If you keep the library elsewhere, BARBRIDGE_NATIVE_LIB lets you point at it instead of relying on the relative path.

I also added a dual MIT OR Apache-2.0 license and cleaned up a stale "macOS build planned" note that had been sitting in both README files since the initial concept push.

What's next

GS1-128 and GS1 DataBar support for logistics/case labels
A WebAssembly sample for the browser
Deciding how much of the core implementation itself to open up

Repo: https://github.com/acrossreport/barbridge — issues and feedback welcome, especially from anyone already dealing with Sunrise 2027 compliance on the printing side.

Migrating Off ActiveReports to the Web and Linux While Keeping Your Existing Assets

Hisa Araki — Mon, 19 Oct 2026 20:07:07 +0000

Background: three pain points of ActiveReports estates

Plenty of .NET Framework-era business systems still rely on ActiveReports (GrapeCity / MESCIUS) for report output. After years of running in production, these setups tend to accumulate the same three frustrations:

License renewal costs keep growing — server and runtime license renewal fees no longer feel proportionate to the value the reporting feature alone provides
Locked into Windows / .NET Framework — ActiveReports itself, and the web app hosting it, assume .NET Framework, blocking a move to Linux containers or a cloud-native setup
Dozens or hundreds of designer assets (report layouts) already exist — rebuilding them all from scratch isn't realistic; "keep the existing assets" is a hard requirement

When all three show up together, neither "full replacement" nor "do nothing" is an easy choice, and projects tend to stall.

The migration approach: aim for "semantic compatibility," not "replacement"

Reading ActiveReports layout files (.rdlx etc.) with full binary compatibility isn't realistic — guaranteeing exact format fidelity is too costly.

Instead, ACR (Across Report), which I develop, takes the approach of reproducing ActiveReports' concepts and behavior at the JSON template level. Concretely, this means baking in the following compatibility at the implementation level:

Section structure compatibility

ACR inherits ActiveReports' Detail / PageHeader / PageFooter section concepts directly, including per-section controls like NewPage AFTER (force a page break after a section outputs), reproduced with the same meaning.

// acr_core/src/layout/engine.rs
// ② ActiveReports-compatible: NewPage AFTER
if sec.new_page_after {
    ...
}

Date format and font specification compatibility

Format tokens from .NET, like yyyy/MM/dd and HH:mm:ss, are interpreted as-is, so existing template format strings can effectively be ported unchanged. Font resolution also follows ActiveReports' own priority order between the Font / FontName fields and a CSS-style Style.font-family.

Barcode type compatibility

ActiveReports' own barcode type codes (e.g., the legacy code 18) are mapped onto current types like Code128B, absorbing the difference so data-side changes stay minimal.

None of this aims for pixel-perfect, zero-deviation reproduction. The goal is letting you carry over existing report definitions, data, and operational know-how without a rewrite.

Why Linux becomes possible

ACR is a native renderer implemented in Rust + Google Skia, with no dependency on .NET Framework or the Windows API.

The rendering engine itself (acr_core / acr_renderer_skia) builds as the same binary structure on Windows, macOS, and Linux
On Linux, installing Japanese fonts (VL Gothic, etc.) is as simple as apt install fonts-vlgothic, producing output identical to Windows
Existing .NET / C# assets can call in via FFI (axr_layout.dll / libaxr_layout.so), so you don't need to rewrite the calling code all at once

// FFI interface (shared between axr_layout.dll and libaxr_layout.so)
char* render_html(const char* template_json, const char* data_json);
void free_string(char* ptr);

In other words, this isn't "throw away the C# app" — it's "swap out just the report-rendering layer for a lightweight Rust/Skia engine, while the calling side keeps using it via FFI, unchanged." Since the same FFI interface works on both Windows and Linux, once you eventually move the main web app into a Linux container, the report portion can be validated and switched over ahead of time, independently.

A typical migration path

Inventory: enumerate existing ActiveReports templates. Check section structure, barcode types, and any special formatting (installment pricing, ruby annotations, vertical text, etc.)
Convert to JSON templates: starting with the highest-priority reports, convert ActiveReports definitions into ACR's JSON template format (usually a fairly mechanical section-by-section, field-by-field conversion)
Validate with parallel operation: run the same data through both the existing ActiveReports output and the new ACR output, then compare visually via the WYSIWYG preview and/or automated diffing
Swap the calling side: on the C# side, this is just a switch to the FFI call — the web frontend and business logic stay untouched
Move to Linux: once a report has been validated, move its rendering piece into a Linux container

Summary

Migrating off ActiveReports doesn't have to be an all-or-nothing choice between a full rewrite and doing nothing
By moving to an engine that semantically inherits ActiveReports' behavior — section structure, date formats, barcode types — you can migrate while keeping your template assets intact
Because only the rendering layer needs to be swapped via FFI, moving from Windows to Linux can happen incrementally too

Note / consultation: I offer consulting on migrating existing report systems (e.g., moving off ActiveReports) using ACR (Across Report), as well as reducing server costs by moving off Puppeteer-based setups.
If you're dealing with rising license renewal costs, or want to port your system cheaply to Linux / cloud environments, feel free to reach out via Across Systems contact.

Building a Blazing-Fast Report PDF Environment on Docker/Linux, Callable from C# and Node.js

Hisa Araki — Mon, 19 Oct 2026 20:06:42 +0000

The goal

Carving out just the report-PDF-generation component into a Linux container, callable from existing C# or Node.js applications, is an increasingly common need — usually driven by wanting to cut Windows server licensing/ops costs, or to autoscale on Kubernetes.

This article walks through that setup using ACR (Across Report), a Rust-based report engine I develop: running a native renderer in a Docker + Linux environment and calling it from existing C# / Node.js code with minimal changes. The key idea is to ship neither a browser engine nor a .NET runtime in the container — just a single native binary.

Overall architecture

┌─────────────────────────┐
│   C# app  /  Node.js app │
└───────────┬─────────────┘
            │ FFI (axr_layout.so)  /  N-API (acr_node_native.so)
┌───────────▼─────────────┐
│    Docker container (Linux) │
│  ├ acr_core              │ ← JSON template → RenderCommand
│  ├ acr_renderer_skia     │ ← RenderCommand → PDF/PNG (Skia)
│  └ fonts-vlgothic        │ ← Japanese fonts
└─────────────────────────┘

What you bundle into the container depends slightly on the calling language:

From C#: call libaxr_layout.so via P/Invoke (the same FFI interface as Windows' axr_layout.dll)
From Node.js: require the acr_node_native native addon (built with napi-rs) directly

Either path ultimately generates the PDF/PNG through the same underlying Rust binary.

Build details that matter

1. Building the Rust core

cargo build --release

This builds every crate, including acr_core / acr_renderer_skia, for Linux. None of the Windows-ARM64-specific workarounds apply here — skia-safe's prebuilt binaries just work on Linux x86_64.

2. Calling from Node.js (napi-rs)

The Node.js-facing native addon lives in the acr_node_native crate. It's a cdylib built with N-API (napi / napi-derive), exposing functions you can call directly from JS:

// index.d.ts (excerpt)
export function renderPdf(templateJson: string, dataJson: string, outputPath: string): number
export function renderPreview(templateJson: string, dataJson: string): Array<PageImage>

To build it:

cd acr_node_native
npm install
npx napi build --platform --release

If your workspace customizes target-dir (e.g., via .cargo/config.toml), napi build's post-processing step can fail to locate the .node file. In that case, fall back to:

cargo build --release -p acr_node_native
# then manually copy/rename the built .so to index.<platform-triple>.node / index.node

Baking this manual copy step directly into your Dockerfile's multi-stage build avoids this trap.

3. Example Dockerfile (Node.js consumer)

# ---- build stage ----
FROM rust:1.78-bookworm AS builder
WORKDIR /app
COPY . .
RUN cargo build --release -p acr_node_native

# ---- runtime stage ----
FROM node:20-bookworm-slim
RUN apt-get update && apt-get install -y --no-install-recommends \
        fonts-vlgothic \
    && rm -rf /var/lib/apt/lists/*

WORKDIR /app
COPY --from=builder /app/target/release/libacr_node_native.so ./index.node
COPY acr_node_native/index.js acr_node_native/index.d.ts ./
COPY acr_node_native/package.json ./

# COPY your app code here, and call it via require('./index.node')

Two things matter here:

Separate the build stage from the runtime stage so the final image doesn't carry the Rust toolchain, keeping it lean
Only install Japanese fonts in the runtime stage (apt install fonts-vlgothic) — the build stage doesn't need them

4. Calling from C

If your C# app is already on .NET (Core) and cross-platform-ready, referencing libaxr_layout.so via P/Invoke just works on Linux, with the exact same calling code as on Windows.

char* render_html(const char* template_json, const char* data_json);
void free_string(char* ptr);

If you're still on .NET Framework, migrating to .NET (Core) / .NET 8+ is a prerequisite — but since the report-rendering call interface is identical to the Windows version, you can "Linux-ify and validate the report engine first, and tackle the rest of the app's .NET migration separately, later."

Why this setup ends up lighter

Compared to Chrome-based PDF generation (Puppeteer, etc.), this architecture wins on a few fronts:

No need to ship a full Chromium install (hundreds of MB) in the runtime image
No "renderer process" concept means none of the process-management/memory-monitoring complexity that scales with page count
A single self-contained Rust binary means faster container startup and shorter cold starts under autoscaling

Summary

Carving out just report-PDF generation into a Linux container, callable natively from C# or Node.js, is achievable via a multi-stage build plus bundling Japanese fonts only in the runtime stage
With two call paths available — a napi-rs addon for Node.js, and a shared .so/.dll FFI interface for C# — the same engine can serve callers regardless of language
Not depending on a browser engine gives you an edge on both image size and startup speed

Fixing Out-of-Memory Errors in Puppeteer PDF Generation

Hisa Araki — Mon, 19 Oct 2026 20:06:02 +0000

What this is about

Many teams generate invoices, delivery slips, and other business documents as PDFs from a web system using Puppeteer (Headless Chrome). It's an easy way to lay out documents in HTML/CSS, but once you scale up, you tend to hit a wall:

Memory balloons and the process gets OOM-killed once page counts reach the hundreds or thousands
Docker container memory limits (512MB–1GB) get hit almost immediately
Per-page generation time stays reasonable, but total time degrades worse than linearly

This article first breaks down the structural reasons Puppeteer runs into OOM, then introduces an alternative: skipping the browser engine entirely. I'll walk through a real example from ACR (Across Report), a report engine I develop in Rust.

Why Puppeteer runs out of memory

When generating PDFs for large numbers of pages with Puppeteer / Headless Chrome, memory bloat usually comes down to three causes.

1. The renderer process heap isn't designed for reuse

A Chrome renderer process is fundamentally designed around "open a page, then close it." If you keep calling page.pdf() repeatedly on the same page object for hundreds of report pages in a row, the V8 heap and DOM tree caches accumulate without being released. Get the timing of page.close() / browser.close() wrong, and zombie Chrome processes linger around your Node.js process too.

2. Fonts and images get reloaded per page

In HTML/CSS-based rendering, a Japanese font specified via @font-face (especially one that isn't subsetted) can get re-parsed on every page transition. If the same font gets re-expanded for every single report page, both memory usage and rendering time degrade proportionally to page count.

3. The `page.pdf()` output buffer accumulates in-process

When combining many pages into a single PDF, if the implementation holds each page's PDF byte sequence in memory before concatenating, the final PDF size translates directly into the Node.js process's memory footprint.

Mitigations (if you stick with Puppeteer)

Restart the browser every N pages and treat the process as disposable
Reference OS-installed fonts via font-family directly instead of embedding Base64 fonts
Isolate generation into worker processes so an OOM doesn't take down the main process (tune --max-old-space-size alongside this)
Give Docker memory limits enough headroom for Chrome's peak memory (typically 3–5x normal usage)

These are workarounds, though — they don't address the root cause, which is repurposing a browser engine for report rendering in the first place. If your report volume and page counts are only going to grow, it's worth considering a different architecture.

An alternative: a report renderer that skips the browser

ACR (Across Report), which I develop, converts a JSON template into an intermediate rendering model (RenderCommand) instead of HTML/CSS, and renders PDF/PNG directly via Google Skia. Written in Rust, it bypasses Chrome entirely, which means:

There's no concept of a "renderer process," so the V8-heap-accumulation problem simply doesn't exist
Fonts are loaded once at process startup and cached; everything after that is a reference
The generated PDF is written page-by-page as a stream, so final file size doesn't directly map to process memory

That said, "not using a browser" doesn't automatically mean "safe" — the same class of bug can creep in depending on the implementation. Here's a real case I ran into.

Case study: rebuilding a font "per page" caused the same kind of bloat

ACR's watermark drawing routine, draw_watermark(), originally resolved a fresh Typeface via FontMgr::new() on every page. This is structurally the exact same problem as Puppeteer's font re-parsing issue.

The result: the PDF output library (Skia's SkPDF) ended up embedding a separate font subset per page instead of sharing one. On a 1,394-page sample report, this produced:

	Before fix	After fix
PDF size	~300MB	~10.3MB
Generation time	~28s	~2.5s

The fix was simple: build the font once outside the page loop, and pass a reference into draw_watermark() instead of rebuilding it (applying the same pattern already used for font_cache).

What this case illustrates is a general principle: in any code generating large numbers of report pages, be suspicious of "whatever we're doing for every single page." Whether in Puppeteer or ACR, most OOM and bloat issues trace back to this pattern — initialization that should happen once, but is instead repeated inside the loop.

Summary

Heavy or crashing PDF generation for large page counts with Puppeteer is, to some degree, a structural consequence of how Chrome's renderer process works
Workarounds (browser restarts, worker isolation, memory limit tuning) can get you by, but only up to a point
If you want to fix it at the root, a native renderer that bypasses the browser engine is one option
Even native implementations can fall into the same trap of redundant per-page initialization, though, so the profiling mindset doesn't change

Rendering PDF/PNG reports in Node.js without Chromium or a subprocess (napi-rs)

Hisa Araki — Sat, 17 Oct 2026 09:45:16 +0000

Most Node.js apps that need to generate PDF reports — invoices, receipts, delivery
slips — end up picking one of two approaches:

Launch headless Chromium (Puppeteer) and print an HTML page to PDF.
Shell out to a separate CLI tool and parse its output.

Both work. Both also come with overhead that has nothing to do with your actual
report: Chromium's startup cost and memory footprint, or a child process's spawn
latency and fragile stdout/stderr error handling.

We just released @acrossreport/acr-node,
a native Node.js/Electron binding that renders PDF/PNG reports in-process, with no
Chromium and no subprocess involved.

What it's built on

ACR (Across Report) is a JSON-template-based report
rendering engine written in Rust on top of Google Skia. It already powered a CLI tool,
a VS Code extension, and a desktop designer app — the same renderer, same pixel output,
across all of them. acr-node is a thin napi-rs binding that exposes
that same Rust core directly to Node.js as a native addon.

Template (JSON) → layout engine → Skia renderer → PDF / PNG

Same template produces byte-identical pixels on Windows/macOS/Linux (true WYSIWYG).
Preview and print output match exactly — no Chromium print-to-PDF layout drift.
A section-based layout model (PageHeader/GroupHeader/Detail/GroupFooter/PageFooter) familiar to anyone who's used traditional report designers (Crystal Reports, ActiveReports, etc.).

Why napi-rs over a CLI wrapper

We considered two designs:

A — shell out to the existing CLI tool. Simplest to build, but:

Process-spawn overhead adds up fast on a server generating many reports.
Error handling over stdout/stderr is brittle.
Binary placement and permissions differ per OS.

B — native addon via napi-rs. Calls the existing Rust core (acr_core /
acr_renderer_skia) directly through FFI, no process boundary, and napi-rs has solid
prior art for both Node.js and Electron with a mature prebuilt-binary distribution
story. Since the Rust engine already existed, there was no good reason to introduce a
process boundary — we went with B.

We'd already built a similar napi-rs binding for a VS Code extension
(acr_vscode_native), so this followed an established pattern rather than starting
from zero.

Implementation notes

The binding itself doesn't touch the existing Rust rendering logic at all — it's a thin
#[napi]-annotated wrapper around functions that already existed. Two details worth
calling out:

Panic handling. If Rust code panics across the napi-rs boundary, it takes the whole Node.js process down with it. A malformed template JSON is a user error, not a reason to crash the host app, so every exported function is wrapped in catch_unwind.
Licensing. Unlicensed rendering adds a watermark to the output (same policy as the CLI/Designer/Viewer tools). The activation cache file uses the same format across all ACR products, so if a license is already activated on the machine by any of them, acr-node picks it up automatically — no duplicate activation needed.

Cross-platform builds

napi-rs follows an index.<platform-triple>.node naming convention and generates a
loader (index.js) that requires the right binary for the current OS/arch:

switch (platform) {
  case "win32":
    switch (arch) {
      case "x64":
        nativeBinding = require("./index.win32-x64-msvc.node");
        break;
      case "arm64":
        nativeBinding = require("./index.win32-arm64-msvc.node");
        break;
    }
    break;
  case "linux":
    // glibc/musl, x64/arm64 ...
  case "darwin":
    // x64/arm64 ...
}

We built and bundled binaries for six platform/arch combinations on real hardware
(Windows x64, Windows ARM64, Intel Mac, Apple Silicon Mac, Ubuntu x64, Ubuntu ARM64 on
WSL2):

Platform	Status
Windows x64	Available
Windows ARM64	Available
Linux x64 (glibc)	Available
Linux ARM64 (glibc)	Available
macOS (Apple Silicon)	Available
macOS (Intel)	Available

Cross-building in CI isn't set up yet — this round was built machine-by-machine with
cargo build --release. Automating that is next on the list.

Usage

npm install @acrossreport/acr-node

import {
  renderPdf,
  renderPreview,
  renderPngZip,
  listDataFields,
  activate,
  licenseStatus,
} from "@acrossreport/acr-node";
import { readFileSync } from "node:fs";

const templateJson = readFileSync("invoice.template.json", "utf8");
const dataJson = readFileSync("invoice.data.json", "utf8");

// PDF output (72dpi). Returns the page count.
const pageCount = renderPdf(templateJson, dataJson, "invoice.pdf");

// PNG-per-page array for on-screen preview (96dpi)
const pages = renderPreview(templateJson, dataJson);
// pages[0].png is a Buffer

// Activate a license key (blocking HTTP request — call from a worker in Electron)
await activate("you@example.com", "ACR-XXXX-XXXX-XXXX-XXXX");

Same API whether you're calling it from a bare Node server (Express, Next.js API
routes) or an Electron main process.

Summary

PDF/PNG report rendering in Node.js/Electron, wired directly into a Rust/Skia engine via napi-rs — no Chromium, no subprocess.
The existing Rust rendering logic (acr_core / acr_renderer_skia) is untouched; only a thin binding layer was added.
Licensing is shared with the existing CLI/Designer/Viewer tools, so one activation per machine covers all of them.
Prebuilt binaries for six platforms ship in the package — no build toolchain required on the consumer side.

Repo: https://github.com/acrossreport/acr-node
npm: https://www.npmjs.com/package/@acrossreport/acr-node

Happy to answer questions about the napi-rs setup, the panic-safety boundary, or the
Skia rendering pipeline in the comments.

ACR is designed as a printer-independent report rendering service, not just a library.

Hisa Araki — Sun, 12 Apr 2026 14:32:27 +0000

Introduction

I have added an HTTP interface to the report engine ACR (Across Report Renderer).

By making ACR available over HTTP, it can be used as a rendering service independent from the application.

Previously, report systems had to be implemented separately depending on the development environment (Desktop, Web), OS, and runtime environment.
With ACR, you can now generate PDF / PNG / HTML simply by sending a template and data.

What you can do

• Generate reports via HTTP
• Language-independent (HTTP-based)
• Can be called from Node.js / C# / Python / Java
• Output formats: PDF / PNG / HTML (PNG embedded in HTML)
• Test directly from a browser (Web UI included)
• Runs on Windows / Linux / macOS
• Can run as a service (daemon) on all supported OS

⸻

Start

./acr_http

You can also specify port and template directory:

./acr_http --port 9000 --templates /opt/acr/templates

Web UI

Open the following in your browser:

http://localhost:8765/

curl（PDF）

curl -X POST http://localhost:8765/render/pdf \
  -H "Content-Type: application/json" \
  -d '{
    "template": "invoice",
    "data": {
      "items": [
        { "name": "Apple", "price": 100 },
        { "name": "Orange", "price": 200 }
      ]
    }
  }' \
  --output out.pdf

curl（PNG）

curl -X POST http://localhost:8765/render/png \
  -H "Content-Type: application/json" \
  -d '{ "template": "invoice", "data": { "items": [] } }' \
  --output out.png

curl (HTML)

curl -X POST http://localhost:8765/render/html \
  -H "Content-Type: application/json" \
  -d '{ "template": "invoice", "data": { "items": [] } }'

Running as a service

Windows

acr_http.exe --install
sc start AcrHttpServer

Linux (systemd)

systemctl enable acr_http
systemctl start  acr_http

macOS

launchctl load ~/Library/LaunchAgents/com.acrossreport.acr_http.plist

Architecture

• Rust-based engine
• Rendering with Skia
• Runs as an HTTP server
• Template and data are separated

⸻

Summary

The HTTP version is already released for evaluation.
• Command-line renderer: acr-cli
• Report designer: acr-designer
• RPX converter for ActiveReports: rpx2json
⸻

Roadmap

The following features are planned:
• WebAssembly (WASM) support for browser execution
• Receipt printer support (ESC/POS)
• Support for printer command languages (ZPL / SBPL / TPCL)

This will extend ACR beyond server-side usage to embedded devices, edge environments, and browsers.

Download

https://github.com/acrossreport

I built a pixel-perfect, printer-independent report designer with Avalonia UI

Hisa Araki — Sun, 12 Apr 2026 06:09:25 +0000

I’ve released ACR Designer, a WYSIWYG report designer for the ACR (Across Report Renderer) engine.

It focuses on pixel-perfect layout and printer-independent rendering.

Key features:

WYSIWYG report designer
Pixel-perfect layout (dot-level accuracy)
Printer-independent rendering
Built with C# and Avalonia UI
Runs natively on Windows and macOS

GitHub:
https://github.com/acrossreport/acr-designer

This is my first time building a full cross-platform desktop application with Avalonia, and I was impressed by how smoothly it works across platforms.

Feedback is welcome.

Personal Note

I’ve also released the macOS version of ACR Designer.

At 66, this project has been an incredibly valuable learning experience for me.

I truly appreciate all the support, and I’ll keep improving it whenever I can.

I built a pixel-perfect, printer-independent report designer with Avalonia UI

Hisa Araki — Sun, 12 Apr 2026 04:17:00 +0000

I’ve released ACR Designer, a WYSIWYG report designer for the ACR (Across Report Renderer) engine.

It focuses on pixel-perfect layout and printer-independent rendering.

Key features:

WYSIWYG report designer
Pixel-perfect layout (dot-level accuracy)
Printer-independent rendering
Built with C# and Avalonia UI
Runs natively on Windows and macOS

GitHub:
https://github.com/acrossreport/acr-designer

This is my first time building a full cross-platform desktop application with Avalonia, and I was impressed by how smoothly it works across platforms.

Feedback is welcome.

Why I built a pixel-perfect report engine with Rust and Skia

Hisa Araki — Fri, 10 Apr 2026 02:23:19 +0000

Introduction

For many years, I have been working on business systems where report generation is a critical component.

However, I repeatedly encountered the same problems:

Layout differences depending on printer drivers
OS-specific rendering inconsistencies
Difficulty achieving true WYSIWYG output

These issues are not new, but they are still not fully solved.

The Problem

In traditional report systems, rendering often depends on external components such as printer drivers or OS-level graphics APIs.

This leads to:

Slight layout shifts
Inconsistent text measurement
Different output between environments

For business reports, even small differences can be unacceptable.

The Approach

To solve this, I designed a report engine with the following principles:

Fully deterministic layout
Pixel-perfect rendering
No dependency on printer drivers
Cross-platform consistency

The engine directly controls rendering using Skia.

Why Rust

I chose Rust for:

Memory safety
Predictable performance
Strong control over low-level behavior

This is important for a rendering engine where consistency is critical.

Technical Highlights

Layout engine with pre-calculated positioning
Pagination control
Consistent font measurement
Rendering abstraction over Skia

Result

The engine produces identical output (PDF / PNG) across environments.

Repository

https://github.com/acrossreport

Closing

If you are interested in rendering engines, Skia, or cross-platform layout systems, I would appreciate your feedback.

DEV Community: Hisa Araki

GS1 Sunrise 2027 Might Not Fit Your Thermal Printer

The 203 dpi printer can't quite hit the minimum 2D size

Side by side, it doesn't fit on a 50 mm label

Verification testing hasn't covered 203 dpi

We wrote up the math as a technical note

We're also building a library for this

BarBridge: a Rust core for GS1 Sunrise 2027 barcode pairs, callable from 7 languages over a C ABI

TL;DR

The problem: GS1 Sunrise 2027

From an ACR feature to a standalone library

Architecture: one Rust core, one C ABI boundary

Today's work: samples for 7 languages × 6 platforms

What's next

Migrating Off ActiveReports to the Web and Linux While Keeping Your Existing Assets

Background: three pain points of ActiveReports estates

The migration approach: aim for "semantic compatibility," not "replacement"

Section structure compatibility

Date format and font specification compatibility

Barcode type compatibility

Why Linux becomes possible

A typical migration path

Summary

Building a Blazing-Fast Report PDF Environment on Docker/Linux, Callable from C# and Node.js

The goal

Overall architecture

Build details that matter

1. Building the Rust core

2. Calling from Node.js (napi-rs)

3. Example Dockerfile (Node.js consumer)

4. Calling from C

Why this setup ends up lighter

Summary

Fixing Out-of-Memory Errors in Puppeteer PDF Generation

What this is about

Why Puppeteer runs out of memory

1. The renderer process heap isn't designed for reuse

2. Fonts and images get reloaded per page

3. The page.pdf() output buffer accumulates in-process

Mitigations (if you stick with Puppeteer)

An alternative: a report renderer that skips the browser

Case study: rebuilding a font "per page" caused the same kind of bloat

Summary

Rendering PDF/PNG reports in Node.js without Chromium or a subprocess (napi-rs)

What it's built on

Why napi-rs over a CLI wrapper

Implementation notes

Cross-platform builds

Usage

Summary

ACR is designed as a printer-independent report rendering service, not just a library.

Introduction

What you can do

Start

You can also specify port and template directory:

Web UI

curl（PDF）

curl（PNG）

curl (HTML)

Running as a service

Windows

Linux (systemd)

macOS

Architecture

Roadmap

Download

I built a pixel-perfect, printer-independent report designer with Avalonia UI

Personal Note

I built a pixel-perfect, printer-independent report designer with Avalonia UI

Why I built a pixel-perfect report engine with Rust and Skia

Introduction

The Problem

The Approach

Why Rust

Technical Highlights

Result

Repository

Closing

3. The `page.pdf()` output buffer accumulates in-process