Colour Requirements: Difference between revisions
mNo edit summary |
m (Text replace - "Category:Scribus_development" to "Category:Development") |
||
Line 1: | Line 1: | ||
[[Category: | [[Category:Development]] | ||
Note: This page edited down from old dw content. | Note: This page edited down from old dw content. | ||
Latest revision as of 23:52, 20 December 2010
Note: This page edited down from old dw content.
Colour in 1.2.x
- RGB
- Name
Colour in 1.3.0
- RGB||CMYK
- Name
Colour for future releases
Many colour spaces:
- RGB
- RGBA
- CMYK
- CMY
- HSV
- CIE L*A*B
- ...
What we need to keep track of about a colour:
- Name
- Translated name(s) -- not just UI only, needs to be saved in colour sets.
- Colour value
- Co-ordinate space (CMYK, RGB, RGBA, etc)
- Co-ordinates (eg 0xFF,0x00,0x00 for red in RGB)
- Colour profile colour should be treated as in (?)
- Co-ordinates to represent this colour in other colour spaces (?)
- Origin (web set, x11 set, user entered, imported set, etc)
- Spot colour name/number
- Commercial names
- Commercial values
- and possibly some sort of index but most likely for UI only. (we need to sort these by name, group etc). May need multiple indexes.
What we need from a colour class
- The ability to provide the info above
- The ability to perform managed and unmanaged transforms between colour schemes, returning colour co-ords in the requested scheme.
- The ability to return a QColor, possibly with managed conversion using the display profile, for on-screen use.
- Easy to use, minimal need to care what sort of colour you're dealing with
- Preferably nice subclass-based structure so new colour schemes can be added easily.
- Virtual functions to provide suitable PS, PDF snippets for including the colour?
- Object factory so you don't have to do nasty hacks or care much about exactly what sort of ScColor you're constructing when you're reading in a colour from a doc / prefs. For example
ScColor* weird = ScColor::fromSchemeAndCoords("RGB", "0xFFAA00EE")
- Ability to return translated name from user-defined table of translations.
Notes
louis: 1. Print-oriented color set based on CMYK + White + Registration 2. Web/Video-oriented color set based on RBG + White, but without Registration 3. Ability in each set to add colors in their own color-mode (no mix unless the user knows for sure what he's doing) from a color-picker table in each mode. A wheel is OK with RGB values and CMYK values. 4. The use of the expression *spot color* is reserved to the print-oriented set. If checked, a new plate will be created at output, if not, the spot will be converted to CMYK values. User can edit those values. 5. We could add a *mix set* of both CMYK-RGB for users who need/prefer that.