Yes, it seems to have worked on this end. Looks normal now.
On Thu, 14 Sep 2017 13:21:53 +0000, Lucas Cordiviola lucarda27@hotmail.com wrote:
Cool.
It will take you 1 minute to test.
- close Pd
- backup 'pd-gui.tcl' (make a copy somewhere)
- edit 'pd-gui.tcl' (on 0.48.0 is on line 137) and save it.
- done.
Start Pd and open your patches. (make sure you are using the standard 'Dejavu sans mono' font, is useless with another font).
If possible compare your results with Pdx to see if EOLs are the same or at least quite the same (or far better than plain vanilla). Please give us your feedback & opinions on this. (don't reply only to me, include the list).
Salutti, Lucarda.
Mensaje telepatico asistido por maquinas.
On 9/14/2017 9:45 AM, Alexander Connor wrote:
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