I had to build a layout engine to turn 4,000 phone photos into a printed book

Pianyubook — Thu, 12 Nov 2026 05:18:58 +0000

A phone gallery has no rules. A printed book has nothing but rules. That gap is the whole product.

I built a small service that takes someone's photos and their written (or dictated) stories and produces a print-ready PDF. It's called Pianyu — https://pianyubook.com — and the part I underestimated was not the UI or the payments. It was page geometry.

Why a template library did not work

My first version was a grid of nice templates: one big photo, two photos, photo plus caption. It looked fine on screen and was wrong for print in ways I only saw on paper:

Page breaks landed in the middle of a sentence.
A landscape photo in a portrait slot was cropped to a portrait crop, losing the face.
Widow lines: one word alone on a page, because the caption below pushed the text.
Running heads collided with the top margin.

Templates assume content fits. Books require the content to be measured and then re-flowed. So the second version is an engine, not a picker.

Fixed print geometry first, everything else after

Before any design, I fixed the canvas:

US Letter, 612 × 792 pt as the page box.
88 pt side margins, 96 pt bottom margin (the optical bottom looks bigger than it measures).
Body text 12.5 pt with a 1.6–1.75 line-height; headings 20–21 pt.
Photos are placed by aspect ratio, never by crop-to-fit. If the slot is portrait and the photo is landscape, the slot changes, not the photo.

Once the geometry is a constant, every layout decision becomes a measurement: does this paragraph fit above the photo, and if not, which page does it continue on. That is the entire engine.

The CJK font problem

The product ships in English and Chinese. A full GBK serif is around 18 MB. A subset of the glyphs actually used is about 5.6 MB. On a cold first page load that is the difference between a page that appears and a page that looks broken.

More importantly: embedding CJK in a PDF reliably was the one thing I got burned on. I started with pdf-lib, which is excellent for documents you will read on a screen, and gave up on it for CJK print output — the results were inconsistent enough that I did not trust a printer to accept them. I moved the final typesetting step to PyMuPDF, which embeds the font file directly and produces what the printer expects.

If your output is going to physical print and contains CJK, test with the actual printer before you build a product on top of it.

The free five pages

The commercial mechanism and the technical one are the same thing: the layout engine can render the first five pages for free, before payment. Nothing is hidden — those five pages are the same code path that produces the paid file, just truncated.

This changed the funnel completely. "Trust me, it will look good" does not sell a book. Seeing your own grandmother's photo set in a serif, with the caption you wrote underneath, does.

Payments were the easy part

I use a merchant of record. Tax, cards, disputes are handled upstream of me, and the webhook is a signed POST that marks an order paid after checking the amount against the SKU. Idempotent, boring, done in an afternoon.

The unsolved part is that nobody arrives. A five-day-old domain does not get indexed on demand, and a dev.to post does not bring buyers. That is a marketing problem, and it is more stubborn than any of the print bugs above.

If you want to see what the output actually looks like, two sample books (five real pages each) are here: https://pianyubook.com — and I'd genuinely like feedback from anyone who has shipped a print PDF a printer did not complain about.

I built a photo-book generator that turns your phone's photo pile into a printed book

Pianyubook — Thu, 12 Nov 2026 04:56:03 +0000

Every family has a folder like this: 4,000 vacation photos on one phone, a few hundred screenshots, and a voice memo of my grandmother describing the old house she grew up in.

Nobody ever opens that folder again. It just sits there, and one day the phone dies.

I wanted one specific thing out of it: a printed book you can put on a shelf, with the photos on the left and the story on the right.

What I built

It's called Pianyu (片语成书, "a few words make a book") — https://pianyubook.com

The flow is deliberately boring, on purpose:

You drop in photos and write (or dictate) the story around them.
The app lays out the pages, typesets the text, and produces a print-ready PDF.
You see the first 5 pages rendered for free before paying anything.
If the pages look right, you pay and get the full PDF — $19 for a photo book, $39 for an illustrated book, $79 for a full life story.

The free preview is the whole funnel. People don't trust a layout engine they can't see, and "trust me, it'll look great" is not a sales pitch.

The stack, briefly

Frontend: uni-app + Vue 3 + TypeScript + Vite, exported to H5 plus WeChat mini-program from one codebase.
Hosting: Cloudflare Pages, with Pages Functions for the API.
Payments: Creem as merchant of record. Webhook verified with HMAC-SHA256, order rows in D1, idempotent on replay, amount checked against the SKU before anything is marked paid.
PDF: my own layout engine emits page geometry, then PyMuPDF embeds the CJK fonts. I started with pdf-lib and gave up on its CJK embedding — the output was not reliable enough for something a printer will actually run.

Four things I got wrong first

1. "Print-ready" is not "looks nice on screen." Margins, bleed, and where a page break lands mid-sentence are the whole job. I rebuilt the layout around fixed print geometry after seeing the first proof.

2. CJK fonts are the real weight problem. A full GBK font is ~18MB; a subset is ~5.6MB. On a cold page load that is the difference between "fine" and "why is nothing happening."

3. I chased indexing too early. The domain was five days old. I burned hours on Search Console dashboards when the honest answer was "wait two weeks." New domains get crawled on the crawler's schedule, not mine.

4. Payments are the easy part now. With a merchant of record, tax and card handling are somebody else's problem. The hard part is that nobody arrives to pay.

Where it stands

Payments are live and verified end to end. Indexing is slowly happening. Traffic is the actual unsolved problem, and it is a marketing problem, not an engineering one.

If you have a photo pile and a story attached to it, the first five pages cost nothing to look at: https://pianyubook.com

Feedback on the layout engine is very welcome — especially from anyone who has shipped a print PDF that a real printer accepted without complaining.

DEV Community: Pianyubook