Change in alpha value in Mapnik color constructor between Mapnik 0.7 and 0.8

[springmeyer]

Is this an intended change? Previously the alpha input was interpreted as a fraction:

0.7:

>>> mapnik.mapnik_version()
700
>>> c = mapnik.Color('rgba(235,217,194,20)')
>>> c.a
255
>>> c = mapnik.Color('rgba(235,217,194,.5)')
>>> c.a
128

trunk:

>>> mapnik.mapnik_version()
800
>>> c = mapnik.Color('rgba(235,217,194,.5)')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
RuntimeError: Failed to parse color value: Expected a color, but got 'rgba(235,217,194,.5)'
>>> c = mapnik.Color('rgba(235,217,194,128)')
>>> c.a
128
]}}

[artem]

Internally, color components (RGBA) stored as uint8_t so I introduced this behaviour by accident. Having just read http://www.w3.org/TR/css3-color/ I think we should revert to using normalised 0...1.0 alpha as per CSS.

[albertov]

If going back to normalized 0... 1.0 alpha don't forget to revert r1734 since I modified color.to_string to compensate for this (before having a chance to read this ticket).

Alberto

[artem]

Fixed in r1922 (+ r1923 reverted r1734 change).