Colour Requirements

From Scribus Wiki
Revision as of 23:52, 20 December 2010 by Malex (talk | contribs) (Text replace - "Category:Scribus_development" to "Category:Development")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

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.