Skip to end of metadata
Go to start of metadata

Zend Framework: Zend_Color Component Proposal

Proposed Component Name Zend_Color
Developer Notes http://framework.zend.com/wiki/display/ZFDEV/Zend_Color
Proposers Jack Sleight
Revision 0.1 - 10 July 2007
0.2 - 21 July 2007
0.2.1 - 21 July 2007
0.3 - 22 February 2008 (wiki revision: 34)

Table of Contents

1. Overview

Zend_Color is a component for generating colours, manipulating colour values, and converting colours between different colour models. Typical uses include using this within views, where you want elements to appear in different tints of a colour based on a dynamic variable, or even customising CSS dynamically to apply custom colour schemes. You could also use the WCAG functions to validate user input colour values offer enough contrast, in for example advertising blocks.

The current version can be downloaded here: http://jacksleight.svn.beanstalkapp.com/zend_color/trunk/

2. References

3. Component Requirements, Constraints, and Acceptance Criteria

  • This component will provide components for RGB, HSL, HSV (HSB) and CMYK colour models.
  • This component will not provide a component for "HEX colours", as "HEX" is not a separate colour model, it is simply an RGB colour expressed in Hexadecimal.
  • This component will provide helper methods within the RGB component for easily working with "HEX colours", and named colours in the HTML spec/X11.
  • This component will support conversion between RGB to/from HSL, RGB to/from HSV and RGB to/from CMYK.
  • This component will provide a consistent API for manipulating colour values, including setting and retrieving colour values in decimal, percentages, fractions and degrees.
  • This component will provide helper functions for generating CSS compatible colour unit strings.
  • This component will provide methods to make a colour web safe or web smart, and to test for WCAG 1.0 and 2.0 contrast compliance.

4. Dependencies on Other Framework Components

  • Zend_Exception

5. Theory of Operation

Typically the four colour model classes (Rgb, Hsl, Hsv and Cmyk) are instantiated as objects, and then those objects each represent a colour. The colour objects can be modified by altering the values (e.g. R, G and B), or can be used to generate the same (or similar) colour in another colour model. The Rgb class contains two static factory methods for generating Rgb objects from HEX colour strings, and HTML spec/X11 colour names. The base class (Zend_Color) only contains the constants required by the other classes.

When a colour object is instantiated the user can specify which format (range, percentages, fractions or degrees) the colour values are in (supported formats vary between colour models). In addition, each colour value object has methods for setting/retrieving and adjusting values in any of the supported formats. Although colour values can be specified, retrieved and adjusted in multiple formats, they are always stored as fractions (between 0 and 1) within the value objects. The Rgb object also contains methods for retrieving the HEX value of a colour, and the closest named colour from the HTML spec/X11 list.

6. Milestones / Tasks

  • Milestone 1: [DONE] Finalise initial proposal ready for community review
  • Milestone 2: Working prototype checked into the incubator
  • Milestone 3: Unit tests exist, work, and are checked into SVN
  • Milestone 4: Initial documentation exists

7. Class Index

  • Zend_Color_Exception
  • Zend_Color
  • Zend_Color_Cmyk
  • Zend_Color_Hsl
  • Zend_Color_Hsv
  • Zend_Color_Rgb
  • Zend_Color_Value
  • Zend_Color_Value_Hue
  • Zend_Color_Value_Rgb

8. Use Cases

UC-01

Get RGB object from hex code

UC-02

Create an RGB object

UC-03

Create an RGB object using percentages

UC-04

Get the RGB values

UC-05

Make a colour web safe or web smart

UC-06

Find the closest named HTML colour

UC-07

Check W3C visibility

UC-08

Convert RGB to HSL, HSV or CMYK

UC-09

Convert HSL, HSV or CMYK to RGB

UC-10

Modify colour values

9. Class Skeletons

