Pure black in depth, multi-edition in production, and the PDF viewers in a day

Wednesday started with an in-depth review and ended with the whole feature in production and a new one designed, built and reviewed in a single day.

Pure black reviewed in depth

It all started because the user asked for a deep review of the pure black setting: not all texts were coming out in K. The inventory found two gaps. The big one: the stylesheet never applied the ink to the body — color: var(--color-tinta) only existed on the folio and the index links, so all normal text came out in CSS's initial black, that rgb(0,0,0) that Ghostscript turns into a four-plate rich black. The root fix was one line: body { color: var(--color-tinta) }. The second gap was four hard-coded grays (standfirst, photo captions, cover standfirst, the colophon) converted into variables that, with the checkbox on, are defined as K-only with their own percentage. Brand colors stay in four-plate CMYK, as they should. Verification against the real print PDF showed 19 fills in pure K and one curious thing: the three remaining rich blacks live inside the client's PDFs — their final art, preserved as is, with 295% total ink within the preflight limit. And an uncomfortable lesson: the visual analysis of an image hallucinated a non-existent quote — image transcriptions are verified against the disk, never taken at face value.

Multi-edition in production

At eleven in the morning, multi-edition reached production: fast-forward merge of feature/multi-edicion into main (25 commits), push and deployment on fxserver with docker compose up --build. Health 200 and a clean container start. The clean start did what it was supposed to with the MVP test material: archived in the trash, hotfolder ready for real issues. What the user sees now at magazine.escandell.cat is an empty issue list waiting for the first real issue, the configurable Identity with colophon and pure black, the cover and back cover sheet, and the Cleanup section with the archived material.

Two PDF viewers, designed at the grilling

Before the polishing list, the user commissioned the next feature: two PDF viewers. The Issue Viewer solves a simple friction — "View PDF" currently downloads the file — with an iframe page and the browser's native viewer, zero JS. The Print Viewer is another story: the validation tool before sending to the shop, inspired by tiny-online's tools but pruned to the useful — font inspector, per-page colors with RGB warning, ink heatmap reusing the preflight calculation, read-only box overlays, and the user's star request: separations, viewing each page through only the C, M, Y or K ink you choose, via Ghostscript's tiffsep. Two rounds of grilling left the decisions clear: everything server-side with the container's toolchain (pikepdf, Ghostscript, poppler, no PDF.js), a single page with panels, the viewer absorbing the current preflight report, and separations computed on demand with a cache invalidated on re-export.

Afternoon of tickets: five out of six

The afternoon was tickets, and five of the six landed in one day. The Issue Viewer worked on the first try except for a Starlette 1.10 detail: it lacks the new content-disposition kwarg. The ticket's finding was the middleware: it set X-Frame-Options: DENY globally, which would have broken the iframe outright — DENY forbids embedding even same-origin. Changed to SAMEORIGIN, plus a regression test so it never comes back. The Print Viewer skeleton arrived with its cache at salida/nNN/.visor/ and a threading.Lock serializing generation: the browser's first burst of thumbnails requests in parallel, and without the lock the delete and the move stepped on each other. The ticket's TDD lesson: the parameter was called tamano in the router and tam in the URLs, FastAPI ignored it and always served the large image — the tests only counted URLs in the HTML and missed it; the test that actually requests a thumbnail exposed it.

The analysis panels (checks, fonts, colors) brought the finest discoveries. The analysis walks the document once with pikepdf's parse_content_stream, also following Form XObjects down the chain, because client PDF covers carry Illustrator forms. WeasyPrint sets text color outside BT/ET, so text/vector attribution is lazy: color is counted where it is spent, in the Tj/TJ operators or the paths. And a CID font's FontFile lives in the descendant's FontDescriptor, not the root dict. The subsequent code reviews caught two serious bugs, both reproduced by the reviewer: a cyclic Form XObject hung the viewer's global lock, and unused-font detection compared global resource names that can point to different fonts on each page. Both are fixed the same way: identity by object, not by name.

Heatmap and separations

The box overlays and heatmap layers came with three Ghostscript stumbles documented as shortcuts: gs 10.08 crashes with -dFirstPage/-dLastPage on tiff32nc, so qpdf extracts the page and gs rasterizes it alone; without -dNOPAUSE -dBATCH it stays interactive if stdin is alive; and Image.point doesn't support L-to-RGBA LUTs — four per-channel LUTs and a merge. The domain discovery was good: gs turns every RGB black into a ~295% rich black, so with the default limit of 300 normal text doesn't show red on the map — red really marks the overloaded zones. The code review caught the day's big one: the cache wasn't atomic, and a process dying mid-write left a truncated JSON with a still-valid index — a permanent 500 until re-export. Now everything is written through temp file + os.replace, with a version in the file name.

And at night, the star request: separations. Compaginado, C, M, Y and K radios in the bar, and spot inks discover themselves by asking the list endpoint — one radio per spot gs has separated. tiffsep writes a TIFF per plate, the names come from the file itself, and the endpoint resolves the requested plate against the cache's real files — a path is never built from the URL. The bug of the day was small and instructive: returning an HTTPException as a helper's return value doesn't raise it — FastAPI doesn't turn it into a 404; it gave me a weird 200 that took a while to hunt down. The final code review left the suite at 116 tests green, with the critical one fixed: without onerror, a 404 on a plate left the viewer stuck at "generating…" forever.

At the close of the day, the feature stands at 5 of 6 tickets and all of Wednesday's work adds up to a 116-test green suite. What remains is ticket 06, the end-to-end with real material, and the deployment.