Gradient Part 1a - Color fixes#2262
Conversation
|
Amazing! |
|
@Dherse I think arguable the bug is really in the raw code, not in the color code. There is no need for it to operate with Typst colors. It should just have let foreground = theme.settings.foreground.unwrap_or(synt::Color::BLACK);Then, We can decide independently of that whether luma and rgb should compare equivalently. I'm not sure about that. |
I'll change it to that and disable the luma == rgb comp |
|
Thank you for the fixes! |
|
It has been confirmed on Discord that this has mostly fixed color inaccuracy issues. |
Tracking issue: #2282
Follow up to #2171:
raw.rsAdded equality between luma and rgb colors: if an rgb color is just a luma color in disguise, it will compare them as if they were luma colorsConvert to syntect colors early avoiding color eq issues in syntect, fixes issue when comparing colors in the internals, it happened inraw.rs, it likely occurs in some other places. Happens to fix Regression in#show raw: set text()#2259Alternatecolor spaces of the ICC profiled colors, the default isDeviceRGBandDeviceGray, this fixes the Wrong colours in PDF export in some viewers #2257 and incorrect generated colour different to one specified #1927. Note that for Wrong colours in PDF export in some viewers #2257 it does not fix issues with readers that have poor support for ICC profiles, that's on poppler for not falling back to an appropriate color space on its own 🤷♂️ Mind you, falling back toDeviceRGBdoes fix rendering in poppler, still they have a bug that needs fixing!This small PR corrects some (albeit small) mistakes, which should fix color inaccuracies that could happen. Due to relying on
DeviceRGBandDeviceGray, any further color inaccuracies are solely an issue with the reader as typst is following best practices and what other PDF writers produce. It also fixes a bug that cropped up due to "naive" color comparisons.I decided to modify theEarly conversion of colors in syntect colors forPartialEqimplementation instead of anything else for the sake of guaranteeing that no other bugs like this occur again.raw-related stuff fixes the issue, note that it might appear somewhere else in the code, but as of know, it seems correct everywhere else. Another fix would be to revert some of the presets (i.eColor::BLACKetc.) back to RGB colors, but this would come with a filesize cost and would actually not really resolve the issue.