[mapserver-dev] Handling alpha values in colors

Tamas Szekeres szekerest at gmail.com
Mon Sep 24 07:34:25 PDT 2012


Steve,

Reading alpha values (with hex colors) is already implemented in the code.
However we have lack of implementation writing hex colors (in writeColor).
We might consider writing the hex format (instead of the integer triplet)
when the alpha value is in effect (0<= alpha <255) but it may cause a
confusuion that setting the opacity of the style causes to write hex
colors.
When reading the mapfiles the opacity value overrides the alpha values
specified explicitly (in hex colors).

Best regards,

Tamas



2012/9/24 Lime, Steve D (DNR) <Steve.Lime at state.mn.us>

> I'm guessing it is possible to tweak the parser using re-ahead
> capabilities. I believe the flex always has the next couple of tokens
> available for inspection. Haven't done anything like that but I recall
> reading about it. Will dig out my yacc/lex book and confirm.
>
> Montreal was right at the 6.0 release point so it wasn't something I would
> have recommended at that late date. Hex color support required no parser
> changes so was a less risky option at the time.
>
> Steve
>
> -----Original Message-----
> From: mapserver-dev-bounces at lists.osgeo.org [mailto:
> mapserver-dev-bounces at lists.osgeo.org] On Behalf Of thomas bonfort
> Sent: Sunday, September 23, 2012 5:03 AM
> To: Tamas Szekeres
> Cc: mapserver-dev at lists.osgeo.org
> Subject: Re: [mapserver-dev] Handling alpha values in colors
>
> 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
> >
> _______________________________________________
> 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/20120924/508ea6b8/attachment-0001.html>


More information about the mapserver-dev mailing list