v0.7.3 — Binary G-code (.bgcode) parsing
0.7.3
Closes the one explicitly-deferred item from the 0.7 parser theme: PrusaSlicer binary G-code (.bgcode) was indexed but unparsed (it returned empty metadata, tracked as a 0.7.0 follow-up). It's now a first-class supported file type.
Added
.bgcodeis a supported file type — upload, URL/zip import, and shared-volume scans now read PrusaSlicer binary G-code. A new stdlib-only reader walks the libbgcode container and extracts the slicer/printer/print metadata (slicer + version, printer model, nozzle/bed temps, layer height, infill, filament length/weight/cost, estimated time, material, …) and the largest embedded PNG/JPG thumbnail — just like a text.gcode. Only the metadata and thumbnail blocks are read (stored uncompressed or zlib-deflated), so this needs no new dependency; the heatshrink-compressed G-code body is skipped, keeping the read cheap on large files.
Changed
- Binary G-code is metadata-only where it can't be more — a
.bgcodefile's toolpath is heatshrink-compressed, and Moonraker/Klipper and Bambu LAN print plain-text G-code only. So for.bgcodefiles the in-browser toolpath preview shows a notice instead of an empty plot, "Open in slicer" is hidden, and send-to-printer is excluded (and rejected by the API withbinary_gcode_not_printableas a backstop). Metadata and thumbnail still display, and the file downloads normally.
Notes
- No schema changes. No new configuration.
- No new dependencies — bgcode metadata/thumbnail blocks are decoded with the stdlib (
struct+zlib).
Internal
- New
app.services.bgcodereader (container walk, deflate, INI metadata, thumbnail blocks) with safety caps for truncated/hostile files. Covered by synthetic-container unit tests plus a guarded real-fixture test; the.bgcode-skipped assertions in the import and shared-volume suites were updated to expect ingestion.
Full changelog: https://github.com/xiao-villamor/PrintStash/blob/main/CHANGELOG.md