> 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 <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/>

>
>
>

_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list