fix(codegen): avoid cropping exported image fills twice - #45
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
about-422-3376was the worst screen in the corpus at 7.46%, and its page height was exactly right - 7240 against a design height of 7240. Every defect fixed here so far has been vertical. This one was not: the content was mis-composed inside a correct height.The cause is a double crop.
A
CROPimage fill carries its framing as a matrix over the image's own 0..1 space, and the generator read that matrix and turned it into a CSSbackground-position/background-size. That would be correct if the file being positioned were the original image. It is not.image_fill_sourcenames anode.exportAsyncrendition, and Figma has already appliedimageTransformwhen producing those pixels. Applying the matrix again framed an already-framed picture.That also explains why the earlier attempt to honour the crop looked like a fix - the symptom was real, the photographs genuinely were wrong - while measuring worse.
A cropped fill now maps its exported frame once onto its layout box.
FIT,FILLandTILEare unchanged, andimage_cropis deleted rather than left for someone to reach for again.All three widths improve, page heights unchanged, and the other twelve screens are byte-identical.
Verification
Measured independently in the main checkout with binaries built from
mainand from this branch, full 15-screen acquire and render on each side. My figures match the worker's to the decimal. The baseline run also fails correctly against the new thresholds (7.46% > 5.51%), which confirms the two runs really are measuring different code rather than reusing inputs.The change is a net deletion. No viewport, breakpoint, node id or capture-specific constant - I grepped the added lines. All 268 plugin byte-parity goldens unchanged. Korean
wordBreak: keep-alluntouched. Only the three measured about thresholds lowered.The
responsive_screenexpectation that asserted the old doubled crop (53.51% -25.92%/91.26% 104.43%) is corrected, with a comment stating why the export is mapped once.Gates:
fmt0,clippy --locked --workspace --all-targets --all-features -D warnings0,cargo test --workspace1070 passed / 0 failed / 2 ignored,insta --checkno drift.