----- Start Forwarded Message ----- Sent: Mon, 11 Sep 2017 21:49:42 -0400 (EDT) From: "Alexander Connor" a.connexx@runbox.com To: "Lucas Cordiviola" lucarda27@hotmail.com Subject: Re: [PD] linux: "-font-size" startup flag -- does this work?
Ah yes thank you I forgot that and was using the wrong GUI window menu --
Unfortunately though, it still doesn't help with this problem because what I need is a size 9, and as I mentioned this is an "in between" variable that isn't available in the GUI options.
Is there a control channel that I could send the desired font size through within the patch to bypass the limited GUI switching? Or alternatively (but much less desirability) a variable to edit within the text file (is that what the last number is in the canvas parameters at the beginning of the file)?
Those things aside, there's still one thing I don't understand about the -font-size flag. As I mentioned -font-face and -font-weight produce the effect I expected -- that is, they change the face and weight of all patches opened after Pd starts up -- but not -font-size. If what you say is the case (sorry haven't been able to test it yet) isn't this a bit inconsistent with the functioning of the other font control flags?
On Mon, 11 Sep 2017 18:00:34 +0000, Lucas Cordiviola lucarda27@hotmail.com wrote:
hi,
The "-font-size" flag will affect your *new* patches. Saved patches have their font size saved.
If you want to change the font of a saved patch use the "GUI Edit->Font option" of that particular window, not the Pd window (the one with the console).
Hope this helps.
Mensaje telepatico asistido por maquinas.
On 9/11/2017 2:02 PM, Alexander Connor wrote:
Hello list -
So whilst testing some of the newer Debian/Ubuntu versions to replace my EOL/close to EOL versions I'm currently using, I ran into the enlarged font rendering issue in Vanilla which has been discussed in various posts to this list and I am aware the devs are still working on this.
I attempted some temporary workarounds. I first tried the GUI Edit->Font option. In pre 0.48 Vanilla, this would change the object box font size (this seems not to be the case in 0.48 as it is now applied to to the window menu fonts???) but this didn't cut it as I needed size that was in between the GUI selectable values.
So I then turned to the -font-size startup flag, and found that no matter what value I put in, on any of the last few revisions of 0.47 or even 0.48, this flag seemed to do *absolutely nothing*. Tried with and without quotes around the variable -- nada. I tested -font-face and -font-weight and these worked as expected. Am I missing something here? Should I file a bug?
BTW I tried searching for -font-size in the archive, but this buries you with the "font-size" line in all the headers in those "attachment" files. Couldn't find any way to filter those. Not very useful.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
----- End Forwarded Message -----
On 9/11/2017 10:52 PM, Alexander Connor wrote:
Ah yes thank you I forgot that and was using the wrong GUI window menu --
Unfortunately though, it still doesn't help with this problem because what I need is a size 9, and as I mentioned this is an "in between" variable that isn't available in the GUI options.
Is there a control channel that I could send the desired font size through within the patch to bypass the limited GUI switching?
Not that I know.
Or alternatively (but much less desirability) a variable to edit within the text file
Nop.
(is that what the last number is in the canvas parameters at the beginning of the file)?
Yes, the last number of the first line.
Those things aside, there's still one thing I don't understand about the -font-size flag. As I mentioned -font-face and -font-weight produce the effect I expected -- that is, they change the face and weight of all patches opened after Pd starts up -- but not -font-size. If what you say is the case (sorry haven't been able to test it yet) isn't this a bit inconsistent with the functioning of the other font control flags?
IMO is not inconsistent as "-font-face" and "-font-weight" are "general" and are not saved in the patch. OTOH "-font-size" is saved in the patch.
Mensaje telepatico asistido por maquinas.
On 2017-09-12 14:55, Lucas Cordiviola wrote:
Or alternatively (but much less desirability) a variable to edit within the text file
Nop.
of course you can (if by "text file" you mean the Pd-patch):
PTS=12
PATCH=patch.pd
sed -e "s/^\(#N canvas [0-9 ]*\) [0-9]*;$/\1 ${PTS};/" -i "${PATCH}"
gbsmdr IOhannes
The OP is trying to use font 9.
He will get font 8 if he edit the the Pd-patch as a text file.
Mensaje telepatico asistido por maquinas.
On 9/12/2017 10:10 AM, IOhannes m zmoelnig wrote:
On 2017-09-12 14:55, Lucas Cordiviola wrote:
Or alternatively (but much less desirability) a variable to edit within the text file
Nop.
of course you can (if by "text file" you mean the Pd-patch):
PTS=12
PATCH=patch.pd
sed -e "s/^\(#N canvas [0-9 ]*\) [0-9]*;$/\1 ${PTS};/" -i "${PATCH}"
gbsmdr IOhannes
Pd-list@lists.iem.atmailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Thank you for these answers.
Editing the Pd text file wasn't really much of a solution for me since I'm dealing with a very large patch with many subpatches which would all have to be changed; I was really looking for a way to scale everything at once and back again should the need arise.
However it would appear that there is basically no solution to this problem until font rendering is fixed.
Guess I'll have to stick with my EOLs for now. Too bad. I really wanted to start distributing this patch. I tried to mostly use the GUI object fonts that aren't affected by this in the "up front" user areas of the patch but there's a few areas such as the symbol boxes where you can't get around this. It completely messes up the neatly spaced background "guts" that I set up to make it easier to read for anyone who wanted to make mods. Lots of compact tightly aligned spacing going on. As I said it's very large (been working on it for years) and reformatting just to correct for this error doesn't seem worth it especially if I have to switch it all back when (if?) the problem is corrected in Pd.
On Tue, 12 Sep 2017 14:03:24 +0000, Lucas Cordiviola lucarda27@hotmail.com wrote:
The OP is trying to use font 9.
He will get font 8 if he edit the the Pd-patch as a text file.
Mensaje telepatico asistido por maquinas.
On 9/12/2017 10:10 AM, IOhannes m zmoelnig wrote:
On 2017-09-12 14:55, Lucas Cordiviola wrote:
Or alternatively (but much less desirability) a variable to edit within the text file
Nop.
of course you can (if by "text file" you mean the Pd-patch):
PTS=12 PATCH=patch.pd sed -e "s/^\(#N canvas [0-9 ]*\) [0-9]*;$/\1 ${PTS};/" -i "${PATCH}"gbsmdr IOhannes
Pd-list@lists.iem.atmailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Hey Alexander
I hear you and I am in the same boat.
On Die, 2017-09-12 at 21:50 -0400, Alexander Connor wrote:
Thank you for these answers.
Editing the Pd text file wasn't really much of a solution for me since I'm dealing with a very large patch with many subpatches which would all have to be changed; I was really looking for a way to scale everything at once and back again should the need arise.
I guess the reason it is not a solution is because the available font sizes don't match what you want. Otherwise I believe it would be worth going through all of your patches. You can automate something like this. IOhannes just gave you the first hint.
However it would appear that there is basically no solution to this problem until font rendering is fixed.
Unfortunately, I think so, too.
Guess I'll have to stick with my EOLs for now. Too bad. I really wanted to start distributing this patch.
I see. There is something nobody mentioned yet: You could also tweak the font metrics in pd-gui.tcl. Obviously, this only fixes the situation for your Pd installation, it wouldn't help if your goal is to distribute your graphically sophisticated patches. I'm in the same situation as you and I currently deal with it by fixing the font- metrics for myself (which is not a viable solution, of course).
I tried to mostly use the GUI object fonts that aren't affected by this in the "up front" user areas of the patch but there's a few areas such as the symbol boxes where you can't get around this.
Absolutely. [symbolatom \ is the only text input I know of in Pd and I keep stumbling about the exact same problem. It'd help a lot already if there is a symbolbox2 with configurable font similar to the 'Number2' widget.
It completely messes up the neatly spaced background "guts" that I set up to make it easier to read for anyone who wanted to make mods. Lots of compact tightly aligned spacing going on. As I said it's very large (been working on it for years) and reformatting just to correct for this error doesn't seem worth it especially if I have to switch it all back when (if?) the problem is corrected in Pd.
I, too, think it is probably not worth to fix this in your patches _now_. Currently, the situation is still a bit messy. As of Pd 0.48, patches are rendered the same on macOS and on Linux, but on both platforms, patches looked different in earlier versions, so patches you made for 0.47 are messed up now. Pd on Windows looks again very different. The different available font sizes result in totally different box sizes on Windows compared to macOS and Linux. Also, box sizes depend on whether the font DejaVu Sans Mono is installed or not. On macOS and Linux, this is already the default font and is shipped with Pd, on Windows this is planned.
It is slightly frustrating not to be able to rely on some graphical features in a graphical programming language.
Roman
On Tue, 12 Sep 2017 14:03:24 +0000, Lucas Cordiviola lucarda27@hotmail.com wrote:
The OP is trying to use font 9.
He will get font 8 if he edit the the Pd-patch as a text file.
Mensaje telepatico asistido por maquinas.
On 9/12/2017 10:10 AM, IOhannes m zmoelnig wrote:
On 2017-09-12 14:55, Lucas Cordiviola wrote:
Or alternatively (but much less desirability) a variable to edit within the text file
Nop.
of course you can (if by "text file" you mean the Pd-patch):
PTS=12 PATCH=patch.pd sed -e "s/^\(#N canvas [0-9 ]*\) [0-9]*;$/\1 ${PTS};/" -i "${PATCH}"gbsmdr IOhannes
Pd-list@lists.iem.atmailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/l istinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/l istinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/lis tinfo/pd-list
Hi Alexander
As Roman mentioned the "pd-gui.tcl" and you surely made your patches with Pdx, can you test tweaking the .tcl?
To check if your patches render correctly?
here's the How-to:
https://github.com/pure-data/pure-data/wiki/Crossplatform-font-metrics-%26-c...
Plans for this were mentioned by Dan a month ago:
https://lists.puredata.info/pipermail/pd-list/2017-08/119967.html
Independently of the "nuts and bolts" of the relevant code that's different from Pdx my tests gave good results. In other words simply changing the hard coded metrics makes patches render like Pdx (specially EOLs).
Can you test and give feedback?
Mensaje telepatico asistido por maquinas.
On 9/13/2017 4:28 AM, Roman Haefeli wrote:
Hey Alexander
I hear you and I am in the same boat.
On Die, 2017-09-12 at 21:50 -0400, Alexander Connor wrote:
Thank you for these answers.
Editing the Pd text file wasn't really much of a solution for me since I'm dealing with a very large patch with many subpatches which would all have to be changed; I was really looking for a way to scale everything at once and back again should the need arise.
I guess the reason it is not a solution is because the available font sizes don't match what you want. Otherwise I believe it would be worth going through all of your patches. You can automate something like this. IOhannes just gave you the first hint.
However it would appear that there is basically no solution to this problem until font rendering is fixed.
Unfortunately, I think so, too.
Guess I'll have to stick with my EOLs for now. Too bad. I really wanted to start distributing this patch.
I see. There is something nobody mentioned yet: You could also tweak the font metrics in pd-gui.tcl. Obviously, this only fixes the situation for your Pd installation, it wouldn't help if your goal is to distribute your graphically sophisticated patches. I'm in the same situation as you and I currently deal with it by fixing the font- metrics for myself (which is not a viable solution, of course).
I tried to mostly use the GUI object fonts that aren't affected by this in the "up front" user areas of the patch but there's a few areas such as the symbol boxes where you can't get around this.
Absolutely. [symbolatom \ is the only text input I know of in Pd and I keep stumbling about the exact same problem. It'd help a lot already if there is a symbolbox2 with configurable font similar to the 'Number2' widget.
It completely messes up the neatly spaced background "guts" that I set up to make it easier to read for anyone who wanted to make mods. Lots of compact tightly aligned spacing going on. As I said it's very large (been working on it for years) and reformatting just to correct for this error doesn't seem worth it especially if I have to switch it all back when (if?) the problem is corrected in Pd.
I, too, think it is probably not worth to fix this in your patches _now_. Currently, the situation is still a bit messy. As of Pd 0.48, patches are rendered the same on macOS and on Linux, but on both platforms, patches looked different in earlier versions, so patches you made for 0.47 are messed up now. Pd on Windows looks again very different. The different available font sizes result in totally different box sizes on Windows compared to macOS and Linux. Also, box sizes depend on whether the font DejaVu Sans Mono is installed or not. On macOS and Linux, this is already the default font and is shipped with Pd, on Windows this is planned.
It is slightly frustrating not to be able to rely on some graphical features in a graphical programming language.
Roman
On Tue, 12 Sep 2017 14:03:24 +0000, Lucas Cordiviola lucarda27@hotmail.commailto:lucarda27@hotmail.com wrote:
The OP is trying to use font 9.
He will get font 8 if he edit the the Pd-patch as a text file.
Mensaje telepatico asistido por maquinas.
On 9/12/2017 10:10 AM, IOhannes m zmoelnig wrote:
On 2017-09-12 14:55, Lucas Cordiviola wrote:
Or alternatively (but much less desirability) a variable to edit within the text file
Nop.
of course you can (if by "text file" you mean the Pd-patch):
PTS=12
PATCH=patch.pd
sed -e "s/^\(#N canvas [0-9 ]*\) [0-9]*;$/\1 ${PTS};/" -i
"${PATCH}"
gbsmdr IOhannes
Pd-list@lists.iem.atmailto:Pd-list@lists.iem.atmailto:Pd-list@lists.iem.atmailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/l istinfo/pd-list
Pd-list@lists.iem.atmailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/l istinfo/pd-list
Pd-list@lists.iem.atmailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/lis tinfo/pd-list
Pd-list@lists.iem.atmailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Hi,
I'll try testing that as soon as I get the chance. I have tried messing with font metrics in "pd-gui.tcl"; someone mentioned a tweak to disable the rounding but it didn't help my issue (the font just got very, very small and left the object boxes too large if I remember correctly). I'll have a look at that page and get back when I can.
On Wed, 13 Sep 2017 14:20:14 +0000, Lucas Cordiviola lucarda27@hotmail.com wrote:
Hi Alexander
As Roman mentioned the "pd-gui.tcl" and you surely made your patches with Pdx, can you test tweaking the .tcl?
To check if your patches render correctly?
here's the How-to:
https://github.com/pure-data/pure-data/wiki/Crossplatform-font-metrics-%26-c...
Plans for this were mentioned by Dan a month ago:
https://lists.puredata.info/pipermail/pd-list/2017-08/119967.html
Independently of the "nuts and bolts" of the relevant code that's different from Pdx my tests gave good results. In other words simply changing the hard coded metrics makes patches render like Pdx (specially EOLs).
Can you test and give feedback?
Mensaje telepatico asistido por maquinas.
On 9/13/2017 4:28 AM, Roman Haefeli wrote:
Hey Alexander
I hear you and I am in the same boat.
On Die, 2017-09-12 at 21:50 -0400, Alexander Connor wrote:
Thank you for these answers.
Editing the Pd text file wasn't really much of a solution for me since I'm dealing with a very large patch with many subpatches which would all have to be changed; I was really looking for a way to scale everything at once and back again should the need arise.
I guess the reason it is not a solution is because the available font sizes don't match what you want. Otherwise I believe it would be worth going through all of your patches. You can automate something like this. IOhannes just gave you the first hint.
However it would appear that there is basically no solution to this problem until font rendering is fixed.
Unfortunately, I think so, too.
Guess I'll have to stick with my EOLs for now. Too bad. I really wanted to start distributing this patch.
I see. There is something nobody mentioned yet: You could also tweak the font metrics in pd-gui.tcl. Obviously, this only fixes the situation for your Pd installation, it wouldn't help if your goal is to distribute your graphically sophisticated patches. I'm in the same situation as you and I currently deal with it by fixing the font- metrics for myself (which is not a viable solution, of course).
I tried to mostly use the GUI object fonts that aren't affected by this in the "up front" user areas of the patch but there's a few areas such as the symbol boxes where you can't get around this.
Absolutely. [symbolatom \ is the only text input I know of in Pd and I keep stumbling about the exact same problem. It'd help a lot already if there is a symbolbox2 with configurable font similar to the 'Number2' widget.
It completely messes up the neatly spaced background "guts" that I set up to make it easier to read for anyone who wanted to make mods. Lots of compact tightly aligned spacing going on. As I said it's very large (been working on it for years) and reformatting just to correct for this error doesn't seem worth it especially if I have to switch it all back when (if?) the problem is corrected in Pd.
I, too, think it is probably not worth to fix this in your patches _now_. Currently, the situation is still a bit messy. As of Pd 0.48, patches are rendered the same on macOS and on Linux, but on both platforms, patches looked different in earlier versions, so patches you made for 0.47 are messed up now. Pd on Windows looks again very different. The different available font sizes result in totally different box sizes on Windows compared to macOS and Linux. Also, box sizes depend on whether the font DejaVu Sans Mono is installed or not. On macOS and Linux, this is already the default font and is shipped with Pd, on Windows this is planned.
It is slightly frustrating not to be able to rely on some graphical features in a graphical programming language.
Roman
On Tue, 12 Sep 2017 14:03:24 +0000, Lucas Cordiviola lucarda27@hotmail.commailto:lucarda27@hotmail.com wrote:
The OP is trying to use font 9.
He will get font 8 if he edit the the Pd-patch as a text file.
Mensaje telepatico asistido por maquinas.
On 9/12/2017 10:10 AM, IOhannes m zmoelnig wrote:
On 2017-09-12 14:55, Lucas Cordiviola wrote:
Or alternatively (but much less desirability) a variable to edit within the text file
Nop.
of course you can (if by "text file" you mean the Pd-patch):
PTS=12 PATCH=patch.pd sed -e "s/^\(#N canvas [0-9 ]*\) [0-9]*;$/\1 ${PTS};/" -i "${PATCH}"gbsmdr IOhannes
Pd-list@lists.iem.atmailto:Pd-list@lists.iem.atmailto:Pd-list@lists.iem.atmailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/l istinfo/pd-list
Pd-list@lists.iem.atmailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/l istinfo/pd-list
Pd-list@lists.iem.atmailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/lis tinfo/pd-list
Pd-list@lists.iem.atmailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
what is "EOLs"?
2017-09-13 11:20 GMT-03:00 Lucas Cordiviola lucarda27@hotmail.com:
Hi Alexander
As Roman mentioned the "pd-gui.tcl" and you surely made your patches with Pdx, can you test tweaking the .tcl?
To check if your patches render correctly?
here's the How-to:
https://github.com/pure-data/pure-data/wiki/Crossplatform- font-metrics-%26-comparisons
Plans for this were mentioned by Dan a month ago:
https://lists.puredata.info/pipermail/pd-list/2017-08/119967.html
Independently of the "nuts and bolts" of the relevant code that's different from Pdx my tests gave good results. In other words simply changing the hard coded metrics makes patches render like Pdx (specially EOLs).
Can you test and give feedback?
Mensaje telepatico asistido por maquinas.
On 9/13/2017 4:28 AM, Roman Haefeli wrote:
Hey Alexander
I hear you and I am in the same boat.
On Die, 2017-09-12 at 21:50 -0400, Alexander Connor wrote:
Thank you for these answers.
Editing the Pd text file wasn't really much of a solution for me since I'm dealing with a very large patch with many subpatches which would all have to be changed; I was really looking for a way to scale everything at once and back again should the need arise.
I guess the reason it is not a solution is because the available font sizes don't match what you want. Otherwise I believe it would be worth going through all of your patches. You can automate something like this. IOhannes just gave you the first hint.
However it would appear that there is basically no solution to this problem until font rendering is fixed.
Unfortunately, I think so, too.
Guess I'll have to stick with my EOLs for now. Too bad. I really wanted to start distributing this patch.
I see. There is something nobody mentioned yet: You could also tweak the font metrics in pd-gui.tcl. Obviously, this only fixes the situation for your Pd installation, it wouldn't help if your goal is to distribute your graphically sophisticated patches. I'm in the same situation as you and I currently deal with it by fixing the font- metrics for myself (which is not a viable solution, of course).
I tried to mostly use the GUI object fonts that aren't affected by this in the "up front" user areas of the patch but there's a few areas such as the symbol boxes where you can't get around this.
Absolutely. [symbolatom \ is the only text input I know of in Pd and I keep stumbling about the exact same problem. It'd help a lot already if there is a symbolbox2 with configurable font similar to the 'Number2' widget.
It completely messes up the neatly spaced background "guts" that I set up to make it easier to read for anyone who wanted to make mods. Lots of compact tightly aligned spacing going on. As I said it's very large (been working on it for years) and reformatting just to correct for this error doesn't seem worth it especially if I have to switch it all back when (if?) the problem is corrected in Pd.
I, too, think it is probably not worth to fix this in your patches _now_. Currently, the situation is still a bit messy. As of Pd 0.48, patches are rendered the same on macOS and on Linux, but on both platforms, patches looked different in earlier versions, so patches you made for 0.47 are messed up now. Pd on Windows looks again very different. The different available font sizes result in totally different box sizes on Windows compared to macOS and Linux. Also, box sizes depend on whether the font DejaVu Sans Mono is installed or not. On macOS and Linux, this is already the default font and is shipped with Pd, on Windows this is planned.
It is slightly frustrating not to be able to rely on some graphical features in a graphical programming language.
Roman
On Tue, 12 Sep 2017 14:03:24 +0000, Lucas Cordiviolalucarda27@hotmail.com lucarda27@hotmail.com wrote:
The OP is trying to use font 9.
He will get font 8 if he edit the the Pd-patch as a text file.
Mensaje telepatico asistido por maquinas.
On 9/12/2017 10:10 AM, IOhannes m zmoelnig wrote:
On 2017-09-12 14:55, Lucas Cordiviola wrote:
Or alternatively (but much less desirability) a variable to edit within the text file
Nop.
of course you can (if by "text file" you mean the Pd-patch):
PTS=12 PATCH=patch.pd sed -e "s/^\(#N canvas [0-9 ]*\) [0-9]*;$/\1 ${PTS};/" -i "${PATCH}"gbsmdr IOhannes
_______________________________________________Pd-list@lists.iem.atmailto:Pd-list@lists.iem.at Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/l istinfo/pd-list
_______________________________________________Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/l istinfo/pd-list
_______________________________________________Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/lis tinfo/pd-list
_______________________________________________Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list
end of life?
On Sep 15, 2017 01:54, "Alexandre Torres Porres" porres@gmail.com wrote:
what is "EOLs"?
2017-09-13 11:20 GMT-03:00 Lucas Cordiviola lucarda27@hotmail.com:
Hi Alexander
As Roman mentioned the "pd-gui.tcl" and you surely made your patches with Pdx, can you test tweaking the .tcl?
To check if your patches render correctly?
here's the How-to:
https://github.com/pure-data/pure-data/wiki/Crossplatform-fo nt-metrics-%26-comparisons
Plans for this were mentioned by Dan a month ago:
https://lists.puredata.info/pipermail/pd-list/2017-08/119967.html
Independently of the "nuts and bolts" of the relevant code that's different from Pdx my tests gave good results. In other words simply changing the hard coded metrics makes patches render like Pdx (specially EOLs).
Can you test and give feedback?
Mensaje telepatico asistido por maquinas.
On 9/13/2017 4:28 AM, Roman Haefeli wrote:
Hey Alexander
I hear you and I am in the same boat.
On Die, 2017-09-12 at 21:50 -0400, Alexander Connor wrote:
Thank you for these answers.
Editing the Pd text file wasn't really much of a solution for me since I'm dealing with a very large patch with many subpatches which would all have to be changed; I was really looking for a way to scale everything at once and back again should the need arise.
I guess the reason it is not a solution is because the available font sizes don't match what you want. Otherwise I believe it would be worth going through all of your patches. You can automate something like this. IOhannes just gave you the first hint.
However it would appear that there is basically no solution to this problem until font rendering is fixed.
Unfortunately, I think so, too.
Guess I'll have to stick with my EOLs for now. Too bad. I really wanted to start distributing this patch.
I see. There is something nobody mentioned yet: You could also tweak the font metrics in pd-gui.tcl. Obviously, this only fixes the situation for your Pd installation, it wouldn't help if your goal is to distribute your graphically sophisticated patches. I'm in the same situation as you and I currently deal with it by fixing the font- metrics for myself (which is not a viable solution, of course).
I tried to mostly use the GUI object fonts that aren't affected by this in the "up front" user areas of the patch but there's a few areas such as the symbol boxes where you can't get around this.
Absolutely. [symbolatom \ is the only text input I know of in Pd and I keep stumbling about the exact same problem. It'd help a lot already if there is a symbolbox2 with configurable font similar to the 'Number2' widget.
It completely messes up the neatly spaced background "guts" that I set up to make it easier to read for anyone who wanted to make mods. Lots of compact tightly aligned spacing going on. As I said it's very large (been working on it for years) and reformatting just to correct for this error doesn't seem worth it especially if I have to switch it all back when (if?) the problem is corrected in Pd.
I, too, think it is probably not worth to fix this in your patches _now_. Currently, the situation is still a bit messy. As of Pd 0.48, patches are rendered the same on macOS and on Linux, but on both platforms, patches looked different in earlier versions, so patches you made for 0.47 are messed up now. Pd on Windows looks again very different. The different available font sizes result in totally different box sizes on Windows compared to macOS and Linux. Also, box sizes depend on whether the font DejaVu Sans Mono is installed or not. On macOS and Linux, this is already the default font and is shipped with Pd, on Windows this is planned.
It is slightly frustrating not to be able to rely on some graphical features in a graphical programming language.
Roman
On Tue, 12 Sep 2017 14:03:24 +0000, Lucas Cordiviolalucarda27@hotmail.com lucarda27@hotmail.com wrote:
The OP is trying to use font 9.
He will get font 8 if he edit the the Pd-patch as a text file.
Mensaje telepatico asistido por maquinas.
On 9/12/2017 10:10 AM, IOhannes m zmoelnig wrote:
On 2017-09-12 14:55, Lucas Cordiviola wrote:
Or alternatively (but much less desirability) a variable to edit within the text file
Nop.
of course you can (if by "text file" you mean the Pd-patch):
PTS=12 PATCH=patch.pd sed -e "s/^\(#N canvas [0-9 ]*\) [0-9]*;$/\1 ${PTS};/" -i "${PATCH}"gbsmdr IOhannes
_______________________________________________Pd-list@lists.iem.atmailto:Pd-list@lists.iem.at Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/l istinfo/pd-list
_______________________________________________Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/l istinfo/pd-list
_______________________________________________Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/lis tinfo/pd-list
_______________________________________________Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/li stinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list
Correct.
This problem has only reared it's head in the more recent Debian-based distributions. Correct me if I'm wrong but I thought it had to do with the newer rendering engines as they migrate to ever higher resolution. A rounding error due to the limited resolution accuracy of the old Pd GUI was it? Or something else?
BTW I'll try to do some more extensive comparison testing when I have time, but the patches are super tight and it would be fairly obvious if it wasn't exactly on point.
On Fri, 15 Sep 2017 08:07:25 +0200, Simon Iten itensimon@gmail.com wrote:
end of life?
On Sep 15, 2017 01:54, "Alexandre Torres Porres" porres@gmail.com wrote:
what is "EOLs"?
2017-09-13 11:20 GMT-03:00 Lucas Cordiviola lucarda27@hotmail.com:
Hi Alexander
As Roman mentioned the "pd-gui.tcl" and you surely made your patches with Pdx, can you test tweaking the .tcl?
To check if your patches render correctly?
here's the How-to:
https://github.com/pure-data/pure-data/wiki/Crossplatform-fo nt-metrics-%26-comparisons
Plans for this were mentioned by Dan a month ago:
https://lists.puredata.info/pipermail/pd-list/2017-08/119967.html
Independently of the "nuts and bolts" of the relevant code that's different from Pdx my tests gave good results. In other words simply changing the hard coded metrics makes patches render like Pdx (specially EOLs).
Can you test and give feedback?
Mensaje telepatico asistido por maquinas.
On 9/13/2017 4:28 AM, Roman Haefeli wrote:
Hey Alexander
I hear you and I am in the same boat.
On Die, 2017-09-12 at 21:50 -0400, Alexander Connor wrote:
Thank you for these answers.
Editing the Pd text file wasn't really much of a solution for me since I'm dealing with a very large patch with many subpatches which would all have to be changed; I was really looking for a way to scale everything at once and back again should the need arise.
I guess the reason it is not a solution is because the available font sizes don't match what you want. Otherwise I believe it would be worth going through all of your patches. You can automate something like this. IOhannes just gave you the first hint.
However it would appear that there is basically no solution to this problem until font rendering is fixed.
Unfortunately, I think so, too.
Guess I'll have to stick with my EOLs for now. Too bad. I really wanted to start distributing this patch.
I see. There is something nobody mentioned yet: You could also tweak the font metrics in pd-gui.tcl. Obviously, this only fixes the situation for your Pd installation, it wouldn't help if your goal is to distribute your graphically sophisticated patches. I'm in the same situation as you and I currently deal with it by fixing the font- metrics for myself (which is not a viable solution, of course).
I tried to mostly use the GUI object fonts that aren't affected by this in the "up front" user areas of the patch but there's a few areas such as the symbol boxes where you can't get around this.
Absolutely. [symbolatom \ is the only text input I know of in Pd and I keep stumbling about the exact same problem. It'd help a lot already if there is a symbolbox2 with configurable font similar to the 'Number2' widget.
It completely messes up the neatly spaced background "guts" that I set up to make it easier to read for anyone who wanted to make mods. Lots of compact tightly aligned spacing going on. As I said it's very large (been working on it for years) and reformatting just to correct for this error doesn't seem worth it especially if I have to switch it all back when (if?) the problem is corrected in Pd.
I, too, think it is probably not worth to fix this in your patches _now_. Currently, the situation is still a bit messy. As of Pd 0.48, patches are rendered the same on macOS and on Linux, but on both platforms, patches looked different in earlier versions, so patches you made for 0.47 are messed up now. Pd on Windows looks again very different. The different available font sizes result in totally different box sizes on Windows compared to macOS and Linux. Also, box sizes depend on whether the font DejaVu Sans Mono is installed or not. On macOS and Linux, this is already the default font and is shipped with Pd, on Windows this is planned.
It is slightly frustrating not to be able to rely on some graphical features in a graphical programming language.
Roman
On Tue, 12 Sep 2017 14:03:24 +0000, Lucas Cordiviolalucarda27@hotmail.com lucarda27@hotmail.com wrote:
The OP is trying to use font 9.
He will get font 8 if he edit the the Pd-patch as a text file.
Mensaje telepatico asistido por maquinas.
On 9/12/2017 10:10 AM, IOhannes m zmoelnig wrote:
On 2017-09-12 14:55, Lucas Cordiviola wrote:
Or alternatively (but much less desirability) a variable to edit within the text file
Nop.
of course you can (if by "text file" you mean the Pd-patch):
PTS=12 PATCH=patch.pd sed -e "s/^\(#N canvas [0-9 ]*\) [0-9]*;$/\1 ${PTS};/" -i "${PATCH}"gbsmdr IOhannes
_______________________________________________Pd-list@lists.iem.atmailto:Pd-list@lists.iem.at Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/l istinfo/pd-list
_______________________________________________Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/l istinfo/pd-list
_______________________________________________Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/lis tinfo/pd-list
_______________________________________________Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/li stinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
In this thread I've used "EOL" for "End of line", mostly related to where "Comments" ends. (without overlapping with things on the right).
:-)
Mensaje telepatico asistido por maquinas.
On 9/15/2017 8:27 AM, Alexander Connor wrote:
Correct.
This problem has only reared it's head in the more recent Debian-based distributions. Correct me if I'm wrong but I thought it had to do with the newer rendering engines as they migrate to ever higher resolution. A rounding error due to the limited resolution accuracy of the old Pd GUI was it? Or something else?
BTW I'll try to do some more extensive comparison testing when I have time, but the patches are super tight and it would be fairly obvious if it wasn't exactly on point.
On Fri, 15 Sep 2017 08:07:25 +0200, Simon Iten itensimon@gmail.commailto:itensimon@gmail.com wrote:
end of life?
On Sep 15, 2017 01:54, "Alexandre Torres Porres" porres@gmail.commailto:porres@gmail.com wrote:
what is "EOLs"?
2017-09-13 11:20 GMT-03:00 Lucas Cordiviola lucarda27@hotmail.commailto:lucarda27@hotmail.com:
Hi Alexander
As Roman mentioned the "pd-gui.tcl" and you surely made your patches with Pdx, can you test tweaking the .tcl?
To check if your patches render correctly?
here's the How-to:
https://github.com/pure-data/pure-data/wiki/Crossplatform-fo nt-metrics-%26-comparisons
Plans for this were mentioned by Dan a month ago:
https://lists.puredata.info/pipermail/pd-list/2017-08/119967.html
Independently of the "nuts and bolts" of the relevant code that's different from Pdx my tests gave good results. In other words simply changing the hard coded metrics makes patches render like Pdx (specially EOLs).
Can you test and give feedback?
Mensaje telepatico asistido por maquinas.
On 9/13/2017 4:28 AM, Roman Haefeli wrote:
Hey Alexander
I hear you and I am in the same boat.
On Die, 2017-09-12 at 21:50 -0400, Alexander Connor wrote:
Thank you for these answers.
Editing the Pd text file wasn't really much of a solution for me since I'm dealing with a very large patch with many subpatches which would all have to be changed; I was really looking for a way to scale everything at once and back again should the need arise.
I guess the reason it is not a solution is because the available font sizes don't match what you want. Otherwise I believe it would be worth going through all of your patches. You can automate something like this. IOhannes just gave you the first hint.
However it would appear that there is basically no solution to this problem until font rendering is fixed.
Unfortunately, I think so, too.
Guess I'll have to stick with my EOLs for now. Too bad. I really wanted to start distributing this patch.
I see. There is something nobody mentioned yet: You could also tweak the font metrics in pd-gui.tcl. Obviously, this only fixes the situation for your Pd installation, it wouldn't help if your goal is to distribute your graphically sophisticated patches. I'm in the same situation as you and I currently deal with it by fixing the font- metrics for myself (which is not a viable solution, of course).
I tried to mostly use the GUI object fonts that aren't affected by this in the "up front" user areas of the patch but there's a few areas such as the symbol boxes where you can't get around this.
Absolutely. [symbolatom \ is the only text input I know of in Pd and I keep stumbling about the exact same problem. It'd help a lot already if there is a symbolbox2 with configurable font similar to the 'Number2' widget.
It completely messes up the neatly spaced background "guts" that I set up to make it easier to read for anyone who wanted to make mods. Lots of compact tightly aligned spacing going on. As I said it's very large (been working on it for years) and reformatting just to correct for this error doesn't seem worth it especially if I have to switch it all back when (if?) the problem is corrected in Pd.
I, too, think it is probably not worth to fix this in your patches _now_. Currently, the situation is still a bit messy. As of Pd 0.48, patches are rendered the same on macOS and on Linux, but on both platforms, patches looked different in earlier versions, so patches you made for 0.47 are messed up now. Pd on Windows looks again very different. The different available font sizes result in totally different box sizes on Windows compared to macOS and Linux. Also, box sizes depend on whether the font DejaVu Sans Mono is installed or not. On macOS and Linux, this is already the default font and is shipped with Pd, on Windows this is planned.
It is slightly frustrating not to be able to rely on some graphical features in a graphical programming language.
Roman
On Tue, 12 Sep 2017 14:03:24 +0000, Lucas Cordiviolalucarda27@hotmail.commailto:lucarda27@hotmail.com lucarda27@hotmail.commailto:lucarda27@hotmail.com wrote:
The OP is trying to use font 9.
He will get font 8 if he edit the the Pd-patch as a text file.
Mensaje telepatico asistido por maquinas.
On 9/12/2017 10:10 AM, IOhannes m zmoelnig wrote:
On 2017-09-12 14:55, Lucas Cordiviola wrote:
Or alternatively (but much less desirability) a variable to edit within the text file
Nop.
of course you can (if by "text file" you mean the Pd-patch):
PTS=12
PATCH=patch.pd
sed -e "s/^\(#N canvas [0-9 ]*\) [0-9]*;$/\1 ${PTS};/" -i
"${PATCH}"
gbsmdr IOhannes
_______________________________________________Pd-list@lists.iem.atmailto:Pd-list@lists.iem.atmailto:Pd-list@lists.iem.at Pd-list@lists.iem.atmailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/l istinfo/pd-list
_______________________________________________Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/l istinfo/pd-list
_______________________________________________Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/lis tinfo/pd-list
_______________________________________________Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.atmailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/li stinfo/pd-list
Pd-list@lists.iem.atmailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list
Pd-list@lists.iem.atmailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.atmailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Oh, is this ever used in real life or just another abbreviation you came up with like "Pdx" :)
2017-09-15 10:54 GMT-03:00 Lucas Cordiviola lucarda27@hotmail.com:
In this thread I've used "EOL" for "End of line", mostly related to where "Comments" ends. (without overlapping with things on the right).
:-)
Mensaje telepatico asistido por maquinas.
On 9/15/2017 8:27 AM, Alexander Connor wrote:
Correct.
This problem has only reared it's head in the more recent Debian-based distributions. Correct me if I'm wrong but I thought it had to do with the newer rendering engines as they migrate to ever higher resolution. A rounding error due to the limited resolution accuracy of the old Pd GUI was it? Or something else?
BTW I'll try to do some more extensive comparison testing when I have time, but the patches are super tight and it would be fairly obvious if it wasn't exactly on point.
On Fri, 15 Sep 2017 08:07:25 +0200, Simon Iten itensimon@gmail.com itensimon@gmail.com wrote:
end of life?
On Sep 15, 2017 01:54, "Alexandre Torres Porres" porres@gmail.com porres@gmail.com wrote:
what is "EOLs"?
2017-09-13 11:20 GMT-03:00 Lucas Cordiviola lucarda27@hotmail.com lucarda27@hotmail.com:
Hi Alexander
As Roman mentioned the "pd-gui.tcl" and you surely made your patches with Pdx, can you test tweaking the .tcl?
To check if your patches render correctly?
here's the How-to: https://github.com/pure-data/pure-data/wiki/Crossplatform-fo nt-metrics-%26-comparisons
Plans for this were mentioned by Dan a month ago: https://lists.puredata.info/pipermail/pd-list/2017-08/119967.html
Independently of the "nuts and bolts" of the relevant code that's different from Pdx my tests gave good results. In other words simply changing the hard coded metrics makes patches render like Pdx (specially EOLs).
Can you test and give feedback?
Mensaje telepatico asistido por maquinas.
On 9/13/2017 4:28 AM, Roman Haefeli wrote:
Hey Alexander
I hear you and I am in the same boat.
On Die, 2017-09-12 at 21:50 -0400, Alexander Connor wrote:
Thank you for these answers.
Editing the Pd text file wasn't really much of a solution for me since I'm dealing with a very large patch with many subpatches which would all have to be changed; I was really looking for a way to scale everything at once and back again should the need arise.
I guess the reason it is not a solution is because the available font sizes don't match what you want. Otherwise I believe it would be worth going through all of your patches. You can automate something like this. IOhannes just gave you the first hint.
However it would appear that there is basically no solution to this problem until font rendering is fixed.
Unfortunately, I think so, too.
Guess I'll have to stick with my EOLs for now. Too bad. I really wanted to start distributing this patch.
I see. There is something nobody mentioned yet: You could also tweak the font metrics in pd-gui.tcl. Obviously, this only fixes the situation for your Pd installation, it wouldn't help if your goal is to distribute your graphically sophisticated patches. I'm in the same situation as you and I currently deal with it by fixing the font- metrics for myself (which is not a viable solution, of course).
I tried to mostly use the GUI object fonts that aren't affected by this in the "up front" user areas of the patch but there's a few areas such as the symbol boxes where you can't get around this.
Absolutely. [symbolatom \ is the only text input I know of in Pd and I keep stumbling about the exact same problem. It'd help a lot already if there is a symbolbox2 with configurable font similar to the 'Number2' widget.
It completely messes up the neatly spaced background "guts" that I set up to make it easier to read for anyone who wanted to make mods. Lots of compact tightly aligned spacing going on. As I said it's very large (been working on it for years) and reformatting just to correct for this error doesn't seem worth it especially if I have to switch it all back when (if?) the problem is corrected in Pd.
I, too, think it is probably not worth to fix this in your patches _now_. Currently, the situation is still a bit messy. As of Pd 0.48, patches are rendered the same on macOS and on Linux, but on both platforms, patches looked different in earlier versions, so patches you made for 0.47 are messed up now. Pd on Windows looks again very different. The different available font sizes result in totally different box sizes on Windows compared to macOS and Linux. Also, box sizes depend on whether the font DejaVu Sans Mono is installed or not. On macOS and Linux, this is already the default font and is shipped with Pd, on Windows this is planned.
It is slightly frustrating not to be able to rely on some graphical features in a graphical programming language.
Roman
On Tue, 12 Sep 2017 14:03:24 +0000, Lucas Cordiviolalucarda27@hotmail.com lucarda27@hotmail.com lucarda27@hotmail.com lucarda27@hotmail.com wrote:
The OP is trying to use font 9.
He will get font 8 if he edit the the Pd-patch as a text file.
Mensaje telepatico asistido por maquinas.
On 9/12/2017 10:10 AM, IOhannes m zmoelnig wrote:
On 2017-09-12 14:55, Lucas Cordiviola wrote:
Or alternatively (but much less desirability) a variable to edit within the text file
Nop.
of course you can (if by "text file" you mean the Pd-patch):
PTS=12 PATCH=patch.pd sed -e "s/^\(#N canvas [0-9 ]*\) [0-9]*;$/\1 ${PTS};/" -i "${PATCH}"gbsmdr IOhannes
_______________________________________________Pd-list@lists.iem.atmailto:Pd-list@lists.iem.at Pd-list@lists.iem.at Pd-list@lists.iem.at Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/l istinfo/pd-list
_______________________________________________Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/l istinfo/pd-list
_______________________________________________Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/lis tinfo/pd-list
_______________________________________________Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
_______________________________________________Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/li stinfo/pd-list
_______________________________________________Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list
_______________________________________________Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
_______________________________________________Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Yeah it took me a minute to figure out what Pdx was. Thought it was some kind of a Pd font-testing app somebody had come up with at first...
On Fri, 15 Sep 2017 13:29:53 -0300, Alexandre Torres Porres porres@gmail.com wrote:
Oh, is this ever used in real life or just another abbreviation you came up with like "Pdx" :)
2017-09-15 10:54 GMT-03:00 Lucas Cordiviola lucarda27@hotmail.com:
In this thread I've used "EOL" for "End of line", mostly related to where "Comments" ends. (without overlapping with things on the right).
:-)
Mensaje telepatico asistido por maquinas.
On 9/15/2017 8:27 AM, Alexander Connor wrote:
Correct.
This problem has only reared it's head in the more recent Debian-based distributions. Correct me if I'm wrong but I thought it had to do with the newer rendering engines as they migrate to ever higher resolution. A rounding error due to the limited resolution accuracy of the old Pd GUI was it? Or something else?
BTW I'll try to do some more extensive comparison testing when I have time, but the patches are super tight and it would be fairly obvious if it wasn't exactly on point.
On Fri, 15 Sep 2017 08:07:25 +0200, Simon Iten itensimon@gmail.com itensimon@gmail.com wrote:
end of life?
On Sep 15, 2017 01:54, "Alexandre Torres Porres" porres@gmail.com porres@gmail.com wrote:
what is "EOLs"?
2017-09-13 11:20 GMT-03:00 Lucas Cordiviola lucarda27@hotmail.com lucarda27@hotmail.com:
Hi Alexander
As Roman mentioned the "pd-gui.tcl" and you surely made your patches with Pdx, can you test tweaking the .tcl?
To check if your patches render correctly?
here's the How-to: https://github.com/pure-data/pure-data/wiki/Crossplatform-fo nt-metrics-%26-comparisons
Plans for this were mentioned by Dan a month ago: https://lists.puredata.info/pipermail/pd-list/2017-08/119967.html
Independently of the "nuts and bolts" of the relevant code that's different from Pdx my tests gave good results. In other words simply changing the hard coded metrics makes patches render like Pdx (specially EOLs).
Can you test and give feedback?
Mensaje telepatico asistido por maquinas.
On 9/13/2017 4:28 AM, Roman Haefeli wrote:
Hey Alexander
I hear you and I am in the same boat.
On Die, 2017-09-12 at 21:50 -0400, Alexander Connor wrote:
Thank you for these answers.
Editing the Pd text file wasn't really much of a solution for me since I'm dealing with a very large patch with many subpatches which would all have to be changed; I was really looking for a way to scale everything at once and back again should the need arise.
I guess the reason it is not a solution is because the available font sizes don't match what you want. Otherwise I believe it would be worth going through all of your patches. You can automate something like this. IOhannes just gave you the first hint.
However it would appear that there is basically no solution to this problem until font rendering is fixed.
Unfortunately, I think so, too.
Guess I'll have to stick with my EOLs for now. Too bad. I really wanted to start distributing this patch.
I see. There is something nobody mentioned yet: You could also tweak the font metrics in pd-gui.tcl. Obviously, this only fixes the situation for your Pd installation, it wouldn't help if your goal is to distribute your graphically sophisticated patches. I'm in the same situation as you and I currently deal with it by fixing the font- metrics for myself (which is not a viable solution, of course).
I tried to mostly use the GUI object fonts that aren't affected by this in the "up front" user areas of the patch but there's a few areas such as the symbol boxes where you can't get around this.
Absolutely. [symbolatom \ is the only text input I know of in Pd and I keep stumbling about the exact same problem. It'd help a lot already if there is a symbolbox2 with configurable font similar to the 'Number2' widget.
It completely messes up the neatly spaced background "guts" that I set up to make it easier to read for anyone who wanted to make mods. Lots of compact tightly aligned spacing going on. As I said it's very large (been working on it for years) and reformatting just to correct for this error doesn't seem worth it especially if I have to switch it all back when (if?) the problem is corrected in Pd.
I, too, think it is probably not worth to fix this in your patches _now_. Currently, the situation is still a bit messy. As of Pd 0.48, patches are rendered the same on macOS and on Linux, but on both platforms, patches looked different in earlier versions, so patches you made for 0.47 are messed up now. Pd on Windows looks again very different. The different available font sizes result in totally different box sizes on Windows compared to macOS and Linux. Also, box sizes depend on whether the font DejaVu Sans Mono is installed or not. On macOS and Linux, this is already the default font and is shipped with Pd, on Windows this is planned.
It is slightly frustrating not to be able to rely on some graphical features in a graphical programming language.
Roman
On Tue, 12 Sep 2017 14:03:24 +0000, Lucas Cordiviolalucarda27@hotmail.com lucarda27@hotmail.com lucarda27@hotmail.com lucarda27@hotmail.com wrote:
The OP is trying to use font 9.
He will get font 8 if he edit the the Pd-patch as a text file.
Mensaje telepatico asistido por maquinas.
On 9/12/2017 10:10 AM, IOhannes m zmoelnig wrote:
On 2017-09-12 14:55, Lucas Cordiviola wrote:
Or alternatively (but much less desirability) a variable to edit within the text file
Nop.
of course you can (if by "text file" you mean the Pd-patch):
PTS=12 PATCH=patch.pd sed -e "s/^\(#N canvas [0-9 ]*\) [0-9]*;$/\1 ${PTS};/" -i "${PATCH}"gbsmdr IOhannes
_______________________________________________Pd-list@lists.iem.atmailto:Pd-list@lists.iem.at Pd-list@lists.iem.at Pd-list@lists.iem.at Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/l istinfo/pd-list
_______________________________________________Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/l istinfo/pd-list
_______________________________________________Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/lis tinfo/pd-list
_______________________________________________Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
_______________________________________________Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/li stinfo/pd-list
_______________________________________________Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list
_______________________________________________Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
_______________________________________________Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
"Pdx" is an abb. I've read on this list.
"EOL" is from another context:
[eol.jpg]
:-)
Mensaje telepatico asistido por maquinas.
On 9/15/2017 1:46 PM, Alexander Connor wrote:
Yeah it took me a minute to figure out what Pdx was. Thought it was some kind of a Pd font-testing app somebody had come up with at first...
On Fri, 15 Sep 2017 13:29:53 -0300, Alexandre Torres Porres porres@gmail.commailto:porres@gmail.com wrote:
Oh, is this ever used in real life or just another abbreviation you came up with like "Pdx" :)
What about making a glossary somewhere in puredata.info, so there's a list of all abbreviations used in the list.
fdch.github.io/tv
On Sep 15, 2017, at 1:10 PM, Lucas Cordiviola lucarda27@hotmail.com wrote:
"Pdx" is an abb. I've read on this list.
"EOL" is from another context:
<eol.jpg>
:-) Mensaje telepatico asistido por maquinas.
On 9/15/2017 1:46 PM, Alexander Connor wrote: Yeah it took me a minute to figure out what Pdx was. Thought it was some kind of a Pd font-testing app somebody had come up with at first...
On Fri, 15 Sep 2017 13:29:53 -0300, Alexandre Torres Porres porres@gmail.com wrote:
Oh, is this ever used in real life or just another abbreviation you came up with like "Pdx" :)
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Well, someone came up with that pdx deal, doesnt seem to be any official thing that should be promoted as such ;) - I get people now have phones and dont like typing, but I'm an old conservative person :(
2017-09-15 16:24 GMT-03:00 Fede Camara Halac camarafede@gmail.com:
What about making a glossary somewhere in puredata.info, so there's a list of all abbreviations used in the list.
fdch.github.io/tv
On Sep 15, 2017, at 1:10 PM, Lucas Cordiviola lucarda27@hotmail.com wrote:
"Pdx" is an abb. I've read on this list.
"EOL" is from another context: <eol.jpg>
:-)
Mensaje telepatico asistido por maquinas.
On 9/15/2017 1:46 PM, Alexander Connor wrote:
Yeah it took me a minute to figure out what Pdx was. Thought it was some kind of a Pd font-testing app somebody had come up with at first...
On Fri, 15 Sep 2017 13:29:53 -0300, Alexandre Torres Porres porres@gmail.com porres@gmail.com wrote:
Oh, is this ever used in real life or just another abbreviation you came up with like "Pdx" :)
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list
-
Alexander Connor -
Alexandre Torres Porres -
Fede Camara Halac -
IOhannes m zmoelnig -
Lucas Cordiviola -
Roman Haefeli -
Simon Iten