"CharBackColor" property of XPropertySet in Java

[johnrdorazio]

I have encountered a strange problem in a plugin I have written in Java using the OpenOffice Netbeans plugin.

I am finding that the "CharColor" property and the "CharBackColor" property are behaving differently.

I can set text color by getting the integer value of the color from a Java Color object without any problem:

Code: Select all   Expand viewCollapse view

xPropertySet.setPropertyValue("CharColor", Color.BLUE.getRGB()); //same as hex 0xFF0000FF

This correctly sets the text to Blue, and the Color object in Java automatically sets the alpha to 100% (0xFF).

However this does not work for the "CharBackColor" property:

Code: Select all   Expand viewCollapse view

xPropertySet.setPropertyValue("CharBackColor", Color.YELLOW.getRGB()); //same as hex 0xFFFFFF00

The above code should set the background color of the text to Yellow, instead there is no visible effect.
If however I explicitly set the alpha to 0 (which should make it transparent), now you can see a Yellow background!

Code: Select all   Expand viewCollapse view

xPropertySet.setPropertyValue("CharBackColor", Color.YELLOW.getRGB() - 0xFF000000); //same as hex 0x00FFFF00

This certainly is not behaving correctly. The only way to set the background color is to explicitly set the alpha to transparent by subtracting the alpha bits!
This only happens for the "CharBackColor" property, and not for the "CharColor" property.

I have not tested this in any other languages, only in Java using the Netbeans plugin.

If anyone else can run a test based on this exact use case, please confirm the results.
I have also opened an issue for this on the bugzilla bug tracker. If anyone can confirm the results from this same test, please confirm on the bug tracker also: https://bz.apache.org/ooo/show_bug.cgi?id=126531

[FJCC]

This Basic code correctly sets the character color to red and the background to blue.

Code: Select all   Expand viewCollapse view

  oText = ThisComponent.getText()
  oObj1 = oText.createTextCursor()
  oObj1.goRight(6, True)
  oObj1.setPropertyValue("CharBackColor", RGB(0,0,255))
  oObj1.setPropertyValue("CharColor", RGB(255,0,0))

[johnrdorazio]

Then I guess that would mean that the problem has something to do with the way Java is bridged to the Uno interfaces... It seems to be language specific. Can anyone confirm this behaviour in Java?

[B Marcelly]

The RGB() function of Basic does not use the alpha channel (its value is always zero).
As I said in the other thread, you don't need to bother with the alpha channel.

Here is the Basic equivalent of your code :

Code: Select all   Expand viewCollapse view

oObj1.CharColor = &HFF0000FF
oObj1.CharBackColor = &HFFFFFF00

Your code, even in Basic, does not work for CharBackColor. Because you set a value to the alpha channel.
A character background color cannot have transparency. See yourself in the user interface of character formatting.

Your code works for CharColor because the alpha channel is ignored.

[johnrdorazio]

B Marcelly, I don't understand what you are talking about.

Code: Select all   Expand viewCollapse view

xPropertySet.setPropertyValue("CharBackColor", Color.YELLOW.getRGB()); //same as hex 0xFFFFFF00

Where did I set the alpha channel? I don't see the alpha channel being set here. If anything, it is set automatically to 100% by the Java Color object (which is intended behaviour).
And yet this above does not work in Java (whereas it does work for the "CharColor" property).

How am I "bothering" with the alpha channel? The above should simply work, as it does for the "CharColor" property, and yet it DOES NOT.
If however I do "bother" with the alpha channel by explicitly setting it to 0%, guess what, it works all of a sudden. I would say that this is NOT intended behaviour in JAVA.

[johnrdorazio]

I would say that the question here at this point is not, how can I set a background color in Java without getting an error.
The question is whether the OpenOffice API is treating Java according to an expected behaviour or not.

In order to do that, one must look at how Java works with Color objects and JColorChooser panels.

It is possible to set a Java Color object with no alpha by not setting the alpha in the Color constructor:

Code: Select all   Expand viewCollapse view

Color red =  new Color(255,0,0);

EDIT: actually even in this case, alpha is defaulted to 100% (as per the Java docs):

public Color(int r,
int g,
int b)
Creates an opaque sRGB color with the specified red, green, and blue values in the range (0 - 255). The actual color used in rendering depends on finding the best match given the color space available for a given output device. Alpha is defaulted to 255.

But otherwise Java Color objects are predefined or preset with an alpha bit:

Code: Select all   Expand viewCollapse view

Color red = Color.RED;

This will have an alpha of 100% already set.

If getting a color from a color chooser panel:

Code: Select all   Expand viewCollapse view

Color userChosenColor = jColorChooser.getColor();

This will have an alpha bit set.

So taking for granted that Java, in it's handling of Java Color objects, will almost always set an alpha bit, then the OpenOffice API should take that into consideration, and if an interface does not support an alpha bit it should automatically strip out any alpha bits that are set.

Until that is taken into account, the only way I can see of making this work correctly when getting a color from a JColorChooser panel for example, is to explicitly clear the alpha bit:

Code: Select all   Expand viewCollapse view

static int stripAlpha(int color){
    return color  & ~0xFF000000;
}


So then you could do this:

Code: Select all   Expand viewCollapse view

xPropertySet.setPropertyValue("CharBackColor", Color.YELLOW.getRGB() & ~0xFF000000);


or this:

Code: Select all   Expand viewCollapse view

Color userChosenColor = jColorChooser.getColor();
xPropertySet.setPropertyValue("CharBackColor", userChosenColor.getRGB()  & ~0xFF000000);


This is not at all obvious, and should be either documented or done automatically behind the scenes. Since I am of the opinion that this should be taken care of behind the scenes, this is why I believe it should be in the issue tracker, and in fact I have already created an issue. If anyone else can see my point and agrees that this should be done behind the scenes by the OpenOffice API, please confirm the issue on the tracker. (Because that's how software gets better!)