Colors: support P3 display

[noppefoxwolf]

This added support for p3 display colorspace.
UIColor instance created by UIColor.init(displayP3Red:green:blue:alpha) when iOS10+.

TODO:

• fix test

[AliSoftware]

Thanks a lot for the PR!

I have to admit I'm not sure about forcing P3 colorspace on all contexts (well, as soon as it's available so in 10+).

That mean that now, every time I use a colors.txt with #336699 I'll get a color with those components in P3 colorspace, instead of the standard colorspace. Which means this will now be a different color than before!

I see multiple solutions here:

1. Allow users to opt-in to P3 colorspace with a template parameter. If people don't mention any extra param, use init(red:green:blue:alpha:), but if they use --param P3 then use your new code
2. Or separate the template in two, one using P3 and one not. But In that specific case I prefer a template param rather than two separate templates, way easier to maintain in the long run
3. Or come up with a new syntax to specify the colorspace on each input format we support, for example #rrggbbaa@P3 in colors.txt or similar. Which would have the advantage to allow us to specify the colorspace on each color's basis, but won't be scalable to all formats (*.clr for example)

Thoughs on all this are welcome, I'd really love to have P3 support but we also need to be careful not to generate different colors than previously generated by SwiftGen previous templates, otherwise people will see their whole color palette change in their app which wouldn't be good.

[AliSoftware]

Be sure to keep an empty newline before titles for correct markdown formatting on all readers 😉

[AliSoftware]

Also note that according to the documentation:

1. When we use init(red:green:blue:alpha:), input values are never clamped to 0.0…1.0 when linked to iOS10+, meaning that values in 0.0…1.0 are in sRGB and values above 1.0 are in P3 (which is just an extended colorspace englobing sRGB)
2. While if we use init(displayP3Red:green:blue:alpha:) then values are always clamped to 0.0…1.0 and always in the P3 colorspace

Which confirms that changing the init will change the colorspace and thus the colors compared to what we previously generated and what users expected (P3 is ~25% larger than sRGB, so changing the colorspace/coordinate system scale will indeed return a different color for the same coordinates/values), but also tells us that we could still use the init(red:green:blue:alpha:) to express colors in the P3 colorspace if we need to, by providing values greater than 1.0 to the parameters of that init. We might just need to come up with a way to represent those higher values in our input files like *.txt and all

[djbe]

I think the floats go from somewhere below 0.0, to somewhere above 1.0. Don't clr files support P3 though? I do know they support multiple colorspaces, which is why we implemented SwiftGen/SwiftGenKit#23 at some point.

[AliSoftware]

Yeah, I'd have to double-check but I'm pretty sure *.clr files support color spaces, so probably already P3 too.

[djbe]

Right, so I think that for the other formats (txt, json, xml) we need to define a way for the parser to support colorspaces and/or P3, convert these to sRGB if needed, and then simply pass these along to the templates.

[djbe]

From a quick check of the Android docs, they don't seem to support wide colours in the R.color xml file:
https://developer.android.com/guide/topics/resources/more-resources.html#Color

[noppefoxwolf]

Thank you there ❤️

In css
https://webkit.org/blog/6682/improving-color-on-the-web/

color(p3 1.0 0 0);

TODO:

• generated class support colorspace.
• clr parser support colorspace.
• txt, json, xml parser support css style.