Bridge card hero is cropped in Adom Desktop — ship a 1.6-aspect hero - Adom Desktop - RustDesk Bridge

Overview Files Skills Discover Packages Releases Dependencies Issues7 Breadcrumbs Pull Requests Activity

Open general

Bridge card hero is cropped in Adom Desktop — ship a 1.6-aspect hero

John Lauer · 4mo ago

Your bridge card's hero is cropped in Adom Desktop — the "RustDesk" / "even on Windows Home" / adom-wiki pkg install … text is clipped off the left edge.

Root cause: the bridge ships no proper hero image, so AD falls back to your wiki page's auto-generated OG social-card (1200×630 = aspect 1.90). AD's bridge-card hero banner is aspect-ratio: 1.6 with object-fit: cover, so a 1.90-aspect (wider) image is scaled to fill the banner's height and clipped on the left/right — exactly the crop you see. This is the bridge's hero, not an AD rendering bug: pup and kicad ship 2000×1250 (aspect 1.60) heroes and fit cleanly.

Fix: publish a real hero at 1.6 aspect (≈2000×1250), full-bleed, like pup/kicad. Set it as your wiki page hero (hero_path) or a hero URL in bridge.json. See the "Card hero + update cost" section of the Bridge SDK: https://wiki.adom.inc/adom/adom-desktop-bridges

Verify: open your card in Adom Desktop — the title/text must not be clipped.

1 Reply

barrett-land · 2mo ago

Likely root cause found, and it is not the aspect ratio. While republishing 0.3.3 the pre-publish linter flagged:

HERO_NOT_IN_FILES: hero "docs/hero.png" is declared but the files[] allowlist
does not match it, so the tarball ships without it

package.json declares hero.screenshot: "docs/hero.png", but files[] is ["SKILL.md", "README.md", "package.json", "rustdesk-bridge-manifest.json", "install.sh", "uninstall.sh"] — no docs/, and no hero at any path. So the package has never shipped a hero image, which matches your diagnosis that AD falls back to the page's auto-generated OG social card, and explains the clipped left edge.

That means shipping a 1.6-aspect image is necessary but not sufficient: the files[] allowlist has to admit it too, or the new hero will be dropped from the tarball exactly like the current one.

I have not fixed this in 0.3.3 — it needs an actual hero image produced (Hero Studio), which is a human step, and the linter separately notes the composed-billboard { headline, subhead, screenshot } hero shape is retired in favour of hero: { "path": "docs/hero.png" }. Both want doing in the same pass. Leaving this open with the cause recorded.