2 of 6 standards met
Summary Fixes a critical bug in where is incorrectly advanced when handling invalid matches (distance=0, length>1). Problem When the optimal parsing DP produces an invalid match with and , the existing code treats it as a literal but advances by the full match length instead of just 1 byte. This causes subsequent tokens to read from incorrect positions in the source data. Example: Token 1: โ Emits literal at position 0, advances by 5 (should be 1) Token 2: โ Tries to read from position 5 instead of position 1 (wrong!) Solution Changed the code to always advance by exactly 1 byte for literals, regardless of the value in the DP arrays: Changes Made Fixed advancement logic in Added comprehensive regression tests Added test for valid match handling (ensure fix doesn't break existing behavior) All existing tests pass Code is well-commented explaining the fix Testing Added two new tests in a dedicated regression test module: 1. * Tests the exact bug scenario with invalid matches Verifies tokens are created from correct positions This test fails without the fix, passes with it 2. Ensures the fix doesn't break valid match handling Tests normal operation with proper distance values [!NOTE] Fix: now treats invalid matches (, ) as a single literal and advances by exactly 1, preventing misaligned reads. Valid matches still advance by and remain unaffected. Tests*: Adds focused regression tests to cover zero-distance multi-byte cases and verify correct behavior for valid matches. Written by Cursor Bugbot for commit cd5793fbddade992c866c2f63de44a310e9c9c3b. This will update automatically on new commits. Configure here.
Repository: leerob/pixo. Description: High-performance image compression library written in Rust. Stars: 394, Forks: 28. Primary language: Rust. Languages: Rust (92.7%), Svelte (3%), TypeScript (2.8%), JavaScript (1.3%), CSS (0.2%). License: MIT. Homepage: https://pixo.leerob.com Open PRs: 0, open issues: 3. Last activity: 2mo ago. Community health: 42%. Top contributors: cursoragent, leerob, esau-morais.
Last 12 weeks ยท 453 commits
I've tried to compress file But instead of compressing, pixo increased file size
When shrinking the image, the smaller image is shown at a different size than the original image, which breaks sliding the divider to view the difference in the compression. I think it should scale the big image down using the browser's native scaling. Chances are it's scaled down anyway. That way it can be seen if there is a significant loss of quality in addition to having a smaller image. Scaling up a scaled down image would be an exception to the rule โ normally it would be scaled down in order to be shown at the scaled down size or smaller.
[!NOTE] Enhancements to image resizing and comparison UI. The resize flow now tracks last applied width/height/algorithm and marks changes as pending only when values differ. Inputs update on typing (), Enter applies when pending, and recompression runs after applying. Improved visual handling of resized results. The app stores /, adjusts the comparison container to the resized aspect ratio, and shows original โ result dimensions in the info panel. Styling tweaks ensure correct layout when resized (container sizing, on slider elements). Written by Cursor Bugbot for commit 2b9eeda049409ec96cee35e903ab30f803a737d0. This will update automatically on new commits. Configure here.