https://gitlab.synchro.net/main/sbbs/-/merge_requests/697#note_9331
**Reviewer context / self-review notes:**
- **Based on current `master`** Ä this branch's only commit has `master` HEAD as its direct parent (linear, no rebase), so it should merge without conflict.
- **Orthogonal to the recent PBM work.** It sits on top of `a44a81fca` ("Fix reading of PBM P4 files", the row-padded `read_pbm_raw_raster`) and `d2efeb08f` ("Some minor PBM fixes"). Those fixed *raster reading*; this fixes only the *headerraster separator* that runs before them Ä no overlap.
- **Matches the PNM spec verbatim.** PBM/PGM/PPM all specify *"A single whitespace character (usually a newline)"* before the raster, which is exactly what netpbm's reference reader consumes. The previous greedy `skip_pbm_whitespace()` (multi-whitespace + `#`-comment aware) was the deviation; against a raw raster it would swallow a leading `0x09/0x0a/0x0d/0x20` byte or treat a leading `0x23` (`#`) as a comment, shifting the raster offset so a valid image reads short and `read_pbm()` returns NULL ( black image).
- **Also covers P4 masks**, not just P6: the `case '4'` path gets the same one-byte separator, so a mask whose first raster byte is unsafe is fixed too (the original report was a P6 scene, but masks share the boundary).
- **Honest caveat Ä this is stricter than the old code.** A *non-conforming* raw file with more than one whitespace byte, or a `#` comment, between the final header value and the raster used to load under the greedy skip and will now fail. That's spec-correct (ImageMagick / netpbm / the emitting door all write exactly one `\n`), but flagging it so it's a known trade-off rather than a surprise.
- **Out of scope (FYI):** the plain `P1`/`P3` *text* raster path is deliberately left on the existing code (the `default:` branch keeps the greedy/comment-aware skip, which is appropriate for whitespace-delimited text rasters). Separately, `read_pbm_number()` may still not advance across the whitespace *between* successive plain-format sample numbers Ä flagging as an unverified observation for a possible follow-up; this MR does not touch it.
Repro that motivated the fix: a 260¨144 `P6` whose top-left pixel red channel is `0x23` Ä 18 of 292 baked Infocom *Arthur* scenes for the Synchronet Z-Machine v6 door hit this and rendered black; all render correctly with the fix, confirmed on both patched and un-patched clients.
Ä *Authored by Claude (Claude Code), on behalf of @rswindell*
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net