Gradient Part 1 - Color rework#2171
Conversation
|
Do you think it would make sense to put all the color constructors into a new module There's quite a few of them ( |
|
I actually agree with you that the most important ones should be at the top level (imo that would be |
|
Before merging: there is a mistake in the HSL PostScript code, some ranges are mixed up, I'll fix it later today |
|
Okay, I have fixed all the PostScript code and it should be pretty much ready for review! |
|
Suggestion: instead of having many |
Initially I wanted to call them |
@istudyatuni I ended up implementing this change as I thought it was a much better implementation. To obtain the same effect as the as, the color conversion is now explicit |
|
|
What I meant by that is that I didn't change it for RGB, etc. and I am not sure whether those implementation were perceptual * |
|
Following some discussion on Discord, I removed the |
There was a problem hiding this comment.
Wow! Looks really good overall, I just have some minor nits + a hope (that will probably soon be shattered) that generics could drastically reduce the amount of code in color.rs: The whole file has quite a lot of methods for conversion / modification and dispatch to subcolors. However, palette has a quite powerful trait-based interface from the looks of it. Could we build on that to prevent this n^2 code size (n = number of color types). E.g. by bounding the ColorExt trait on Desaturate + FromColor<HsvColor> + ...?
Co-authored-by: Laurenz <laurmaedje@gmail.com>
|
@laurmaedje in tests, I added a special |
|
Regarding improving things using trait, I have tried A L-O-T on an uncommitted version, and the best I could achieve was a 100-ish line reduction. The main reason why I am not using the |
|
Also, now that I see them, the top level
|
|
Thank you! I'm really happy with the result. :) |
@laurmaedje I am really glad this big chunk of gradients is merged 🎉 |

Tracking issue: #2282
This PR does some fundamental changes to the way colors work, as well as introducing several breaking changes. Following is the list of changes in no particular order:
DeviceRGBandDeviceGraywith the correct D65 white pointoklab,linear-rgb,hsl, andhsvcomponentswhich replaces the oldto-rgba,to-cmyk, andto-luma. This is a breaking change. These return an array of the color components in the target color space (i.e luma, cmyk, etc.).rgb(hsv(10deg, 10%, 40%))converts an HSV color into an RGB color.lighten,darkenare now based on the perceived lightness value and handled directly inside of palette.rotatewhich allows the rotation of the hue by a given angleBlack,White, andGrayare now based on aLumaColorinstead of being RGB, this should save a small amount of PDF file size, which may be quite large over an entire documentsRGB,linear-RGB,oklab, andHSLsince those are natively supported by the SVG spec. The other color space fallback to a hex sRGB value.saturateanddesaturatemethods on colors, they increase/decrease the saturation based on a percent value.Color precision
It was quite hard to find a good balance for color precision, in the end, the solution that worked best was
f64colors simply because typst's floats are alsof64s and it solves some issues when comparing numbers. However, in general, I would highly recommend against comparing color values purely based on the numerical values as colors are converted lossilyICC profiles
The ICC profiles are tiny (especially once
delfated) accounting for at most ~500 bytesPostScript function
Have been tested to be correct (although automated testing using GhostScript might be desirable), are written with comments. The comments, line breaks, etc. are stripped before being
deflated for size optimizationGradients
This is the first PR towards gradient, and part of a series of 5 PRs (Colors, Layout & Export, Shape gradients, Text gradients, Fine control of gradients) that will allow gradients to be added to typst.
Printing
On my printer (a cheapo Brother), all color spaces print just fine.