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

Liam Goodacre liamg_uw at hotmail.com
Wed Mar 21 19:52:25 CET 2018

It would certainly help me to have be able to query atom sizes. Beyond the issue of tight GOP areas, in Context you can resize atoms dynamically (see the attached gif). The whole thing rests on knowing the basic dimensions of an atom. If there is a margin of error here, then the whole thing gets thrown off.

I'll grant that this is an unusual case, but it seems likely that many other users could benefit from a system which sizes GOPs and canvases according to font units. Roman, I don't see this getting in the way of any future solution--it's more just an optional feature which would enhance compatibility between older and newer versions of PD, many of which will remain in use for a long time.

BTW, we are talking about two different things here: font size and atom size. What is the relationship between them? In 0.48.1, the atom appears to have increased in height, suggesting that they are not always proportional.
From: Dan Wilcox <danomatika at gmail.com>
Sent: 21 March 2018 16:09
To: Liam Goodacre
Cc: Pd-List
Subject: Re: [PD] reporting the dimensions of a symbol / float atom

More less, except for Windows which is not using DejaVu Sans Mono yet, although we have a font loader for it now. This should be fixed in an upcoming version.

The sizing is taken from Pd-extended which largely had tested Tcl font rendering across all platforms. With the same font, the patches should render the same size most everywhere, as shown with our testing. I would still suggest not relying on *exact* pixel sizes and give yourself a little padding here and there to be safe.

In some ways, this was really not a fun problem as people moving from Pd-extended had broken sizing and people with tight GUIs like yourself have broken patches, but it should be *much* easier to resolve the sizing in the future. OTOH maybe it's worth talking about a different sizing algorithm and/or object size querying as setting a different font will of course change the sizing slightly base on what TK gives us. Maybe being able to query the size and width a character in the current font might help...

On Mar 21, 2018, at 3:18 PM, pd-list-request at lists.iem.at<mailto:pd-list-request at lists.iem.at> wrote:

From: Liam Goodacre <liamg_uw at hotmail.com<mailto:liamg_uw at hotmail.com>>
To: "pd-list at lists.iem.at<mailto:pd-list at lists.iem.at>" <pd-list at lists.iem.at<mailto:pd-list at lists.iem.at>>
Subject: Re: [PD] reporting the dimensions of a symbol / float atom
<VI1PR0102MB35843E5E52585015E68EC8F3FCAA0 at VI1PR0102MB3584.eurprd01.prod.exchangelabs.com<mailto:VI1PR0102MB35843E5E52585015E68EC8F3FCAA0 at VI1PR0102MB3584.eurprd01.prod.exchangelabs.com>>

Content-Type: text/plain; charset="utf-8"

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...

Dan Wilcox

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20180321/43318043/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vokoscreen-2018-03-21_22-07-11.gif
Type: image/gif
Size: 451611 bytes
Desc: vokoscreen-2018-03-21_22-07-11.gif
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20180321/43318043/attachment-0001.gif>

More information about the Pd-list mailing list