Colour Requirements: Difference between revisions
No edit summary |
|||
Line 36: | Line 36: | ||
** Commercial values | ** 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. | * 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 <code>ScColor* weird = ScColor::fromSchemeAndCoords("RGB", "0xFFAA00EE")</code> | |||
* Ability to return translated name from '''user-defined''' table of translations. | |||
=== Notes === | === 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. | 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. |
Revision as of 17:31, 28 July 2005
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.