fit() cut words the moment a line overran, so the style row printed as
"Electro, Synth-…" -- the one line a customer scans for -- while the extension's
own label engine printed it whole. Step the font down to ~70% of its authored
size first (still legible at 203 dpi) and only ellipsise if it still will not
fit. Returns (text, font) so callers draw with whatever size actually fitted.
Verified on the rfid65 render: the full "Electro, Synth-pop" at a slightly
smaller bold.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
render() always rotated the landscape design 90 degrees -- right for the 24 mm
narrow stock, which feeds narrow-edge-first, and wrong for the 65 x 35 UHF roll,
whose 65 mm is the WEB. On that roll the rotated design ran along a 35 mm label:
printed sideways and clipped after ~35 mm, seen on the bench.
rotate now defaults from the profile (rfid65: False) and only an explicit
argument overrides it, so the Dymo path (which passes rotate itself) is
untouched. When a label-printer profile is unrotated the canvas is still the
media -- web x pitch, 65 x 35 -- with the 64 x 34 design centred, not an
art-sized bitmap; that art-sized case is kept only for the Dymo, whose head is
wider than its label. Offline render verified 520 x 280 px = 65.0 x 35.0 mm,
upright.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
web 65 / pitch 35 / gap 0 / art 64x34. 65 is the roll width and 35 the label
length: sent the other way round (SIZE 34,65.35) the printer advanced nearly two
labels per feed, which presented as an inlay that never stopped at the antenna.
gap=0 because the inlay fills most of the label and blinds the optical gap
sensor. Proven with a real print-test on this roll -- printer returned Ready, no
VOID -- so callers stop passing w/h/gap overrides.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Answers "can we direct print to the Dymo via CUPS, or is it the cmd-P dance?":
neither. The LW450 (0922:0020) is a bidirectional USB printer-class device just
like the Urovo, so its raster protocol goes straight to the bulk endpoint -- no
DYMO driver, no CUPS queue, no print dialog. Command set taken from DYMO's own
LabelWriter 450 Series Technical Reference Manual and documented in dymo.py.
Verified on the bench: revision 1750111r53, status 0x03 Ready, 283 raster lines
at 82 bytes/line accepted.
Also corrects an assumption inherited from daemon.cs: UHF WRITE commits
immediately and does NOT wait for PRINT. Confirmed by writing a chip and reading
it back with no PRINT sent. Two consequences:
- the Urovo can program a chip without printing or consuming a label, which is
what makes the Urovo-encodes/Dymo-prints split work at all;
- an encode can be verified BEFORE printing, so a failed write never costs a
label. /print-encode and /encode both do this now.
New routes: /devices (all three devices at a glance), /encode (chip only),
/print-paper (Dymo), /tag-and-print (Mode A in one call).
label.py is now resolution-aware (203 dpi Urovo / 300 dpi Dymo via profile(dpmm=))
and orientation-aware: the Urovo's 24mm web feeds narrow-edge-first so the design
rotates 90 degrees, while the Dymo's 57mm head is wider than the label so the same
design feeds landscape unrotated.
Also fixes tag read parsing: with dataFormat 'H' the printer replies in ASCII hex
TEXT, not raw bytes -- the old code hex-encoded it a second time. flush_in() now
drains fully, since a late reply to one command was being attributed to the next
and silently corrupting reads.
KNOWN ISSUE: the Node rfid-daemon (Chafon + scale + inventory) also binds :7790.
Both cannot run at once and this service does not implement its routes. Unresolved.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
ASSESSMENT.md §7 assumed the RFID encode was locked inside the Windows-only
GTSPL_SDK.dll and would need a USBPcap sniff or the GTSPL Java jar to recover.
It didn't. The DLL is a managed .NET assembly, and its IL shows every RFID call
is a one-line String.Concat -> ASCII -> WritePrinter. Recovered from ldstr order
plus argument order, and confirmed by a second independent decompile:
UHF WRITE H,2,12,E,"<24 hex>" UHF READ/QUERY ...
UHF GEN2 EPC|TID|USER|ACCESS|KILL <action>,"<pw>"
SET RFID <tagType>,<rw_pos>,<void>,<try>,<err>,<speed>,<retry> (dots, not mm)
&DEFAULT,i &CALIBRATE,A,R PRINT <set>, <copy>
So the whole recipe is plain ASCII over the printer's bulk endpoint and ports to
macOS with no vendor binaries at all.
- mac/urovo.py USB transport + full GTSPL command set, status decoding, the
ribbon-latch recovery, SKU<->EPC packing ported from daemon.cs.
- mac/label.py PIL bitmap renderer -> TSPL BITMAP. Media-profile driven, so both
shop stocks work (small 51x19 and large 55x24 on the 24mm web),
with a safe-area inset so the design can't clip at the edges.
- mac/daemon.py :7790 HTTP service, same routes/JSON/CORS as daemon.cs, plus a
/preview route that renders a label as PNG without printing one.
Verified on the bench from macOS: printer identifies (MODEL:UROVO-D812R), the
latched 0x08 "out of ribbon" clears with SET RIBBON OFF + FORMFEED, and labels
print correctly oriented and dark on the 24x55 stock.
NOT yet verified: the RFID encode itself. It is wired and the printer accepts the
command, but the loaded thermal stock has no inlays so nothing has been written to
a chip. Needs a PET RFID label at the antenna. The SKU<->EPC byte layout also
remains unconfirmed against existing Chafon-written tags.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
