Tk Source Code

textIndex-19.14 fails on Linux only, not on Windows nor on OS X:

==== textIndex-19.14 Display lines + lines with Unicode text FAILED
==== Contents of test case:

    destroy .t
    pack [text .t -font {Courier -24}]
    update
    .t insert end "abcdefgh\n\u0430\u0431\u0432\u0433\u0491\u0434\u0435\u0454\n\u4E00\u4F0A\u4F9D\u533B\u54BF\u566B\u6B39\u6CC6"
    .t sync
    set res {}
    lappend res [.t index "1.4 +1lines"] [.t index "1.4 +2lines"]
    lappend res [.t index "1.4 +1displaylines"] [.t index "1.4 +2displaylines"]
    lappend res [.t index "3.4 -1lines"] [.t index "3.4 -2lines"]
    lappend res [.t index "3.4 -1displaylines"] [.t index "3.4 -2displaylines"]
    set res

---- Result was:
2.4 3.4 2.2 3.2 2.4 1.4 2.3 1.5
---- Result should have been (exact matching):
2.4 3.4 2.4 3.2 2.4 1.4 2.6 1.6
==== textIndex-19.14 FAILED

This happens whether the test is run in isolation:

    make test TESTFLAGS="-file textIndex.test -match textIndex-19.14 -verbose bepst"

How strange.

After make clean in Tk AND in Tcl, recompiling everything from scratch, I get the expected:

% font actual {{DejaVu Sans}}
-family {DejaVu Sans} -size 12 -weight normal -slant roman -underline 0 -overstrike 0

And textIndex-19.14 no longer fails. Closing.

Here is the output I get:

$ pkg-config --cflags xft
-I/usr/include/freetype2 
$ pkg-config --libs xft
-lXft 

The output of the configure script (extract) looks like this:

[...]
checking for X... libraries , headers 
checking for main in -lXbsd... no
checking whether to use xft... yes
checking for X11/Xft/Xft.h... yes
checking for XftFontOpen in -lXft... yes
checking for FcFontSort in -lfontconfig... yes
checking for X11/XKBlib.h... yes
checking for XkbKeycodeToKeysym in -lX11... yes
checking whether XKeycodeToKeysym is deprecated... yes
[...]

Nevertheless tkUnixRFont.c is not used it seems. tkUnixFont.c is instead.

