Fix invalid JSON in receipt print response#81
Closed
Igglybuff wants to merge 8 commits into
Closed
Conversation
Adds a Dockerfile, docker-compose.yaml, and .dockerignore for running Estrella as a container. The image is built locally; publishing is left as a future improvement. The serve command gains a --width flag (also readable from the PRINTER_WIDTH env var) specifying the printer's dot width. Defaults to 576 to match the TSP650II. Set to 384 for 58mm printers like the mC-Print2. PRINTER_DEVICE and LISTEN_ADDR env vars are added for the other serve options for consistency. All server handlers (photo, patterns, weave) now use the configured width instead of a hardcoded reference to PrinterConfig::TSP650II. Dividers in the patterns and weave handlers derive their character width from the printer dot width so they don't wrap on narrower paper. Adds PrinterConfig::MCP21 (384 dots, 58mm) alongside the existing TSP650II constant, and a PrinterConfig::with_width() constructor for building a config from an arbitrary dot width. README gets a Docker section covering the build, bluetooth setup, docker compose usage, environment variables, and persisting the RFCOMM binding with a systemd unit. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Same fix as patterns and weave: derive chars_per_line from printer_width instead of using Divider::default(), which assumed TSP650II column count. Also threads printer_width into the preview handler. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
The env attribute on #[arg] requires clap's env feature flag. The PrinterConfig import in receipt.rs was unused after refactoring build_receipt to take a raw u16 width. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
The Markdown component gains two new optional fields: - `size: [u8; 2]`: height and width multipliers for body text (0 = 1×, 1 = 2×, etc.), defaulting to [0, 0] (no scaling). Heading sizes within the document are unaffected; this controls the base font size for paragraph text only. - `chars_per_line: Option<usize>`: when set, body text is word-wrapped to this column width at 1× size. The emit logic divides by the width multiplier to find the effective wrap column, so the same field works correctly at any scale. Word-wrapping is performed in a new `emit_wrapped` helper that tracks the current column position and inserts newlines at word boundaries. Soft breaks are suppressed when word-wrapping is active (they are handled implicitly as spaces). Hard breaks and paragraph ends reset the column counter. Both fields default to their zero/None values, so all existing documents and API callers are unaffected. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Pass `chars_per_line` (derived from `printer_width`) into the Markdown component so body text word-wraps correctly on narrow paper. Also reduce the default receipt title from size [3, 2] to [1, 1] — the original value was calibrated for 80mm paper and produces oversized output on 58mm printers. Add `TZ` as a commented-out example in docker-compose.yaml. Timestamps in printed receipts use the system clock, so without a TZ env var the container defaults to UTC; setting this to the local timezone gives correct printed times without rebuilding the image. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Add `title_size` and `body_size` fields to `ReceiptForm` so callers can override the character size multipliers per-request without changing any defaults. Both accept a `[height, width]` array where 0 = 1×, 1 = 2×, etc. Defaults are unchanged from the original: `title_size` defaults to [3, 2] and `body_size` defaults to [0, 0] (normal size), so existing API callers are unaffected. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
success_response and error_response were building JSON via string interpolation. A title containing any characters (particularly the wrapping quotes added by the format string) produced malformed JSON that browsers couldn't parse. Switch both functions to use axum::Json with serde-derived structs.
Author
|
Woops, ignore this one, forgot to cherry-pick. Correct PR: #82 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The
success_responseanderror_responsefunctions were building JSON via string interpolation. When a title was provided, the format string wrapped it in literal"characters which were then embedded directly into the JSON string value, breaking the response:The
None/no-title branch happened to produce valid JSON, so the bug only manifested when a title was actually supplied.Fix: switch both functions to
axum::Jsonwith serde-derived structs so serialization is always correct regardless of input.🤖 Generated with Claude Code