There is an issue with image export. Gemini CLI will be discontinued soon, please switch to Antigravity CLI. #70

Activity

1. lefarcen

   added

   bugSomething isn't workingSomething isn't working

   on May 20, 2026
2. lefarcen commented on May 20, 2026

   

   lefarcen

   on May 20, 2026

   More actions

   Hi @LuckyFishGeek! 👋 Thanks for the detailed report and screenshots.

   Image cropping

   The left-edge crop you're seeing is interesting — our export code in image.ts uses documentElement.clientWidth to measure the viewport, which should capture the full layout width. A few possibilities:

   • The iframe might have internal padding/margin on the left that's getting excluded from the capture bounds
   • The content might be wider than the measured viewport, causing overflow that gets clipped
   • There could be a scaling calculation issue where we're setting the wrong base width for the foreignObject SVG

   Could you share:

   1. Which skill/template you're exporting? (e.g. deck-guizang-editorial, poster-modernist-grid)
   2. Rough screen/window width when you hit export?
   3. Does it happen consistently across different templates, or just specific ones?

   That'll help narrow down whether it's layout-specific or a systematic measurement bug.

   Gemini CLI → Antigravity CLI migration

   Confirmed — Google announced the June 18, 2026 sunset for Gemini CLI (free/Pro/Ultra tiers). We'll need to update the agent auto-detection and docs to reflect the migration to Antigravity CLI.

   The good news: since html-anything detects CLIs by scanning PATH for known executables, adding Antigravity CLI support should be straightforward once Google ships the new binary. If you're already using Antigravity CLI and it's not getting detected, let us know the exact binary name (antigravity? ag-cli?) and we can add it to the agent list.

   In the meantime, Claude Code should work fine as your primary agent — the 8-CLI support is about flexibility, not a hard dependency on any single one.
3. lefarcen

   added

   help wantedExtra attention is neededExtra attention is needed

   on May 20, 2026
4. lefarcen commented on May 20, 2026

   

   lefarcen

   on May 20, 2026

   More actions

   This is open for community help.

   If you'd like to work on it, comment /claim below. The first /claim after the latest release gets it. Any comment, linked PR, or progress note keeps the claim active.
5. 111wukong commented on May 20, 2026

   

   111wukong

   on May 20, 2026

   More actions

   /claim
6. lefarcen

   assigned

   111wukong

   on May 20, 2026
7. lefarcen commented on May 20, 2026

   

   lefarcen

   on May 20, 2026

   More actions

   Claimed by @111wukong. Thanks for picking this up! 🎉

   Quick question to time check-ins right — roughly how long do you think this will take?

   • A few hours / today
   • 1-3 days
   • ~ 1 week
   • Longer / unsure

   Reply with whatever fits. If you don't reply, I'll default to checking in every ~12h. Either way, any comment, linked PR, or progress note keeps the claim active.
8. lefarcen commented on May 20, 2026

   

   lefarcen

   on May 20, 2026

   More actions

   Hi @LuckyFishGeek — @111wukong opened #73 for the image-export crop part of this report. The proposed fix targets the Windows scrollbar path described above: during iframe capture, the export code switches the captured document overflow to hidden so the always-visible scrollbar does not narrow clientWidth and cut off the left edge.

   Keeping this issue open until the PR lands and we can verify the export result. The Gemini CLI → Antigravity CLI migration is still separate from this PR.

   👍React with 👍1Reacted by LuckyFish
