Update README.md#86
Conversation
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request updates the README to provide more detailed information about ZPL import capabilities and the differences between saving designs in .zpl and .json formats. The reviewer suggested several improvements to the documentation's accuracy, specifically recommending that ^FC (Field Clock) be listed as an unsupported command and that the claim regarding .zpl files 'round-tripping cleanly' be qualified to reflect existing parser limitations.
| > Import is best-effort: simple labels (especially those originally created in this tool) come back cleanly, complex or machine-generated ones may lose detail. Use **Save design (.json)** to keep a fully editable copy. `.zpl` is a printer output format, not a design source. | ||
|
|
||
| The parser covers the most common ZPL commands. Anything it doesn't recognize is skipped and listed in the import report. | ||
| > Import round-trips text, barcodes, shapes, images (including printer-stored and compressed graphics), and label-header settings. The main gap is variable template fields (`^FN`/`^FV`/`^FE`), which have no editor equivalent. Anything the parser doesn't recognize is skipped and listed in the import report. |
There was a problem hiding this comment.
The parser also ignores ^FC (Field Clock) commands (see src/lib/zplParser.ts line 1800), which are commonly used for date/time stamps. It would be more accurate to include ^FC in the list of known gaps.
| > Import round-trips text, barcodes, shapes, images (including printer-stored and compressed graphics), and label-header settings. The main gap is variable template fields (`^FN`/`^FV`/`^FE`), which have no editor equivalent. Anything the parser doesn't recognize is skipped and listed in the import report. | |
| > Import round-trips text, barcodes, shapes, images (including printer-stored and compressed graphics), and label-header settings. The main gaps are variable template fields and date/time codes (^FN/^FV/^FE/^FC), which have no editor equivalent. Anything the parser doesn't recognize is skipped and listed in the import report. |
| ### Saving and loading | ||
|
|
||
| Use `.json` (File → Save Design) to save your work. It preserves every object exactly and can be reopened as a fully editable design. `.zpl` is a printer output format: use it to send to a printer, not to save your design. | ||
| Both `.zpl` and `.json` round-trip cleanly. `.zpl` preserves all printable content and works as a design source: re-import it and keep editing. `.json` (File → Save Design) additionally stores designer-only state that has no ZPL representation: locked/hidden objects, items excluded from export, custom object names, and group structure. |
There was a problem hiding this comment.
The claim that .zpl "round-trips cleanly" and "preserves all printable content" is a bit strong given that several ZPL commands (like ^FN and ^FC) are explicitly ignored by the parser. If a user relies on .zpl as their primary design source for labels containing these elements, they will lose data upon re-import. It is safer to qualify this statement and continue recommending .json for full fidelity.
| Both `.zpl` and `.json` round-trip cleanly. `.zpl` preserves all printable content and works as a design source: re-import it and keep editing. `.json` (File → Save Design) additionally stores designer-only state that has no ZPL representation: locked/hidden objects, items excluded from export, custom object names, and group structure. | |
| Both .zpl and .json support round-tripping for most common elements. .zpl preserves printable content supported by the editor and can work as a design source for many labels. However, .json (File → Save Design) remains the most reliable format as it preserves every object exactly and additionally stores designer-only state that has no ZPL representation: locked/hidden objects, items excluded from export, custom object names, and group structure. |
1 participant
No description provided.