> I could be wrong but I believe that when you ask for a negative font size
that inhibits scaling... so the line in pd-gui.tcl: negative font-size numbers in tk mean pixel sizing instead of point sizing. > set foo [list $::font_family -$fsize bold] > is asking for pixel-deterministic font sizes. Pixel sizes do not guarantee that the text will fit into a particular pixel-based sizing spec. > I think that TCL/TK 8.6 is in fact misrepresenting the true font size by 1 pixel. What I don't know is whether to throw in a workaround (test for TCL version and adjust ifit's 8.6???) or to try to dig up the problem in tcl/tk itself... Determine the sizes for object and message boxes using fontspec heights/widths instead of the ones particular to the font tcl/tk measured. Otherwise users will not be able to tell the difference between a font-rendering bug on their system and a patch where the author happened to create collisions. -Jonathan > cheers > Miller On Wed, Feb 15, 2017 at 12:52:00AM -0700, Dan Wilcox wrote: > 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 <danomat...@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 <m...@ucsd.edu > >> <mailto:m...@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/> > > > _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
