Thanks. I haven't run any tests with custom DPI settings for the gui port. But I'd be willingto bet all that works just fine since people can view websites on Iphones. -Jonathan
On Saturday, October 3, 2015 12:43 PM, Matt Barber <brbrof...@gmail.com> wrote: There was a problem in extended some years ago when tcl/tk 8.5 broke a lot of font stuff by trying to do too much automatically, which caused some cross-platform trouble. I ended up having to make a wrapper for linux that momentarily changed the screen DPI, since 8.5 would use that to size fonts, and would get it wrong. I have no clue what happens now, but maybe this will be helpful: http://markmail.org/message/ssygglbvuz6mdkjz On Sat, Oct 3, 2015 at 12:20 PM, Jonathan Wilkes via Pd-list <pd-list@lists.iem.at> wrote: > 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. Actually, I'm not at all certain if its the Pd font metrics. It may be that the font engine uses differentinter-line spacing, or that tcl/tk reports the wrong metric, or something else. The point is that if your message box is 400 pixels high and the text that fills it is only 380 pixels high, Pd calculates cursorposition based on the _box_ size. As you add more lines to the box that discrepancy grows untilit becomes nearly impossible to move the cursor or select text accurately. -Jonathan On Saturday, October 3, 2015 12:12 PM, Jonathan Wilkes via Pd-list <pd-list@lists.iem.at> wrote: 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 <reduz...@gmail.com> 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 > _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list