Here's my analysis of this:
We want to have patches be laid out the exact same on all platforms, pixel-by-pixel. This is necessary to have decent GUI layouts that work. Part of this is having the box sizes be the same. If you can get the code to use the automatic sizing, and produce boxes with the same exact size on all platforms, that's fine by me.
I personally think that having the sizes the exact same was worth installing the font, and dealing with making sure the fonts are working.
When a font doesn't work properly in an OS, like with Luke's problem, that's not a problem we should try to deal with in Pd. We should help people fix that problem on their OS.
It might be a better solution to have the box sizes fixed, then use the text measuring so that the cursor goes into the right place, no matter what the font situation is.
An even nicer solution would be to have the font face, font size, and box sizes saved in the patch. Then each OS could draw it the same. But then people with missing or broken fonts will still have troubles.
.hc
On Oct 23, 2007, at 8:25 PM, Miller Puckette wrote:
The following lines:
sys_fontlist[i].fi_hostfontsize = atom_getintarg(3 * best + 2, argc, argv); sys_fontlist[i].fi_width = atom_getintarg(3 * best + 3,argc, argv); sys_fontlist[i].fi_height = atom_getintarg(3 * best + 4, argc, argv);
are how Pd finds out the actual font size from teh Tk front end; in Pd extended the font patch comments these lines out, so Pd assumes the font size is exactly as specified. This leads to problems like clicking on one place and getting text selected in another. I never understood why the lines were commented out.
I'm not sure how wise it is to make a relase of Pd that depends on having a particular font installed... looks like this breaks a lot of machines.
cheers Miller
On Tue, Oct 23, 2007 at 08:01:16PM -0400, Hans-Christoph Steiner wrote:
Yup, you don't have Bitstream Vera Sans Mono working/installed. It has a distinctive lower L.
.hc
On Oct 23, 2007, at 7:15 PM, Luke Iannini (pd) wrote:
Here's a new pic demonstrating the issue, by the way (I'll add it to the tracker) The 1px wide canvas is demonstrating where I am clicking, and the actual cursor is visible to show the result.
On 10/23/07, Luke Iannini (pd) <lukexipd@gmail.com > wrote:
Sounds good to me! I think my biggest "blocker"-level issues with the extended 0.40.3 builds are the mismatched font-cursor handling in object-boxes with the new fonts, and the inability to use >~/ mtx_*~ and so on (though I believe IOhannes may have fixed that recently?).
What mismatched font cursor handling? If there's a bug, please report it on the tracker. :-)
I did, and apparently it was fixed : ). Anyway, the description is exactly the same: http://sourceforge.net/tracker /index.php? func=detail&aid=1650752&group_id=55736&atid=478070
Can this be reopened or should I submit a new one?
Cheers Luke
<Picture 1.png>
kill your television
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
------------------------------------------------------------------------ ----
"Free software means you control what your computer does. Non-free software means someone else controls that, and to some extent controls you." - Richard M. Stallman