> tkUnixRFont.c is not used it seems. tkUnixFont.c is instead
> (I will try to check whether the test still fails with --enable-xft...

Whether xft is enabled per default depends on

    pkg-config --cflags   -> -I/usr/include/freetype2
    pkg-config --libs     -> xft

this command should not fail and should deliver these (or similar) values. If xft is not enabled although the correct values has been received from pkg-config then the configure script has any bug related to xft.

tkUnixRFont.c is not used it seems. tkUnixFont.c is instead (I will try to check whether the test still fails with --enable-xft, which I guess should make use of tkUnixRFont.c).

Debugging this a bit, just by running font actual {{DejaVu Sans}}, everything looks OK until:

(gdb) bt
#0  ListFonts (display=0x6804e0, faceName=0x73a8f0 "DejaVu Sans", numNamesPtr=0x7fffffffd71c) at /home/francois/Documents/tcltk/fossil/tk/unix/../unix/tkUnixFont.c:2914
#1  0x00007ffff7b549f5 in ListFontOrAlias (display=0x6804e0, faceName=0x73a8f0 "DejaVu Sans", numNamesPtr=0x7fffffffd71c) at /home/francois/Documents/tcltk/fossil/tk/unix/../unix/tkUnixFont.c:2927
#2  0x00007ffff7b523fb in CreateClosestFont (tkwin=0x667880, faPtr=0x7fffffffd830, xaPtr=0x7fffffffd7d0) at /home/francois/Documents/tcltk/fossil/tk/unix/../unix/tkUnixFont.c:1493
#3  0x00007ffff7b512a2 in TkpGetFontFromAttributes (tkFontPtr=0x0, tkwin=0x667880, faPtr=0x7fffffffd830) at /home/francois/Documents/tcltk/fossil/tk/unix/../unix/tkUnixFont.c:782
#4  0x00007ffff7a017ae in Tk_AllocFontFromObj (interp=0x618ca0, tkwin=0x667880, objPtr=0x65c7e0) at /home/francois/Documents/tcltk/fossil/tk/unix/../generic/tkFont.c:1182
#5  0x00007ffff7a0027e in Tk_FontObjCmd (clientData=0x667880, interp=0x618ca0, objc=3, objv=0x61cd50) at /home/francois/Documents/tcltk/fossil/tk/unix/../generic/tkFont.c:584
#6  0x00007ffff75bdd45 in Dispatch (data=0x65f5d8, interp=0x618ca0, result=0) at /home/francois/Documents/tcltk/fossil/tcl/generic/tclBasic.c:4365
#7  0x00007ffff75bddce in TclNRRunCallbacks (interp=0x618ca0, result=0, rootPtr=0x0) at /home/francois/Documents/tcltk/fossil/tcl/generic/tclBasic.c:4398
#8  0x00007ffff75c0919 in TclEvalObjEx (interp=0x618ca0, objPtr=0x0, flags=131072, invoker=0x0, word=0) at /home/francois/Documents/tcltk/fossil/tcl/generic/tclBasic.c:5963
#9  0x00007ffff75c08af in Tcl_EvalObjEx (interp=0x618ca0, objPtr=0xffffffff, flags=131072) at /home/francois/Documents/tcltk/fossil/tcl/generic/tclBasic.c:5944
#10 0x00007ffff76ae972 in Tcl_RecordAndEvalObj (interp=0x618ca0, cmdPtr=0x661bb0, flags=131072) at /home/francois/Documents/tcltk/fossil/tcl/generic/tclHistory.c:190
#11 0x00007ffff76ae637 in Tcl_RecordAndEval (interp=0x618ca0, cmd=0x7fffffffdec0 "font actual {{DejaVu Sans}}\n", flags=131072) at /home/francois/Documents/tcltk/fossil/tcl/generic/tclHistory.c:75
#12 0x00007ffff7a17f78 in StdinProc (clientData=0x7fffffffdea0, mask=2) at /home/francois/Documents/tcltk/fossil/tk/unix/../generic/tkMain.c:456
#13 0x00007ffff76c1dff in Tcl_NotifyChannel (channel=0x6eae00, mask=2) at /home/francois/Documents/tcltk/fossil/tcl/generic/tclIO.c:8360
#14 0x00007ffff773971a in FileHandlerEventProc (evPtr=0x7048e0, flags=-3) at /home/francois/Documents/tcltk/fossil/tcl/unix/tclUnixNotfy.c:805
#15 0x00007ffff76e669f in Tcl_ServiceEvent (flags=-3) at /home/francois/Documents/tcltk/fossil/tcl/generic/tclNotify.c:670
#16 0x00007ffff76e6adb in Tcl_DoOneEvent (flags=-3) at /home/francois/Documents/tcltk/fossil/tcl/generic/tclNotify.c:967
#17 0x00007ffff79fe7f2 in Tk_MainLoop () at /home/francois/Documents/tcltk/fossil/tk/unix/../generic/tkEvent.c:2148
#18 0x00007ffff7a17d42 in Tk_MainEx (argc=-1, argv=0x7fffffffe1e0, appInitProc=0x400aeb <Tcl_AppInit>, interp=0x618ca0) at /home/francois/Documents/tcltk/fossil/tk/unix/../generic/tkMain.c:390
#19 0x0000000000400ae4 in main (argc=1, argv=0x7fffffffe1d8) at /home/francois/Documents/tcltk/fossil/tk/unix/../unix/tkAppInit.c:78

ListFonts simply is:

    sprintf(buf, "-*-%.80s-*-*-*-*-*-*-*-*-*-*-*-*", faceName);
    return XListFonts(display, buf, 10000, numNamesPtr);

At this point we have:

(gdb) p faceName
$39 = 0x73a8f0 "DejaVu Sans"
(gdb) p buf
$40 = "-*-DejaVu Sans-*-*-*-*-*-*-*-*-*-*-*-*\000\000@2`\000\000\000\000\000`\302a", '\000' <repeats 13 times>, "\260\325\377\377\377\177\000\000\213\252\\\367\377\177\000\000\310[k\000\000\000\000\000\300[k\000*\000\000\000 \326\377\377\377\177\000\000 \255\205\000\000\000\000\000\360\325\377\377\377\177\000\000\034\343j\367\377\177\000\000\364m\271\367\377\177\000\000\070\ag\000\000\000\000\000 \255\205\000\000\000\000\000\037\331j\367\n\000\000\000\364m\271\367\377\177\000\000\320\341\377\377\n\000\000\000P\326\377\377\377\177\000\000\224\333j\367\377\177\000\000\060\350s\000\025\000\000\000"...

The X11 library XListFonts() does not return any font with this (numNamesPtr is zero).

> It seems that Tk does not manage to obtain this font on my system.

This means that the X11 font handling has a severe bug. I think that the functions InitFont(), GetFont(), TkpGetFontFromAttributes() in tkUnixRFont.c are responsible. Another important function is TkpGetFontFamilies(), is this function recognizing the font? Can you figure out where it fails? Unfortunately (!) under my system the font handling works.

The package fonts-dejavu really is installed in my Linux Debian. I can use {DejaVu Sans} in other software, e.g. Kate.

It seems that Tk does not manage to obtain this font on my system.

We have seen this before with your chess-specific font. I could finally install it on my system but never use it from within Tk.

Results:

OS X:

% font actual {{DejaVu Sans}}
-family .AppleSystemUIFont -size 13 -weight normal -slant roman -underline 0 -overstrike 0

Win:

% font actual {{DejaVu Sans}}
-family {DejaVu Sans} -size 12 -weight normal -slant roman -underline 0 -overstrike 0

Debian 8:

% font actual {{DejaVu Sans}}
-family fixed -size 13 -weight normal -slant roman -underline 0 -overstrike 0

Looks like this test is a candidate for a font constraint.

 Under my system DejaVu Sans looks perfect, see attached screenshot (DejaVuSans-Ubuntu.png). Is this font installed under the different systems, please try:

<verbatim>
puts [font actual {{DejaVu Sans}}]
</verbatim>

But the changed test still fails on Debian:

---- Result was:
2.4 3.4 2.2 3.2 2.4 1.4 2.4 1.8
---- Result should have been (exact matching):
2.4 3.4 2.4 3.2 2.4 1.4 2.6 1.7

Looking at the rendering it's better, but there are still two "box-like" characters. The font does not appear to feature the required glyphs.

Almost OK for Win and OS X, but the changed test fails with:

---- Result was:
2.4 3.4 2.4 3.2 2.4 1.4 2.7 1.7
---- Result should have been (exact matching):
2.4 3.4 2.4 3.2 2.4 1.4 2.6 1.7

I see, your distro is using different fonts. I think that this test script should use an Unicode font, the most common under Linux is DejaVu:

test textIndex-19.14 {Display lines + lines with Unicode text} {
    destroy .t
    pack [text .t -font {{DejaVu Sans} -24}]
    update
    .t insert end "abcdefgh\n\u0430\u0431\u0432\u0433\u0491\u0434\u0435\u0454\n\u4E00\u4F0A\u4F9D\u533B\u54BF\u566B\u6B39\u6CC6"
    .t sync
    set res {}
    lappend res [.t index "1.4 +1lines"] [.t index "1.4 +2lines"]
    lappend res [.t index "1.4 +1displaylines"] [.t index "1.4 +2displaylines"]
    lappend res [.t index "3.4 -1lines"] [.t index "3.4 -2lines"]
    lappend res [.t index "3.4 -1displaylines"] [.t index "3.4 -2displaylines"]
    set res
} {2.4 3.4 2.4 3.2 2.4 1.4 2.6 1.7}

But I don't know whether this works with Windows/Mac.

Indeed. Snapshot attached.

It seems that your Linux distro is providing/choosing different fonts. I've attached a screenshot how it looks like under Ubuntu 14.04. Please compare this with your display. Use the following script:

pack [text .t -font {Courier -24} -width 10 -height 3]
.t insert end "abcdefgh\n\u0430\u0431\u0432\u0433\u0491\u0434\u0435\u0454\n\u4E00\u4F0A\u4F9D\u533B\u54BF\u566B\u6B39\u6CC6"