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 different inter-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 cursor position based on the _box_ size. As you add more lines to the box that discrepancy grows until it 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 to work. There are two hardcoded collections of font metrics-- one in font_fixed_metrics in that tcl file, and another in s_main.c called sys_fontlist. It looks like the one in the tcl file is used as a point of reference against which tcl/tk can measure the font on the user's system. But then when you sent those metrics off to Pd, it takes them and compares them _again_, this time against the sys_fontlist min/max x/y values. That seems unnecessarily complex and prone to error.
And I use "hardcoded" loosely-- for all the "pixel exact" talk wrt Pd-extended, you would think that the sys_fontlist in s_main.c would never change. Those numbers determine the max size of msg/obj boxes; if you increase the maximum height/width there, then someone's perfectly arranged patch in 0.39 could have overlapping objects in 0.46. But they've been changed slightly 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 problem is with multi-line message boxes. Typically, you end up with a bunch of extra space at the bottom of the box. (And tcl/tk doesn't let you control the spaces between lines of text so there's no way to 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 GUI port. One of the side effects is that the characters of the font itself are noticeably larger than they are in Pd-Vanilla. For example, [get] in my port will touch the top of the outlet with the bottom of the "g" character. I've found that making the xlets light gray is a decent compromise, and that things 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 reduzent@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