[Bug]: Split-screen target width assumes a 16px gap but the renderer uses 6px
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 78/100
Research direction
Start in crates/app/src/export.rs at compute_split_scale_for_width() and compare its gap value with SPLIT_GAP in crates/renderer/src/canvas.rs and crates/renderer/src/svg.rs. Check whether the renderer crate exposes a shared definition in layout.rs, as the issue suggests. Done means split screen exports match the requested target width within rounding for both PNG and SVG.
Written by the indexing model from the issue text.
Description
What happened?
The target width computation for split-screen mode assumes a 16px gap between the two panels, but the renderer uses a 6px gap. The computed scale is therefore slightly wrong and the exported image is 10 * scale device pixels narrower than the requested target width.
Steps to reproduce
- Enable split-screen comparison.
- Set a target width, for example 1920.
- Export PNG and measure the actual image width. It falls short of the target.
Expected behavior
The exported image matches the requested target width (within rounding).
Actual behavior
compute_split_scale_for_width() in crates/app/src/export.rs:266 uses the magic number 16.0 for the gap, while the drawing code uses SPLIT_GAP = 6.0 (crates/renderer/src/canvas.rs:376, crates/renderer/src/svg.rs:250).
Where did it go wrong?
PNG export / SVG export (split mode)
Settings
Split-screen enabled, target width set.
Browser
Not browser specific.
CodeFrame version
0.7.0
Console output or extra context
Suggested fix: export SPLIT_GAP from the renderer crate and use it in export.rs instead of the local literal. The constant is currently duplicated in canvas.rs and svg.rs, so a single shared definition in layout.rs would remove the duplication at the same time.
- Dominant language
- Rust
- Stars
- 1
- Forks
- 0
- Avg merge
- 1d 7h
- Merged PRs (30d)
- 5
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from suradet-ps/codeframe
-
enhancement good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 83/100
suradet-ps/codeframe#40 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
suradet-ps/codeframe#35 ·
Maintainers usually reply within 1 day
-
documentation good first issue
Difficulty 1/5 1-3 hours Newbie friendliness 88/100
suradet-ps/codeframe#36 ·
Maintainers usually reply within 1 day
-
[Bug]: Target width input clamps the value on every keystrokePossibly taken @AnushreeKasturi claimed this today. Openbug good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
suradet-ps/codeframe#37 · 2 comments ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
suradet-ps/codeframe#38 ·
Maintainers usually reply within 1 day
All issues in suradet-ps/codeframe
Similar issues
-
agent duplicate providers tool triaged
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Maintainers usually reply within 1 day
-
founders_reward panics on a configured Testnet when the slow-start subsidy is not a multiple of 5Openexternal-contribution
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
ZcashFoundation/zebra#11792 ·
Maintainers usually reply within 1 day
-
content:edit documentation effort:high
Difficulty 1/5 1-3 hours Newbie friendliness 67/100
cloudflare/cloudflare-docs#34428 ·
Maintainers usually reply within 1 day
-
area/cli bug
Difficulty 2/5 1-3 hours Newbie friendliness 85/100