[mapserver-dev] Handling alpha values in colors

Tamas Szekeres szekerest at gmail.com
Sun Sep 23 03:20:13 PDT 2012


Thomas,

IMHO, the current approach (requiring to use hex colors when using alpha
values) seems to be a reasonable solution, if we implement the same when
writing color values to the mapfile (in writeColor).

Best regards,

Tamas



2012/9/23 thomas bonfort <thomas.bonfort at gmail.com>

> Tamas,
> The handling of alphas in colors is a bit flakey, I agree. The initial
> aim when we worked on this at the montreal code sprint was to drop
> support of the OPACITY keyword at the STYLE level in the mapserver
> library (while maintaining it in the parser for backwards
> compatibility), by allowing colors to be specified with quadruplets
> instead of triplets. I don't rememember the reason (Steve might
> recollect), but in the end having the parser be able to parse both
> triplet and quadruplet integers was not possible, and we are thus
> stuck in this less than ideal state.
> If someone has a solution for this parser problem that would be great,
> as it would open up varying opacity for all *COLOR entries.
>
> regards,
> thomas
>
> On Sun, Sep 23, 2012 at 11:38 AM, Tamas Szekeres <szekerest at gmail.com>
> wrote:
> > Hi All,
> >
> > I don't properly understand how we intend to handle alpha values of
> colors
> > in mapserver. Currently the alpha values can be specified in mapfiles (by
> > using the hexadecimal format), but that values are not written back to
> the
> > file in msSaveMap.
> > Style level opacity seems to override alpha values specified in mapfiles,
> > but on the other hand we cannot specify opacity at some places (like in
> > label text colors).
> > By using the opacity values of styles seems to change the alpha values of
> > multiple properties (color, outlinecolor, background color etc.) which
> > doesn't seems to be as such generic as specifying the alpha values for
> the
> > colors individually.
> >
> > I can also see the conditional compilation flag ALPHACOLOR_ENABLED in the
> > code, but it doesn't have much effect for the operation.
> >
> > Could someone explain how the things are expected to work?
> >
> > Best regards,
> >
> > Tamas
> >
> > _______________________________________________
> > mapserver-dev mailing list
> > mapserver-dev at lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/mapserver-dev
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-dev/attachments/20120923/3dca0da4/attachment.html>


More information about the mapserver-dev mailing list