Colour Requirements: Difference between revisions

From Scribus Wiki
Jump to navigation Jump to search
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.