On further digging, I think the culprit is a slightly different tk scaling value:
Tk 8.4 -> scaling: 0.999016715831
Tk 8.6 -> scaling: 0.9990167158308751
Looks like a precision/rounding issue after all w/ 11 digits versus 17.
On Feb 15, 2017, at 12:16 AM, Dan Wilcox danomatika@gmail.com wrote:
Looks like you’re right. I checked the debug output of the fit_font_into_metrics proc:
In Tk 8.4 with Monaco, I get
6 4 7 7 4 9 8 5 10 9 7 11 10 6 13 …
And in Tk 8.6:
6 4 9 7 5 10 8 5 11 9 6 12 10 7 14 …
I wonder if this is a rounding error?
On Feb 12, 2017, at 9:20 AM, Miller Puckette <msp@ucsd.edu mailto:msp@ucsd.edu> wrote:
About that padding - the Tcl code sends Pd the font metrics on startup, and Pd follows them in setting the dimensions of boxes. So I guess the new version of Tcl/Tk is overstating the font width by one pixel. Perhaps height is also wrong in the same way (make a mesages box with 20-ish lines in it and see if the box is 20 pixels too tall).
cheers M
On Sun, Feb 12, 2017 at 02:39:32AM -0700, Dan Wilcox wrote:
As for comparisons, here’s the same patch using Deja Vu Sans Mono and Monaco, both with Tk 8.4 & with Tk 8.6 Retina HiDPI rendering: https://flic.kr/p/QLGphN https://flic.kr/p/QLGphN <https://flic.kr/p/QLGphN https://flic.kr/p/QLGphN> (zoom in or download & view at full size)
Jonathan: One of the remaining problems I have with the Tk 8.6 build is the padding added to the object box width in HiDPI. Any clues on what to look into to fix this? The object arguments are clearly the same width… or appear to be.
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/