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=478070Can this be reopened or should I submit a new one?
Cheers Luke
<Picture 1.png>
kill your television
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=478070Can 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
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
I agree it would be excellent to have the font come out the same size on all platforms (and also that it agree at least approximately with the sizes of the old fonts used). But, as a fallback, when the font shows up at the wrong size, I think it's better to fall back to the old behavior of adjustin the boxes to the text.
cheers Miller
On Tue, Oct 23, 2007 at 10:27:21PM -0400, Hans-Christoph Steiner wrote:
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
I am fine with that as long as the box sizes for the default font
face and standard font sizes are the same to the pixel on all platforms.
.hc
On Oct 23, 2007, at 10:52 PM, Miller Puckette wrote:
I agree it would be excellent to have the font come out the same size on all platforms (and also that it agree at least approximately with the sizes of the old fonts used). But, as a fallback, when the font shows up at the wrong size, I think it's better to fall back to the old behavior of adjustin the boxes to the text.
cheers Miller
On Tue, Oct 23, 2007 at 10:27:21PM -0400, Hans-Christoph Steiner
wrote: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=478070Can 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
All mankind is of one author, and is one volume; when one man dies,
one chapter is not torn out of the book, but translated into a better
language; and every chapter must be so translated.... -John Donne
On Tue, 23 Oct 2007, Miller Puckette wrote:
I agree it would be excellent to have the font come out the same size on all platforms (and also that it agree at least approximately with the sizes of the old fonts used). But, as a fallback, when the font shows up at the wrong size, I think it's better to fall back to the old behavior of adjustin the boxes to the text.
I'm beginning to think that it would be better to have box sizes fit to the size of font that one would like to have, rather than the box size that one gets. This way, patchcords lie exactly where they were meant to go.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Oct 25, 2007, at 3:18 PM, Mathieu Bouchard wrote:
On Tue, 23 Oct 2007, Miller Puckette wrote:
I agree it would be excellent to have the font come out the same size on all platforms (and also that it agree at least approximately with the sizes of the old fonts used). But, as a fallback, when the font shows up at the wrong size, I think it's better to fall back to the old behavior of adjustin the boxes to the text.
I'm beginning to think that it would be better to have box sizes
fit to the size of font that one would like to have, rather than
the box size that one gets. This way, patchcords lie exactly where
they were meant to go.
Yes, if the font info was saved to the patch, and everything was
rendered the same on all platforms, that would definitely be the best
option. My key point is that consistent rendering is more important
than some flexibility in box sizes, IMHO.
.hc
Looking at things from a more basic level, you can come up with a
more direct solution... It may sound small in theory, but it in
practice, it can change entire economies. - Amy Smith
-
Hans-Christoph Steiner -
Mathieu Bouchard -
Miller Puckette