[Feature Request] Journey Book PDF: photos don’t scale (cropped), cover-title overlap, dropped photos + export options

[xthephreakx]

Type: enhancement / bug
Component: Journey Book PDF export (Travel Journal → Save as PDF)
Version: 3.4.1 (self-hosted, Docker)

Summary

The Journey Book PDF is a lovely idea, but in practice the layout leaves a lot of
polish on the table. On a real journey (12 entries, mix of long text and 0–5 photos
per entry) the output has large empty pages, a cover whose title collides with the
decorative script, and it silently ignores photos beyond the third on an entry.

What I observed

1. Cover: long titles overlap the decorative script watermark.
   With the title “Australië & Bali 2013” the bold title and the large cursive
   background version of the same title overlap and become hard to read — the script
   sticks out on both sides behind the solid title. Long / multi-word titles aren’t
   handled.

2. Text-only or few-photo entries waste ~half the page.
   A4-landscape entries with no photos render the text at the top and leave the entire
   lower ~60% blank. There’s no vertical centering, no scaling, and no option to place
   multiple entries per page, so a journal with rich text but sparse photos looks empty.

3. Only the first 3 photos per entry are rendered.
   The entry layout is fixed to hero + 2 stacked (e[0], e[1], e[2]). If an entry
   has 4–5 photos, the extras are silently dropped from the book — surprising, since the
   journal UI lets you attach more.

4. Photos are a fixed size and don’t scale — and are cropped.
   Photo slots use a hard-coded height (e.g. height: 45vh for the duo, similar for the
   trio) together with object-fit: cover. Two consequences:

   • No scaling to fit: the images stay locked to that fixed height regardless of how
     much empty space the page has, so they never grow to fill the generous whitespace
     (or shrink to sit alongside long text). The result reads as a small photo block
     stranded in a large empty page.
   • Cropping: because of object-fit: cover, the fixed box crops the image —
     portrait photos in particular get badly cut off (heads/subjects out of frame). There
     is no orientation/aspect-ratio handling. Concrete example: an entry photo of an
     airplane against the sky is cropped so tightly that only the sky remains and the
     plane — the actual subject — is gone.

5. The pros/cons card can orphan onto its own near-empty page.
   When an entry’s photos + text nearly fill a page, the “Could be better / Loved” card
   is pushed to a second, otherwise-blank page.

Suggested improvements

• Cover: fit/scale (or hide) the cursive watermark to the title width, or truncate
  gracefully, so long titles stay readable.
• Export options — allow hiding the title: offer a toggle to omit the title (and/or the
  decorative script watermark) on export. Some users just want a clean cover photo, or a
  title-less book — and it’s the simplest possible fix for the overlap above. Ideally a
  small set of export options here: show/hide title, show/hide script, show/hide stat tiles.
• Fill the page: for entries with little/no imagery, vertically center the content,
  scale type up, and/or allow packing multiple short entries per page. Consider a
  “compact” vs “photo-book” density toggle.
• Show all photos: support >3 photos per entry (e.g. a grid/masonry that grows to
  additional rows or pages), or at least make the per-entry photo count explicit/configurable.
• Respect aspect ratio: offer object-fit: contain (matte background) or an
  orientation-aware layout with real portrait slots, so photos aren’t cropped.
• Keep cards with content: avoid orphaning the pros/cons card onto a blank page.

Why it matters

The journal + Journey Book is one of TREK’s most delightful features; these tweaks would
make the exported book look intentional and print-ready instead of sparse, especially for
trips where the writing carries as much as the photos.

Happy to test builds / provide the sample PDF that produced the above.

Related (checked — not a duplicate)

• Discussion Large feature expansion for Journey Add-On #1614 “Large feature expansion for Journey Add-On” — broad Journey wishlist;
  its point 4 mentions “more options on how the PDF looks” but none of the specific
  Journey Book layout problems above (photo scaling/cropping, cover overlap, hide-title).
• Discussion PDF Export - remove page breaks between days #1292 “PDF Export – remove page breaks between days” — touches pagination /
  whitespace, but is a narrower/separate request.
