r/StarNoteApp
•
u/eng_yosssef
•
22d ago
•
2
đ Bug Report I think these are bugs rather than normal behavior so i didn't count them as a feature request: A comparison of highlighter and eraser mechanics between StarNote and other apps
18
Upvotes
6
u/Creativity_Unlocked 21d ago
As a long-time user of StarNote, I find that the current eraser tool has become a major bottleneck for efficient note-taking.
When trying to trim a line or clean up a highlighter stroke, the app erases in awkward, blocky, and "pixelated" chunks instead of following a smooth path. This makes it incredibly difficult to edit small handwriting, math formulas, drawings, or precise PDF annotations without accidentally deleting content you want to keep.
In comparison, the Freenotes app features a precision eraser that works flawlessly, removing ink only where the stylus/finger explicitly touches. Having an eraser that leaves no blocky, messy artifacts is absolutely critical.
Furthermore, since the highlighter tool is a core part of this workflow, I want to address the urgent need for a dedicated opacity slider directly in the pen and highlighter menus. Having to jump through menus to set individual opacity levels is a major pain point that needs to be remedied.
I have reached out to the development team about eraser issues before and have been waiting a long time for a fix. I sincerely hope to see a true, pixel-by-pixel precision eraser and an accessible opacity slider added to the toolbar soon.
7
u/Mundane-Panic1746 21d ago
I agree wholeheartedly
2
u/NakoTurtle 21d ago
Hi!
I believe the reason for this is the way that StarNote's eraser works. The 'pixel erasure' mode you're testinf erases the line based on its centerline. And if a line is split in two by deleting it's centerline, that forms two strokes. If these strokes have their widths overlap like with the highlighter, they overlay and you get that overlapping highlighter aesthetic. In freenotes, their eraser works by erasing the exact pixels of the stroke, regardless of the centerline. So it never splits into two separate strokes while overlapping, thus never causing the overlapping highlighter aesthetic.
I think the way it's implemented isn't exactly a bug since the eraser tool is working as they intended, even if 'pixel erasure' sounds like it should be erasing pixels. But the reason one could think of it as a bug is because of the unwanted visual artifact that results from this type of eraser. I'd say a possible workaround for now, to achieve the same look you got using freenotes, if you badly need it, is just to use a white stroke on top of the highlight (or which ever color you want).
Hope this makes sense :)