Skip to content

feat(engine): export LoadImages for non-raster painters - #114

Merged
tannevaled merged 1 commit into
mainfrom
export-load-images
Sep 4, 2026
Merged

feat(engine): export LoadImages for non-raster painters#114
tannevaled merged 1 commit into
mainfrom
export-load-images

Conversation

@tannevaled

Copy link
Copy Markdown
Contributor

Summary

  • `Engine.LoadImages` is a thin exported entry point over the existing (unexported) `loadImages`: fetch, decode, budget and viewport-fit every `` and inline ``, returning the intrinsic-size map `layout.LayoutDocument` needs and the bitmap map a painter needs, both keyed by element.
  • Motivation: `go-pdfkit/html2pdf` runs the engine's own cascade + layout but paints to a vector PDF instead of the raster canvas. Without this it had no way to size or draw images short of re-implementing fetch/decode/budgeting — which the fleet doctrine says to share, not silo. `RenderDocument` uses the exact same code path, so the consumer draws images exactly as the engine would.
  • No behaviour change for existing callers; `loadImages` itself is untouched.

Test plan

  • `TestLoadImagesExported` — a data:-URI PNG round-trips offline into both maps at its 8x8 intrinsic size; a `display:none` and a src-less `` are excluded from both.
  • `go test ./...` green across every package; `go vet ./...` clean; gofmt clean on the two touched files.

🤖 Generated with Claude Code

…ter target

loadImages — fetch, decode, budget and viewport-fit every <img> and inline
<svg>, returning the intrinsic sizes layout needs and the bitmaps a painter
needs — was unexported, so a consumer running the engine's own cascade and
layout but painting elsewhere (go-pdfkit/html2pdf, which writes a vector
PDF) had no way to size or draw images short of re-implementing all of that.
LoadImages is a thin exported entry point over the same code path
RenderDocument uses, so such a consumer lays out and draws images exactly as
the built-in raster canvas does.

Covered by TestLoadImagesExported: a data:-URI PNG round-trips offline into
both maps keyed by its element, at its 8x8 intrinsic size, while a
display:none and a src-less <img> land in neither.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
@tannevaled
tannevaled merged commit e12c4d7 into main Sep 4, 2026
7 checks passed
@tannevaled
tannevaled deleted the export-load-images branch September 4, 2026 14:03
tannevaled added a commit to go-pdfkit/html2pdf that referenced this pull request Sep 4, 2026
…dImages (#2)

Both image gaps the README documented close in one step. Rather than
re-implement fetch/decode/budgeting here, Export calls the engine's own
pipeline — Engine.LoadImages, exported for exactly this in
go-webengine/engine#114 — hands its intrinsic-size map to
layout.LayoutDocument and its bitmap map to the PDF painter. An image is
therefore laid out at, and drawn at, precisely the size the engine's raster
canvas would use, and an inline <svg> arrives already rasterised by the same
path. Options.BaseURL resolves a relative src; a failed fetch/decode leaves
that element out, as on the raster canvas. This is the one place Export
touches the network.

Corpus, this run: embedded image XObjects — Wikipedia (Go) 30, countries
list 10, go.dev/blog 40, Hacker News 6, pkg.go.dev/net/http 88, react.dev
166; text length unchanged on every page. Two costs recorded in CORPUS.md:
react.dev grew to 12 pages / 9 MB (166 icon SVGs stored as raw FlateDecode
RGB, no bitmap dedup yet — the obvious next saving), and the Render column
is now network-bound for image-bearing pages since fetch runs inside Export.

Also pins go-webengine/engine to the merged #114 commit and drops the
temporary local replace used during development.

Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant