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@lists.iem.at wrote:
From: Liam Goodacre <liamg_uw@hotmail.com mailto:liamg_uw@hotmail.com> To: "pd-list@lists.iem.at mailto:pd-list@lists.iem.at" <pd-list@lists.iem.at mailto:pd-list@lists.iem.at> Subject: Re: [PD] reporting the dimensions of a symbol / float atom Message-ID: <VI1PR0102MB35843E5E52585015E68EC8F3FCAA0@VI1PR0102MB3584.eurprd01.prod.exchangelabs.com mailto:VI1PR0102MB35843E5E52585015E68EC8F3FCAA0@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 @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
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@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@lists.iem.atmailto:pd-list-request@lists.iem.at wrote:
From: Liam Goodacre <liamg_uw@hotmail.commailto:liamg_uw@hotmail.com> To: "pd-list@lists.iem.atmailto:pd-list@lists.iem.at" <pd-list@lists.iem.atmailto:pd-list@lists.iem.at> Subject: Re: [PD] reporting the dimensions of a symbol / float atom Message-ID: <VI1PR0102MB35843E5E52585015E68EC8F3FCAA0@VI1PR0102MB3584.eurprd01.prod.exchangelabs.commailto:VI1PR0102MB35843E5E52585015E68EC8F3FCAA0@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 @danomatikahttp://twitter.com/danomatika danomatika.comhttp://danomatika.com robotcowboy.comhttp://robotcowboy.com
On Mit, 2018-03-21 at 18:52 +0000, Liam Goodacre wrote:
It would certainly help me to have be able to query atom sizes.
I see your point and the benefit of such a feature. Independent of that, I'd like to be able to count on consistent box sizes across platforms and future Pd versions.
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.
Right. I was assuming those would be related, but my main concern is about box size, exactly because of fitting atoms into GOP areas.
Roman
just a thought here:
what about using [number2] instead of PD's native number atom in a GOP ?
i was recently in a situation where i worked with my own objects on a different platform (OSX) and the patches DID look a little different, but my GOPs (which only use [number2] were consistent.
i know that also [number2] size depends upon the selected font renderings, but i had the feeling it's a little more stable
best
oliver
Roman Haefeli wrote:
On Mit, 2018-03-21 at 18:52 +0000, Liam Goodacre wrote:
It would certainly help me to have be able to query atom sizes.
I see your point and the benefit of such a feature. Independent of that, I'd like to be able to count on consistent box sizes across platforms and future Pd versions.
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.
Right. I was assuming those would be related, but my main concern is about box size, exactly because of fitting atoms into GOP areas.
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Thanks for the suggestion. I have considered this, but I really don't like the little triangle in the corner, and the space it takes up. Besides, I'm equally concerned with the symbol atom, for which there is no alternative object. ________________________________ From: Pd-list pd-list-bounces@lists.iem.at on behalf of oliver oliver@klingt.org Sent: 22 March 2018 09:40 To: pd-list@mail.iem.at Subject: Re: [PD] reporting the dimensions of a symbol / float atom
just a thought here:
what about using [number2] instead of PD's native number atom in a GOP ?
i was recently in a situation where i worked with my own objects on a different platform (OSX) and the patches DID look a little different, but my GOPs (which only use [number2] were consistent.
i know that also [number2] size depends upon the selected font renderings, but i had the feeling it's a little more stable
best
oliver
Roman Haefeli wrote:
On Mit, 2018-03-21 at 18:52 +0000, Liam Goodacre wrote:
It would certainly help me to have be able to query atom sizes.
I see your point and the benefit of such a feature. Independent of that, I'd like to be able to count on consistent box sizes across platforms and future Pd versions.
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.
Right. I was assuming those would be related, but my main concern is about box size, exactly because of fitting atoms into GOP areas.
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
-- \\\\\\\\\\\\\\\\\\\\\\\\\\\\ /////////////// http://pendler.klingt.org ////////////// \\\\\\\\ http://oliver.klingt.org \\\\\\\ ////////////////////////////////////////////////////////
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Hello,
Everything is in the title (Pd 0.48.1, MacOSX) : during a workshop some people with this configuration trying to create a GUI object with keyboard shortcut, create two times this object. (I don't know exactly the version of MacOSX). Is it a known bug ? ++
Jack
-
Dan Wilcox -
Jack -
Liam Goodacre -
oliver -
Roman Haefeli