Summary
Generated PDF page dimensions are consistently ~2.8x oversized in both directions. Root cause appears to be that the tool computes the correct label size in dots (from ^PW/^LL, or from explicit width/height/dpi parameters), then writes those dot values directly into the PDF's /MediaBox as if they were PDF points (1/72 inch), instead of converting dots → inches → points.
Reproduction
Tested against 22 real-world ZPL label files (various VSR carton/pallet label types, all intended as standard 4"×6" labels at 203 DPI). Confirmed four separate ways, all producing the same wrong result:
- Letting the tool auto-detect from
^LL1219 in the ZPL (no ^PW present) — CLI conversion mode, no extra flags.
- Injecting
^PW812 (812 dots = 4in × 203dpi) directly into the ZPL before conversion.
- CLI flags:
ZPL2PDF.exe -i input.zpl -o outputFolder -w 4 -h 6 -u in -d 203
- REST API, using the exact documented request body from
docs/guides/API_GUIDE.md:
{
"zpl": "...",
"format": "pdf",
"width": 4.0,
"height": 6.0,
"unit": "in",
"dpi": 203
}
Expected
A 4in × 6in label should produce a PDF page with /MediaBox [0 0 288 432] (288pt = 4in × 72, 432pt = 6in × 72).
Actual
/MediaBox [0 0 813 1219] on every method above — i.e. the dot dimensions (4in×203dpi=812, 6in×203dpi=1218, rounded to 813/1219) written directly as PDF points. That's roughly 203/72 ≈ 2.82x oversized in both width and height. Confirmed on 22/22 real label files, 0 exceptions, regardless of whether the source ZPL already contained ^PW/^LL or dimensions were passed explicitly via API/CLI parameters.
Environment
- ZPL2PDF v3.1.3, Windows x64 (self-contained build,
ZPL2PDF-v3.1.3-win-x64.zip)
- Reproduced via both CLI conversion mode and REST API mode (
--api --renderer offline)
--renderer offline (BinaryKits-based local renderer) — have not tested whether --renderer labelary has the same issue, since that renderer mode appears to be broken in a separate way (see companion issue).
Cross-check
For comparison, sending the same 22 filtered ZPL files directly to the real Labelary cloud API (api.labelary.com/v1/printers/8dpmm/labels/4x6/0/) produced correct output on all 22: /MediaBox [0.0 0.0 288.0 432.0] exactly, every time. So the dot→point conversion is the specific gap here, not a fundamental limit of rendering these labels correctly.
Happy to share sample input ZPL / output PDFs if useful for reproduction.
Summary
Generated PDF page dimensions are consistently ~2.8x oversized in both directions. Root cause appears to be that the tool computes the correct label size in dots (from
^PW/^LL, or from explicitwidth/height/dpiparameters), then writes those dot values directly into the PDF's/MediaBoxas if they were PDF points (1/72 inch), instead of converting dots → inches → points.Reproduction
Tested against 22 real-world ZPL label files (various VSR carton/pallet label types, all intended as standard 4"×6" labels at 203 DPI). Confirmed four separate ways, all producing the same wrong result:
^LL1219in the ZPL (no^PWpresent) — CLI conversion mode, no extra flags.^PW812(812 dots = 4in × 203dpi) directly into the ZPL before conversion.ZPL2PDF.exe -i input.zpl -o outputFolder -w 4 -h 6 -u in -d 203docs/guides/API_GUIDE.md:{ "zpl": "...", "format": "pdf", "width": 4.0, "height": 6.0, "unit": "in", "dpi": 203 }Expected
A 4in × 6in label should produce a PDF page with
/MediaBox [0 0 288 432](288pt = 4in × 72, 432pt = 6in × 72).Actual
/MediaBox [0 0 813 1219]on every method above — i.e. the dot dimensions (4in×203dpi=812, 6in×203dpi=1218, rounded to 813/1219) written directly as PDF points. That's roughly203/72 ≈ 2.82xoversized in both width and height. Confirmed on 22/22 real label files, 0 exceptions, regardless of whether the source ZPL already contained^PW/^LLor dimensions were passed explicitly via API/CLI parameters.Environment
ZPL2PDF-v3.1.3-win-x64.zip)--api --renderer offline)--renderer offline(BinaryKits-based local renderer) — have not tested whether--renderer labelaryhas the same issue, since that renderer mode appears to be broken in a separate way (see companion issue).Cross-check
For comparison, sending the same 22 filtered ZPL files directly to the real Labelary cloud API (
api.labelary.com/v1/printers/8dpmm/labels/4x6/0/) produced correct output on all 22:/MediaBox [0.0 0.0 288.0 432.0]exactly, every time. So the dot→point conversion is the specific gap here, not a fundamental limit of rendering these labels correctly.Happy to share sample input ZPL / output PDFs if useful for reproduction.