9. LuckyFishGeek commented on May 21, 2026

   

   LuckyFishGeek

   on May 21, 2026

   Last edited by LuckyFishGeek

   Author

   More actions

   Hi @111wukong and @lefarcen,

   Thank you for looking into this! I tested the overflow: hidden fix from this PR on my Windows 10 environment, but unfortunately, the left-side crop issue still persists.

   After doing some local debugging, I found that the root cause isn't just the scrollbar. The real culprit is the centered layout (e.g., margin: auto or justify-center).

   Since the Xiaohongshu template card is fixed at 1080px wide, if the user's iframe preview area is narrower than 1080px (due to sidebars or Windows UI scaling), the card overflows to both the left and right to stay centered. modern-screenshot captures starting from coordinate X: 0, so whatever overflows to the left (negative coordinates) gets permanently cropped out. Hiding the scrollbar doesn't recover this lost width.

   The Ultimate Fix:
   To perfectly fix this, we need to temporarily force the iframe to be wide enough to contain the entire content right before capturing, and then restore it.

   I have tested this locally and the exported images are now 100% perfect with no missing left edges. Hope this helps refine the PR!

   Here is the code adjustment that completely solved the issue for me in next/src/lib/export/image.ts (iframeToBlob function):

   export async function iframeToBlob(
     iframe: HTMLIFrameElement,
     opts: ImageOpts = {},
   ): Promise<Blob> {
     // ... 
     const prevIframeHeight = iframe.style.height;
     const prevIframeWidth = iframe.style.width; // <--- 1. Record original width
     const prevDocOverflow = doc.documentElement.style.overflow;
     const prevBodyOverflow = doc.body.style.overflow;
   
     const fullHeight = fullScrollHeight(doc);
     if (!fullHeight) throw new Error("preview has no content yet");
   
     // <--- 2. Calculate true width (ensure it fits the 1080px card)
     const fullWidth = Math.max(doc.documentElement.scrollWidth, doc.body.scrollWidth, 1080);
     
     iframe.style.height = `${fullHeight}px`;
     iframe.style.width = `${fullWidth}px`; // <--- 3. Force iframe width to prevent center-overflow
     
     doc.documentElement.style.overflow = "hidden";
     doc.body.style.overflow = "hidden";
   
     await NEXT_FRAME();
     await sleep(100); // Give browser a moment to reflow the new width
     await NEXT_FRAME();
   
     try {
       // <--- 4. Use the forced width
       const layoutWidth = doc.documentElement.scrollWidth || fullWidth;
       const layoutHeight = fullScrollHeight(doc);
   
       // ... domToBlob execution ...
     } finally {
       iframe.style.height = prevIframeHeight;
       iframe.style.width = prevIframeWidth; // <--- 5. Restore original width
       doc.documentElement.style.overflow = prevDocOverflow;
       doc.body.style.overflow = prevBodyOverflow;
     }
   }   
10. lefarcen commented on May 21, 2026

    

    lefarcen

    on May 21, 2026

    More actions

    Hey @LuckyFishGeek, this is very helpful — thanks for testing #73 on the actual Windows setup.

    Your centered-layout explanation matches the capture path: if the preview iframe is narrower than the 1080px Xiaohongshu card, the document can lay out with negative left overflow, and modern-screenshot starting at x = 0 cannot recover pixels that are outside the viewport. That means the scrollbar-only change in #73 is likely incomplete for this template.

    @111wukong, the next refinement should make the capture viewport wide enough for the full content before calling domToBlob, then restore the iframe width afterward. One small implementation note: try to derive the needed width from the document/card scroll dimensions rather than hard-coding 1080, and keep the reflow wait before capture so the layout settles.

    We'll keep this issue open until #73 covers this centered-overflow case and @LuckyFishGeek can verify the export again.

    ❤️React with ❤️1Reacted by LuckyFish
11. lefarcen commented on May 22, 2026

    

    lefarcen

    on May 22, 2026

    More actions

    Hi @LuckyFishGeek — #83 is now open for the Gemini CLI → Antigravity CLI migration part of this report. It adds agy detection plus the Antigravity invocation/parser path, and it also includes a small guard so agent-side errors keep the conversion status as error instead of being silently marked done.

    Keeping this issue open while #83 is reviewed; the image-export crop work is still tracked separately in #73.
12. lefarcen commented on Oct 3, 2026

    

    lefarcen

    on Oct 3, 2026

    More actions

    Heads-up @LuckyFishGeek — draft PR #161 is now revisiting the Gemini CLI → Antigravity migration portion of this report. It adds agy detection plus the adapter’s invocation and stream-output handling across both the web app and CLI; the image-export crop investigation remains separate in #73.

    We’ll keep this issue open until the relevant changes land and can be verified.