Menu

#3075 tag pixel range errors in Aqua/Cocoa

current: 8.6.0
open
5
2013-03-24
2013-03-08
kjnash
No

The attached archive contains a script and a screenshot that demonstrate the bug. Sorry about the tarball, Sourceforge only allows one file upload these days.

The script tries to color a tagged range in a text widget.

$text tag configure $tagName -foreground red

For certain fonts, the range of pixels that are colored is about 5 pixels to the left of where it should be. This is independent of any borders that the widget has. In the demo script, the borders are set to 0.

One font that behaves this way is {Courier New}, which is supplied with OS X.

The screenshot image shows that the glyph positions agree with Tk's [$text bbox] measurements, and are consistent with a fixed-width font with width 11 pixels.

$ /usr/local/tcl8.6/bin/wish8.6
% source text-tag-colors2.tcl
-ascent 15 -descent 5 -linespace 20 -fixed 1
% font metrics {{Courier New} 18}
-ascent 15 -descent 5 -linespace 20 -fixed 1
%
% .f.t bbox 1.0
0 0 11 20
% .f.t bbox 1.1
11 0 11 20
% .f.t bbox 1.2
22 0 11 20
% .f.t bbox 1.3
33 0 11 20

Most fonts do not exhibit this bug: the Courier, Menlo, and Monaco fonts are fine. Apart from {Courier New}, I also have trouble with {DejaVu Sans Mono}, which is a TrueType font.

The bug seems to occur only with Tk/Aqua/Cocoa; I do not see it on the 8.5.11 Carbon version of Tk, or on other platforms. I don't see it in other applications either - e.g. TextEdit appears to be a Cocoa application, and can correctly color a range of {Courier New} text.

Discussion

  • kjnash

    kjnash - 2013-03-08

    tarball of demo script and screenshot

     
  • kjnash

    kjnash - 2013-03-08
    • milestone: --> current: 8.6.0
     
  • Kevin Walzer

    Kevin Walzer - 2013-03-24
    • assigned_to: hobbs --> wordtech
     
  • Kevin Walzer

    Kevin Walzer - 2013-03-24

    Looking at tkMacOSXFont.c, I see this comment:

    /*
    * The ascent, descent and fixed fields are not correct for all fonts, as
    * a workaround deduce that info from the metrics of some typical glyphs,
    * along with screenfont kerning (space advance difference to printer font)
    */

    This suggests to me that the inconsistency may be a known issue, with no known workaround. The fact that it only seems to hit on certain fonts suggests that avoiding those fonts is the simplest solution.