Labels:
zend_color zend_color Delete
proposal proposal Delete
color color Delete
conversion conversion Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Dec 21, 2007

    This component would typically be used in the view to work with colors. So I think a view helper is a must have.

    1. Feb 22, 2008

      Hi Lars,
      Yes, you're right, the typical use for this component would be in views. However as colour manipulations involve direct calls to the colour objects, the only view helpers you could rally have would be to instantiate new colour objects, which you could do without the need for a helper.

  2. Jun 03, 2008

    This could be helpfull. My only problem is that you always convert trought RGB, which can't cover the complete colorspectrum. You might consider converting using a device independent model, for instance CIE XYZ or CIE L*ab.

    Introducing device independent convesion allows for usage outside the computerscreen domain, for instance print (CMY and CMYK) and video (YIQ, YUV and co.).

    1. Jun 03, 2008

      Hi Vincent,
      I agree that including a device independent model such as CIE XYZ would be a welcome addition, and I had intended to include this in a future version, however at the time of writing I didn't have enough time to work on additional colour models. I'll look into this, and if feasible for the first version I'll add it in.

      The reason for the focus RGB at present is because this would most commonly used for web sites, which obviously use RGB almost exclusively (although HSL is also supported in CSS).

      1. Jun 05, 2008

        Might I suggest to add a base class (Zend_Color_Abstract?), which enforces a toLab(), fromLab() and a toRgb()?

        This is a very rough scetch and I'm not sure if this would cover everything. Adding a base class, would however ensure a common ground for conversion. You could use CIE XYZ instead of CIE L*ab of course.

        1. Jun 05, 2008

          Yes, good idea. I'll add it in.

          1. Jun 05, 2008

            I've mailed you a start.

            I've chosen CIE XYZ as middel model, since all functions are available at www.easyrgb.com and I am a lazy ***.

            1. Jun 11, 2008

              I've added the mentioned the mentioned Abstract class to the subversion repository. I've hit a dead end for now, since I can't find a direct XYZ to/from CMY(K) algorithm which started it all.

              So far for my lazyness, have to do some more research into color conversion...

              1. Jun 11, 2008

                This was (one of) my worries regarding including functions in the abstract class. There is no single colour model that can be converted directly to and from every other. XYZ is related to RGB, and therefore it's very unlikely you'll find a CMYK > XYZ algorithm (that isn't just a combination of the CMYK > RGB > XYZ algorithms).

                We'll have the same problem with RGB, as there's no RGB > Lab algorithm. This is why I think all the classes should be independent, and simply have to*() methods for the formats supported. from*() methods complicate things, because not every model can accept every other (or even one other).

                1. Jun 16, 2008

                  I would suggest you convert to a neutral format like you planned. If a format can't convert directly, special case it and just do a multi-step conversion. It's not like these conversions are processor intensive, right?

                  1. Jun 16, 2008

                    That was my plan of attack indeed. The only big exception is CMY(K), but I'll convert those from RGB. Have to find some time this week to complete those and determine which other conversions I should optimize, for instance to prevent RGB -> XYZ -> RGB -> CMYK.

  3. Sep 26, 2008

    Curious, would it be possible to add some color theory functions?

    • getComplementaryColor()
    • getAnalogousColor()
    • getTriadicColor()
  4. Nov 18, 2008

    Is Jack still working on this? Else I'm going to fork it to a new proposal with a (imho) better API, Color Profile handling, etc.

    1. Nov 18, 2008

      Hi Ben,
      I'm sorry to say that with my current workload I'm not going to be able to continue working on this for the foreseeable future. You're welcome to take anything from here, as well as the code from http://jacksleight.svn.beanstalkapp.com/zend_color/trunk/ to use as a starting point if you want. You may also want to contact Vincent de Lau (vincent [at] delau [dot] nl), as he was very keen to (and did) contribute code to the proposal, and may be interested in contributing further.

      1. Nov 21, 2008

        I'm also buried in work at the moment. When you start working on this, I'll be glad to give my input and maybe even help with some code.

  5. Jun 09, 2009

    1. I think it is better to group color models e.g.:
    -> rename Zend_Color_Cmyk -> Zend_Color_Model_Cmyk

    2. You can use one color model as the base model like Xyz but all other models can convert directly.

    1. Jul 27, 2009

      nice library Jack,

      i think this library could provide one-way to get colors

      Zend_Color::factory() implementation could use something like Marc's Zend_Color_Model_Abstract::__call()

      still using Zend_Color_Model_Abstract::__call(),
      the translation could work like this

      compare method could be done as well

      1. Jul 28, 2009

        Hi Renan

        "Hex" is not a color model, it is a "hex"-string formated rgb color.
        Theoretical you can format all colors of all models to a similar string .

        Comparisons are very interesting but could get the difference of colors.
        I don't no if the following example is usable for all color models:

        All values returned by compare* could based percentage of the original color.

        1. Aug 03, 2009

          Hi,

          yep, hex isnt a color type, it's a fake rgb, you are right

          wow! this methods for comparison looks very nice, i prefer receive percentage than boolean

          these types of comparison can be used for effects operations as well

          1. Aug 04, 2009

            If my memory serves me well, I think the current codebase (see SVN) supports passing parameters either as hexadecimal (00-FF), decimal (0-255), float (0-1) and percentage (0-100) (and degrees (0-360) for hue).

            Most calculations use floats, percentages are very common in print (CMYK) and hexadecimal and decimal notation mostly are used with RGB values in software and programming.

            In the current codebase there is also some work done on comparing colors.

            1. Aug 04, 2009

              I like your implementation to handle the different parameter values. But I think Renan means that he missed a factory which can automatic parse the given string to color instance like the following:

              Sorry but on scan your svn code base I only found some WCAG comparison methods that are only work with the rgb model (all other models convert to rgb first) and the compare methods are not in your abstract class. Does this mean that they are different in different color models ?

    2. Aug 04, 2009

      Hi Mark,

      I've done some work in this direction already. It is in SVN but not in the wiki page. Basically there is a base color class and all other models inherit from it. (Renaming seems a good idea IMO) All models should implement CIE XYZ conversion functions for comparison etcetera to work transparent. I hit a little bump in the road however when I was working on this (see discussion above, expand the thread). In a couple of weeks I might have some time to implement the rest.

      Another thing I think might be nice to do is to separate out the color library (HTML colors) and make it generic. You could then also add other color libraries. Pantone would be an example, but probably could never be part of the Zend Framework due to licensing issues. RAL might be easier: http://www.pats.ch/formulaire/unites/unites11.aspx.

  6. Jan 08, 2010

    Hi Vincent,

    Is this proposal active?
    I would like to help you to put this to "Ready for Recommendation" section.

    Greetings

  7. Feb 07, 2011

    Archiving this proposal, feel free to recover it when you want to work on it again. For more details see this email.