DEV Community: Azeem Ullah

Printing a receipt with a logo and Georgian text from a .NET Windows service, without System.Drawing

Azeem Ullah — Tue, 20 Oct 2026 14:40:31 +0000

A question on Stack Overflow this year describes a setup I see a lot: an ASP.NET Core backend for kiosks, each kiosk a Windows PC with Chrome and a USB-only thermal printer (a NIPPON PRIMEX NP-3511). Sharing the printer over the network to the server kept dropping, so the author moved printing into a small service on each kiosk. Then printing itself broke: the receipts were built with System.Drawing and PrintDocument, which Microsoft doesn't support in Windows services, and SkiaSharp didn't seem to have a way to print at all.

The receipts need a logo, formatted text, and Georgian.

I don't have an NP-3511. I do have a different 80 mm USB receipt printer, .NET 9 and the NP-3511's specification sheet, so I built the part that can be checked without the printer. Here is what I found, and what I'd do.

Stop printing through a graphics API

PrintDocument asks Windows to draw your page through the printer driver with GDI+. That is the bit Microsoft's System.Drawing remarks warn about: the GDI+ types such as Bitmap and Font are not supported in Windows services or ASP.NET apps.

A receipt printer doesn't need a page drawn for it, though. It takes a stream of bytes: commands, text, and bitmap rows, one bit per dot. So the work splits into three steps, and none of them touches GDI+:

