Lay lists out with ^FB field blocks - #57
Merged
Merged
Conversation
Consecutive list items were each emitted as their own ^FO/^FD pair with a Y coordinate computed on the host. A run of items is now one ^FB field block: a single origin, items joined with \&, and the printer performing the line advance. For a 19-line list that is 83 -> 38 commands, 557 -> 395 bytes, and 18 -> 6 computed origins. It also fixes silent truncation. Text wider than ^PW was clipped at the right edge with no error; inside a block the same text wraps. Teach ZPLLengthEstimator about ^FB first, since InjectLength would otherwise compute a wrong ^LL for any block label. The estimator now models the block width, its line-spacing parameter, its max-lines cap, and the wrapping the printer will do inside it -- wrapping being the part that cannot be had from counting \& separators. Wrap estimation has no font metrics to work from, so it charges each character a fixed fraction of the declared cell width. Font 0 is proportional and measures near 0.44 of its cell against Labelary; 0.6 is used for headroom, which leaves ^LL a little long rather than short, because running long wastes media and running short clips the print. The bundled zpl2png helper does not implement ^FB -- it renders a block's first line and silently drops the rest -- so the list examples preview via LabelaryRenderer, which matches the ZD620. This makes those previews require network access; printing is unaffected. A literal \& in item text is deliberately left unescaped because it cannot be escaped: the printer applies ^FH substitution before scanning for line breaks, so _5C& becomes \& and breaks the line just the same. Such an item prints as two lines, losing layout but not content. Fixes #54
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.
Fixes #54
A run of consecutive list items is now emitted as one
^FBfield block — a single^FOorigin, items joined with\&, and the printer performing the line advance — instead of one host-computed^FO/^FDpair per item.Measured on a 19-line list (
labelprint zpl, before vs after):^FOThe remaining origins are the 3 headers and the 3 blocks between them.
^FBalso fixes silent truncationText wider than
^PWwas clipped at the right edge with no error. Inside a block the same text wraps. Verified against Labelary — a 74-character item now prints on two lines instead of losing its tail.ZPLLengthEstimatorlearns^FBfirstThis was the prerequisite:
InjectLengthwould otherwise compute a wrong^LLfor any block label. The estimator now models the block width, its line-spacing parameter, its max-lines cap, and — the part that can't be had from counting\&separators — the wrapping the printer does inside the block.It has no font metrics, so it charges each character a fixed fraction of the declared cell width. Font 0 is proportional and measures near 0.44 of its cell against Labelary; 0.6 is used for headroom, so
^LLruns a little long rather than short. Running long wastes a little media; running short clips the print.Decisions worth review
Two things went differently from the issue's description, both verified against Labelary rather than assumed:
zpl2pngis worse than "renders\&as glyphs" — it renders a block's first line and silently drops the rest. Per the decision on the issue,labelprint previewandexample-reminderlist previewnow useLabelaryRenderer, which matches the ZD620. Those previews therefore need network access; printing is unaffected, andcompare-renderersstill shows the divergence.A literal
\&in item text cannot be escaped. The printer applies^FHsubstitution before scanning for line breaks, so_5C&becomes\&and breaks the line just the same (verified — I tried it). Such an item prints as two lines: layout is lost, content is not. Documented onescaped(_:)rather than papered over.Tests
133 pass. New coverage: 6 estimator tests (block spacing, wrapping, word-boundary breaks, max-lines cap, per-field scope, zero font width) and 3
ListLayouttests (block grouping, header ending a run,^LLcovering wrapped lines). Existing tests that asserted the per-item^FOform were updated to the block form — the same geometry facts, restated.