Hi all
I've been struggling with the font sizes changing from one release to another, as it throws off the sizing of atoms. I often use tightly fitted GOP's around a symbol or float atom, but everything made on 0.47 fails in 0.48 because the atom is slightly taller there.
I know that this has been discussed at length before, and I do not wish to re-open the issue for debate. Instead, I'm wondering if we could have an object that reports the dimensions of the atom in your system. So for instance, [bang(---[atomsize] would give you "8 15" if you were on 0.47 (8*15 pixels being the dimensions of a width-1 atom in 0.47 on Ubuntu) and "7 18" if you're on 0.48, etc. This would at least give you the information you need to dynamically resize GOPs to fit the system. It's not a perfect solution, but it would make things considerably more stable than they are now.
Alex Porres is willing to include such an object in his Else library if it's feasible, but unfortunately neither of us are familiar enough with the source code to know how to go about it. Can anybody help? To someone as naive as myself, it would seem like a pretty easy task. The dimensions must be defined somewhere, so it's just a matter of knowing which variable to call, right?
Liam
2018-03-18 15:09 GMT-03:00 Liam Goodacre liamg_uw@hotmail.com:
it's just a matter of knowing which variable to call, right?
seems so, I guess we know that much :) but i don't get it, what do you need? Font size? That should be simple, and nice/useful cause you could work around you patches even if you change a patch's font size.
The problem is that when I move from one system to another, many of my abstractions fail to display correctly, because the atoms fall outside of the GOP area. (See the attached image: the GOP area was set in 0.47, but it won't display in 0.48). The Context library uses a lot of tightly fitted GOPs (for better or worse), and I'm looking for a solution so that I can guarantee that they will display correctly on all systems. Even if the PD font width is standardized, there is always the chance that somebody loads PD with the -font-weight bold flags, which would throw it off again.
An external object that reported the system standard dimensions would offer a solution, since you could then set the abstraction to resize itself according to the system.
I'm also open to other solutions, if anyone can think of them. ________________________________ From: Alexandre Torres Porres porres@gmail.com Sent: 20 March 2018 19:43 To: Liam Goodacre Cc: pd-list@mail.iem.at Subject: Re: [PD] reporting the dimensions of a symbol / float atom
2018-03-18 15:09 GMT-03:00 Liam Goodacre <liamg_uw@hotmail.commailto:liamg_uw@hotmail.com>: it's just a matter of knowing which variable to call, right?
seems so, I guess we know that much :) but i don't get it, what do you need? Font size? That should be simple, and nice/useful cause you could work around you patches even if you change a patch's font size.
On Mit, 2018-03-21 at 13:08 +0000, Liam Goodacre wrote:
The problem is that when I move from one system to another, many of my abstractions fail to display correctly, because the atoms fall outside of the GOP area. (See the attached image: the GOP area was set in 0.47, but it won't display in 0.48). The Context library uses a lot of tightly fitted GOPs (for better or worse), and I'm looking for a solution so that I can guarantee that they will display correctly on all systems. Even if the PD font width is standardized, there is always the chance that somebody loads PD with the -font- weight bold flags, which would throw it off again.
An external object that reported the system standard dimensions would offer a solution, since you could then set the abstraction to resize itself according to the system.
I'm also open to other solutions, if anyone can think of them.
I'm in the same boat. This is the single-most important culprit I experience with non-consistent font sizes. I think Dan did a great deal of work to harmonize font and box sizes across platforms.
My strategy has been to wait until things are corrected on the Pd side instead of trying to work-around those issues myself. So, I hope I can stick with this strategy, because working-around it is so much work. Personally, I'd rather have people agree on the notion that this should be addressed in Pd than people who establish their own ways to mitigate the problem.
So, if you ask me, please don't use any reporting of sizes ;-)
Is this still an issue with Pd 0.48-1? I thought not, but I might need to check again.
Roman
Thanks for the input, Roman. I followed the discussion bout font sizes, and I also appreciate the amount of work that people have put in to solving it. Are the font sizes in 0.48.1 considered to be stable? If so, maybe it's time for me to cash in and resize everything manually, but I am wary of doing this in case things change again... ________________________________ From: Pd-list pd-list-bounces@lists.iem.at on behalf of Roman Haefeli reduzent@gmail.com Sent: 21 March 2018 13:46 To: pd-list@lists.iem.at Subject: Re: [PD] reporting the dimensions of a symbol / float atom
On Mit, 2018-03-21 at 13:08 +0000, Liam Goodacre wrote:
The problem is that when I move from one system to another, many of my abstractions fail to display correctly, because the atoms fall outside of the GOP area. (See the attached image: the GOP area was set in 0.47, but it won't display in 0.48). The Context library uses a lot of tightly fitted GOPs (for better or worse), and I'm looking for a solution so that I can guarantee that they will display correctly on all systems. Even if the PD font width is standardized, there is always the chance that somebody loads PD with the -font- weight bold flags, which would throw it off again.
An external object that reported the system standard dimensions would offer a solution, since you could then set the abstraction to resize itself according to the system.
I'm also open to other solutions, if anyone can think of them.
I'm in the same boat. This is the single-most important culprit I experience with non-consistent font sizes. I think Dan did a great deal of work to harmonize font and box sizes across platforms.
My strategy has been to wait until things are corrected on the Pd side instead of trying to work-around those issues myself. So, I hope I can stick with this strategy, because working-around it is so much work. Personally, I'd rather have people agree on the notion that this should be addressed in Pd than people who establish their own ways to mitigate the problem.
So, if you ask me, please don't use any reporting of sizes ;-)
Is this still an issue with Pd 0.48-1? I thought not, but I might need to check again.
Roman
On Mit, 2018-03-21 at 13:08 +0000, Liam Goodacre wrote:
An external object that reported the system standard dimensions would offer a solution, since you could then set the abstraction to resize itself according to the system.
This reminds of my finding, that when using 'donecanvasdialog' to change the visual size of the GOP area, the abstraction is marked dirty which leads to more dialogs when closing the patch.
Is there a way to adjust the GOP size without marking the instance of the abstraction/patch dirty?
Roman
Is there a way to adjust the GOP size without marking the instance of the abstraction/patch dirty?
yes, add a "dirty 0" message to the GOP's namecanvas, like this:
put a [namecanvas YOURNAME] onto the patch's top level.
then send it a message like this:
[donecanvasdialog 1 -1 3 0 -1 1 1 100 100 10 10, dirty 0( | | [send YOURNAME]
best
oliver
On Mit, 2018-03-21 at 14:57 +0100, oliver wrote:
Is there a way to adjust the GOP size without marking the instance of the abstraction/patch dirty?
[..] send it a message like this:
[donecanvasdialog 1 -1 3 0 -1 1 1 100 100 10 10, dirty 0( | [send YOURNAME]
Cool. It's never too late to learn new things. Many thanks :-)
Roman
Another option is the "coords" message. In my mind, this is always preferable to "donecanvasdialog" because you don't need to dirty it, and because the syntax is slightly easier to remember. If you open the .pd file in a text editor, you'll find the "coords" term at the very bottom, and you can work it out from there. ________________________________ From: Pd-list pd-list-bounces@lists.iem.at on behalf of oliver oliver@klingt.org Sent: 21 March 2018 13:57 To: pd-list@mail.iem.at Subject: Re: [PD] changing GOP size dynamically without dirty flag
Is there a way to adjust the GOP size without marking the instance of the abstraction/patch dirty?
yes, add a "dirty 0" message to the GOP's namecanvas, like this:
put a [namecanvas YOURNAME] onto the patch's top level.
then send it a message like this:
[donecanvasdialog 1 -1 3 0 -1 1 1 100 100 10 10, dirty 0( | | [send YOURNAME]
best
oliver
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
-
Alexandre Torres Porres -
Liam Goodacre -
oliver -
Roman Haefeli