Problem
When an article has no real lead image, small images — favicons, site logos, author avatars — end up scaled up as the hero at the top of the post. A 32–64px image stretched into the hero slot looks blurry and wrong.
Nothing in either pipeline checks actual image dimensions:
- Hero render (
viewer/04-article.js ~line 912): any meta.thumbnail becomes the full-width hero. The frontmatter image: comes from the extractor's og:image/twitter:image fallback (src/extractor.ts ~line 714) — some sites' og:image IS their logo/favicon, and it gets rez'd up regardless of size.
- Card/list image fallback (
src/viewer.ts ~line 468): when frontmatter has no thumbnail, listFiles grabs the first body image filtered only by URL heuristics (w=\d{1,2}, /pixel|beacon|badge|icon/, feedburner, small gif/svg). Tiny images whose URLs don't match those patterns (avatars, inline emoji, logos without "icon" in the path) slip through and become the card image — which the Rundown deck and dash cards then display large.
Likely more visible since 0.5.1: the hero-dedup fix (#113) means heroes actually render now, so previously-invisible bad thumbnails are on screen.
Fix shape
Client-side dimension gate is the cheap, reliable half: on hero (and dash-card) <img> load, check naturalWidth/naturalHeight — below a threshold (e.g. <200px wide, or tiny-and-square like a favicon), hide the container instead of scaling up (same pattern as the existing onerror handlers). Optionally also skip URLs under /favicons/ and obvious favicon.*/apple-touch-icon filenames at pick time in listFiles.
No image beats a blurry rez'd-up favicon — fall back to the existing no-image treatment (initials/color block in cards, no hero in reader).
Filed by Claude Code on behalf of @shellen.
Problem
When an article has no real lead image, small images — favicons, site logos, author avatars — end up scaled up as the hero at the top of the post. A 32–64px image stretched into the hero slot looks blurry and wrong.
Nothing in either pipeline checks actual image dimensions:
viewer/04-article.js~line 912): anymeta.thumbnailbecomes the full-width hero. The frontmatterimage:comes from the extractor'sog:image/twitter:imagefallback (src/extractor.ts~line 714) — some sites' og:image IS their logo/favicon, and it gets rez'd up regardless of size.src/viewer.ts~line 468): when frontmatter has no thumbnail,listFilesgrabs the first body image filtered only by URL heuristics (w=\d{1,2},/pixel|beacon|badge|icon/, feedburner, small gif/svg). Tiny images whose URLs don't match those patterns (avatars, inline emoji, logos without "icon" in the path) slip through and become the card image — which the Rundown deck and dash cards then display large.Likely more visible since 0.5.1: the hero-dedup fix (#113) means heroes actually render now, so previously-invisible bad thumbnails are on screen.
Fix shape
Client-side dimension gate is the cheap, reliable half: on hero (and dash-card)
<img>load, checknaturalWidth/naturalHeight— below a threshold (e.g. <200px wide, or tiny-and-square like a favicon), hide the container instead of scaling up (same pattern as the existingonerrorhandlers). Optionally also skip URLs under/favicons/and obviousfavicon.*/apple-touch-iconfilenames at pick time inlistFiles.No image beats a blurry rez'd-up favicon — fall back to the existing no-image treatment (initials/color block in cards, no hero in reader).
Filed by Claude Code on behalf of @shellen.