xyz-tools/gcode-preview

What happens Load any preset (e.g. 3DBenchy), then drag & drop a G-code file onto the canvas. The info widget updates the file name, size, layer count and slicer, but the model credits and the thumbnail still belong to the previously selected preset. So a dropped file ends up displayed under someone else's model name, designer and license: 3DBenchy by CreativeTools CC0 - public domain dropped-test.gcode (733.57 kB) Sliced with PrusaSlicer The attribution is wrong rather than just stale, which is the part that matters — it credits a model the user did not load. Why model is only ever assigned in selectPreset() in demo/js/app.js, from preset.model. Nothing clears it on drop. The thumbnail has the same shape of problem: updateUI() sets thumbnail.value from the parser metadata, so a dropped file whose slicer embedded no thumbnail leaves the previous preset's thumbnail on screen. Suggested fix Clear the preset-derived state when a dropped file starts loading. The demo already listens for

Problem src/thumbnail.ts builds its data URL with a hardcoded prefix: const prefix = 'data:image/jpeg;base64,'; The embedded payload is not necessarily JPEG. Slicers embed different formats: PrusaSlicer/SuperSlicer write PNG (and QOI in newer versions), Bambu Studio writes PNG, some others write JPEG. Reproduction demo/gcodes/screw.gcode embeds two PrusaSlicer thumbnails (16x16 and 220x124). Loading it and reading: preview.parser.metadata.thumbnails['220x124'].src gives data:image/jpeg;base64,iVBORw0.... iVBORw0 is the base64 encoding of the PNG magic bytes \x89PNG, so the payload is PNG while the URL declares JPEG. Impact Low. Browsers sniff the content and render it anyway (the image decodes at 220x124), so it is not visible in an <img>. But any consumer that trusts the declared MIME type gets the wrong answer: saving the file with an extension derived from the type uploading it somewhere that validates the content type fetching the data URL and checking blob.type Proposed fix Dete

Set home offsets so the current position becomes the origin. Seen in: calibration workflows; rare inside print files. Behavior: equivalent to setting M206 offsets such that the current position reads as zero. Related: #434 Docs: M428

Apply a persistent offset that shifts the coordinate origin. Seen in: start gcode and configuration on Marlin/Prusa/Smoothieware. Behavior: persistent origin shift applied to subsequent moves, taking effect after homing. Gotchas: RepRapFirmware implements it as the equivalent of a negative G10 L2 offset on coordinate system 1. Related: #435, #422 Docs: M206

Interpret X/Y/Z coordinates as absolute or relative depending on mode. Seen in: every file's start gcode sets G90; G91 typically wraps Z-hops and end-gcode lifts. Behavior: mode flag for XYZ interpretation; in relative mode each move adds to the current position. Gotchas: in Marlin/Prusa, G90/G91 also affects E unless M82/M83 overrides it; on RepRapFirmware they never affect E. Related: #419, #433 Docs: G90 / G91