Re: Alpha in Pango Color

[William Kappler <wekapple ncsu edu>]

I didn’t consider that when I suggested a possible separate tag – it would seem excessive to have more than one alpha tag, and if the background and foreground at least couldn’t be independently controlled, a lot of possible functionality would be lost. I’m not sure about things like the strikethrough or underline being independent. It seems it might be inconsistent if they behaved differently. That said, let me just suggest a case for my initial suggestion of expanding the hex color values.

First off, I didn’t realize color was supported in different precision formats. That would cause a problem with adding a 4th parameter because of ffffffffffff – which could be either 3 colors X 4 or 4 colors X 3. As such, perhaps adding an optional marker of some sort at the end of the existing hex color, followed by another hex value (representing only alpha) would be a solution. For example: “#0000FF|5”. That should not conflict with anything else or anyone’s expected behavior. ‘|’ isn’t necessarily the symbol that should be used, but I can’t off the top of my head think of a better marker.

Then, PangoColor would have to be modified to have the additionally guint16 for alpha. This of course means the alpha becomes a core part of the color, and they have to be specified together. If the user chooses not to specify an alpha, I think it should default to fully opaque. Typically that’s how text systems handle color and alpha, like CSS. Unless the alpha is specified via “rgba”, it assumes fully opaque, overriding any previous foreground alpha.

Actually drawing the color would be as easy as switching cairo_set_source_rgb for cairo_set_source_rgba and adding the new component.

The only downside I see is the work to implement such a change and that it could cause some users of Pango to see text suddenly becoming fully opaque when they use a 3-parameter color tag, if they previously set the alpha via Cairo. Since Pango’s support for alpha is basically nonexistent now, anyone using alpha would benefit in the long run even if some refactoring of how they handle colors was needed.

In any case, thank you both for taking my suggestion seriously. It would be a great help if anything like this were implemented. Again, if there’s anything I can do to help, I’m more than willing to do what I can.

:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-
William E. Kappler II
LinkedIn · Blog · Project Website

On Tue, Aug 11, 2015 at 10:37 AM, Behdad Esfahbod <behdad esfahbod gmail com> wrote:

On 15-08-11 03:58 PM, Matthias Clasen wrote:
> On Sat, 2015-08-08 at 11:36 +0200, Behdad Esfahbod wrote:
>> Hi William,
>>
>> Currently Pango doesn't support alpha in colors.  At this point, it
>> might make
>> sense to add a separate PANGO_ATTR_ALPHA, instead of an RGBA type.
>>
>> I'd take a patch.  Matthias, is this something you can possibly
>> implement?
>> Shouldn't take long to implement and test...
>
> No, sorry. Not in the short term. But I would be interested in having
> alpha support in pango, and would look at making GTK+ use it if it
> appears.
>
> If we make this a separate attribute, we would need fg-alpha, bg-alpha,
> strikethrough-alpha and underline-alpha. And there would be some
> complication where you could end up with (say) the underline-color and
> underline-alpha attributes ending at different positions. We would fall
> back to fg for the underline color where underline-color has ended. But
> do we combine it with the underline-alpha? Maybe that is just a corner
> -case that needs clear documentation.

Hum..  We definitely don't want four alpha attributes.  Are there realistic
usecases for needing different alpha for those?  I guess different alha for
background vs foreground makes a lot of sense...

b