What font are you using? I have to admit that after looking at Pd's font system, I have no idea how it's supposed towork. There are two hardcoded collections of font metrics-- one in font_fixed_metrics in thattcl file, and another in s_main.c called sys_fontlist. It looks like the one in the tcl file is used asa point of reference against which tcl/tk can measure the font on the user's system. But thenwhen you sent those metrics off to Pd, it takes them and compares them _again_, this timeagainst the sys_fontlist min/max x/y values. That seems unnecessarily complex and proneto error.
And I use "hardcoded" loosely-- for all the "pixel exact" talk wrt Pd-extended, you would thinkthat the sys_fontlist in s_main.c would never change. Those numbers determine the max sizeof msg/obj boxes; if you increase the maximum height/width there, then someone's perfectlyarranged patch in 0.39 could have overlapping objects in 0.46. But they've been changedslightly over the years, so I don't think I'm the only one who doesn't understand the system. Additionally, Pd-extended standardized the default font on each platform to be DejaVu Sans Mono.I could be wrong, but I think Miller uses a different font. The main place this becomes a problemis with multi-line message boxes. Typically, you end up with a bunch of extra space at the bottomof the box. (And tcl/tk doesn't let you control the spaces between lines of text so there's no wayto fix it.) This becomes more than an aesthetic problem-- for example, if you try to move the cursor,Pd moves it based on Miller's font metrics, not the users. This means that for large message boxes,when a Pd-extended user tries to select a line of text it will select the text a line or two above that. At the moment, I've got DejaVu Sans Mono perfectly size to fit Miller's sys_fontlist in the GUIport. One of the side effects is that the characters of the font itself are noticeably larger thanthey are in Pd-Vanilla. For example, [get] in my port will touch the top of the outlet with the bottomof the "g" character. I've found that making the xlets light gray is a decent compromise, and thatthings are generally more readable. (I'm also not using bold typeface.) I was also going to try Droid Sans Mono Dotted because I read that it covers CJK characters.But in my tests it looks like DejaVu does as well, so I haven't done that. -Jonathan On Saturday, October 3, 2015 2:24 AM, Roman Haefeli <[email protected]> wrote: Only after having access to more Windows virtual machines, I realize this is an issue only on _one_ Windows machine (unfortunately, the one I did the most of the testing with). Sorry for the noise (that caused no reaction anyway). Roman On Don, 2015-09-10 at 14:43 +0200, Roman Haefeli wrote: > Hi all > > It's old news, but deken makes Pd-vanilla _the_ target platform and I do > care about portability: > > Font sizes in canvasses are different between Linux and Windows. > > Some patches created on Linux break on Windows because symbol boxes are > overlapping the GOP area and are not visible anymore. > > From the list of available sizes in the 'Edit'->'Font' menu, only a few > sizes are actually affected. The sizes 8, 10 and 12 are one pixel per > character wider on Windows than on Linux. The sizes 16, 24 and 36 are > OK. > > Now the question is what is the correct way to fix that, I mean on what > platform should it be changed? I'd say it should be changed on Windows, > because I can't imagine that shrinking boxes would break any patches, > while widening boxes might do. > > Pd-extended already dealt with the issue and apparently found a fix. > What would speak against incorporating that fix into Pd? > > Roman > _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
