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 <[email protected]> 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 <[email protected] >> <mailto:[email protected]>> 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/>
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
