PDA

View Full Version : [FNR][1.2.3] TextMetrics does not account for font-weight due to GXT bug



jonjanisch
29 Apr 2009, 11:48 AM
The TextMetrics class will incorrectly compute the width of any text which is bold since the bind method does not copy the font-weight (fontWeight) style property.

I think the reason why the dev who wrote the TextMetrics.bind method ignored the font-weight property is because El.getStyleAttribute("fontWeight") will throw an internal Javascript exception (atleast in IE) if the font-weight was specified in an external CSS file.

In other words, this works fine:


El copy = new El(el);
copy.setStyleAttribute("fontWeight", "bold");
this.el.setStyleAttribute("fontWeight", copy.getStyleAttribute("fontWeight"));
This does not work:


El copy = new El(el);
this.el.setStyleAttribute("fontWeight", copy.getStyleAttribute("fontWeight")); // font-weight specified in external CSS
The reason why it fails is because the DOM's fontWeight property returns a number while the native javascript method XElement.getStyleAttribute method declaration returns a String.

Before I show my solution, I have one question. In XElement.java, the native getStyleAttribute() method calls "this.getStyle()". Where exactly is the getStyle() method defined?

Anyway, since I couldn't "step into" that code, I created my own methods to get the font weight from the DOM.



public final native String getFontWeight(Element el) /*-{
return $doc.defaultView.getComputedStyle(el, "").fontWeight + '';
}-*/;


public final native String getFontWeightIE(Element el) /*-{
return el.currentStyle.fontWeight + '';
}-*/;
If I did not concatenate the empty string, it will throw the same error unless I change the return type to "int". So my proposed solution (that I cannot test) is to change the internal implementation of getStyle so that it always concats an empty string to the DOM style property (to ensure it returns a String).

Secondly, TextMetrics.bind should be updated to include the fontWeight property.

Does this make sense?

Thanks
Jonathan

sven
29 Apr 2009, 11:51 AM
Yes, i also looked into that a bit deeper some time ago.

It is some more to fix that. It will be fixed for 2.0 with one of the next milestones.

jonjanisch
29 Apr 2009, 12:15 PM
Great thanks.

Also, can you point me to the source for the getStyle() method (in XElement.getStyleAttribute)? I'm clueless as to where the implementation for this actually is..

sven
29 Apr 2009, 12:18 PM
That is a javascript reference defined in the Ext class.

jonjanisch
29 Apr 2009, 12:28 PM
Thanks. That class hurts my brain. I'll go back into my Java corner now :)

darrellmeyer
1 May 2009, 11:25 AM
Thanks for investigating. Fixed in SVN.

The_Jackal
13 May 2009, 9:05 PM
This is marked as FNR 1.2.3. I'm using 1.2.4 and I can't see any fontweight fixes. Is it fixed in this version?

Should the FNR tag be changed to FNR-1.x or FNR-2.x to indicate the branch? We will be using the 1 branch for a while (till the 2 branch RTM is released.

The_Jackal

sven
13 May 2009, 9:25 PM
It is fixed in SVN. it willl be fixed with 1.2.5

The_Jackal
13 May 2009, 10:13 PM
Thanks. What do you think about the FNR tag? It can be misleading.

sven
13 May 2009, 10:14 PM
No. There is FIXED with means the fix is released and FNR which means fix not released.