Tk Source Code

The following should see the label's font underlined during mouse-over.

===========
catch {font create url}
catch {font create urlmo}
font configure url   -family Arial -size 12 -underline 0
font configure urlmo -family Arial -size 12 -underline 1

grid [ttk::label .l -text "Should be underlined on mouse-over." -font url -foreground darkgreen]

bind .l <Enter> ".l configure -cursor hand2 -font urlmo -foreground darkblue" 
bind .l <Leave> ".l configure -cursor arrow -font url -foreground darkgreen" 
bind .l <Button-1> ".l configure -font urlmo -foreground red ; # someProc"
===========

The font's colour changes on X11 (so the rest of the configure works).

Underline tested OK on Windows and Mac OS X.

allow_comments - 1

Fixed for 8.5 and HEAD.
The HEAD fix was awkward because the underline/overstrike had to also work rotated...

The fundamental problem is that xft/fontconfig doesn't provide a mechanism for determining the underlining metrics (position and size of underline rule, though size is not critical).

is there a plan to fix this?  It seems like using the "old (ugly) font engine" (ID: 2778846) using the --disable-xft option to configure might not even fix the underline problem (from  teopetuk on Date: 2008-09-10 13:38, below) and would probably introduce old issues as well.
I have tested this underline problem up to 8.5.7, and it still doesn't work, even though there is a "Group:" status as "obsolete: 8.5.2". Is that right?
I see a code change below, but should this change be incorporated into the code base?

thanks,

Blaine

Much googling indicates that Keith Packard forgot to include (or deliberately omitted) properties for the underline position and rendering in Xft/fontconfig.

At least one alternative puts the underline at 0.1 of the character height (within the bounding box cell), or at 0.5 for strikeout.

After looking through unix/tkUnixRFont.c I'd say that neither -underline nor -overstrike are implemented for Xft fonts. So, curently the only way to get underlined or overstricken fonts outside text widget is to use X core fonts.

Sorry... i mean _overstrike_
This is a code snippet that works fine in linux wish8.4 but not 8.5
-----
set LABEL1 [label .l1 -text {overstrike = 0}]
set LABEL2 [label .l2 -text {overstrike = 1}]
set lFont [$LABEL1 cget -font]
set overstruckfont [font actual "[font actual $lFont] -overstrike 1"]
.l2 configure -font $overstruckfont
pack .l1 -side top
pack .l2 -side bottom
-----

Font understrike doesn't work either on all 8.5 i've tested, up to 8.5.4.
(stevenaaus)

Apparently I've tested the patch using Xft-disabled build. So, while it fixes canvas postscript problem, it doesn't fix underlined fonts. Sorry for the noise.

While investigating another font related bug (see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=498408) I've found that when using old X11 fonts Tk never uses negative font sizes (it converts them to positive throug TkFontGetPoints()). So, I suppose that there's code which uses fonts and implicitly assumes that its size is always positive.

After applying the attached patch which simply converts font size to a positive value (size in points) both bug in canvas and this bug are gone. Though probably in long run it would be better to find code which cannot work if font size is negative and fix it.

(Can't find how to attach the patch, so listing it here)

--- tk8.5-8.5.4.orig/unix/tkUnixRFont.c
+++ tk8.5-8.5.4/unix/tkUnixRFont.c
@@ -260,6 +260,7 @@
     ftFont = GetFont(fontPtr, 0);
     fontPtr->font.fid = XLoadFont(Tk_Display(tkwin), "fixed");
     GetTkFontAttributes(ftFont, &fontPtr->font.fa);
+    fontPtr->font.fa.size = TkFontGetPoints(tkwin, fontPtr->font.fa.size);
     GetTkFontMetrics(ftFont, &fontPtr->font.fm);
 
     return fontPtr;
@@ -517,6 +518,7 @@
 /* Actual font used to render the character */
 
     GetTkFontAttributes(ftFont, faPtr);
+    faPtr->size = TkFontGetPoints(tkwin, faPtr->size);
     faPtr->underline = fontPtr->font.fa.underline;
     faPtr->overstrike = fontPtr->font.fa.overstrike;
 }

Logged In: YES 
user_id=2029956
Originator: YES

The first example using ttk::label, but, I've just tested with the standard Tk label and it's much the same. Definitely font related rather than widget related.