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