draw the receipt into an in-memory bitmap (SkiaSharp is fine for this, you just don't print with it),
turn the bitmap into the printer's raster command,
hand those bytes to the Windows spooler with the RAW datatype, so the driver passes them through unchanged.

Georgian means printing an image

The NP-3511's spec sheet lists its character tables: Japanese, code page 858, and Windows code pages 1250 to 1254 (Central European, Cyrillic, Western, Greek, Turkish). None of them contains Georgian. Sending Georgian as text can't work, whatever encoding you pick.

So the whole receipt goes out as a picture. Draw the text with a font that has Georgian letters. Sylfaen ships with Windows; if you don't want to depend on that, bundle Noto Sans Georgian with the service. In my test SkiaSharp drew Mkhedruli and the lari sign (₾) correctly with plain DrawText, without any extra shaping library.

The printer-specific part: NP-3511 doesn't use GS v 0

Most "print an image on a receipt printer" code you'll find sends Epson's raster command GS v 0 (1D 76 30). The NP-3511 command table in the NP-2511/3511 specification (hosted by Rice Lake, a distributor) has no GS v 0. It has its own raster command:

ESC b n1 n2 n3 data      1B 62 n1 n2 n3 ...
n1 = bytes per row (1..72 on the 3-inch model)
height = n2 + 256 * n3 dot rows
bit 1 = black

72 bytes is 576 dots, so that's the width to draw at. The same table uses 1D 76 00 (GS v NUL) to switch on automatic status reporting, so an Epson 1D 76 30 header lands on a different command. The cut is ESC i (full) or ESC m (partial), not Epson's GS V.

That document says "Ver. 0.07" and calls itself provisional, so check it against the manual for your firmware. If you do have one of these printers, the first test is a tiny ESC b image, before anything else.

The code

Tested on .NET 9 with SkiaSharp 4.153.1 (dotnet add package SkiaSharp). This is a console app so it's easy to try; the three classes drop into a Worker Service unchanged.

using System.Runtime.InteropServices;
using SkiaSharp;

const int WidthDots = 576;   // NP-3511: ESC b allows at most 72 bytes = 576 dots per row
using var typeface = SKTypeface.FromFile(@"C:\Windows\Fonts\sylfaen.ttf"); // has Georgian
using var receipt = Receipt.Render(WidthDots, typeface, logoPath: null,
[
    ("ყავის სახლი", null, 40f, true),
    ("თბილისი, რუსთაველის გამზირი 12", null, 22f, false),
    ("ესპრესო x2", "7.00 ₾", 24f, false),
    ("ხაჭაპური", "12.50 ₾", 24f, false),
    ("სულ", "19.50 ₾", 28f, true),
    ("გმადლობთ!", null, 24f, false),
]);

var (rows, bytesPerRow, height) = Raster.Pack(receipt);
byte[] np3511 = [.. Raster.EscB(rows, bytesPerRow, height), 0x1B, 0x64, 4, 0x1B, 0x69]; // feed 4 lines, full cut (ESC i)
byte[] escpos = [0x1B, 0x40, .. Raster.GsV0(rows, bytesPerRow, height), 0x1B, 0x64, 4, 0x1D, 0x56, 1];

RawPrinter.Send("NP-3511", np3511);   // the queue name as it appears in Windows

static class Receipt
{
    public static SKBitmap Render(int width, SKTypeface tf, string? logoPath,
        (string left, string? right, float size, bool bold)[] lines)
    {
        var bmp = new SKBitmap(width, 2000);
        using var c = new SKCanvas(bmp);
        c.Clear(SKColors.White);
        using var paint = new SKPaint { Color = SKColors.Black, IsAntialias = false };
        float y = 0, margin = 8;
        if (logoPath != null)
        {
            using var logo = SKImage.FromEncodedData(logoPath);
            float h = logo.Height * Math.Min(1f, (width - 2 * margin) / logo.Width);
            float w = logo.Width * h / logo.Height;
            c.DrawImage(logo, SKRect.Create((width - w) / 2, y, w, h), new SKSamplingOptions(SKFilterMode.Linear));
            y += h + 10;
        }
        foreach (var (left, right, size, bold) in lines)
        {
            using var font = new SKFont(tf, size) { Embolden = bold, Edging = SKFontEdging.Alias };
            y += size * 1.3f;
            if (right == null)
                c.DrawText(left, width / 2f, y, SKTextAlign.Center, font, paint);
            else
            {
                c.DrawText(left, margin, y, SKTextAlign.Left, font, paint);
                c.DrawText(right, width - margin, y, SKTextAlign.Right, font, paint);
            }
        }
        var cropped = new SKBitmap(width, (int)(y + 12));
        bmp.ExtractSubset(cropped, SKRectI.Create(0, 0, width, (int)(y + 12)));
        return cropped.Copy();
    }
}

static class Raster
{
    // One bit per dot, rows top to bottom, 1 = black.
    public static (byte[] rows, int bytesPerRow, int height) Pack(SKBitmap bmp)
    {
        int bpr = (bmp.Width + 7) / 8;
        var data = new byte[bpr * bmp.Height];
        for (int y = 0; y < bmp.Height; y++)
            for (int x = 0; x < bmp.Width; x++)
            {
                var p = bmp.GetPixel(x, y);
                if (p.Alpha > 127 && p.Red * 0.299 + p.Green * 0.587 + p.Blue * 0.114 < 128)
                    data[y * bpr + x / 8] |= (byte)(0x80 >> (x % 8));
            }
        return (data, bpr, bmp.Height);
    }

    // NIPPON PRIMEX NP-2511/3511: ESC b n1 n2 n3 data (n1 = bytes per row, height = n2 + 256*n3).
    public static byte[] EscB(byte[] rows, int bpr, int height) => Bands(rows, bpr, height,
        h => [0x1B, 0x62, (byte)bpr, (byte)(h & 0xFF), (byte)(h >> 8)]);

    // Epson-style ESC/POS: GS v 0 m xL xH yL yH data.
    public static byte[] GsV0(byte[] rows, int bpr, int height) => Bands(rows, bpr, height,
        h => [0x1D, 0x76, 0x30, 0, (byte)(bpr & 0xFF), (byte)(bpr >> 8), (byte)(h & 0xFF), (byte)(h >> 8)]);

    // Send tall receipts in bands so the printer's receive buffer never has to hold the whole image.
    static byte[] Bands(byte[] rows, int bpr, int height, Func<int, byte[]> header, int band = 256)
    {
        var o = new List<byte>();
        for (int y = 0; y < height; y += band)
        {
            int h = Math.Min(band, height - y);
            o.AddRange(header(h));
            o.AddRange(rows.AsSpan(y * bpr, h * bpr).ToArray());
        }
        return [.. o];
    }
}

static class RawPrinter
{
    [StructLayout(LayoutKind.Sequential, CharSet = CharSet.Unicode)]
    class DOC_INFO_1 { public string? pDocName; public string? pOutputFile; public string? pDatatype; }

    [DllImport("winspool.drv", CharSet = CharSet.Unicode, SetLastError = true)]
    static extern bool OpenPrinter(string name, out IntPtr h, IntPtr defaults);
    [DllImport("winspool.drv", SetLastError = true)] static extern bool ClosePrinter(IntPtr h);
    [DllImport("winspool.drv", CharSet = CharSet.Unicode, SetLastError = true)]
    static extern int StartDocPrinter(IntPtr h, int level, DOC_INFO_1 di);
    [DllImport("winspool.drv", SetLastError = true)] static extern bool EndDocPrinter(IntPtr h);
    [DllImport("winspool.drv", SetLastError = true)] static extern bool StartPagePrinter(IntPtr h);
    [DllImport("winspool.drv", SetLastError = true)] static extern bool EndPagePrinter(IntPtr h);
    [DllImport("winspool.drv", SetLastError = true)]
    static extern bool WritePrinter(IntPtr h, byte[] buf, int count, out int written);

    public static void Send(string printerName, byte[] data)
    {
        if (!OpenPrinter(printerName, out var h, IntPtr.Zero))
            throw new System.ComponentModel.Win32Exception();
        try
        {
            // "RAW" tells the spooler to pass the bytes through without the driver rendering anything.
            if (StartDocPrinter(h, 1, new DOC_INFO_1 { pDocName = "Receipt", pDatatype = "RAW" }) == 0)
                throw new System.ComponentModel.Win32Exception();
            StartPagePrinter(h);
            bool ok = WritePrinter(h, data, data.Length, out int written);
            EndPagePrinter(h);
            EndDocPrinter(h);
            if (!ok || written != data.Length) throw new System.ComponentModel.Win32Exception();
        }
        finally { ClosePrinter(h); }
    }
}

GetPixel in a loop is slow for big images, but a receipt is a few hundred rows; it runs in milliseconds and keeps the code obvious.

Two details worth knowing:

Logos. The printer has no grey. My first test logo had a dark green background, and after the threshold it came out as a solid black rectangle with white text. Use a black-on-white version of the logo, or dither it.
Bands. I send the image in strips of 256 rows. The spec allows one ESC b block up to 65,535 rows tall. Strips just keep each command small; I haven't measured whether it changes anything on this printer.

Windows service or not?

A service is a reasonable home for this: it runs at boot with nobody signed in, which is what a kiosk wants. The open question is how a receipt gets to it. There are two options.

The kiosk page calls the service on http://127.0.0.1. This is simple, but Chrome 142 and later shows a permission prompt before a public website may talk to a program on the same machine. Until someone clicks Allow, the requests just hang. On a kiosk nobody is there to click, so pre-allow your site with the Chrome policy LocalNetworkAccessAllowedForUrls. I measured how this looks to the page in an earlier post.

The service connects out to your backend and receives jobs. That can be a WebSocket or SignalR connection, or a poll every second or two. The browser is no longer involved, a page reload can't lose a receipt, and the server already knows what it wants printed. Give each job an ID and have the service report "printed" or "failed" back, so a reconnect doesn't print the same receipt twice.

Since the backend already builds the receipts, I would go with the second.

Two smaller service details:

The service's account has to see the printer queue by its exact name. OpenPrinter fails with error 1801 (ERROR_INVALID_PRINTER_NAME) if it doesn't, so log Win32Exception.NativeErrorCode.
The spec sheet lists drivers only for Windows 2000, XP and CE 5.0. If nothing newer exists, the RAW path doesn't need the driver to understand anything. It only needs a queue on the right USB port. Windows' "Generic / Text Only" driver is the first thing I'd try. I haven't tried it with this printer.

What I actually tested

Tested: the code above builds and runs on .NET 9. The Georgian receipt renders correctly. I decoded the generated ESC b bytes back into an image and got the receipt back pixel for pixel, with a 4-line feed and ESC i at the end. The same program queued the GS v 0 version on my own printer (a BIXOLON SRP-352plusIII) through RawPrinter.Send. OpenPrinter, StartDocPrinter and WritePrinter all succeeded.
Not tested: any of this on an NP-3511, and running it inside an actual Windows service rather than a console app. I also have no paper result yet: my printer was switched off when the job went in.

If you have an NP-3511 and try the ESC b path, I'd like to hear what came out.

Disclosure: I sell Thermalink, a local print agent for web apps that does this bitmap rendering for you. When I first published this post it only sent Epson's GS v 0, so it could not drive an NP-3511. Version 1.0.2, added the same day, has a "commands": "nippon" printer setting that sends ESC b and ESC i / ESC m as described above. It's written from the same spec sheet and covered by automated tests, but it hasn't been tried on a real NP-3511 yet. Everything in this post is plain .NET and doesn't need it.

I tested a CSV cleaner on data it should leave alone. It failed 4 of 23 checks.

Azeem Ullah — Sat, 17 Oct 2026 12:05:16 +0000

A CSV cleaner landed on my desk this week: an MIT-licensed, browser-only tool that repairs broken quotes, fixes garbled characters and masks emails and phone numbers. It came with 50 tests, and all 50 passed.

Every one of those tests fed it broken data and checked that it got fixed. None of them fed it good data and checked that it stayed the same. So I wrote 23 of those.

Why I cared

The broken-quote problem is real and common. Shopify's own community forum has several threads titled some version of "Illegal quoting in line 2", usually caused by an inch mark or a quote inside a product title or description: https://community.shopify.com/t/illegal-quoting-in-line-2-and-missing-headers-title/10418

A tool that fixes that is useful. A tool that fixes that and quietly changes other cells is worse than no tool, because nobody checks a 5,000-row file by eye.

What failed

1. Two identical rows became one. Duplicate removal was switched on by default. That sounds tidy until you remember that two identical order lines (same order, same item, same quantity) are real data.

order,item,qty
7,Pen,1
7,Pen,1

Output: one row. The fix was to make it opt-in.

2. "SÃO PAULO" became "SÁO PAULO". The mojibake fixer was a table of find-and-replace pairs: Ã© to é, â€™ to ', and so on. One entry was just Ã to Á (the real pair is Ã plus an invisible control character, which had probably been lost), so every Ã in correct Portuguese text got changed.

The fix was to stop guessing with a table. Mojibake is UTF-8 bytes read as Windows-1252, so you can reverse it exactly: take a suspicious run of characters, turn each one back into its Windows-1252 byte, and decode those bytes as UTF-8 with a strict decoder. If they are not valid UTF-8, the text was never mojibake, and you leave it alone.

const decoder = new TextDecoder('utf-8', { fatal: true });
function fixRun(run) {
  const bytes = toCp1252Bytes(run);      // null if a character has no Windows-1252 byte
  if (!bytes) return run;
  try { return decoder.decode(new Uint8Array(bytes)); }
  catch { return run; }                  // not valid UTF-8: it was real text
}

3. Curly apostrophes came back straight. The same table mapped â€™ to a plain '. The original character was ’. The round trip above gives back exactly what was there.

4. An ISBN got masked as a phone number. With masking on, 9780306406157 became (***) ***-6157. The phone pattern matched any long run of digits. Order numbers and account numbers had the same risk. Now it only masks numbers written like phone numbers (a +, brackets, or groups separated by spaces or dashes), and card masking checks the card checksum.

The other thing the tests didn't cover

The tool had six landing pages, each with a little demo box. They didn't use the engine at all. Each one had its own short script, and its line-split regex was written as /\\r?\\n/ with doubled backslashes, so it matched a literal backslash followed by n and never split anything. The tests only covered the engine, so nobody noticed. All six now use the same engine as the main page.

What I took from it

For any tool that changes data, half the tests should be inputs it must not touch: valid escaped quotes, quoted commas, line breaks inside fields, correct accented text, real duplicate rows, numbers that only look like phone numbers. Those are the bugs users never report, because they never notice.

The fixed version is here, free, and it runs in your browser: https://mianazeemdaula.github.io/csv-shield/
Source: https://github.com/mianazeemdaula/csv-shield

Tested in Node 22 and headless Chrome 155. Not tested in Firefox, Safari or on large files yet.

WebUSB says "Access denied" to your receipt printer on Windows. Here is who has it.

Azeem Ullah — Sun, 11 Oct 2026 11:42:35 +0000

If you have tried to print to a USB receipt or label printer straight from the browser on Windows, you have probably met this:

DOMException: Failed to execute 'open' on 'USBDevice': Access denied.

It is not a permission you forgot to grant. The user picked the device in Chrome's chooser, and it still fails.

People keep getting stuck on this. A developer with a Zebra ZD621 posted it on Zebra's own forum: fine on macOS, "Access denied" on Windows 10 and 11, reinstalling the driver did nothing, and nobody from Zebra answered. Back in 2021 someone raised the same thing with a label printer on the WebUSB spec repo.

So I looked at my own machine to see what is actually holding the printer.

Who has the printer

My receipt printer is a BIXOLON SRP-352plusIII on USB. This asks Windows which driver service owns its USB device:

Get-PnpDevice | Where-Object { $_.FriendlyName -match 'BIXOLON' } |
  Select-Object Class, FriendlyName,
    @{n='Service';e={(Get-PnpDeviceProperty -InstanceId $_.InstanceId `
      -KeyName DEVPKEY_Device_Service -ErrorAction SilentlyContinue).Data}},
    InstanceId | Format-List

The line that matters:

Class        : USB
FriendlyName : BIXOLON  SRP-352plusIII
Service      : usbprint
InstanceId   : USB\VID_1504&PID_003F\00000001

usbprint is usbprint.sys, Microsoft's USB printing driver. It is what gives you the USB004 port and lets the Windows spooler talk to the printer. It also owns the printer's USB interface, and Windows gives an interface to one driver at a time.

Chrome's WebUSB on Windows can only open an interface that is bound to WinUSB. So open() is refused. That is the whole error.

The WebUSB editor said as much on that 2021 issue: "I don't think there is a good solution for this problem, particularly on Windows."

What you can do about it

1. Swap the driver with Zadig. This is the fix people in both threads ended up with: replace usbprint with WinUSB for that device, and WebUSB can open it. The cost is that the printer stops being a Windows printer. Nothing else can print to it until you put the old driver back, and every customer machine needs the same manual step. The Zebra poster rejected it for exactly that reason. I have not done this to my own printer, because I still need it to print normally.

2. Use a different door. If the printer has a serial or virtual COM mode, Web Serial may work where WebUSB does not. Network printers are no help here: a web page cannot open a raw TCP socket to port 9100.

3. Leave the driver alone and go through the spooler. The spooler will accept raw bytes for a print queue and pass them to the printer untouched. A web page cannot call the spooler, so this needs a small program on the PC that listens on localhost and hands the bytes over. QZ Tray works this way. So does the one I wrote, Thermalink, which is how the BIXOLON above prints from my web app with its normal driver still installed.

Which one

If you control the machine and the printer is used by one web app only, Zadig is free and it works. Write down how to undo it.

If the printer also has to work for anything else on that PC, or you are shipping to customers who will not run a driver tool, option 3 is the one that survives.

What I did not test

I did not reproduce the open() failure on my own printer; the error text and the Zadig result come from the two threads linked above. What I checked myself is the driver binding shown here, and that raw printing through the spooler works on this printer. Everything in this post is about Windows. Both threads say macOS works.

Thermalink has a site now, with the docs and a free ESC/POS, ZPL and TSPL cheat sheet: https://mianazeemdaula.github.io/thermalink/

My form wrote a sentence that wasn't true, and the user would have signed it

Azeem Ullah — Sun, 11 Oct 2026 11:28:55 +0000

I built a small page that writes appeal letters for UK private parking tickets. You answer a few questions, it produces a letter.

I tested it the way I test most forms. Fill in good data, check the output looks right. Every combination passed: three parts of the UK, keeper or driver, five grounds. No script errors.

Then I did the thing I should have done first. I picked a ground and typed in data that did not support it.

The ground

One of the five grounds is about a deadline. In England and Wales, if a private parking company posts you a ticket and nothing was left on the windscreen, the notice has to be delivered to the registered keeper within 14 days. It's in Schedule 4 of the Protection of Freedoms Act 2012, paragraph 9. People ask about it on forums all the time. Here is one thread where the notice took more than 30 days: https://www.ftla.uk/private-parking-tickets/late-notice-to-keeper-30-days-worth-appealing/

So the form asks for the date of parking and the date the notice arrived.

The bug

I entered a parking date and a received date 7 days apart. Under the field, the helper text did the right thing:

You received it 7 days after the parking date. This ground needs more than 14 days, so it may not apply.

And the letter, a few centimetres to the right, said this:

Your notice is dated 6 October 2026 and I received it on 6 October 2026, which is outside that period.

That sentence is false, and the page wrote it. The person using it is stressed, skims the preview, prints, signs.

The cause was boring. The helper text and the letter were built by two different functions. One compared the dates. The other just filled a template.

The fix

I did not make the letter clever. A letter that silently rewrites its own argument is hard to trust. The page now puts a warning above the letter, next to the count of unfilled fields:

const pd = $('parkDate').value, rd = $('receivedDate').value;
if (radio('ground') === 'keeper' && $('jurisdiction').value === 'EW'
    && pd && rd && daysBetween(pd, rd) <= 14) {
  add('', '<strong>Check your dates.</strong> This letter says the notice ' +
    'arrived more than 14 days after parking, but the dates you entered are ' +
    'within 14 days. Correct the dates or choose a different ground.');
}

The second one

While I was in there I found the letter's date came from this:

new Date().toISOString().slice(0, 10)

toISOString() is UTC. The UK is an hour ahead of UTC in summer. Between midnight and 1 am the letter would be dated yesterday. Not a disaster, but it is a dated legal letter, and the fix is three lines:

const localIso = d =>
  `${d.getFullYear()}-${String(d.getMonth() + 1).padStart(2, '0')}-${String(d.getDate()).padStart(2, '0')}`;

What I took from it

If a form generates text that a person will sign, test each option with inputs that contradict it. "Does it render" is not the test. "Can it say something untrue" is.

The page is here if you want to poke at it: https://mianazeemdaula.github.io/parking-appeal-letter/
Source: https://github.com/mianazeemdaula/parking-appeal-letter

I'm a developer, not a lawyer, and no solicitor has reviewed the wording. It was tested in headless Chrome only, not on real phones, Safari or Firefox.

The receipt CSS everyone copies, @page { size: 80mm auto }, does nothing in Chrome

Azeem Ullah — Sat, 10 Oct 2026 11:21:19 +0000

If you print receipts with window.print(), you have probably pasted this into your stylesheet at some point:

@page { size: 80mm auto; margin: 0; }

It's everywhere. One example: on the WordPress.org support forum, a WooCommerce invoice plugin's support team gave exactly this rule to a user setting up an 80 mm thermal printer. It reads well. 80 mm wide, as tall as the content. That's what a receipt is.

I wanted to know what Chrome does with it, so I measured.

The test

One small receipt: a shop name, two lines and a total. I printed it to PDF with headless Chrome 155 on Windows, changing only the @page rule, then read the page size out of each PDF.

`@page` rule	Page Chrome produced
none	215.9 × 279.4 mm (Letter)
`size: 80mm auto`	215.9 × 279.4 mm (Letter)
`size: 80mm`	80 × 80 mm
`size: 80mm 297mm`	80 × 297 mm
height measured in JS	80 × 27 mm

Row two is the same as row one. The rule did nothing.

I didn't trust that, so I asked the browser directly:

const s = new CSSStyleSheet();
s.replaceSync('@page { size: 80mm auto; margin: 0 }');
s.cssRules[0].style.getPropertyValue('size');   // ""

Empty string. Chrome's parser drops the declaration. auto is valid on its own, and 80mm 297mm is valid, but a length followed by auto isn't something size accepts. So the browser falls back to the default page, and your receipt sits in the corner of a Letter or A4 sheet. I think that explains the two classic complaints, a tiny shrunken receipt and a long tail of blank paper, though which one you get will depend on the driver.

Row three caught me out too. size: 80mm with one value doesn't mean "80 wide, any height". It means a square.

What works: measure, then tell Chrome

CSS has no way to say "page as tall as the content". But you know how tall the receipt is, because it's already laid out on screen. Measure it and write the number in.

function printReceipt(el) {
  const mm = el.getBoundingClientRect().height * 25.4 / 96;   // CSS px to mm
  let style = document.getElementById('receipt-page');
  if (!style) {
    style = document.createElement('style');
    style.id = 'receipt-page';
    document.head.appendChild(style);
  }
  style.textContent = `@page { size: 80mm ${Math.ceil(mm + 2)}mm; margin: 0 }`;
  window.print();
}

That's row five in the table: an 80 × 27 mm page for a 25 mm receipt, with nothing left over.

It matters more as the receipt gets longer. I ran the same thing with long orders:

Receipt	`size: 80mm 297mm`	measured height
120 lines	2 pages	1 page, 532 mm
600 lines	9 pages	1 page, 2588 mm

A fixed 297 mm page cuts a long receipt into pieces. On a printer with an auto-cutter that can mean an actual cut through the middle of an order. With the measured height it stays one page, even at two and a half metres.

Two things to watch with the measuring:

Measure after fonts and images have loaded. A logo that arrives late makes the receipt taller than the page you just declared.
Measure the element at the width it will print at. If your print stylesheet changes the width, the text wraps differently and the height is wrong.

Your 80 mm printer is 72 mm wide

The other complaint I keep seeing is "the right side of my receipt is cut off". Payment and POS vendors have whole help pages about it, and they usually tell staff to play with margins and scale in the print dialog.

I looked at what the drivers on my own machine report. I have a BIXOLON SRP-352plusIII and a generic "POS-80" driver installed. This is what Windows says their paper sizes are:

Paper name in the driver	Actual size
80 x 297 mm	71.9 × 296.9 mm
80 x 3276 mm	71.9 × 3275.8 mm
Thermal Paper (80 x 210)	72.1 × 210.1 mm

Every "80" is 72. The roll is 80 mm wide, but the print head only covers about 72 mm of it, and that's the size the driver hands to the browser.

So if your receipt container is width: 80mm, it's 8 mm wider than the page. Something has to give, and the right edge is usually what goes. Make the container 72 mm so it fits the page the driver actually offers:

.receipt { width: 72mm; }

58 mm printers have the same gap. Check what your driver really reports before you pick a number. In PowerShell:

Add-Type -AssemblyName System.Drawing
$p = New-Object System.Drawing.Printing.PrinterSettings
$p.PrinterName = 'YOUR PRINTER NAME'
$p.PaperSizes | % { '{0}: {1:N1} x {2:N1} mm' -f $_.PaperName, ($_.Width * 0.254), ($_.Height * 0.254) }

What I didn't test

All the page sizes above come from Chrome's PDF output, which is the only place I can measure a page exactly. Since publishing I've printed one measured receipt from Chrome to my BIXOLON and it came out fine, but I haven't put a ruler on paper for each variant in the table. A real print goes through the driver, and I can't promise every driver accepts a custom page height the same way. If yours ignores it, selecting the long roll size in the driver (the 3276 mm one above) is the next thing I'd try, but I haven't measured that.

I also only tested Chrome. Firefox and Safari have their own history with @page size.

If you'd rather not write this yourself

I packaged the stylesheet, the measuring script and 8 receipt templates (each for 80 mm and 58 mm rolls) as the Receipt Print Kit. It's $9, or $5 for the first 20 buyers through this link (code FIRST20). Disclosure: I built it. Everything in this post works without it.

Where `window.print()` stops

Even with the page size right, the browser still shows a dialog, and it can't cut the paper or open the cash drawer. Those need raw commands sent to the printer. I wrote about that route here, and I sell a small agent that does it called Thermalink. Disclosure: I built it.

For a lot of shops, though, a correct page size and a 72 mm container are all that was missing. If you try the measuring trick on a real printer and it behaves differently from my table, tell me the model and what came out.

Free: the measuring function on its own, MIT licensed: receipt-fit on GitHub. And if you end up sending raw bytes instead, here's the ESC/POS, ZPL and TSPL cheat sheet I use.

"Agent not running" when it is running: Chrome's local network prompt and localhost helpers

Azeem Ullah — Sat, 10 Oct 2026 11:14:14 +0000

This week I found a bug in my own code by reading another company's support page.

Dynamsoft sell a document scanning SDK. Like a lot of hardware-in-the-browser tools, it works through a small service installed on the user's PC, and the web page talks to it on 127.0.0.1. Their FAQ lists this symptom for Chromium 142 and later: the page keeps asking the user to download and install the service, even though it is already installed and running.

I build the same kind of thing for receipt printers, so I read that and thought: mine probably does this too. It did.

What changed in the browser

Since Chrome 142 (28 October 2025), a public website can't just fetch() something on the user's machine or LAN. Chrome shows a permission prompt first. The Chrome team's post about it calls this Local Network Access.

A few things have moved since then. These come from Chrome's own guidance tracker and the Dynamsoft page:

Chrome 145 split the one permission into two. loopback-network is for programs on the same computer, and in site settings it shows as "Apps on device". local-network is for other devices on the LAN. The old name local-network-access still works as an alias.
Chrome 147 put WebSocket and WebTransport connections behind the same prompt. If your helper speaks WebSocket and you thought you'd escaped, you haven't.
Chrome 156 is planned to remove LocalNetworkAccessRestrictionsTemporaryOptOut, the enterprise policy some IT teams used to switch the whole thing off. If a customer told you "we fixed it with a policy", ask them which one.
Firefox 153 now does the same on desktop, with its own prompt.

So this is no longer a Chrome quirk you can wait out.

What your page sees

This is the part I couldn't find written down, so I tested it. Chrome 155 on Windows, my agent listening on 127.0.0.1:17777, and a page on a public https:// origin that had never asked before.

First, the permission state:

for (const name of ['loopback-network', 'local-network', 'local-network-access']) {
  console.log(name, (await navigator.permissions.query({ name })).state);
}
// loopback-network prompt
// local-network prompt
// local-network-access prompt

All three names are accepted, and all say prompt.

Then the request, with a 3 second timeout on an AbortController:

Target	Result
`127.0.0.1:17777` (agent running)	hangs, then my own timeout aborts it after 3 s
`127.0.0.1:17778` (nothing listening)	`TypeError: Failed to fetch` after about 10 ms

Two things I didn't expect.

Chrome only asks when something is actually there. A dead port fails straight away, with no prompt.

And while the prompt is open, the request doesn't fail. It just waits. There's no error and no event. The promise sits there until the user clicks something.

Now look at how nearly every "is the helper installed?" check is written, mine included:

async isRunning() {
  try {
    const r = await this._req('GET', '/v1/health', undefined, 1500); // 1.5 s timeout
    return !!r.ok;
  } catch (e) {
    return false;
  }
}

The prompt appears. The cashier is looking at the till, not at the address bar. 1.5 seconds pass, the check gives up, and the app says "Printer helper is not running, please install it". The helper is running. The browser is waiting for a click nobody knows they need to make.

If the user clicks Block instead, it gets worse. From what I've read, Chrome doesn't ask that site again, and every request fails from then on. Dynamsoft's page shows the console message for that case: Permission was denied for this request to access the unknown address space. Your JavaScript can't read that text. It gets the same TypeError as a missing agent.

The fix: ask the browser before you blame the agent

You can't trigger the prompt on demand and you can't clear a block from script. What you can do is tell the three situations apart and show the right message.

async function agentStatus(url = 'http://127.0.0.1:17777/v1/health') {
  const ctrl = new AbortController();
  const timer = setTimeout(() => ctrl.abort(), 1500);
  try {
    const res = await fetch(url, { signal: ctrl.signal, targetAddressSpace: 'loopback' });
    return res.ok ? 'running' : 'not_running';
  } catch (err) {
    const perm = await lnaState();
    if (perm === 'denied') return 'permission_denied';
    // an unanswered prompt leaves the request hanging until our own abort
    if (perm === 'prompt' && err.name === 'AbortError') return 'permission_prompt';
    return 'not_running';
  } finally {
    clearTimeout(timer);
  }
}

async function lnaState() {
  if (!navigator.permissions?.query) return 'unsupported';
  for (const name of ['loopback-network', 'local-network-access']) { // 145+, then 142-144
    try { return (await navigator.permissions.query({ name })).state; } catch {}
  }
  return 'unsupported'; // Safari, older browsers
}

Then say something useful for each one:

permission_prompt: "Click Allow in the prompt next to the address bar, then print again."
permission_denied: "Your browser is blocking the printer helper. Click the icon to the left of the address bar, open Site settings, set Apps on device to Allow, and reload." (Chrome 142 to 144 call it "Local network access".)
not_running: only now do you show the install link.

The AbortError check matters. A page whose permission is still prompt but whose agent really is missing gets the fast TypeError, and that should still say "not running".

Other things that bit, or will

Iframes. If your app is embedded cross-origin, the outer page has to hand the permission down: <iframe allow="loopback-network; local-network-access" ...>. Same-origin frames are fine.
HTTPS only. The Chrome post says the prompt can only be requested from a secure context. A public page on plain http:// has no way to get the permission.
Dev machines hide it. A page you open from http://localhost:3000 isn't a public site, so you never see the prompt while developing. It first shows up in production, on someone else's computer.
Managed fleets. LocalNetworkAccessAllowedForUrls pre-allows your origin so staff never see the prompt. That's the policy to ask IT for, not the opt-out that's going away.
A correction to my earlier post. I wrote that you need to answer the preflight with Access-Control-Allow-Private-Network: true. That header belongs to the older Private Network Access design, which this permission replaced. I still send it and it does no harm, but it isn't what lets you through any more.

What I haven't tested

The "blocked" branch. I ran it against a mocked permission state, and the behaviour I describe for it comes from Dynamsoft's documentation, not from me clicking Block on a real machine. I also haven't run any of this on Firefox 153 or on a Mac. If you see something different there, tell me and I'll update the post.

Where this landed in my own product

I make Thermalink, a paid local print agent and JS SDK for receipt and label printers. Disclosure: I built it. Version 1.0.1 has this fix: tl.status() returns those four states, and print calls throw permission_prompt or permission_denied instead of a misleading not_running.

You don't need it to use anything above. The function is about twenty lines, and it works for any localhost helper: printing, scanning, card readers, scales.

If you maintain one and you've seen different timing from what's in my table, I'd like to compare notes.

More: Thermalink's public troubleshooting page covers this prompt and the other ways a local print agent looks dead when it isn't, and there's a free ESC/POS, ZPL and TSPL cheat sheet on the same site.

Printing shipping and product labels from a web app (ZPL and TSPL, no PDF)

Azeem Ullah — Fri, 09 Oct 2026 09:41:36 +0000

If your web app ships parcels, prices products or tracks stock, sooner or later someone asks: "Can it print the label straight to the Zebra?"

The usual first attempt is to generate a PDF and call window.print(). That works badly. The label comes out scaled, shifted or split across two labels, and every PC needs its own driver settings. Label printers have their own languages, and sending those directly is simpler and much more reliable.

This post covers the two languages you'll meet most (ZPL and TSPL), the units and sizes that trip people up, and how to get the bytes from a browser to the printer.

Two languages cover most printers

Language	Printers
ZPL	Zebra, and most printers sold as "Zebra-compatible"
TSPL	TSC, 4BARCODE, many Xprinter and generic 4" label printers
EPL	older Zebra/Eltron models (avoid for new work)

Both are plain text. You build a string, send it to the printer as-is (raw), and the printer draws the label itself. No driver rendering, no PDF, no scaling.

Units: everything is in dots

This is where most first labels go wrong. Coordinates are in printer dots, not millimetres or pixels:

203 dpi printers (the common ones): 8 dots per mm
300 dpi printers: about 11.8 dots per mm

So a 4 × 6 inch shipping label is 812 × 1218 dots at 203 dpi, and 1200 × 1800 at 300 dpi. If your label prints at two-thirds size, you wrote it for 203 dpi and sent it to a 300 dpi printer (or the other way round). Keep the dpi in your printer settings and multiply.

ZPL: a shipping label

^XA
^PW812
^LL1218
^CI28
^CF0,40
^FO40,40^FDShip to: Jane Doe^FS
^CF0,30
^FO40,90^FD221B Baker Street, London^FS
^FO40,150^BY3^BCN,120,Y,N,N^FD1Z999AA10123456784^FS
^FO40,320^BQN,2,6^FDQA,https://example.com/track/1Z999AA10123456784^FS
^XZ

What the commands do:

^XA … ^XZ: start and end of a label
^PW812 / ^LL1218: print width and label length in dots (4 × 6" at 203 dpi)
^CI28: treat field data as UTF-8, so é, ü and £ work with the built-in scalable font
^CF0,40: default font 0 (scalable), 40 dots high
^FOx,y: field origin (top-left of the next element)
^FD…^FS: field data, then field separator
^BY3^BCN,120,Y,N,N: Code 128 barcode, module width 3, 120 dots high, human-readable text underneath
^BQN,2,6 + ^FDQA,…: QR code, magnification 6. The QA, prefix means error-correction level Q and automatic input mode. It isn't part of your data.

Tip: paste ZPL into the free Labelary viewer to see the label before you print a single one. It saves a lot of paper.

TSPL: a product label

SIZE 50 mm, 30 mm
GAP 2 mm, 0 mm
DIRECTION 1
CLS
TEXT 20,20,"3",0,1,1,"Organic Honey 500g"
TEXT 20,60,"2",0,1,1,"Price: 9.99"
BARCODE 20,100,"128",70,1,0,2,2,"SKU-000123"
PRINT 1,1

SIZE / GAP: label size and the gap between labels. TSPL lets you use mm here, but TEXT and BARCODE positions are still in dots.
CLS: clear the image buffer. Forget it and you'll print the previous label on top of the new one.
TEXT x,y,"font",rotation,x-mul,y-mul,"content"
BARCODE x,y,"128",height,readable,rotation,narrow,wide,"content"
QRCODE x,y,M,4,A,0,"https://…" adds a QR code (ECC level M, cell width 4).
PRINT 1,1: print one copy of one set

End each line with \r\n. Many printers accept \n, but some older firmware doesn't.

Common gotchas

Wrong gap/label length = blank labels or a label skipped every time. Calibrate the media sensor once. On Zebra, hold the feed button or send ~JC. On TSC, use the printer's utility or the AUTODETECT command. Then make sure ^LL / SIZE match the real stock.
Built-in fonts are limited. ZPL's font 0 plus ^CI28 handles most Latin text. TSPL's bitmap fonts are often ASCII-only. For Arabic, Cyrillic or CJK, either install a font on the printer or draw the text as an image in the browser (a <canvas>), then send it with ZPL ^GFA or TSPL BITMAP. Treat the image as 1-bit and threshold it, because label printers don't do greys.
Don't send ZPL through a "normal" print job. On Windows, a job submitted through the driver with datatype RAW (OpenPrinter → StartDocPrinter with "RAW" → WritePrinter) passes your ZPL through untouched. Printing a text file through the driver instead prints the ZPL source code as text on the label. On macOS/Linux, lp -d <printer> -o raw label.zpl does the right thing.
Network label printers listen on TCP port 9100. nc 192.168.1.60 9100 < label.zpl is the fastest way to test one. Browsers can't open raw TCP sockets, though, which brings us to…

Getting the bytes from the browser to the printer

Option 1: the vendor's agent

Zebra ships a free local agent called Browser Print, with a JS library. If every printer you'll ever support is a Zebra, use it. It doesn't help with TSC and the many generic TSPL printers, and you'll need a separate solution for receipt printers.

Option 2: WebUSB

Chromium-only, needs a user gesture to pair, and on Windows the installed driver usually holds the USB interface, so the browser can't claim it. It's fine for a kiosk where you control the machine, and painful anywhere else.

Option 3: your own small local agent

A program on the PC listens on 127.0.0.1, your page POSTs the ZPL/TSPL string to it, and it writes the bytes to the OS print queue as RAW (or to TCP 9100 for network printers). It's about a hundred lines of code, plus the parts people skip:

answer Chrome's Local Network Access preflight with Access-Control-Allow-Private-Network: true. If you pass targetAddressSpace to fetch, use 'loopback' for 127.0.0.1. In Chrome 155, 'local' fails.
bind to 127.0.0.1 only, check the Origin header against an allowlist, and reject non-loopback Host headers (DNS rebinding)
lock per printer so two tabs don't interleave two labels

I wrote up the receipt-printer side of this (ESC/POS, printer widths, raster images) in a previous post.

If you'd rather not build the agent

I packaged that agent as Thermalink: a single ~7 MB binary for Windows/macOS/Linux plus a JS SDK. For label printers it's a pure raw passthrough: you write the ZPL/TSPL, and it gets the bytes to the right printer (USB via the OS queue, or network via 9100). The same agent also does receipt printers, where it renders receipts as images.

const tl = new Thermalink();
await tl.printRaw(zpl, { printer: 'labels' }); // 'labels' = alias for the Zebra/TSC queue or tcp://ip:9100

To be upfront: I've tested it on a real BIXOLON receipt printer, and the raw label path is covered by automated tests, but I haven't tested it on a physical label printer yet. If you try it on one, I'd like to hear how it went. It's a paid one-time download with full source: https://7207381545467.gumroad.com/l/xwyogp. Disclosure: I built it.

Everything above works without it too. If you're stuck on a specific label printer, drop the model and your ZPL/TSPL in the comments and I'll take a look.

Free reference: the ZPL, TSPL and ESC/POS commands I use, on one page: printer command cheat sheet. Thermalink's setup docs are public too: mianazeemdaula.github.io/thermalink.

Printing receipts silently from a web app: what actually works in 2026

Azeem Ullah — Fri, 09 Oct 2026 08:03:46 +0000

If you've built a POS, restaurant or warehouse web app, you've hit the receipt-printer wall: the browser wants to show a print dialog, the cashier wants the receipt now, and the printer wants raw bytes.

Here's what I learned getting a web page to print to a thermal receipt printer with no dialog, including two gotchas that cost me real time.

Option 1: `window.print()`

Works everywhere, but:

it always shows a dialog (outside kiosk mode)
it adds page margins and scaling you don't control
it can't cut the paper or open the cash drawer

Fine for the occasional print, painful at a busy counter.

If you do stay with window.print(), the page size is the part that usually goes wrong: tiny receipts on a big page, or a long tail of blank paper. I measured what Chrome does and wrote up the fix in a separate post.

Option 2: WebUSB / Web Serial

No install, but it's Chromium-only, needs a user gesture to pair the device, and on Windows it fights the installed printer driver for the USB interface. It's OK for kiosks you fully control.

Option 3: a local agent (what most POS apps end up doing)

A small program on the shop PC listens on 127.0.0.1, and your page calls it with fetch(). It talks to the printer through the OS print queue or a network socket. Three things to get right:

1. Chrome's Local Network Access rules

Updated 10 Oct 2026. I got this part wrong the first time.

I originally wrote that the thing to get right here was answering the preflight with Access-Control-Allow-Private-Network: true. That header comes from the older Private Network Access design. What actually stands in your way now is a permission prompt: since Chrome 142 the user has to click Allow before a public site can reach 127.0.0.1, and Firefox 153 does the same.

While that prompt is open, your request doesn't fail. It hangs. A typical "is the agent running?" check times out and tells the user to install something that is already running. I tested this and wrote up the fix in a separate post.

One detail from the original still holds. If you pass the newer targetAddressSpace fetch option, it has to match the real address space. In Chrome 155, targetAddressSpace: 'local' for a loopback address makes the fetch fail outright. 'loopback' (or no option) works:

await fetch('http://127.0.0.1:17777/v1/health', { targetAddressSpace: 'loopback' });

2. Security

Anything listening on localhost can be called by any website the user opens. At minimum:

bind to 127.0.0.1 only, never 0.0.0.0
check the Origin header against an allowlist (browsers set it, and pages can't fake it)
reject requests whose Host header isn't a loopback name, which blocks DNS-rebinding attacks
require an API key for non-browser callers (no Origin header)

3. Printer width is never what the spec sheet says

This one surprised me. "80 mm" printers differ in DPI (180 vs 203), some have a 58 mm mode switch, and they all keep their own margins. My BIXOLON SRP-352plusIII is 576 dots wide on paper (the spec sheet), but in practice only 568 dots print. Text at the very right edge got clipped.

If you build receipts out of fixed 48-character text lines, they'll wrap or clip differently on the next printer you meet. The approach that fixed it for me: render the receipt as a bitmap at the printer's measured width (real TTF fonts, measured columns, QR codes, barcodes) and send it as an ESC/POS raster image. Then it looks the same on every brand.

How to measure: print a ruler image 640 dots wide with a tick every 8 dots and a number every 32 dots, each number ending at its tick. The last fully readable number (+8 per extra tick) is the usable width.

ESC/POS cheat sheet

What	Bytes
Initialize	`1B 40`
Partial cut	`1D 56 01`
Kick cash drawer (pin 2)	`1B 70 00 19 FA`
Raster image	`1D 76 30 00 xL xH yL yH` + 1 bit per dot, MSB first

Tips:

Send raster images in bands of about 128 rows. Cheap printers overflow their buffer on one huge image.
On Windows, send bytes through the spooler with datatype RAW (OpenPrinter → StartDocPrinter with "RAW" → WritePrinter). Then any installed driver works, and it won't re-render your bytes.
On macOS/Linux, lp -d <printer> -o raw does the same through CUPS.
Network printers almost always accept raw bytes on TCP port 9100.

If you'd rather not build it

I packaged all of the above as Thermalink: a ~7 MB agent for Windows/macOS/Linux plus a small JS SDK. It has image mode (and a text mode for slow links), a calibrate command that prints that ruler, QR/barcodes/logos, cash drawer, label printers (ZPL/TSPL), and full source:

const tl = new Thermalink();
await tl.print(
  Thermalink.receipt()
    .title('BLUE DOOR CAFE')
    .row('Flat white x2', '8.00')
    .row('TOTAL', '8.00', { bold: true })
    .qr('https://example.com/r/A1B2C3')
    .cut()
);

It's a paid, one-time download: https://7207381545467.gumroad.com/l/xwyogp. Disclosure: I built it. Everything in this article works without it too. Happy to answer ESC/POS questions in the comments.

Free reference: the ESC/POS, ZPL and TSPL commands I use, on one page: printer command cheat sheet. Thermalink's setup docs are public too: mianazeemdaula.github.io/thermalink.

DEV Community: Azeem Ullah

Printing a receipt with a logo and Georgian text from a .NET Windows service, without System.Drawing

Stop printing through a graphics API

Georgian means printing an image

The printer-specific part: NP-3511 doesn't use GS v 0

The code

Windows service or not?

What I actually tested

I tested a CSV cleaner on data it should leave alone. It failed 4 of 23 checks.

Why I cared

What failed

The other thing the tests didn't cover

What I took from it

WebUSB says "Access denied" to your receipt printer on Windows. Here is who has it.

Who has the printer

What you can do about it

Which one

What I did not test

My form wrote a sentence that wasn't true, and the user would have signed it

The ground

The bug

The fix

The second one

What I took from it

The receipt CSS everyone copies, @page { size: 80mm auto }, does nothing in Chrome

The test

What works: measure, then tell Chrome

Your 80 mm printer is 72 mm wide

What I didn't test

If you'd rather not write this yourself

Where window.print() stops

"Agent not running" when it is running: Chrome's local network prompt and localhost helpers

What changed in the browser

What your page sees

The fix: ask the browser before you blame the agent

Other things that bit, or will

What I haven't tested

Where this landed in my own product

Printing shipping and product labels from a web app (ZPL and TSPL, no PDF)

Two languages cover most printers

Units: everything is in dots

ZPL: a shipping label

TSPL: a product label

Common gotchas

Getting the bytes from the browser to the printer

Option 1: the vendor's agent

Option 2: WebUSB

Option 3: your own small local agent

If you'd rather not build the agent

Printing receipts silently from a web app: what actually works in 2026

Option 1: window.print()

Option 2: WebUSB / Web Serial

Option 3: a local agent (what most POS apps end up doing)

1. Chrome's Local Network Access rules

2. Security

3. Printer width is never what the spec sheet says

ESC/POS cheat sheet

If you'd rather not build it

Where `window.print()` stops

Option 1: `window.print()`