• Existing PDF issues (e.g. [BUG] No header padding on PDF Trip Exports #1531, [BUG] PDF Trip Export - Add padding to overflowing (next page) place/event cards #1471) are all closed and concern the Trip Plan
  PDF, not the Journey Book.

[SimMesg20]

I am currently fleshing out how the entire to pdf/book/other formats could work better, i am open to feedback, you already attached my FR as i can see.

This entire better formating and more choices is my next goal for the Journey rework

[xthephreakx]

Great to hear this is next up. I'd be happy to go beyond feedback and actually help build it — I took a look and the Journey Book output all lives in one self-contained file (client/src/components/PDF/JourneyBookPDF.tsx, plus its test), so several of these are pretty contained fixes:

• swap object-fit: cover for an aspect-aware layout (contain/matte or orientation-aware slots) so subjects don't get cropped out,
• let renderPhotoBlock handle more than 3 photos with a grid that grows,
• replace the fixed vh heights with a layout that fills the page,
• an options prop for the export toggles (title / script / stats).

Since you're actively reworking this area, I don't want to send a PR that cuts across your direction. Could you share where you're heading — is there a design/branch you're working toward, and would focused PRs be welcome during the rework, or would you rather I hold until the new structure lands? Happy to start small with a single low-conflict fix (e.g. the crop/aspect-ratio one, or "show all photos") if that helps.

Either way I can share the sample PDF that surfaced these. Thanks for the great work on TREK!

[SimMesg20]

i have yet to actually develop on it, still trying to think how to make it properly, if you want we could think of a shared solution and once the Trek team says thats good ill implement it.
I am not sure how easy it would be to work together on it due to the few files that would be affected.

I was currently thinking of 1 obviously fixing the format issue, but to also make building the pdfs more individual, having a actual "designer" that lets you form how large pictures are and how they are placed, aswell as the other text elements.

[xthephreakx]

Sounds good — I actually like the "co-design, then you implement once the TREK team signs off" workflow. With such a small file surface, agreeing on a spec and having one person implement is cleaner than two of us editing JourneyBookPDF.tsx in parallel.

On direction: a full visual designer is a great end goal, but it's a big lift — so maybe phase it so users get wins early:

Phase 1 — fix the defaults (no schema change). Aspect-aware photos (contain/matte or orientation-aware slots so subjects aren't cropped), images that scale to fill the page, and renderPhotoBlock handling >3 photos. This alone makes the current book look intentional.

Phase 2 — presets + export options. A small set of named per-entry layouts (e.g. full-bleed photo, hero + grid, text-focus, collage) plus global toggles (density, show/hide title / script / stats). Store just a layout key (+ optional per-photo fit/span) on the entry — cheap schema-wise, and it's exactly the data a designer would emit.

Phase 3 — the visual designer. Drag/resize picture and text blocks that write into that same layout model. Because phase 2 already defines the data, the designer is a UI on top rather than a rewrite.

The nice part: if the designer emits a simple declarative layout object (blocks with position/size + a fit mode), the PDF renderer stays dumb and testable, and the same layouts can render both on-screen and in the book.

Happy to draft a short spec (layout data model + the phase-1 default rules) as a starting point for the TREK team to react to — want me to?

[SimMesg20]

Sounds good,
i am prototyping right now to see how it would look in its entirety but yea i agree a bit after bit roll out might be better, although if its easier then assumed i might put out the entire thing at once, it really comes down to how complex it might be.

for now i was thinking of splitting the one file into multiple making it more maintainable and co-developing friendly.
something like this for example:

client/src/features/journey-export/

model/

render/

preview/

designer/

persistence/

[xthephreakx]

That structure looks great — splitting it up is the right call, and it maps cleanly onto the phased idea. Rough responsibilities as I'd see them:

• model/ — the declarative layout schema + defaults. A JourneyBook doc made of pages/entries, each entry a set of blocks (photo / text) with position, size/span and a fit mode. This is the one contract everything else depends on.
• render/ — a pure model → HTML string function for the print iframe (what JourneyBookPDF.tsx does today, but consuming the model). Kept dumb and unit-testable.
• preview/ — on-screen rendering of the same model, sharing the layout math with render/ so preview == PDF (no WYSIWYG drift).
• designer/ — the editing UI that mutates the model (drag/resize), emitting model changes only.
• persistence/ — load/save the model per journey, plus a "generate sensible default layout from entry photos/text" step for journeys that have none yet.

The big win of nailing model/ first: render and designer can then be built in parallel without stepping on each other, and the phased rollout falls out naturally — phase 1 is just good defaults in model + render, phase 2 adds presets/options, phase 3 is the designer writing into the same model.

If it's useful, I can draft the model/ types (the layout/block schema + the phase-1 default-generation rules) as a first strawman for you and the TREK team to poke holes in. Want me to put that up?

[SimMesg20]

If you are up for it you can take a spin at it. i am currently in the midst of giving the split into multiple files a try.

[SimMesg20]

#1718
i have done the first splitting of the files if you want to take a look at it

[xthephreakx]

Nice — the split makes this really clean to build on. I went ahead and implemented the Journey Book fixes on top of your feat/add-journey-export-designer branch, and it works end to end.

To be sure it wasn't just theory, I built the branch + change into a Docker image and ran it against a real 12-entry / 20-photo journey (neutral test images). Before vs after:

• Before: photos cropped so the subject is cut off, capped at 3 per entry, large empty pages.
• After: every photo shown in justified rows with nothing cropped, and the grouped "Options" popover (Layout / Cover / Content toggles) works live and carries into the export.

I've opened a PR onto your branch so it stacks on the refactor instead of cutting across it: SimMesg20#1. More than happy to reshape it to match where you're taking the designer — it's a starting point, not a fait accompli.

Before — cropped, max 3 photos (the subject is cut right out of the purple tile):

After — justified rows, every photo, nothing cropped:

Export options — the new grouped popover (Layout / Cover / Content):

Mood / weather chips + verdict card: