[mapserver-dev] Handling alpha values in colors

[Tamas Szekeres]

Yes, I'm thinking about the following addition (in writeColor) if you don't
mind.

if (color->alpha >= 0 && color->alpha < 255)
    fprintf(stream, "%s \"#%02x%02x%02x%02x\"\n", name, color->red,
color->green, color->blue, color->alpha);
  else
    fprintf(stream, "%s %d %d %d\n", name, color->red, color->green,
color->blue);




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

>  Could we just write hex if color->alpha<255? At least until all
> representations support it…****
>
> ** **
>
> *From:* Tamas Szekeres [mailto:szekerest at gmail.com]
> *Sent:* Monday, September 24, 2012 1:02 PM
>
> *To:* Lime, Steve D (DNR)
> *Cc:* thomas bonfort; mapserver-dev at lists.osgeo.org
> *Subject:* Re: [mapserver-dev] Handling alpha values in colors****
>
>  ** **
>
> I think so. Here is the corresponding code in loadColor (mapfile.c):****
>
> ** **
>
> if(symbol == MS_NUMBER) {****
>
>     color->red = (int) msyynumber;****
>
>     if(getInteger(&(color->green)) == -1) return MS_FAILURE;****
>
>     if(getInteger(&(color->blue)) == -1) return MS_FAILURE;****
>
>   } else if(symbol == MS_STRING) {****
>
>     int len = strlen(msyystring_buffer);****
>
>     if(msyystring_buffer[0] == '#' && (len == 7 || len == 9)) { /* got a
> hex color w/optional alpha */****
>
>       hex[0] = msyystring_buffer[1];****
>
>       hex[1] = msyystring_buffer[2];****
>
>       color->red = msHexToInt(hex);****
>
>       hex[0] = msyystring_buffer[3];****
>
>       hex[1] = msyystring_buffer[4];****
>
>       color->green = msHexToInt(hex);****
>
>       hex[0] = msyystring_buffer[5];****
>
>       hex[1] = msyystring_buffer[6];****
>
>       color->blue = msHexToInt(hex);****
>
>       if(len == 9) {****
>
>         hex[0] = msyystring_buffer[7];****
>
>         hex[1] = msyystring_buffer[8];****
>
>         color->alpha = msHexToInt(hex);****
>
>       }****
>
> ** **
>
> Best regards,****
>
> ** **
>
> Tamas****
>
> ** **
>
> ** **
>
> 2012/9/24 Lime, Steve D (DNR) <Steve.Lime at state.mn.us>****
>
> Is the only way a to have color with a non-opaque alpha<255 if it was
> originally entered that way via hex?****
>
>  ****
>
> *From:* Tamas Szekeres [mailto:szekerest at gmail.com]
> *Sent:* Monday, September 24, 2012 9:34 AM
> *To:* Lime, Steve D (DNR)
> *Cc:* thomas bonfort; mapserver-dev at lists.osgeo.org****
>
>
> *Subject:* Re: [mapserver-dev] Handling alpha values in colors****
>
>  ****
>
> 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/90f39c6e/attachment-0001.html>