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
On Thu, 2015-09-10 at 14:43 +0200, Roman Haefeli wrote:
Pd-extended already dealt with the issue and apparently found a fix. What would speak against incorporating that fix into Pd?
Something I found in Pd-extended is a different metric matrix in pd-gui.tcl . I took over some of Pd-extended's values and it does already a better job, but still not perfect:
diff --git a/tcl/pd-gui.tcl b/tcl/pd-gui.tcl index 92c632e..b10ced6 100755 --- a/tcl/pd-gui.tcl +++ b/tcl/pd-gui.tcl @@ -125,10 +125,10 @@ set font_weight "normal" # sizes of chars for each of the Pd fixed font sizes: # fontsize width(pixels) height(pixels) set font_fixed_metrics {
- 8 6 11
- 8 5 11 9 6 12
- 10 7 13
- 12 9 16
- 10 6 13
- 12 10 16 14 8 17 16 10 20 18 11 22
The width of the sizes 8 and 10 are OK now, but 10 is now one pixel taller on Linux compared to Windows. Size 12 didn't change at all. It is still wider and one pixel taller on Windows compared to Linux.
Roman
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
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 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
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 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
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
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 <brbrofsvl@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 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
On Sat, 2015-10-03 at 16:11 +0000, Jonathan Wilkes wrote:
What font are you using?
On Winodws 7 (quite pristine) I get the following message:
WARNING: Font family 'DejaVu Sans Mono' not found, using default (courier)
On Linux, I don't get such a message. So I assume I'm actually using 'DejaVi Sans Mono'.
I have to admit that after looking at Pd's font system, I have no idea how it's supposed to work.
I see. So do I (given how much you understand of Pd's code, there isn't much of a chance I could understand it).
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.
I couldn't figure out what those lists of numbers actually do. Are they meant to define a box that the best-suiting font-size is fitted into automatically? Sorry that this so alien to me even after your explanation (but maybe there is no need for me to understand it).
Anyway, what I said in my last mail is still not true. The problem is more complex. On one WinXP box and also with Wine I get different widths for the sizes 8, 10 and 12 (compared to Linux). On another WinXP and a Win7 box I get a different width only for the size 12. On a closer look, though, box heights are differ sometimes, too. See this animated gif:
http://www.netpd.org/~roman/tmp/font_comaprison_linux_windows7.gif
Now, since you asked what font I'm using, I notice that this is probably the reason for the different box sizes on Windows. On Wine it looks like Pd is using 'DejaVu Sans Mono' (so when using the _same_ font, the differences are _bigger_).
To make a long story short: The topic definitely is still an issue. And we haven't even talked about Pd on Mac (probably it is not an issue there?)
Roman
-
Jonathan Wilkes -
Matt Barber -
Roman Haefeli