v0.3.1 and what's next #356

This is a ridiculously good project. I am blown away by how polished and clean the ui is and the feature set. Outstanding work

Hi! I found a reproducible issue with custom fonts in the macOS desktop application.

Environment:

• ZPLab v0.3.2, Apple Silicon build
• macOS Tahoe
• MacBook Air M4
• Font: NotoSans-Regular.ttf

Steps to reproduce:

1. Open the Fonts tab (Aa).
2. Click Add font.
3. Enter NOTOSANS.TTF as the printer filename.
4. Select NotoSans-Regular.ttf.

The desktop application displays:

Could not load font file

The same TTF file loads successfully in the web version at zplab.org. Uploading it through Typography → Advanced → Font path also leaves the desktop status at Font not loaded.

I suspect this is caused by the desktop CSP. fontCache.ts registers the selected font through a data URL:

data:font/ttf;base64,...

but src-tauri/tauri.conf.json currently allows only:

font-src 'self';

Could data: be added to both csp and devCsp?

font-src 'self' data:;

Expected behavior: a valid TTF/OTF should load in the desktop application for canvas preview and ~DY embedding, as it does in the web version.

I am experiencing what appears to be a rendering issue in ZPLLab when using ^FR with a custom TrueType font over a filled black box.

Environment:

• Label size: 60 ×ばつ 30 mm
• Resolution: 12 dpmm / 300 dpi
• Canvas size: 720 ×ばつ 360 dots
• Custom font: DIN Alternate Bold
• Font file on the printer: E:DINALTERNATE.TTF
• Font alias: J

Relevant font mapping:

^CWJ,E:DINALTERNATE.TTF

The font is included in the original ZPL using a ~DY command:

~DYE:DINALTERNATE,A,T,...

Relevant label code:

^XA
^PW720
^LL360
^CI28
^CWJ,E:DINALTERNATE.TTF
^FO152,288
^GB125,63,63,B,2
^FS
^FO166,307
^AJN,37,37
^FR
^FD10 ML
^FS
^XZ

Observed result:

The black rounded rectangle is rendered correctly, but the text 10 ML appears as hollow or outlined characters. Only the contours of the glyphs are white, while the interiors remain black.

Expected result:

The custom font should be rendered as solid white text knocked out of the black rectangle. According to the ZPL behavior of ^FR, the entire glyph area should be reversed against the existing black background.

The exported ZPL does not contain any command requesting outlined or stroked text. The relevant field only contains:

^AJN,37,37^FR^FD10 ML^FS

I also tried referencing the font directly instead of using the ^CW alias:

^FO166,307
^A@N,37,37,E:DINALTERNATE.TTF
^FR
^FD10 ML
^FS

This is functionally equivalent and should still produce solid reverse text.

The field order also appears correct:

1. The filled black ^GB field is drawn first.
2. The custom-font text field is drawn afterward.
3. ^FR is applied only to the text field.

Possible area to investigate:

The ZPLLab canvas renderer appears to render reverse text using a white fill combined with:

globalCompositeOperation: "difference"

in KonvaObject.tsx.

It may be worth checking whether Konva’s difference compositing behaves incorrectly when the text uses a dynamically loaded custom font. The result looks as though only the glyph edges are being composited, while the glyph fill is being cancelled or covered.

A useful control test would be to replace the custom font temporarily with Zebra’s built-in font:

^FO166,307
^A0N,37,28
^FR
^FD10 ML
^FS

If the built-in font renders as solid white while the custom TTF remains outlined, the problem is probably specific to the custom-font rendering path. If both fields appear outlined, the issue may affect the general implementation of ^FR.

I have attached a screenshot showing the outlined text