[PD] reporting the dimensions of a symbol / float atom

Liam Goodacre liamg_uw at hotmail.com
Wed Mar 21 15:18:41 CET 2018


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 at lists.iem.at> on behalf of Roman Haefeli <reduzent at gmail.com>
Sent: 21 March 2018 13:46
To: pd-list at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20180321/e7943e68/attachment-0001.html>


More information about the Pd-list mailing list