Hi,
attached screenshot shows a comparison of the font, I use with Pd on Debian Squeeze: FreeMono. I start Pd with "-font-face FreeMono", no size or weight options.
My patches usually use size 10 as default, this also is used on the screenshot. It seems that 0.43 scales the font to be one step too small. 0.42 has about the same size as the GVim I also show as comparison.
Is this expected behaviour or amy I doing something wrong?
I can fix the size difference by adding "-font-size 12" to the startup options or probably by some tcl hacking, but actually I was hoping, that the GUI reqrite would finally allow me to avoid using startup options for basic GUI configuration and behave more like normal software.
Ciao
Frank
btw I remember to ask myself why pd do not allow the user to choose his/her own fonts... why?
2010/8/20 Frank Barknecht fbar@footils.org:
Hi,
attached screenshot shows a comparison of the font, I use with Pd on Debian Squeeze: FreeMono. I start Pd with "-font-face FreeMono", no size or weight options.
My patches usually use size 10 as default, this also is used on the screenshot. It seems that 0.43 scales the font to be one step too small. 0.42 has about the same size as the GVim I also show as comparison.
Is this expected behaviour or amy I doing something wrong?
I can fix the size difference by adding "-font-size 12" to the startup options or probably by some tcl hacking, but actually I was hoping, that the GUI reqrite would finally allow me to avoid using startup options for basic GUI configuration and behave more like normal software.
Ciao
Frank
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I don't know how to do this in a way that's portable across platforms... this has been a huge unsolved problem for years :)
Miller
On Fri, Aug 20, 2010 at 01:58:30PM -0300, Bernardo Barros wrote:
btw I remember to ask myself why pd do not allow the user to choose his/her own fonts... why?
2010/8/20 Frank Barknecht fbar@footils.org:
Hi,
attached screenshot shows a comparison of the font, I use with Pd on Debian Squeeze: FreeMono. I start Pd with "-font-face FreeMono", no size or weight options.
My patches usually use size 10 as default, this also is used on the screenshot. It seems that 0.43 scales the font to be one step too small. 0.42 has about the same size as the GVim I also show as comparison.
Is this expected behaviour or amy I doing something wrong?
I can fix the size difference by adding "-font-size 12" to the startup options or probably by some tcl hacking, but actually I was hoping, that the GUI reqrite would finally allow me to avoid using startup options for basic GUI configuration and behave more like normal software.
Ciao
Frank
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Fri, Aug 20, 2010 at 10:17:27AM -0700, Miller Puckette wrote:
I don't know how to do this in a way that's portable across platforms... this has been a huge unsolved problem for years :)
Hehe, yeah, I'm used to tears. :)
Anyway in my quick test the GUI rewrite seems to have degraded a bit in this regard, as 0.42 showed the same font size that standard Gtk apps like Vim use.
But maybe some Gnome users can compare font sizes between Pd and Gtk- (or Qt) apps and some defaults for Linux can just be adapted?
Ciao
Frank
I would vote for this fixed-spaced (but not ugly) font: http://www.levien.com/type/myfonts/inconsolata.html
2010/8/20 Frank Barknecht fbar@footils.org:
On Fri, Aug 20, 2010 at 10:17:27AM -0700, Miller Puckette wrote:
I don't know how to do this in a way that's portable across platforms... this has been a huge unsolved problem for years :)
Hehe, yeah, I'm used to tears. :)
Anyway in my quick test the GUI rewrite seems to have degraded a bit in this regard, as 0.42 showed the same font size that standard Gtk apps like Vim use.
But maybe some Gnome users can compare font sizes between Pd and Gtk- (or Qt) apps and some defaults for Linux can just be adapted?
Ciao
Frank
The font point sizes do not match up to other apps, so a 12pt font in
Pd is not the same size as a 12pt font in a GNOME app. That is
because the Pd box sizes are hard coded in pixel sizes. That means
that you always get the same size box no matter what platform, or no
matter what font you have installed. In order to make this work, the
font for a given point size is the largest font that will fit into the
fixed box size.
In order for there to be proper font sizing and cross-platform layout,
things need to be architected quite a bit differently. I think the
best way would be to implement using Tk scaling, then allow the GUI to
handle mouse motion, clicks, etc. There are issues there too, its
unfortunately not simple. But basically, the communcation between pd
and pd-gui should be more about logical actions than positions.
Inconsolata is an awesome font, by far the best fixed-font I've seen
anywhere. That's why made Pd use it if it can find it. Otherwise it
settles on what Tcl/Tk decides to call "courier" (see Tk font docs).
set testfonts {"Inconsolata" "Courier New" "Liberation Mono"
"FreeMono"
"DejaVu Sans Mono" "Bitstream Vera Sans Mono"}
.hc
On Aug 20, 2010, at 1:30 PM, Bernardo Barros wrote:
I would vote for this fixed-spaced (but not ugly) font: http://www.levien.com/type/myfonts/inconsolata.html
2010/8/20 Frank Barknecht fbar@footils.org:
On Fri, Aug 20, 2010 at 10:17:27AM -0700, Miller Puckette wrote:
I don't know how to do this in a way that's portable across
platforms... this has been a huge unsolved problem for years :)Hehe, yeah, I'm used to tears. :)
Anyway in my quick test the GUI rewrite seems to have degraded a
bit in this regard, as 0.42 showed the same font size that standard Gtk apps like Vim use.But maybe some Gnome users can compare font sizes between Pd and Gtk- (or Qt) apps and some defaults for Linux can just be adapted?
Ciao
Frank
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
"[W]e have invented the technology to eliminate scarcity, but we are
deliberately throwing it away to benefit those who profit from
scarcity." -John Gilmore
On Fri, 20 Aug 2010, Hans-Christoph Steiner wrote:
Inconsolata is an awesome font, by far the best fixed-font I've seen anywhere. That's why made Pd use it if it can find it. Otherwise it settles on what Tcl/Tk decides to call "courier" (see Tk font docs). set testfonts {"Inconsolata" "Courier New" "Liberation Mono" "FreeMono"
"DejaVu Sans Mono" "Bitstream Vera Sans Mono"}
Why don't you just stick with DejaVu Sans Mono that we all got used to ?
Is the default size of Inconsolata exactly the same character size (6px by 13px) as the default size of DejaVu Sans Mono ?
Then the IEMGUI font size just doesn't follow in a cross-platform way. I had to add the use of my new abstraction [doc_iemfont] so that IEMGUI labels have sizes that match those of standard pd "size 10" text (size 10 according to .pd format and FONT BOMB).
Then I've been told that Pd (41 or 42 ?) for Windows has a default font and font size that make characters not 6 by 13. (I can't verify this now because my Windows partition committed suicide by... deleting its own dll files or something) ... so... ask Jonathan.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On Aug 21, 2010, at 1:50 PM, Mathieu Bouchard wrote:
On Fri, 20 Aug 2010, Hans-Christoph Steiner wrote:
Inconsolata is an awesome font, by far the best fixed-font I've
seen anywhere. That's why made Pd use it if it can find it.
Otherwise it settles on what Tcl/Tk decides to call "courier" (see
Tk font docs). set testfonts {"Inconsolata" "Courier New" "Liberation Mono"
"FreeMono"
"DejaVu Sans Mono" "Bitstream Vera Sans Mono"}Why don't you just stick with DejaVu Sans Mono that we all got used
to ?Is the default size of Inconsolata exactly the same character size
(6px by 13px) as the default size of DejaVu Sans Mono ?
Well, IMHO, Inconsolata is so nice that its worth the little hassles
there might be. But the box sizes don't change with different fonts,
even when you use proportionally spaced fonts. Therefore the layout
should be the same. Editing text might be slight different, i.e.
clicking in the same spot with different fonts could put the cursor
betweeen different characters.
Then the IEMGUI font size just doesn't follow in a cross-platform
way. I had to add the use of my new abstraction [doc_iemfont] so
that IEMGUI labels have sizes that match those of standard pd "size
10" text (size 10 according to .pd format and FONT BOMB).Then I've been told that Pd (41 or 42 ?) for Windows has a default
font and font size that make characters not 6 by 13. (I can't verify
this now because my Windows partition committed suicide by...
deleting its own dll files or something) ... so... ask Jonathan.
Yeah, the IEMGUI font size issues are still very present. I think the
best way forward is to write a new GUI lib, the IEMGUI code is really
hard to follow and/or modify. That's why I started the tkwidgets
library and I hope to pick it up again soon, and also that others will
contribute.
.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
On Sat, 21 Aug 2010, Hans-Christoph Steiner wrote:
Yeah, the IEMGUI font size issues are still very present. I think the best way forward is to write a new GUI lib, the IEMGUI code is really hard to follow and/or modify.
Come on. It only has with the use of the -%d in the sys_vgui calls, whereever the "fs" variable appears. We introduced that to fix a certain problem about sizes, but for some reason, it didn't produce the result we expected (the use of pixel sizes). It will be a small fix like this, by search-and-replace in a few files or so.
That's why I started the tkwidgets library and I hope to pick it up again soon, and also that others will contribute.
Your TkWidgets won't provide the same functionality, and I have no guarantee that it will be any easier to maintain. What will you do differently, so that it becomes easier to maintain ?
I ask because, currently, there's mostly only one structure of GUI widget used in externals other than mine, and it's largely a calque of IEMGUI's, in all cases something quite verbose (though at least it shares some code in g_all_guis.c in the case of IEMGUI). I introduced several new ways of writing GUI externals (the old gridflow way, the new gridflow way, and the desiredata way) but they have been so undiscussed that I wonder whether any new GUI classes would be any different in a good way. It really looks like whatever research I do on the topic of readability and modifiability of the GUI code has to be only for myself, as I don't seem to be getting any honest feedback on it.
what I currently see in /tkwidgets/ seems somewhat different from the usual case, but currently I can't get it to run, and then, it doesn't have a properties dialogue either, and then, it doesn't need to render anything as multiple canvasitems because it's for wrapping Tk Widgets instead of Tk Canvas Items, so, it's somewhat of a different deal anyway.
And it doesn't fix the problem with IEMGUIs, that people will continue to use for quite a while. One of the advantages of the IEMGUIs is that they are transparent (this is something I realised much after I made my rewrite of IEMGUI in early 2004, in which I made them opaque because back then I thought it was better that way).
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On Aug 22, 2010, at 12:34 PM, Mathieu Bouchard wrote:
On Sat, 21 Aug 2010, Hans-Christoph Steiner wrote:
Yeah, the IEMGUI font size issues are still very present. I think
the best way forward is to write a new GUI lib, the IEMGUI code is
really hard to follow and/or modify.Come on. It only has with the use of the -%d in the sys_vgui calls,
whereever the "fs" variable appears. We introduced that to fix a
certain problem about sizes, but for some reason, it didn't produce
the result we expected (the use of pixel sizes). It will be a small
fix like this, by search-and-replace in a few files or so.
Please fix it and submit a patch, that would be awesome!
That's why I started the tkwidgets library and I hope to pick it up
again soon, and also that others will contribute.Your TkWidgets won't provide the same functionality, and I have no
guarantee that it will be any easier to maintain. What will you do
differently, so that it becomes easier to maintain ?I ask because, currently, there's mostly only one structure of GUI
widget used in externals other than mine, and it's largely a calque
of IEMGUI's, in all cases something quite verbose (though at least
it shares some code in g_all_guis.c in the case of IEMGUI). I
introduced several new ways of writing GUI externals (the old
gridflow way, the new gridflow way, and the desiredata way) but they
have been so undiscussed that I wonder whether any new GUI classes
would be any different in a good way. It really looks like whatever
research I do on the topic of readability and modifiability of the
GUI code has to be only for myself, as I don't seem to be getting
any honest feedback on it.what I currently see in /tkwidgets/ seems somewhat different from
the usual case, but currently I can't get it to run, and then, it
doesn't have a properties dialogue either, and then, it doesn't need
to render anything as multiple canvasitems because it's for wrapping
Tk Widgets instead of Tk Canvas Items, so, it's somewhat of a
different deal anyway.And it doesn't fix the problem with IEMGUIs, that people will
continue to use for quite a while. One of the advantages of the
IEMGUIs is that they are transparent (this is something I realised
much after I made my rewrite of IEMGUI in early 2004, in which I
made them opaque because back then I thought it was better that way).
I haven't looked at tkwidgets in a while, so I don't know the state,
sadly.
.hc
I have the audacity to believe that peoples everywhere can have three
meals a day for their bodies, education and culture for their minds,
and dignity, equality and freedom for their spirits. - Martin
Luther King, Jr.
On Tue, 24 Aug 2010, Hans-Christoph Steiner wrote:
On Aug 22, 2010, at 12:34 PM, Mathieu Bouchard wrote:
On Sat, 21 Aug 2010, Hans-Christoph Steiner wrote:
Yeah, the IEMGUI font size issues are still very present. I think the best way forward is to write a new GUI lib, the IEMGUI code is really hard to follow and/or modify.
Come on. It only has with the use of the -%d in the sys_vgui calls, whereever the "fs" variable appears. We introduced that to fix a certain problem about sizes, but for some reason, it didn't produce the result we expected (the use of pixel sizes). It will be a small fix like this, by search-and-replace in a few files or so.
Please fix it and submit a patch, that would be awesome!
What I mean is that the part of changing the IEMGUI code is simple. What I don't know, is what needs to be done so that -%d gets replaced by something that is considered cross-platform in Tk.
The fudge factor I used is the same value as the [tk scaling] value I have on my computer, which is 1.332... ; but the font sizes I use are not big enough to make sure that it's the right constant to use.
| Mathieu Bouchard ------------------------------ Villeray, Montréal, QC
On Sep 5, 2010, at 5:16 PM, Mathieu Bouchard wrote:
On Tue, 24 Aug 2010, Hans-Christoph Steiner wrote:
On Aug 22, 2010, at 12:34 PM, Mathieu Bouchard wrote:
On Sat, 21 Aug 2010, Hans-Christoph Steiner wrote:
Yeah, the IEMGUI font size issues are still very present. I
think the best way forward is to write a new GUI lib, the IEMGUI
code is really hard to follow and/or modify.Come on. It only has with the use of the -%d in the sys_vgui
calls, whereever the "fs" variable appears. We introduced that to
fix a certain problem about sizes, but for some reason, it didn't
produce the result we expected (the use of pixel sizes). It will
be a small fix like this, by search-and-replace in a few files or
so.Please fix it and submit a patch, that would be awesome!
What I mean is that the part of changing the IEMGUI code is simple.
What I don't know, is what needs to be done so that -%d gets
replaced by something that is considered cross-platform in Tk.The fudge factor I used is the same value as the [tk scaling] value
I have on my computer, which is 1.332... ; but the font sizes I use
are not big enough to make sure that it's the right constant to use.
tk scaling is set to a fixed size in Pd 0.43, so it should work cross- platform. I suppose its really a matter of testing it.
.hc
Mistrust authority - promote decentralization. - the hacker ethic
On Sun, 5 Sep 2010, Hans-Christoph Steiner wrote:
tk scaling is set to a fixed size in Pd 0.43, so it should work cross-platform. I suppose its really a matter of testing it.
ah, I tried it and it seems to work. I mean this in particular.
What would be a good way to get the version number of pd, from an external that can run on Pd 41, 42 and 43 at once ?
Btw, in eval_tclentry, the posts seem to be missing the final "\n". Remember that "post" in the Tcl code needs an implicit newline, whereas in the C code, it's implied in post(), not implied in startpost().
I can't get my GUI objects to display at all, and they prevent patch windows from closing, and I get no error messages at all. How should I try debugging this ?
| Mathieu Bouchard ------------------------------ Villeray, Montréal, QC
On Sep 9, 2010, at 4:15 PM, Mathieu Bouchard wrote:
On Sun, 5 Sep 2010, Hans-Christoph Steiner wrote:
tk scaling is set to a fixed size in Pd 0.43, so it should work
cross-platform. I suppose its really a matter of testing it.ah, I tried it and it seems to work. I mean this in particular.
What would be a good way to get the version number of pd, from an
external that can run on Pd 41, 42 and 43 at once ?
0.43 declares Tcl variables for this, so you could test for them.
Check the top of pd/tcl/pd-gui.tcl.
Btw, in eval_tclentry, the posts seem to be missing the final "\n".
Remember that "post" in the Tcl code needs an implicit newline,
whereas in the C code, it's implied in post(), not implied in
startpost().I can't get my GUI objects to display at all, and they prevent patch
windows from closing, and I get no error messages at all. How should
I try debugging this ?
I don't understand, perhaps try "./pd -stderr -d 3"
.hc
"Making boring techno music is really easy with modern tools, but with
live coding, boring techno is much harder." - Chris McCormick
You can choose your own fonts, but only from command line flags, or by
editing the Tcl files.
.hc
On Aug 20, 2010, at 12:58 PM, Bernardo Barros wrote:
btw I remember to ask myself why pd do not allow the user to choose his/her own fonts... why?
2010/8/20 Frank Barknecht fbar@footils.org:
Hi,
attached screenshot shows a comparison of the font, I use with Pd on Debian Squeeze: FreeMono. I start Pd with "-font-face FreeMono", no
size or weight options.My patches usually use size 10 as default, this also is used on the screenshot. It seems that 0.43 scales the font to be one step too
small. 0.42 has about the same size as the GVim I also show as comparison.Is this expected behaviour or amy I doing something wrong?
I can fix the size difference by adding "-font-size 12" to the
startup options or probably by some tcl hacking, but actually I was hoping,
that the GUI reqrite would finally allow me to avoid using startup options for basic GUI configuration and behave more like normal software.Ciao
Frank
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Computer science is no more related to the computer than astronomy is
related to the telescope. -Edsger Dykstra
nice: pd -jack -font-face Inconsolata -font-size 12
2010/8/20 Hans-Christoph Steiner hans@at.or.at:
You can choose your own fonts, but only from command line flags, or by editing the Tcl files.
.hc
On Aug 20, 2010, at 12:58 PM, Bernardo Barros wrote:
btw I remember to ask myself why pd do not allow the user to choose his/her own fonts... why?
2010/8/20 Frank Barknecht fbar@footils.org:
Hi,
attached screenshot shows a comparison of the font, I use with Pd on Debian Squeeze: FreeMono. I start Pd with "-font-face FreeMono", no size or weight options.
My patches usually use size 10 as default, this also is used on the screenshot. It seems that 0.43 scales the font to be one step too small. 0.42 has about the same size as the GVim I also show as comparison.
Is this expected behaviour or amy I doing something wrong?
I can fix the size difference by adding "-font-size 12" to the startup options or probably by some tcl hacking, but actually I was hoping, that the GUI reqrite would finally allow me to avoid using startup options for basic GUI configuration and behave more like normal software.
Ciao
Frank
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra
Hi,
On Fri, Aug 20, 2010 at 03:14:57PM -0300, Bernardo Barros wrote:
nice: pd -jack -font-face Inconsolata -font-size 12
It seems that this will just make all your patches default to a font size of 12 (check with Edit->Font), it will not make your 10px font become bigger.
Ciao
Frank
well, it looks different here. If I check the menu option, the boxes are not placed so well.
I like the looks like this, Inconsolata 16 (that is our 12) and no *bold*: -font-face Inconsolata -font-size 16 -font-weight normal
2010/8/21 Frank Barknecht fbar@footils.org:
Hi,
On Fri, Aug 20, 2010 at 03:14:57PM -0300, Bernardo Barros wrote:
nice: pd -jack -font-face Inconsolata -font-size 12
It seems that this will just make all your patches default to a font size of 12 (check with Edit->Font), it will not make your 10px font become bigger.
Ciao
Frank
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Fri, 20 Aug 2010, Frank Barknecht wrote:
I can fix the size difference by adding "-font-size 12" to the startup options or probably by some tcl hacking, but actually I was hoping, that the GUI reqrite would finally allow me to avoid using startup options for basic GUI configuration and behave more like normal software.
BTW I've been using Pd-Extended's Linux/OSX default font size as the basis for all my patches for making my last 400 patches or so. I pretty much expect the standard font size of Pd to become 6 pixels wide and 13 pixels high. Any deviation from that is making it complicated to have patches that look good on any OS and any Pd branch.
You can measure the width of a font by looking at the width difference between [sel] and [pack]. You can measure the height of the font by looking at the height difference between a single-line box and a double-line box. Move one of the two boxes one pixel at a time and see how many 1px moves it take to go from being left-justified to being right-justified, and top-justified to bottom-justified.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
Hi,
On Sat, Aug 21, 2010 at 01:39:08PM -0400, Mathieu Bouchard wrote:
BTW I've been using Pd-Extended's Linux/OSX default font size as the basis for all my patches for making my last 400 patches or so.
I've used Pd vanilla for all my patches so far, with a "10" font-size, whatever that is in pixels. I know, that Pd-extended uses some different layout for several years now, which makes patches look wrong when you load them in Pd vanilla and the other way around. I have not much interest to discuss the differences between vanilla and Pd-x, as I am hoping the two to unify again with the gui-rewrite. So I'm willing to change my preferences to whatever will be the new vanilla, but I'd prefer to not do again that with every release or with every new Courier-like font that pops up on the Internets' Top 10 console font lists and is so much better than the previous ones.
Ciao
Frank
On Aug 23, 2010, at 7:01 AM, Frank Barknecht wrote:
Hi,
On Sat, Aug 21, 2010 at 01:39:08PM -0400, Mathieu Bouchard wrote:
BTW I've been using Pd-Extended's Linux/OSX default font size as the basis for all my patches for making my last 400 patches or so.
I've used Pd vanilla for all my patches so far, with a "10" font-size, whatever that is in pixels. I know, that Pd-extended uses some
different layout for several years now, which makes patches look wrong when you load them in Pd vanilla and the other way around. I have not much interest to discuss the differences between vanilla and Pd-x, as I am hoping the two to unify again with the gui-rewrite. So I'm willing to change my preferences to whatever will be the new vanilla, but I'd prefer to not do again that with every release or with every new Courier-like font that pops up on the Internets' Top 10 console font lists and is so much better than the previous ones.
Unless Miller changes it in the future, Pd 0.43 should have the same
boxes sizes that Pd-extended has had for a couple versions. That was
one of my goals with the GUI rewrite. Its a bug if that's not the case.
.hc
The arc of history bends towards justice. - Dr. Martin Luther
King, Jr.
Long as there's a way to fix a problem I'm having: in message boxes with many lines of text, you can easily click on one character and select one above it... it gets very confusing. (Fedora 13 out-of-box).
I'm guessing that in the current version the GUI simply tells Pd what size the font ought to have had instead of the genuine one. Pd could easily expand the box to the ought-to size (at least optionally for those wishing to make cross-platform patches) but should know about the text's actual size anyway. To be continued...
cheers Miller
On Tue, Aug 24, 2010 at 01:21:08AM -0400, Hans-Christoph Steiner wrote:
On Aug 23, 2010, at 7:01 AM, Frank Barknecht wrote:
Hi,
On Sat, Aug 21, 2010 at 01:39:08PM -0400, Mathieu Bouchard wrote:
BTW I've been using Pd-Extended's Linux/OSX default font size as the basis for all my patches for making my last 400 patches or so.
I've used Pd vanilla for all my patches so far, with a "10" font-size, whatever that is in pixels. I know, that Pd-extended uses some different layout for several years now, which makes patches look wrong when you load them in Pd vanilla and the other way around. I have not much interest to discuss the differences between vanilla and Pd-x, as I am hoping the two to unify again with the gui-rewrite. So I'm willing to change my preferences to whatever will be the new vanilla, but I'd prefer to not do again that with every release or with every new Courier-like font that pops up on the Internets' Top 10 console font lists and is so much better than the previous ones.
Unless Miller changes it in the future, Pd 0.43 should have the same boxes sizes that Pd-extended has had for a couple versions. That was one of my goals with the GUI rewrite. Its a bug if that's not the case.
.hc
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I think the real solution to this would be one step deeper. If Pd
used Tcl to handle the GUI interaction, then we could use the Tk
scaling feature, which is what Tk does to handle cross-platform
differences in font rendering. Pd could then store the Tk scaling
number in the patch, and use it to scale internal copies of pixel
values, when necessary. Then we could have the best of both worlds.
This would also give us the ability to zoom/scale patches for free.
This is not as hard as it might seem, I believe DesireData has this
working. I think this would also be quite clean and actually simplify
Pd's code rather than adding more complexity by tracking both when
fonts should fit to the box size and when the box size should fit to
the font.
I'll take a look at the big text block clicking issue now. Do you
have an example patch?
.hc
On Aug 24, 2010, at 4:38 PM, Miller Puckette wrote:
Long as there's a way to fix a problem I'm having: in message boxes
with many lines of text, you can easily click on one character and select
one above it... it gets very confusing. (Fedora 13 out-of-box).I'm guessing that in the current version the GUI simply tells Pd
what size the font ought to have had instead of the genuine one. Pd could
easily expand the box to the ought-to size (at least optionally for those
wishing to make cross-platform patches) but should know about the text's
actual size anyway. To be continued...cheers Miller
On Tue, Aug 24, 2010 at 01:21:08AM -0400, Hans-Christoph Steiner
wrote:On Aug 23, 2010, at 7:01 AM, Frank Barknecht wrote:
Hi,
On Sat, Aug 21, 2010 at 01:39:08PM -0400, Mathieu Bouchard wrote:
BTW I've been using Pd-Extended's Linux/OSX default font size as
the basis for all my patches for making my last 400 patches or so.I've used Pd vanilla for all my patches so far, with a "10" font- size, whatever that is in pixels. I know, that Pd-extended uses some different layout for several years now, which makes patches look wrong when
you load them in Pd vanilla and the other way around. I have not much interest to discuss the differences between vanilla and Pd-x, as I
am hoping the two to unify again with the gui-rewrite. So I'm willing
to change my preferences to whatever will be the new vanilla, but I'd prefer to not do again that with every release or with every new Courier-like font that pops up on the Internets' Top 10 console font lists and is so much better than the previous ones.Unless Miller changes it in the future, Pd 0.43 should have the same boxes sizes that Pd-extended has had for a couple versions. That was one of my goals with the GUI rewrite. Its a bug if that's not the case.
.hc
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
You can't steal a gift. Bird gave the world his music, and if you can
hear it, you can have it. - Dizzy Gillespie
Sure... here:
#N canvas 359 131 405 427 10; #X msg 98 55 ; line 1 ; line 2 ; line 3 ; line 4 ; line 5 ; line 6 ; line 7 ; line 8 ; line 9 ; line 10 ; line 11 ; line 12 ; line 13 ; line 14 ; line 15 ; line 16 ; line 17 ; line 18 ; line 19 ; line 20;
On my machine the text box is several (20?) pixels too tall and to select the bottom line of text you have to click way below it.
I don't see how the thing can be made truly cross-platform unless there's a way to get text to have a determined size (both vertical and horizontal) and that seems to be impossible to get to work cross-platform.
The only solution I can think of for getting boxes to have consistent sizes is to use Mathieu's suggestion and make the box have a standardized size, simply adding margin when the text font doesn't actually fill it. (There's have to be an outline drawn around comments when the patch is unlocked too.)
cheers Miller
On Wed, Aug 25, 2010 at 12:15:11PM -0400, Hans-Christoph Steiner wrote:
I think the real solution to this would be one step deeper. If Pd used Tcl to handle the GUI interaction, then we could use the Tk scaling feature, which is what Tk does to handle cross-platform differences in font rendering. Pd could then store the Tk scaling number in the patch, and use it to scale internal copies of pixel values, when necessary. Then we could have the best of both worlds. This would also give us the ability to zoom/scale patches for free.
This is not as hard as it might seem, I believe DesireData has this working. I think this would also be quite clean and actually simplify Pd's code rather than adding more complexity by tracking both when fonts should fit to the box size and when the box size should fit to the font.
I'll take a look at the big text block clicking issue now. Do you have an example patch?
.hc
On Aug 24, 2010, at 4:38 PM, Miller Puckette wrote:
Long as there's a way to fix a problem I'm having: in message boxes with many lines of text, you can easily click on one character and select one above it... it gets very confusing. (Fedora 13 out-of-box).
I'm guessing that in the current version the GUI simply tells Pd what size the font ought to have had instead of the genuine one. Pd could easily expand the box to the ought-to size (at least optionally for those wishing to make cross-platform patches) but should know about the text's actual size anyway. To be continued...
cheers Miller
On Tue, Aug 24, 2010 at 01:21:08AM -0400, Hans-Christoph Steiner wrote:
On Aug 23, 2010, at 7:01 AM, Frank Barknecht wrote:
Hi,
On Sat, Aug 21, 2010 at 01:39:08PM -0400, Mathieu Bouchard wrote:
BTW I've been using Pd-Extended's Linux/OSX default font size as the basis for all my patches for making my last 400 patches or so.
I've used Pd vanilla for all my patches so far, with a "10" font-size, whatever that is in pixels. I know, that Pd-extended uses some different layout for several years now, which makes patches look wrong when you load them in Pd vanilla and the other way around. I have not much interest to discuss the differences between vanilla and Pd-x, as I am hoping the two to unify again with the gui-rewrite. So I'm willing to change my preferences to whatever will be the new vanilla, but I'd prefer to not do again that with every release or with every new Courier-like font that pops up on the Internets' Top 10 console font lists and is so much better than the previous ones.
Unless Miller changes it in the future, Pd 0.43 should have the same boxes sizes that Pd-extended has had for a couple versions. That was one of my goals with the GUI rewrite. Its a bug if that's not the case.
.hc
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
You can't steal a gift. Bird gave the world his music, and if you can hear it, you can have it. - Dizzy Gillespie
Ok, testing now... as for having the boxes with a standardized size, that's been the case with Pd-extended 0.40 and is also the case with 0.43 as of now. I'm not sure if I understand your idea about the margin tho, but an outline in edit mode sounds like a good idea.
.hc
On Wed, 2010-08-25 at 11:09 -0700, Miller Puckette wrote:
Sure... here:
#N canvas 359 131 405 427 10; #X msg 98 55 ; line 1 ; line 2 ; line 3 ; line 4 ; line 5 ; line 6 ; line 7 ; line 8 ; line 9 ; line 10 ; line 11 ; line 12 ; line 13 ; line 14 ; line 15 ; line 16 ; line 17 ; line 18 ; line 19 ; line 20;
On my machine the text box is several (20?) pixels too tall and to select the bottom line of text you have to click way below it.
I don't see how the thing can be made truly cross-platform unless there's a way to get text to have a determined size (both vertical and horizontal) and that seems to be impossible to get to work cross-platform.
The only solution I can think of for getting boxes to have consistent sizes is to use Mathieu's suggestion and make the box have a standardized size, simply adding margin when the text font doesn't actually fill it. (There's have to be an outline drawn around comments when the patch is unlocked too.)
cheers Miller
On Wed, Aug 25, 2010 at 12:15:11PM -0400, Hans-Christoph Steiner wrote:
I think the real solution to this would be one step deeper. If Pd used Tcl to handle the GUI interaction, then we could use the Tk scaling feature, which is what Tk does to handle cross-platform differences in font rendering. Pd could then store the Tk scaling number in the patch, and use it to scale internal copies of pixel values, when necessary. Then we could have the best of both worlds. This would also give us the ability to zoom/scale patches for free.
This is not as hard as it might seem, I believe DesireData has this working. I think this would also be quite clean and actually simplify Pd's code rather than adding more complexity by tracking both when fonts should fit to the box size and when the box size should fit to the font.
I'll take a look at the big text block clicking issue now. Do you have an example patch?
.hc
On Aug 24, 2010, at 4:38 PM, Miller Puckette wrote:
Long as there's a way to fix a problem I'm having: in message boxes with many lines of text, you can easily click on one character and select one above it... it gets very confusing. (Fedora 13 out-of-box).
I'm guessing that in the current version the GUI simply tells Pd what size the font ought to have had instead of the genuine one. Pd could easily expand the box to the ought-to size (at least optionally for those wishing to make cross-platform patches) but should know about the text's actual size anyway. To be continued...
cheers Miller
On Tue, Aug 24, 2010 at 01:21:08AM -0400, Hans-Christoph Steiner wrote:
On Aug 23, 2010, at 7:01 AM, Frank Barknecht wrote:
Hi,
On Sat, Aug 21, 2010 at 01:39:08PM -0400, Mathieu Bouchard wrote:
BTW I've been using Pd-Extended's Linux/OSX default font size as the basis for all my patches for making my last 400 patches or so.
I've used Pd vanilla for all my patches so far, with a "10" font-size, whatever that is in pixels. I know, that Pd-extended uses some different layout for several years now, which makes patches look wrong when you load them in Pd vanilla and the other way around. I have not much interest to discuss the differences between vanilla and Pd-x, as I am hoping the two to unify again with the gui-rewrite. So I'm willing to change my preferences to whatever will be the new vanilla, but I'd prefer to not do again that with every release or with every new Courier-like font that pops up on the Internets' Top 10 console font lists and is so much better than the previous ones.
Unless Miller changes it in the future, Pd 0.43 should have the same boxes sizes that Pd-extended has had for a couple versions. That was one of my goals with the GUI rewrite. Its a bug if that's not the case.
.hc
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
You can't steal a gift. Bird gave the world his music, and if you can hear it, you can have it. - Dizzy Gillespie
By 'margin' I meant that 'the box is larger than the text inside it so there's a bunch of empty space inside it'... if you don't see that you won't have the problem I'm having :)
M
On Wed, Aug 25, 2010 at 02:45:12PM -0400, Hans-Christoph Steiner wrote:
Ok, testing now... as for having the boxes with a standardized size, that's been the case with Pd-extended 0.40 and is also the case with 0.43 as of now. I'm not sure if I understand your idea about the margin tho, but an outline in edit mode sounds like a good idea.
.hc
On Wed, 2010-08-25 at 11:09 -0700, Miller Puckette wrote:
Sure... here:
#N canvas 359 131 405 427 10; #X msg 98 55 ; line 1 ; line 2 ; line 3 ; line 4 ; line 5 ; line 6 ; line 7 ; line 8 ; line 9 ; line 10 ; line 11 ; line 12 ; line 13 ; line 14 ; line 15 ; line 16 ; line 17 ; line 18 ; line 19 ; line 20;
On my machine the text box is several (20?) pixels too tall and to select the bottom line of text you have to click way below it.
I don't see how the thing can be made truly cross-platform unless there's a way to get text to have a determined size (both vertical and horizontal) and that seems to be impossible to get to work cross-platform.
The only solution I can think of for getting boxes to have consistent sizes is to use Mathieu's suggestion and make the box have a standardized size, simply adding margin when the text font doesn't actually fill it. (There's have to be an outline drawn around comments when the patch is unlocked too.)
cheers Miller
On Wed, Aug 25, 2010 at 12:15:11PM -0400, Hans-Christoph Steiner wrote:
I think the real solution to this would be one step deeper. If Pd used Tcl to handle the GUI interaction, then we could use the Tk scaling feature, which is what Tk does to handle cross-platform differences in font rendering. Pd could then store the Tk scaling number in the patch, and use it to scale internal copies of pixel values, when necessary. Then we could have the best of both worlds. This would also give us the ability to zoom/scale patches for free.
This is not as hard as it might seem, I believe DesireData has this working. I think this would also be quite clean and actually simplify Pd's code rather than adding more complexity by tracking both when fonts should fit to the box size and when the box size should fit to the font.
I'll take a look at the big text block clicking issue now. Do you have an example patch?
.hc
On Aug 24, 2010, at 4:38 PM, Miller Puckette wrote:
Long as there's a way to fix a problem I'm having: in message boxes with many lines of text, you can easily click on one character and select one above it... it gets very confusing. (Fedora 13 out-of-box).
I'm guessing that in the current version the GUI simply tells Pd what size the font ought to have had instead of the genuine one. Pd could easily expand the box to the ought-to size (at least optionally for those wishing to make cross-platform patches) but should know about the text's actual size anyway. To be continued...
cheers Miller
On Tue, Aug 24, 2010 at 01:21:08AM -0400, Hans-Christoph Steiner wrote:
On Aug 23, 2010, at 7:01 AM, Frank Barknecht wrote:
Hi,
On Sat, Aug 21, 2010 at 01:39:08PM -0400, Mathieu Bouchard wrote: >BTW I've been using Pd-Extended's Linux/OSX default font >size as the >basis for all my patches for making my last 400 patches or so.
I've used Pd vanilla for all my patches so far, with a "10" font-size, whatever that is in pixels. I know, that Pd-extended uses some different layout for several years now, which makes patches look wrong when you load them in Pd vanilla and the other way around. I have not much interest to discuss the differences between vanilla and Pd-x, as I am hoping the two to unify again with the gui-rewrite. So I'm willing to change my preferences to whatever will be the new vanilla, but I'd prefer to not do again that with every release or with every new Courier-like font that pops up on the Internets' Top 10 console font lists and is so much better than the previous ones.
Unless Miller changes it in the future, Pd 0.43 should have the same boxes sizes that Pd-extended has had for a couple versions. That was one of my goals with the GUI rewrite. Its a bug if that's not the case.
.hc
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
You can't steal a gift. Bird gave the world his music, and if you can hear it, you can have it. - Dizzy Gillespie
I figured out the cause. The problem is caused by the font used being different than the font that fits into the standardized boxes. If you have the margin problem or the offset clicking problem then your Tcl/Tk is not used "DejaVu Sans Mono" or "Andale Mono", the two fonts I have found that fit into the standard box size.
Other fonts have different ratios of height to width, and when Pd uses a different font, it tries to size it larger to fit the DejaVu Sans Mono. Also Tcl/Tk 8.4 does a bad job of font handling on GNU/Linux/X11. 8.5 is better but different than 8.4.
The DejaVu fonts are the standard fonts for GNOME and are included in all major distros, so those seem the natural font to standardize on. Also, DejaVu Sans Mono looks pretty good.
To get an idea, run the attached script with your wish. It would be quite useful if people would post the results of that script here so we can see what fonts are commonly available.
.hc
On Wed, 2010-08-25 at 11:49 -0700, Miller Puckette wrote:
By 'margin' I meant that 'the box is larger than the text inside it so there's a bunch of empty space inside it'... if you don't see that you won't have the problem I'm having :)
M
On Wed, Aug 25, 2010 at 02:45:12PM -0400, Hans-Christoph Steiner wrote:
Ok, testing now... as for having the boxes with a standardized size, that's been the case with Pd-extended 0.40 and is also the case with 0.43 as of now. I'm not sure if I understand your idea about the margin tho, but an outline in edit mode sounds like a good idea.
.hc
On Wed, 2010-08-25 at 11:09 -0700, Miller Puckette wrote:
Sure... here:
#N canvas 359 131 405 427 10; #X msg 98 55 ; line 1 ; line 2 ; line 3 ; line 4 ; line 5 ; line 6 ; line 7 ; line 8 ; line 9 ; line 10 ; line 11 ; line 12 ; line 13 ; line 14 ; line 15 ; line 16 ; line 17 ; line 18 ; line 19 ; line 20;
On my machine the text box is several (20?) pixels too tall and to select the bottom line of text you have to click way below it.
I don't see how the thing can be made truly cross-platform unless there's a way to get text to have a determined size (both vertical and horizontal) and that seems to be impossible to get to work cross-platform.
The only solution I can think of for getting boxes to have consistent sizes is to use Mathieu's suggestion and make the box have a standardized size, simply adding margin when the text font doesn't actually fill it. (There's have to be an outline drawn around comments when the patch is unlocked too.)
cheers Miller
On Wed, Aug 25, 2010 at 12:15:11PM -0400, Hans-Christoph Steiner wrote:
I think the real solution to this would be one step deeper. If Pd used Tcl to handle the GUI interaction, then we could use the Tk scaling feature, which is what Tk does to handle cross-platform differences in font rendering. Pd could then store the Tk scaling number in the patch, and use it to scale internal copies of pixel values, when necessary. Then we could have the best of both worlds. This would also give us the ability to zoom/scale patches for free.
This is not as hard as it might seem, I believe DesireData has this working. I think this would also be quite clean and actually simplify Pd's code rather than adding more complexity by tracking both when fonts should fit to the box size and when the box size should fit to the font.
I'll take a look at the big text block clicking issue now. Do you have an example patch?
.hc
On Aug 24, 2010, at 4:38 PM, Miller Puckette wrote:
Long as there's a way to fix a problem I'm having: in message boxes with many lines of text, you can easily click on one character and select one above it... it gets very confusing. (Fedora 13 out-of-box).
I'm guessing that in the current version the GUI simply tells Pd what size the font ought to have had instead of the genuine one. Pd could easily expand the box to the ought-to size (at least optionally for those wishing to make cross-platform patches) but should know about the text's actual size anyway. To be continued...
cheers Miller
On Tue, Aug 24, 2010 at 01:21:08AM -0400, Hans-Christoph Steiner wrote:
On Aug 23, 2010, at 7:01 AM, Frank Barknecht wrote:
>Hi, > >On Sat, Aug 21, 2010 at 01:39:08PM -0400, Mathieu Bouchard wrote: >>BTW I've been using Pd-Extended's Linux/OSX default font >>size as the >>basis for all my patches for making my last 400 patches or so. > >I've used Pd vanilla for all my patches so far, with a "10" >font-size, >whatever that is in pixels. I know, that Pd-extended uses some >different >layout for several years now, which makes patches look wrong >when you >load them in Pd vanilla and the other way around. I have not much >interest to discuss the differences between vanilla and Pd-x, >as I am >hoping the two to unify again with the gui-rewrite. So I'm >willing to >change my preferences to whatever will be the new vanilla, but I'd >prefer to not do again that with every release or with every new >Courier-like font that pops up on the Internets' Top 10 console font >lists and is so much better than the previous ones.
Unless Miller changes it in the future, Pd 0.43 should have the same boxes sizes that Pd-extended has had for a couple versions. That was one of my goals with the GUI rewrite. Its a bug if that's not the case.
.hc
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
You can't steal a gift. Bird gave the world his music, and if you can hear it, you can have it. - Dizzy Gillespie
hello,
withubuntu 10.04
pd -noprefs -> the message box are higher than the text pd -noprefs -font-face "andale mono" solve the problem
so, andale mono is here, but not used...
here is the result of your script.
linespace ascent descent font name
13 11 2 msbm10 13 11 2 webdings 13 11 2 fixed 18 15 3 lucidatypewriter 19 14 5 courier 10 pitch 13 11 2 cmsy10 21 17 4 andale mono 14 11 3 clean 17 13 4 terminal 16 14 2 gothic 13 11 2 cmr10 13 11 2 wenquanyi zenhei 16 14 2 song ti 37 15 22 open look cursor 13 11 2 cmex10 16 14 2 mincho 13 11 2 msam10 18 14 4 courier 13 11 2 inconsolata 16 16 0 nil 13 11 2 cmmi10 16 14 2 fangsong ti 20 16 4 dotum 28 17 11 courier new 18 14 4 nimbus mono l 20 16 4 batang 13 11 2 wasy10
Cyrille
Le 25/08/2010 21:39, Hans-Christoph Steiner a écrit :
I figured out the cause. The problem is caused by the font used being different than the font that fits into the standardized boxes. If you have the margin problem or the offset clicking problem then your Tcl/Tk is not used "DejaVu Sans Mono" or "Andale Mono", the two fonts I have found that fit into the standard box size.
Other fonts have different ratios of height to width, and when Pd uses a different font, it tries to size it larger to fit the DejaVu Sans Mono. Also Tcl/Tk 8.4 does a bad job of font handling on GNU/Linux/X11. 8.5 is better but different than 8.4.
The DejaVu fonts are the standard fonts for GNOME and are included in all major distros, so those seem the natural font to standardize on. Also, DejaVu Sans Mono looks pretty good.
To get an idea, run the attached script with your wish. It would be quite useful if people would post the results of that script here so we can see what fonts are commonly available.
.hc
On Wed, 2010-08-25 at 11:49 -0700, Miller Puckette wrote:
By 'margin' I meant that 'the box is larger than the text inside it so there's a bunch of empty space inside it'... if you don't see that you won't have the problem I'm having :)
M
On Wed, Aug 25, 2010 at 02:45:12PM -0400, Hans-Christoph Steiner wrote:
Ok, testing now... as for having the boxes with a standardized size, that's been the case with Pd-extended 0.40 and is also the case with 0.43 as of now. I'm not sure if I understand your idea about the margin tho, but an outline in edit mode sounds like a good idea.
.hc
On Wed, 2010-08-25 at 11:09 -0700, Miller Puckette wrote:
Sure... here:
#N canvas 359 131 405 427 10; #X msg 98 55 ; line 1 ; line 2 ; line 3 ; line 4 ; line 5 ; line 6 ; line 7 ; line 8 ; line 9 ; line 10 ; line 11 ; line 12 ; line 13 ; line 14 ; line 15 ; line 16 ; line 17 ; line 18 ; line 19 ; line 20;
On my machine the text box is several (20?) pixels too tall and to select the bottom line of text you have to click way below it.
I don't see how the thing can be made truly cross-platform unless there's a way to get text to have a determined size (both vertical and horizontal) and that seems to be impossible to get to work cross-platform.
The only solution I can think of for getting boxes to have consistent sizes is to use Mathieu's suggestion and make the box have a standardized size, simply adding margin when the text font doesn't actually fill it. (There's have to be an outline drawn around comments when the patch is unlocked too.)
cheers Miller
On Wed, Aug 25, 2010 at 12:15:11PM -0400, Hans-Christoph Steiner wrote:
I think the real solution to this would be one step deeper. If Pd used Tcl to handle the GUI interaction, then we could use the Tk scaling feature, which is what Tk does to handle cross-platform differences in font rendering. Pd could then store the Tk scaling number in the patch, and use it to scale internal copies of pixel values, when necessary. Then we could have the best of both worlds. This would also give us the ability to zoom/scale patches for free.
This is not as hard as it might seem, I believe DesireData has this working. I think this would also be quite clean and actually simplify Pd's code rather than adding more complexity by tracking both when fonts should fit to the box size and when the box size should fit to the font.
I'll take a look at the big text block clicking issue now. Do you have an example patch?
.hc
On Aug 24, 2010, at 4:38 PM, Miller Puckette wrote:
Long as there's a way to fix a problem I'm having: in message boxes with many lines of text, you can easily click on one character and select one above it... it gets very confusing. (Fedora 13 out-of-box).
I'm guessing that in the current version the GUI simply tells Pd what size the font ought to have had instead of the genuine one. Pd could easily expand the box to the ought-to size (at least optionally for those wishing to make cross-platform patches) but should know about the text's actual size anyway. To be continued...
cheers Miller
On Tue, Aug 24, 2010 at 01:21:08AM -0400, Hans-Christoph Steiner wrote: > > On Aug 23, 2010, at 7:01 AM, Frank Barknecht wrote: > >> Hi, >> >> On Sat, Aug 21, 2010 at 01:39:08PM -0400, Mathieu Bouchard wrote: >>> BTW I've been using Pd-Extended's Linux/OSX default font >>> size as the >>> basis for all my patches for making my last 400 patches or so. >> >> I've used Pd vanilla for all my patches so far, with a "10" >> font-size, >> whatever that is in pixels. I know, that Pd-extended uses some >> different >> layout for several years now, which makes patches look wrong >> when you >> load them in Pd vanilla and the other way around. I have not much >> interest to discuss the differences between vanilla and Pd-x, >> as I am >> hoping the two to unify again with the gui-rewrite. So I'm >> willing to >> change my preferences to whatever will be the new vanilla, but I'd >> prefer to not do again that with every release or with every new >> Courier-like font that pops up on the Internets' Top 10 console font >> lists and is so much better than the previous ones. > > > Unless Miller changes it in the future, Pd 0.43 should have the same > boxes sizes that Pd-extended has had for a couple versions. That > was one of my goals with the GUI rewrite. Its a bug if that's not > the case. > > .hc > > > ---------------------------------------------------------------------------- > > The arc of history bends towards justice. - Dr. Martin Luther > King, Jr. > > > > _______________________________________________ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
You can't steal a gift. Bird gave the world his music, and if you can hear it, you can have it. - Dizzy Gillespie
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Which wish are you using?
$ wish % info patchlevel 8.5.8
.hc
On Wed, 2010-08-25 at 22:30 +0200, cyrille henry wrote:
hello,
withubuntu 10.04
pd -noprefs -> the message box are higher than the text pd -noprefs -font-face "andale mono" solve the problem
so, andale mono is here, but not used...
here is the result of your script.
linespace ascent descent font name
13 11 2 msbm10 13 11 2 webdings 13 11 2 fixed 18 15 3 lucidatypewriter 19 14 5 courier 10 pitch 13 11 2 cmsy10 21 17 4 andale mono 14 11 3 clean 17 13 4 terminal 16 14 2 gothic 13 11 2 cmr10 13 11 2 wenquanyi zenhei 16 14 2 song ti 37 15 22 open look cursor 13 11 2 cmex10 16 14 2 mincho 13 11 2 msam10 18 14 4 courier 13 11 2 inconsolata 16 16 0 nil 13 11 2 cmmi10 16 14 2 fangsong ti 20 16 4 dotum 28 17 11 courier new 18 14 4 nimbus mono l 20 16 4 batang 13 11 2 wasy10
Cyrille
Le 25/08/2010 21:39, Hans-Christoph Steiner a écrit :
I figured out the cause. The problem is caused by the font used being different than the font that fits into the standardized boxes. If you have the margin problem or the offset clicking problem then your Tcl/Tk is not used "DejaVu Sans Mono" or "Andale Mono", the two fonts I have found that fit into the standard box size.
Other fonts have different ratios of height to width, and when Pd uses a different font, it tries to size it larger to fit the DejaVu Sans Mono. Also Tcl/Tk 8.4 does a bad job of font handling on GNU/Linux/X11. 8.5 is better but different than 8.4.
The DejaVu fonts are the standard fonts for GNOME and are included in all major distros, so those seem the natural font to standardize on. Also, DejaVu Sans Mono looks pretty good.
To get an idea, run the attached script with your wish. It would be quite useful if people would post the results of that script here so we can see what fonts are commonly available.
.hc
On Wed, 2010-08-25 at 11:49 -0700, Miller Puckette wrote:
By 'margin' I meant that 'the box is larger than the text inside it so there's a bunch of empty space inside it'... if you don't see that you won't have the problem I'm having :)
M
On Wed, Aug 25, 2010 at 02:45:12PM -0400, Hans-Christoph Steiner wrote:
Ok, testing now... as for having the boxes with a standardized size, that's been the case with Pd-extended 0.40 and is also the case with 0.43 as of now. I'm not sure if I understand your idea about the margin tho, but an outline in edit mode sounds like a good idea.
.hc
On Wed, 2010-08-25 at 11:09 -0700, Miller Puckette wrote:
Sure... here:
#N canvas 359 131 405 427 10; #X msg 98 55 ; line 1 ; line 2 ; line 3 ; line 4 ; line 5 ; line 6 ; line 7 ; line 8 ; line 9 ; line 10 ; line 11 ; line 12 ; line 13 ; line 14 ; line 15 ; line 16 ; line 17 ; line 18 ; line 19 ; line 20;
On my machine the text box is several (20?) pixels too tall and to select the bottom line of text you have to click way below it.
I don't see how the thing can be made truly cross-platform unless there's a way to get text to have a determined size (both vertical and horizontal) and that seems to be impossible to get to work cross-platform.
The only solution I can think of for getting boxes to have consistent sizes is to use Mathieu's suggestion and make the box have a standardized size, simply adding margin when the text font doesn't actually fill it. (There's have to be an outline drawn around comments when the patch is unlocked too.)
cheers Miller
On Wed, Aug 25, 2010 at 12:15:11PM -0400, Hans-Christoph Steiner wrote:
I think the real solution to this would be one step deeper. If Pd used Tcl to handle the GUI interaction, then we could use the Tk scaling feature, which is what Tk does to handle cross-platform differences in font rendering. Pd could then store the Tk scaling number in the patch, and use it to scale internal copies of pixel values, when necessary. Then we could have the best of both worlds. This would also give us the ability to zoom/scale patches for free.
This is not as hard as it might seem, I believe DesireData has this working. I think this would also be quite clean and actually simplify Pd's code rather than adding more complexity by tracking both when fonts should fit to the box size and when the box size should fit to the font.
I'll take a look at the big text block clicking issue now. Do you have an example patch?
.hc
On Aug 24, 2010, at 4:38 PM, Miller Puckette wrote:
> Long as there's a way to fix a problem I'm having: in message > boxes with > many lines of text, you can easily click on one character and > select one above > it... it gets very confusing. (Fedora 13 out-of-box). > > I'm guessing that in the current version the GUI simply tells Pd > what size > the font ought to have had instead of the genuine one. Pd could > easily > expand the box to the ought-to size (at least optionally for those > wishing > to make cross-platform patches) but should know about the text's > actual size > anyway. To be continued... > > cheers > Miller > > On Tue, Aug 24, 2010 at 01:21:08AM -0400, Hans-Christoph Steiner > wrote: >> >> On Aug 23, 2010, at 7:01 AM, Frank Barknecht wrote: >> >>> Hi, >>> >>> On Sat, Aug 21, 2010 at 01:39:08PM -0400, Mathieu Bouchard wrote: >>>> BTW I've been using Pd-Extended's Linux/OSX default font >>>> size as the >>>> basis for all my patches for making my last 400 patches or so. >>> >>> I've used Pd vanilla for all my patches so far, with a "10" >>> font-size, >>> whatever that is in pixels. I know, that Pd-extended uses some >>> different >>> layout for several years now, which makes patches look wrong >>> when you >>> load them in Pd vanilla and the other way around. I have not much >>> interest to discuss the differences between vanilla and Pd-x, >>> as I am >>> hoping the two to unify again with the gui-rewrite. So I'm >>> willing to >>> change my preferences to whatever will be the new vanilla, but I'd >>> prefer to not do again that with every release or with every new >>> Courier-like font that pops up on the Internets' Top 10 console font >>> lists and is so much better than the previous ones. >> >> >> Unless Miller changes it in the future, Pd 0.43 should have the same >> boxes sizes that Pd-extended has had for a couple versions. That >> was one of my goals with the GUI rewrite. Its a bug if that's not >> the case. >> >> .hc >> >> >> ---------------------------------------------------------------------------- >> >> The arc of history bends towards justice. - Dr. Martin Luther >> King, Jr. >> >> >> >> _______________________________________________ >> Pd-list@iem.at mailing list >> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
You can't steal a gift. Bird gave the world his music, and if you can hear it, you can have it. - Dizzy Gillespie
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
8.4.19 c
Le 25/08/2010 22:58, Hans-Christoph Steiner a écrit :
Which wish are you using?
$ wish % info patchlevel 8.5.8
.hc
On Wed, 2010-08-25 at 22:30 +0200, cyrille henry wrote:
hello,
withubuntu 10.04
pd -noprefs -> the message box are higher than the text pd -noprefs -font-face "andale mono" solve the problem
so, andale mono is here, but not used...
here is the result of your script.
linespace ascent descent font name
13 11 2 msbm10 13 11 2 webdings 13 11 2 fixed 18 15 3 lucidatypewriter 19 14 5 courier 10 pitch 13 11 2 cmsy10 21 17 4 andale mono 14 11 3 clean 17 13 4 terminal 16 14 2 gothic 13 11 2 cmr10 13 11 2 wenquanyi zenhei 16 14 2 song ti 37 15 22 open look cursor 13 11 2 cmex10 16 14 2 mincho 13 11 2 msam10 18 14 4 courier 13 11 2 inconsolata 16 16 0 nil 13 11 2 cmmi10 16 14 2 fangsong ti 20 16 4 dotum 28 17 11 courier new 18 14 4 nimbus mono l 20 16 4 batang 13 11 2 wasy10
Cyrille
Le 25/08/2010 21:39, Hans-Christoph Steiner a écrit :
I figured out the cause. The problem is caused by the font used being different than the font that fits into the standardized boxes. If you have the margin problem or the offset clicking problem then your Tcl/Tk is not used "DejaVu Sans Mono" or "Andale Mono", the two fonts I have found that fit into the standard box size.
Other fonts have different ratios of height to width, and when Pd uses a different font, it tries to size it larger to fit the DejaVu Sans Mono. Also Tcl/Tk 8.4 does a bad job of font handling on GNU/Linux/X11. 8.5 is better but different than 8.4.
The DejaVu fonts are the standard fonts for GNOME and are included in all major distros, so those seem the natural font to standardize on. Also, DejaVu Sans Mono looks pretty good.
To get an idea, run the attached script with your wish. It would be quite useful if people would post the results of that script here so we can see what fonts are commonly available.
.hc
On Wed, 2010-08-25 at 11:49 -0700, Miller Puckette wrote:
By 'margin' I meant that 'the box is larger than the text inside it so there's a bunch of empty space inside it'... if you don't see that you won't have the problem I'm having :)
M
On Wed, Aug 25, 2010 at 02:45:12PM -0400, Hans-Christoph Steiner wrote:
Ok, testing now... as for having the boxes with a standardized size, that's been the case with Pd-extended 0.40 and is also the case with 0.43 as of now. I'm not sure if I understand your idea about the margin tho, but an outline in edit mode sounds like a good idea.
.hc
On Wed, 2010-08-25 at 11:09 -0700, Miller Puckette wrote:
Sure... here:
#N canvas 359 131 405 427 10; #X msg 98 55 ; line 1 ; line 2 ; line 3 ; line 4 ; line 5 ; line 6 ; line 7 ; line 8 ; line 9 ; line 10 ; line 11 ; line 12 ; line 13 ; line 14 ; line 15 ; line 16 ; line 17 ; line 18 ; line 19 ; line 20;
On my machine the text box is several (20?) pixels too tall and to select the bottom line of text you have to click way below it.
I don't see how the thing can be made truly cross-platform unless there's a way to get text to have a determined size (both vertical and horizontal) and that seems to be impossible to get to work cross-platform.
The only solution I can think of for getting boxes to have consistent sizes is to use Mathieu's suggestion and make the box have a standardized size, simply adding margin when the text font doesn't actually fill it. (There's have to be an outline drawn around comments when the patch is unlocked too.)
cheers Miller
On Wed, Aug 25, 2010 at 12:15:11PM -0400, Hans-Christoph Steiner wrote: > > I think the real solution to this would be one step deeper. If Pd > used Tcl to handle the GUI interaction, then we could use the Tk > scaling feature, which is what Tk does to handle cross-platform > differences in font rendering. Pd could then store the Tk scaling > number in the patch, and use it to scale internal copies of pixel > values, when necessary. Then we could have the best of both worlds. > This would also give us the ability to zoom/scale patches for free. > > This is not as hard as it might seem, I believe DesireData has this > working. I think this would also be quite clean and actually > simplify Pd's code rather than adding more complexity by tracking > both when fonts should fit to the box size and when the box size > should fit to the font. > > I'll take a look at the big text block clicking issue now. Do you > have an example patch? > > .hc > > > On Aug 24, 2010, at 4:38 PM, Miller Puckette wrote: > >> Long as there's a way to fix a problem I'm having: in message >> boxes with >> many lines of text, you can easily click on one character and >> select one above >> it... it gets very confusing. (Fedora 13 out-of-box). >> >> I'm guessing that in the current version the GUI simply tells Pd >> what size >> the font ought to have had instead of the genuine one. Pd could >> easily >> expand the box to the ought-to size (at least optionally for those >> wishing >> to make cross-platform patches) but should know about the text's >> actual size >> anyway. To be continued... >> >> cheers >> Miller >> >> On Tue, Aug 24, 2010 at 01:21:08AM -0400, Hans-Christoph Steiner >> wrote: >>> >>> On Aug 23, 2010, at 7:01 AM, Frank Barknecht wrote: >>> >>>> Hi, >>>> >>>> On Sat, Aug 21, 2010 at 01:39:08PM -0400, Mathieu Bouchard wrote: >>>>> BTW I've been using Pd-Extended's Linux/OSX default font >>>>> size as the >>>>> basis for all my patches for making my last 400 patches or so. >>>> >>>> I've used Pd vanilla for all my patches so far, with a "10" >>>> font-size, >>>> whatever that is in pixels. I know, that Pd-extended uses some >>>> different >>>> layout for several years now, which makes patches look wrong >>>> when you >>>> load them in Pd vanilla and the other way around. I have not much >>>> interest to discuss the differences between vanilla and Pd-x, >>>> as I am >>>> hoping the two to unify again with the gui-rewrite. So I'm >>>> willing to >>>> change my preferences to whatever will be the new vanilla, but I'd >>>> prefer to not do again that with every release or with every new >>>> Courier-like font that pops up on the Internets' Top 10 console font >>>> lists and is so much better than the previous ones. >>> >>> >>> Unless Miller changes it in the future, Pd 0.43 should have the same >>> boxes sizes that Pd-extended has had for a couple versions. That >>> was one of my goals with the GUI rewrite. Its a bug if that's not >>> the case. >>> >>> .hc >>> >>> >>> ---------------------------------------------------------------------------- >>> >>> The arc of history bends towards justice. - Dr. Martin Luther >>> King, Jr. >>> >>> >>> >>> _______________________________________________ >>> Pd-list@iem.at mailing list >>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list > > > > > ---------------------------------------------------------------------------- > > You can't steal a gift. Bird gave the world his music, and if you > can hear it, you can have it. - Dizzy Gillespie > > >
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
You will get poor results using anything less than 8.5. There are
serious bugs in the 8.4 branch, especially with font handling on GNU/
Linux. If you are on a Debian system, you can do:
apt-get install tcl8.5 tk8.5 update-alternatives wish
Then choose wish8.5. Pd 0.42 should be fine with 8.5.
.hc
On Aug 25, 2010, at 5:50 PM, cyrille henry wrote:
8.4.19 c
Le 25/08/2010 22:58, Hans-Christoph Steiner a écrit :
Which wish are you using?
$ wish % info patchlevel 8.5.8
.hc
On Wed, 2010-08-25 at 22:30 +0200, cyrille henry wrote:
hello,
withubuntu 10.04
pd -noprefs -> the message box are higher than the text pd -noprefs -font-face "andale mono" solve the problem
so, andale mono is here, but not used...
here is the result of your script.
linespace ascent descent font name
13 11 2 msbm10 13 11 2 webdings 13 11 2 fixed 18 15 3 lucidatypewriter 19 14 5 courier 10 pitch 13 11 2 cmsy10 21 17 4 andale mono 14 11 3 clean 17 13 4 terminal 16 14 2 gothic 13 11 2 cmr10 13 11 2 wenquanyi zenhei 16 14 2 song ti 37 15 22 open look cursor 13 11 2 cmex10 16 14 2 mincho 13 11 2 msam10 18 14 4 courier 13 11 2 inconsolata 16 16 0 nil 13 11 2 cmmi10 16 14 2 fangsong ti 20 16 4 dotum 28 17 11 courier new 18 14 4 nimbus mono l 20 16 4 batang 13 11 2 wasy10
Cyrille
Le 25/08/2010 21:39, Hans-Christoph Steiner a écrit :
I figured out the cause. The problem is caused by the font used
being different than the font that fits into the standardized boxes.
If you have the margin problem or the offset clicking problem then your
Tcl/Tk is not used "DejaVu Sans Mono" or "Andale Mono", the two fonts I
have found that fit into the standard box size.Other fonts have different ratios of height to width, and when Pd
uses a different font, it tries to size it larger to fit the DejaVu Sans
Mono. Also Tcl/Tk 8.4 does a bad job of font handling on GNU/Linux/ X11. 8.5 is better but different than 8.4.The DejaVu fonts are the standard fonts for GNOME and are
included in all major distros, so those seem the natural font to standardize
on. Also, DejaVu Sans Mono looks pretty good.To get an idea, run the attached script with your wish. It would
be quite useful if people would post the results of that script here
so we can see what fonts are commonly available..hc
On Wed, 2010-08-25 at 11:49 -0700, Miller Puckette wrote:
By 'margin' I meant that 'the box is larger than the text inside
it so there's a bunch of empty space inside it'... if you don't see that you
won't have the problem I'm having :)M
On Wed, Aug 25, 2010 at 02:45:12PM -0400, Hans-Christoph Steiner
wrote:Ok, testing now... as for having the boxes with a standardized
size, that's been the case with Pd-extended 0.40 and is also the case
with 0.43 as of now. I'm not sure if I understand your idea about
the margin tho, but an outline in edit mode sounds like a good idea..hc
On Wed, 2010-08-25 at 11:09 -0700, Miller Puckette wrote: > Sure... here: > > #N canvas 359 131 405 427 10; > #X msg 98 55 ; line 1 ; line 2 ; line 3 ; line 4 ; line 5
> ; line > 6 ; line 7 ; line 8 ; line 9 ; line 10 ; line 11 ; line
> 12 ; > line 13 ; line 14 ; line 15 ; line 16 ; line 17 ; line 18
> ; line > 19 ; line 20; > > On my machine the text box is several (20?) pixels too tall
> and to select > the bottom line of text you have to click way below it. > > I don't see how the thing can be made truly cross-platform
> unless there's > a way to get text to have a determined size (both vertical and
> horizontal) > and that seems to be impossible to get to work cross-platform. > > The only solution I can think of for getting boxes to have
> consistent sizes is > to use Mathieu's suggestion and make the box have a
> standardized size, simply > adding margin when the text font doesn't actually fill it.
> (There's have to > be an outline drawn around comments when the patch is unlocked
> too.) > > cheers > Miller > > On Wed, Aug 25, 2010 at 12:15:11PM -0400, Hans-Christoph
> Steiner wrote: >> >> I think the real solution to this would be one step deeper.
>> If Pd >> used Tcl to handle the GUI interaction, then we could use the
>> Tk >> scaling feature, which is what Tk does to handle cross-platform >> differences in font rendering. Pd could then store the Tk
>> scaling >> number in the patch, and use it to scale internal copies of
>> pixel >> values, when necessary. Then we could have the best of both
>> worlds. >> This would also give us the ability to zoom/scale patches for
>> free. >> >> This is not as hard as it might seem, I believe DesireData
>> has this >> working. I think this would also be quite clean and actually >> simplify Pd's code rather than adding more complexity by
>> tracking >> both when fonts should fit to the box size and when the box
>> size >> should fit to the font. >> >> I'll take a look at the big text block clicking issue now.
>> Do you >> have an example patch? >> >> .hc >> >> >> On Aug 24, 2010, at 4:38 PM, Miller Puckette wrote: >> >>> Long as there's a way to fix a problem I'm having: in message >>> boxes with >>> many lines of text, you can easily click on one character and >>> select one above >>> it... it gets very confusing. (Fedora 13 out-of-box). >>> >>> I'm guessing that in the current version the GUI simply
>>> tells Pd >>> what size >>> the font ought to have had instead of the genuine one. Pd
>>> could >>> easily >>> expand the box to the ought-to size (at least optionally for
>>> those >>> wishing >>> to make cross-platform patches) but should know about the
>>> text's >>> actual size >>> anyway. To be continued... >>> >>> cheers >>> Miller >>> >>> On Tue, Aug 24, 2010 at 01:21:08AM -0400, Hans-Christoph
>>> Steiner >>> wrote: >>>> >>>> On Aug 23, 2010, at 7:01 AM, Frank Barknecht wrote: >>>> >>>>> Hi, >>>>> >>>>> On Sat, Aug 21, 2010 at 01:39:08PM -0400, Mathieu Bouchard
>>>>> wrote: >>>>>> BTW I've been using Pd-Extended's Linux/OSX default font >>>>>> size as the >>>>>> basis for all my patches for making my last 400 patches
>>>>>> or so. >>>>> >>>>> I've used Pd vanilla for all my patches so far, with a "10" >>>>> font-size, >>>>> whatever that is in pixels. I know, that Pd-extended uses
>>>>> some >>>>> different >>>>> layout for several years now, which makes patches look wrong >>>>> when you >>>>> load them in Pd vanilla and the other way around. I have
>>>>> not much >>>>> interest to discuss the differences between vanilla and Pd- >>>>> x, >>>>> as I am >>>>> hoping the two to unify again with the gui-rewrite. So I'm >>>>> willing to >>>>> change my preferences to whatever will be the new vanilla,
>>>>> but I'd >>>>> prefer to not do again that with every release or with
>>>>> every new >>>>> Courier-like font that pops up on the Internets' Top 10
>>>>> console font >>>>> lists and is so much better than the previous ones. >>>> >>>> >>>> Unless Miller changes it in the future, Pd 0.43 should have
>>>> the same >>>> boxes sizes that Pd-extended has had for a couple
>>>> versions. That >>>> was one of my goals with the GUI rewrite. Its a bug if
>>>> that's not >>>> the case. >>>> >>>> .hc >>>> >>>> >>>> ---------------------------------------------------------------------------- >>>> >>>> The arc of history bends towards justice. - Dr. Martin
>>>> Luther >>>> King, Jr. >>>> >>>> >>>> >>>> _______________________________________________ >>>> Pd-list@iem.at mailing list >>>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list >> >> >> >> >> ---------------------------------------------------------------------------- >> >> You can't steal a gift. Bird gave the world his music, and if
>> you >> can hear it, you can have it. - Dizzy Gillespie >> >> >>
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I spent 33 years and four months in active military service and during
that period I spent most of my time as a high class muscle man for Big
Business, for Wall Street and the bankers. - General Smedley Butler
I have found that "Courier 10 Pitch", "DejaVu Sans Mono", and "Andale Mono" work best. We should probably change the font searching thing in pd-gui.tcl to use those instead of what's there.
.hc
On Wed, 2010-08-25 at 22:30 +0200, cyrille henry wrote:
hello,
withubuntu 10.04
pd -noprefs -> the message box are higher than the text pd -noprefs -font-face "andale mono" solve the problem
so, andale mono is here, but not used...
here is the result of your script.
linespace ascent descent font name
13 11 2 msbm10 13 11 2 webdings 13 11 2 fixed 18 15 3 lucidatypewriter 19 14 5 courier 10 pitch 13 11 2 cmsy10 21 17 4 andale mono 14 11 3 clean 17 13 4 terminal 16 14 2 gothic 13 11 2 cmr10 13 11 2 wenquanyi zenhei 16 14 2 song ti 37 15 22 open look cursor 13 11 2 cmex10 16 14 2 mincho 13 11 2 msam10 18 14 4 courier 13 11 2 inconsolata 16 16 0 nil 13 11 2 cmmi10 16 14 2 fangsong ti 20 16 4 dotum 28 17 11 courier new 18 14 4 nimbus mono l 20 16 4 batang 13 11 2 wasy10
Cyrille
Le 25/08/2010 21:39, Hans-Christoph Steiner a écrit :
I figured out the cause. The problem is caused by the font used being different than the font that fits into the standardized boxes. If you have the margin problem or the offset clicking problem then your Tcl/Tk is not used "DejaVu Sans Mono" or "Andale Mono", the two fonts I have found that fit into the standard box size.
Other fonts have different ratios of height to width, and when Pd uses a different font, it tries to size it larger to fit the DejaVu Sans Mono. Also Tcl/Tk 8.4 does a bad job of font handling on GNU/Linux/X11. 8.5 is better but different than 8.4.
The DejaVu fonts are the standard fonts for GNOME and are included in all major distros, so those seem the natural font to standardize on. Also, DejaVu Sans Mono looks pretty good.
To get an idea, run the attached script with your wish. It would be quite useful if people would post the results of that script here so we can see what fonts are commonly available.
.hc
On Wed, 2010-08-25 at 11:49 -0700, Miller Puckette wrote:
By 'margin' I meant that 'the box is larger than the text inside it so there's a bunch of empty space inside it'... if you don't see that you won't have the problem I'm having :)
M
On Wed, Aug 25, 2010 at 02:45:12PM -0400, Hans-Christoph Steiner wrote:
Ok, testing now... as for having the boxes with a standardized size, that's been the case with Pd-extended 0.40 and is also the case with 0.43 as of now. I'm not sure if I understand your idea about the margin tho, but an outline in edit mode sounds like a good idea.
.hc
On Wed, 2010-08-25 at 11:09 -0700, Miller Puckette wrote:
Sure... here:
#N canvas 359 131 405 427 10; #X msg 98 55 ; line 1 ; line 2 ; line 3 ; line 4 ; line 5 ; line 6 ; line 7 ; line 8 ; line 9 ; line 10 ; line 11 ; line 12 ; line 13 ; line 14 ; line 15 ; line 16 ; line 17 ; line 18 ; line 19 ; line 20;
On my machine the text box is several (20?) pixels too tall and to select the bottom line of text you have to click way below it.
I don't see how the thing can be made truly cross-platform unless there's a way to get text to have a determined size (both vertical and horizontal) and that seems to be impossible to get to work cross-platform.
The only solution I can think of for getting boxes to have consistent sizes is to use Mathieu's suggestion and make the box have a standardized size, simply adding margin when the text font doesn't actually fill it. (There's have to be an outline drawn around comments when the patch is unlocked too.)
cheers Miller
On Wed, Aug 25, 2010 at 12:15:11PM -0400, Hans-Christoph Steiner wrote:
I think the real solution to this would be one step deeper. If Pd used Tcl to handle the GUI interaction, then we could use the Tk scaling feature, which is what Tk does to handle cross-platform differences in font rendering. Pd could then store the Tk scaling number in the patch, and use it to scale internal copies of pixel values, when necessary. Then we could have the best of both worlds. This would also give us the ability to zoom/scale patches for free.
This is not as hard as it might seem, I believe DesireData has this working. I think this would also be quite clean and actually simplify Pd's code rather than adding more complexity by tracking both when fonts should fit to the box size and when the box size should fit to the font.
I'll take a look at the big text block clicking issue now. Do you have an example patch?
.hc
On Aug 24, 2010, at 4:38 PM, Miller Puckette wrote:
> Long as there's a way to fix a problem I'm having: in message > boxes with > many lines of text, you can easily click on one character and > select one above > it... it gets very confusing. (Fedora 13 out-of-box). > > I'm guessing that in the current version the GUI simply tells Pd > what size > the font ought to have had instead of the genuine one. Pd could > easily > expand the box to the ought-to size (at least optionally for those > wishing > to make cross-platform patches) but should know about the text's > actual size > anyway. To be continued... > > cheers > Miller > > On Tue, Aug 24, 2010 at 01:21:08AM -0400, Hans-Christoph Steiner > wrote: >> >> On Aug 23, 2010, at 7:01 AM, Frank Barknecht wrote: >> >>> Hi, >>> >>> On Sat, Aug 21, 2010 at 01:39:08PM -0400, Mathieu Bouchard wrote: >>>> BTW I've been using Pd-Extended's Linux/OSX default font >>>> size as the >>>> basis for all my patches for making my last 400 patches or so. >>> >>> I've used Pd vanilla for all my patches so far, with a "10" >>> font-size, >>> whatever that is in pixels. I know, that Pd-extended uses some >>> different >>> layout for several years now, which makes patches look wrong >>> when you >>> load them in Pd vanilla and the other way around. I have not much >>> interest to discuss the differences between vanilla and Pd-x, >>> as I am >>> hoping the two to unify again with the gui-rewrite. So I'm >>> willing to >>> change my preferences to whatever will be the new vanilla, but I'd >>> prefer to not do again that with every release or with every new >>> Courier-like font that pops up on the Internets' Top 10 console font >>> lists and is so much better than the previous ones. >> >> >> Unless Miller changes it in the future, Pd 0.43 should have the same >> boxes sizes that Pd-extended has had for a couple versions. That >> was one of my goals with the GUI rewrite. Its a bug if that's not >> the case. >> >> .hc >> >> >> ---------------------------------------------------------------------------- >> >> The arc of history bends towards justice. - Dr. Martin Luther >> King, Jr. >> >> >> >> _______________________________________________ >> Pd-list@iem.at mailing list >> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
You can't steal a gift. Bird gave the world his music, and if you can hear it, you can have it. - Dizzy Gillespie
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Wed, 25 Aug 2010, cyrille henry wrote:
here is the result of your script.
It doesn't have a column for font width where applicable. In our case, that's quite critical.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard on the road (in Îles-de-la-Madeleine, QC).
On Aug 25, 2010, at 5:24 PM, Mathieu Bouchard wrote:
On Wed, 25 Aug 2010, cyrille henry wrote:
here is the result of your script.
It doesn't have a column for font width where applicable. In our
case, that's quite critical.
this version does:
.hc
Information wants to be free. -Stewart Brand
$ wish '/home/jack/Bureau/fonttest.tcl' linespace ascent descent font name
16 14 2 fangsong ti 13 11 2 fixed 18 15 3 lucidatypewriter 19 14 5 courier 10 pitch 16 14 2 song ti 37 15 22 open look cursor 16 14 2 mincho 20 16 4 dotum 15 12 3 courier 14 11 3 clean 16 16 0 nil 17 13 4 terminal 20 16 4 batang
$ wish % info patchlevel 8.4.19
++
Jack
Le mercredi 25 août 2010 à 15:39 -0400, Hans-Christoph Steiner a écrit :
I figured out the cause. The problem is caused by the font used being different than the font that fits into the standardized boxes. If you have the margin problem or the offset clicking problem then your Tcl/Tk is not used "DejaVu Sans Mono" or "Andale Mono", the two fonts I have found that fit into the standard box size.
Other fonts have different ratios of height to width, and when Pd uses a different font, it tries to size it larger to fit the DejaVu Sans Mono. Also Tcl/Tk 8.4 does a bad job of font handling on GNU/Linux/X11. 8.5 is better but different than 8.4.
The DejaVu fonts are the standard fonts for GNOME and are included in all major distros, so those seem the natural font to standardize on. Also, DejaVu Sans Mono looks pretty good.
To get an idea, run the attached script with your wish. It would be quite useful if people would post the results of that script here so we can see what fonts are commonly available.
.hc
On Wed, 2010-08-25 at 11:49 -0700, Miller Puckette wrote:
By 'margin' I meant that 'the box is larger than the text inside it so there's a bunch of empty space inside it'... if you don't see that you won't have the problem I'm having :)
M
On Wed, Aug 25, 2010 at 02:45:12PM -0400, Hans-Christoph Steiner wrote:
Ok, testing now... as for having the boxes with a standardized size, that's been the case with Pd-extended 0.40 and is also the case with 0.43 as of now. I'm not sure if I understand your idea about the margin tho, but an outline in edit mode sounds like a good idea.
.hc
On Wed, 2010-08-25 at 11:09 -0700, Miller Puckette wrote:
Sure... here:
#N canvas 359 131 405 427 10; #X msg 98 55 ; line 1 ; line 2 ; line 3 ; line 4 ; line 5 ; line 6 ; line 7 ; line 8 ; line 9 ; line 10 ; line 11 ; line 12 ; line 13 ; line 14 ; line 15 ; line 16 ; line 17 ; line 18 ; line 19 ; line 20;
On my machine the text box is several (20?) pixels too tall and to select the bottom line of text you have to click way below it.
I don't see how the thing can be made truly cross-platform unless there's a way to get text to have a determined size (both vertical and horizontal) and that seems to be impossible to get to work cross-platform.
The only solution I can think of for getting boxes to have consistent sizes is to use Mathieu's suggestion and make the box have a standardized size, simply adding margin when the text font doesn't actually fill it. (There's have to be an outline drawn around comments when the patch is unlocked too.)
cheers Miller
On Wed, Aug 25, 2010 at 12:15:11PM -0400, Hans-Christoph Steiner wrote:
I think the real solution to this would be one step deeper. If Pd used Tcl to handle the GUI interaction, then we could use the Tk scaling feature, which is what Tk does to handle cross-platform differences in font rendering. Pd could then store the Tk scaling number in the patch, and use it to scale internal copies of pixel values, when necessary. Then we could have the best of both worlds. This would also give us the ability to zoom/scale patches for free.
This is not as hard as it might seem, I believe DesireData has this working. I think this would also be quite clean and actually simplify Pd's code rather than adding more complexity by tracking both when fonts should fit to the box size and when the box size should fit to the font.
I'll take a look at the big text block clicking issue now. Do you have an example patch?
.hc
On Aug 24, 2010, at 4:38 PM, Miller Puckette wrote:
Long as there's a way to fix a problem I'm having: in message boxes with many lines of text, you can easily click on one character and select one above it... it gets very confusing. (Fedora 13 out-of-box).
I'm guessing that in the current version the GUI simply tells Pd what size the font ought to have had instead of the genuine one. Pd could easily expand the box to the ought-to size (at least optionally for those wishing to make cross-platform patches) but should know about the text's actual size anyway. To be continued...
cheers Miller
On Tue, Aug 24, 2010 at 01:21:08AM -0400, Hans-Christoph Steiner wrote: > >On Aug 23, 2010, at 7:01 AM, Frank Barknecht wrote: > >>Hi, >> >>On Sat, Aug 21, 2010 at 01:39:08PM -0400, Mathieu Bouchard wrote: >>>BTW I've been using Pd-Extended's Linux/OSX default font >>>size as the >>>basis for all my patches for making my last 400 patches or so. >> >>I've used Pd vanilla for all my patches so far, with a "10" >>font-size, >>whatever that is in pixels. I know, that Pd-extended uses some >>different >>layout for several years now, which makes patches look wrong >>when you >>load them in Pd vanilla and the other way around. I have not much >>interest to discuss the differences between vanilla and Pd-x, >>as I am >>hoping the two to unify again with the gui-rewrite. So I'm >>willing to >>change my preferences to whatever will be the new vanilla, but I'd >>prefer to not do again that with every release or with every new >>Courier-like font that pops up on the Internets' Top 10 console font >>lists and is so much better than the previous ones. > > >Unless Miller changes it in the future, Pd 0.43 should have the same >boxes sizes that Pd-extended has had for a couple versions. That >was one of my goals with the GUI rewrite. Its a bug if that's not >the case. > >.hc > > >---------------------------------------------------------------------------- > >The arc of history bends towards justice. - Dr. Martin Luther >King, Jr. > > > >_______________________________________________ >Pd-list@iem.at mailing list >UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
You can't steal a gift. Bird gave the world his music, and if you can hear it, you can have it. - Dizzy Gillespie
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
This is on Ubuntu Lucid x86 32bit:
-----8.5.8----------------------------------------------------- linespace ascent descent font name
18 14 4 Andale Mono 19 15 4 DejaVu Sans Mono 19 15 4 Aquabase-spanish-support 20 14 6 TlwgMono 17 13 4 Lucida Console 19 14 5 Courier 10 Pitch 18 13 5 Liberation Mono 18 13 5 Nimbus Mono L 20 14 6 Tlwg Typo 18 13 5 Courier New 17 13 4 FreeMono
-----8.4.19---------------------------------------------------- linespace ascent descent font name
13 11 2 msbm10 13 11 2 fixed 18 15 3 lucidatypewriter 19 14 5 courier 10 pitch 13 11 2 cmsy10 14 11 3 clean 17 13 4 terminal 16 14 2 gothic 13 11 2 cmr10 13 11 2 wenquanyi zenhei 16 14 2 song ti 37 15 22 open look cursor 13 11 2 cmex10 16 14 2 mincho 13 11 2 msam10 18 14 4 courier 16 16 0 nil 13 11 2 cmmi10 16 14 2 fangsong ti 20 16 4 dotum 18 14 4 nimbus mono l 20 16 4 batang 13 11 2 wasy10
Roman
On Wed, 2010-08-25 at 15:39 -0400, Hans-Christoph Steiner wrote:
I figured out the cause. The problem is caused by the font used being different than the font that fits into the standardized boxes. If you have the margin problem or the offset clicking problem then your Tcl/Tk is not used "DejaVu Sans Mono" or "Andale Mono", the two fonts I have found that fit into the standard box size.
Other fonts have different ratios of height to width, and when Pd uses a different font, it tries to size it larger to fit the DejaVu Sans Mono. Also Tcl/Tk 8.4 does a bad job of font handling on GNU/Linux/X11. 8.5 is better but different than 8.4.
The DejaVu fonts are the standard fonts for GNOME and are included in all major distros, so those seem the natural font to standardize on. Also, DejaVu Sans Mono looks pretty good.
To get an idea, run the attached script with your wish. It would be quite useful if people would post the results of that script here so we can see what fonts are commonly available.
.hc
On Wed, 2010-08-25 at 11:49 -0700, Miller Puckette wrote:
By 'margin' I meant that 'the box is larger than the text inside it so there's a bunch of empty space inside it'... if you don't see that you won't have the problem I'm having :)
M
On Wed, Aug 25, 2010 at 02:45:12PM -0400, Hans-Christoph Steiner wrote:
Ok, testing now... as for having the boxes with a standardized size, that's been the case with Pd-extended 0.40 and is also the case with 0.43 as of now. I'm not sure if I understand your idea about the margin tho, but an outline in edit mode sounds like a good idea.
.hc
On Wed, 2010-08-25 at 11:09 -0700, Miller Puckette wrote:
Sure... here:
#N canvas 359 131 405 427 10; #X msg 98 55 ; line 1 ; line 2 ; line 3 ; line 4 ; line 5 ; line 6 ; line 7 ; line 8 ; line 9 ; line 10 ; line 11 ; line 12 ; line 13 ; line 14 ; line 15 ; line 16 ; line 17 ; line 18 ; line 19 ; line 20;
On my machine the text box is several (20?) pixels too tall and to select the bottom line of text you have to click way below it.
I don't see how the thing can be made truly cross-platform unless there's a way to get text to have a determined size (both vertical and horizontal) and that seems to be impossible to get to work cross-platform.
The only solution I can think of for getting boxes to have consistent sizes is to use Mathieu's suggestion and make the box have a standardized size, simply adding margin when the text font doesn't actually fill it. (There's have to be an outline drawn around comments when the patch is unlocked too.)
cheers Miller
On Wed, Aug 25, 2010 at 12:15:11PM -0400, Hans-Christoph Steiner wrote:
I think the real solution to this would be one step deeper. If Pd used Tcl to handle the GUI interaction, then we could use the Tk scaling feature, which is what Tk does to handle cross-platform differences in font rendering. Pd could then store the Tk scaling number in the patch, and use it to scale internal copies of pixel values, when necessary. Then we could have the best of both worlds. This would also give us the ability to zoom/scale patches for free.
This is not as hard as it might seem, I believe DesireData has this working. I think this would also be quite clean and actually simplify Pd's code rather than adding more complexity by tracking both when fonts should fit to the box size and when the box size should fit to the font.
I'll take a look at the big text block clicking issue now. Do you have an example patch?
.hc
On Aug 24, 2010, at 4:38 PM, Miller Puckette wrote:
Long as there's a way to fix a problem I'm having: in message boxes with many lines of text, you can easily click on one character and select one above it... it gets very confusing. (Fedora 13 out-of-box).
I'm guessing that in the current version the GUI simply tells Pd what size the font ought to have had instead of the genuine one. Pd could easily expand the box to the ought-to size (at least optionally for those wishing to make cross-platform patches) but should know about the text's actual size anyway. To be continued...
cheers Miller
On Tue, Aug 24, 2010 at 01:21:08AM -0400, Hans-Christoph Steiner wrote: > >On Aug 23, 2010, at 7:01 AM, Frank Barknecht wrote: > >>Hi, >> >>On Sat, Aug 21, 2010 at 01:39:08PM -0400, Mathieu Bouchard wrote: >>>BTW I've been using Pd-Extended's Linux/OSX default font >>>size as the >>>basis for all my patches for making my last 400 patches or so. >> >>I've used Pd vanilla for all my patches so far, with a "10" >>font-size, >>whatever that is in pixels. I know, that Pd-extended uses some >>different >>layout for several years now, which makes patches look wrong >>when you >>load them in Pd vanilla and the other way around. I have not much >>interest to discuss the differences between vanilla and Pd-x, >>as I am >>hoping the two to unify again with the gui-rewrite. So I'm >>willing to >>change my preferences to whatever will be the new vanilla, but I'd >>prefer to not do again that with every release or with every new >>Courier-like font that pops up on the Internets' Top 10 console font >>lists and is so much better than the previous ones. > > >Unless Miller changes it in the future, Pd 0.43 should have the same >boxes sizes that Pd-extended has had for a couple versions. That >was one of my goals with the GUI rewrite. Its a bug if that's not >the case. > >.hc > > >---------------------------------------------------------------------------- > >The arc of history bends towards justice. - Dr. Martin Luther >King, Jr. > > > >_______________________________________________ >Pd-list@iem.at mailing list >UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
You can't steal a gift. Bird gave the world his music, and if you can hear it, you can have it. - Dizzy Gillespie
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Here is the answer to this font problem:
- use Tcl/Tk 8.5 or newer, Tcl 8.4 is very flawed (see archives for
discussion, basically it makes bad guesses and assigns them to the fontname "courier")
- use one of these fonts: {"Courier 10 Pitch" "DejaVu Sans Mono"
"Bitstream Vera Sans Mono" "Droid Sans Mono" "Andale Mono"
Anything else and you'll have strange results. In order to have better font support, we need to do some major surgery.
.hc
On Tue, 2010-08-24 at 13:38 -0700, Miller Puckette wrote:
Long as there's a way to fix a problem I'm having: in message boxes with many lines of text, you can easily click on one character and select one above it... it gets very confusing. (Fedora 13 out-of-box).
I'm guessing that in the current version the GUI simply tells Pd what size the font ought to have had instead of the genuine one. Pd could easily expand the box to the ought-to size (at least optionally for those wishing to make cross-platform patches) but should know about the text's actual size anyway. To be continued...
cheers Miller
On Tue, Aug 24, 2010 at 01:21:08AM -0400, Hans-Christoph Steiner wrote:
On Aug 23, 2010, at 7:01 AM, Frank Barknecht wrote:
Hi,
On Sat, Aug 21, 2010 at 01:39:08PM -0400, Mathieu Bouchard wrote:
BTW I've been using Pd-Extended's Linux/OSX default font size as the basis for all my patches for making my last 400 patches or so.
I've used Pd vanilla for all my patches so far, with a "10" font-size, whatever that is in pixels. I know, that Pd-extended uses some different layout for several years now, which makes patches look wrong when you load them in Pd vanilla and the other way around. I have not much interest to discuss the differences between vanilla and Pd-x, as I am hoping the two to unify again with the gui-rewrite. So I'm willing to change my preferences to whatever will be the new vanilla, but I'd prefer to not do again that with every release or with every new Courier-like font that pops up on the Internets' Top 10 console font lists and is so much better than the previous ones.
Unless Miller changes it in the future, Pd 0.43 should have the same boxes sizes that Pd-extended has had for a couple versions. That was one of my goals with the GUI rewrite. Its a bug if that's not the case.
.hc
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
My machine is running 8.5... but I don't think it's good to have Pd's default font choice come out all wrong... ideally, it should do something reasonable no matter what the font (well, at least if it's fixed-pitch). At the very least, Pd has to know the correct font metrics... and it seems now not to.
Perhaps a solution for cross-platform patching (such as for making help files) could be to say "this will look woerd on other machines unless you use font <blaz> to develope the patch so that you see the canonical sizes.
cheers M
On Wed, Aug 25, 2010 at 04:18:49PM -0400, Hans-Christoph Steiner wrote:
Here is the answer to this font problem:
- use Tcl/Tk 8.5 or newer, Tcl 8.4 is very flawed (see archives for
discussion, basically it makes bad guesses and assigns them to the fontname "courier")
- use one of these fonts: {"Courier 10 Pitch" "DejaVu Sans Mono"
"Bitstream Vera Sans Mono" "Droid Sans Mono" "Andale Mono"Anything else and you'll have strange results. In order to have better font support, we need to do some major surgery.
.hc
On Tue, 2010-08-24 at 13:38 -0700, Miller Puckette wrote:
Long as there's a way to fix a problem I'm having: in message boxes with many lines of text, you can easily click on one character and select one above it... it gets very confusing. (Fedora 13 out-of-box).
I'm guessing that in the current version the GUI simply tells Pd what size the font ought to have had instead of the genuine one. Pd could easily expand the box to the ought-to size (at least optionally for those wishing to make cross-platform patches) but should know about the text's actual size anyway. To be continued...
cheers Miller
On Tue, Aug 24, 2010 at 01:21:08AM -0400, Hans-Christoph Steiner wrote:
On Aug 23, 2010, at 7:01 AM, Frank Barknecht wrote:
Hi,
On Sat, Aug 21, 2010 at 01:39:08PM -0400, Mathieu Bouchard wrote:
BTW I've been using Pd-Extended's Linux/OSX default font size as the basis for all my patches for making my last 400 patches or so.
I've used Pd vanilla for all my patches so far, with a "10" font-size, whatever that is in pixels. I know, that Pd-extended uses some different layout for several years now, which makes patches look wrong when you load them in Pd vanilla and the other way around. I have not much interest to discuss the differences between vanilla and Pd-x, as I am hoping the two to unify again with the gui-rewrite. So I'm willing to change my preferences to whatever will be the new vanilla, but I'd prefer to not do again that with every release or with every new Courier-like font that pops up on the Internets' Top 10 console font lists and is so much better than the previous ones.
Unless Miller changes it in the future, Pd 0.43 should have the same boxes sizes that Pd-extended has had for a couple versions. That was one of my goals with the GUI rewrite. Its a bug if that's not the case.
.hc
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 2010-08-26 06:52, Miller Puckette wrote:
Perhaps a solution for cross-platform patching (such as for making help files) could be to say "this will look woerd on other machines unless you use font <blaz> to develope the patch so that you see the canonical sizes.
this page is best viewed with Internet Explorer 3.
fgmasdr IOhannes
On Aug 26, 2010, at 3:26 AM, IOhannes m zmoelnig wrote:
On 2010-08-26 06:52, Miller Puckette wrote:
Perhaps a solution for cross-platform patching (such as for making
help files) could be to say "this will look woerd on other machines unless you use font <blaz> to develope the patch so that you see the
canonical sizes.this page is best viewed with Internet Explorer 3.
fgmasdr IOhannes
Patches welcome!
.hc
There is no way to peace, peace is the way. -A.J. Muste
Yes, I agree. I think the font to standardize on is DevaVu Sans
Mono. Its a decent font, it fits already, its free software, and it
has the best unicode support of probably any font. It also comes
installed by default on most GNU/Linux systems. In Pd-extended, the
Windows installer installs DejaVu Sans Mono. On Mac OS X, shipping a
font with the Pd.app is a massive pain, so Pd-extended uses Monaco,
which is included in Mac OS X, and quite close in size to DejaVu Sans
Mono.
I'd welcome a better solution, but I have spent literally days on
dealing with fonts, mostly on GNU/Linux, and I can't see a better way,
especially since wish 8.4 and 8.5 on GNU/Linux handle fonts so much
differently from each other. (For example, if you look at the output
of fonttest.tcl using 8.4 and 8.5, you'll see that the same fonts have
different metrics!).
.hc
On Aug 26, 2010, at 12:52 AM, Miller Puckette wrote:
My machine is running 8.5... but I don't think it's good to have Pd's default font choice come out all wrong... ideally, it should do something reasonable no matter what the font (well, at least if it's fixed-pitch). At the very least, Pd has to know the correct font metrics... and it seems now not to.
Perhaps a solution for cross-platform patching (such as for making
help files) could be to say "this will look woerd on other machines unless you use font <blaz> to develope the patch so that you see the
canonical sizes.cheers M
On Wed, Aug 25, 2010 at 04:18:49PM -0400, Hans-Christoph Steiner
wrote:Here is the answer to this font problem:
- use Tcl/Tk 8.5 or newer, Tcl 8.4 is very flawed (see archives for
discussion, basically it makes bad guesses and assigns them to the fontname "courier")
- use one of these fonts: {"Courier 10 Pitch" "DejaVu Sans Mono"
"Bitstream Vera Sans Mono" "Droid Sans Mono" "Andale Mono"Anything else and you'll have strange results. In order to have
better font support, we need to do some major surgery..hc
On Tue, 2010-08-24 at 13:38 -0700, Miller Puckette wrote:
Long as there's a way to fix a problem I'm having: in message
boxes with many lines of text, you can easily click on one character and
select one above it... it gets very confusing. (Fedora 13 out-of-box).I'm guessing that in the current version the GUI simply tells Pd
what size the font ought to have had instead of the genuine one. Pd could
easily expand the box to the ought-to size (at least optionally for those
wishing to make cross-platform patches) but should know about the text's
actual size anyway. To be continued...cheers Miller
On Tue, Aug 24, 2010 at 01:21:08AM -0400, Hans-Christoph Steiner
wrote:On Aug 23, 2010, at 7:01 AM, Frank Barknecht wrote:
Hi,
On Sat, Aug 21, 2010 at 01:39:08PM -0400, Mathieu Bouchard wrote:
BTW I've been using Pd-Extended's Linux/OSX default font size
as the basis for all my patches for making my last 400 patches or so.I've used Pd vanilla for all my patches so far, with a "10" font- size, whatever that is in pixels. I know, that Pd-extended uses some different layout for several years now, which makes patches look wrong
when you load them in Pd vanilla and the other way around. I have not much interest to discuss the differences between vanilla and Pd-x, as
I am hoping the two to unify again with the gui-rewrite. So I'm
willing to change my preferences to whatever will be the new vanilla, but I'd prefer to not do again that with every release or with every new Courier-like font that pops up on the Internets' Top 10 console
font lists and is so much better than the previous ones.Unless Miller changes it in the future, Pd 0.43 should have the
same boxes sizes that Pd-extended has had for a couple versions. That was one of my goals with the GUI rewrite. Its a bug if that's not the case..hc
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
As we enjoy great advantages from inventions of others, we should be
glad of an opportunity to serve others by any invention of ours; and
this we should do freely and generously. - Benjamin Franklin
On Aug 26, 2010, at 12:52 AM, Miller Puckette wrote:
My machine is running 8.5... but I don't think it's good to have Pd's default font choice come out all wrong... ideally, it should do something reasonable no matter what the font (well, at least if it's fixed-pitch). At the very least, Pd has to know the correct font metrics... and it seems now not to.
I should add, given my experience, I don't think this is a realistic
goal without major surgery. Its something I've put a lot of work into
trying to get working. My experience tells me that the best bet is
using a default font.
Even better would be making the pd <--> pd-gui communication not deal
with pixel values and mouse motion, but instead logical operations.
For example, instead of pd knowing anything about the text editing
operation, that should happen entirely in the gui. Then once the
editing operation is complete, the GUI would send the result to pd.
.hc
Perhaps a solution for cross-platform patching (such as for making
help files) could be to say "this will look woerd on other machines unless you use font <blaz> to develope the patch so that you see the
canonical sizes.cheers M
On Wed, Aug 25, 2010 at 04:18:49PM -0400, Hans-Christoph Steiner
wrote:Here is the answer to this font problem:
- use Tcl/Tk 8.5 or newer, Tcl 8.4 is very flawed (see archives for
discussion, basically it makes bad guesses and assigns them to the fontname "courier")
- use one of these fonts: {"Courier 10 Pitch" "DejaVu Sans Mono"
"Bitstream Vera Sans Mono" "Droid Sans Mono" "Andale Mono"Anything else and you'll have strange results. In order to have
better font support, we need to do some major surgery..hc
On Tue, 2010-08-24 at 13:38 -0700, Miller Puckette wrote:
Long as there's a way to fix a problem I'm having: in message
boxes with many lines of text, you can easily click on one character and
select one above it... it gets very confusing. (Fedora 13 out-of-box).I'm guessing that in the current version the GUI simply tells Pd
what size the font ought to have had instead of the genuine one. Pd could
easily expand the box to the ought-to size (at least optionally for those
wishing to make cross-platform patches) but should know about the text's
actual size anyway. To be continued...cheers Miller
On Tue, Aug 24, 2010 at 01:21:08AM -0400, Hans-Christoph Steiner
wrote:On Aug 23, 2010, at 7:01 AM, Frank Barknecht wrote:
Hi,
On Sat, Aug 21, 2010 at 01:39:08PM -0400, Mathieu Bouchard wrote:
BTW I've been using Pd-Extended's Linux/OSX default font size
as the basis for all my patches for making my last 400 patches or so.I've used Pd vanilla for all my patches so far, with a "10" font- size, whatever that is in pixels. I know, that Pd-extended uses some different layout for several years now, which makes patches look wrong
when you load them in Pd vanilla and the other way around. I have not much interest to discuss the differences between vanilla and Pd-x, as
I am hoping the two to unify again with the gui-rewrite. So I'm
willing to change my preferences to whatever will be the new vanilla, but I'd prefer to not do again that with every release or with every new Courier-like font that pops up on the Internets' Top 10 console
font lists and is so much better than the previous ones.Unless Miller changes it in the future, Pd 0.43 should have the
same boxes sizes that Pd-extended has had for a couple versions. That was one of my goals with the GUI rewrite. Its a bug if that's not the case..hc
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Programs should be written for people to read, and only incidentally
for machines to execute.
- from Structure and Interpretation of Computer Programs
OK.. but for 0.43... is there a stopgap? I can't think of any way to get text editing working (i.e., getting the character you click on to be the one Pd sees you click on) except by going back to status quo.
cheers MIller
On Thu, Aug 26, 2010 at 01:54:15PM -0400, Hans-Christoph Steiner wrote:
On Aug 26, 2010, at 12:52 AM, Miller Puckette wrote:
My machine is running 8.5... but I don't think it's good to have Pd's default font choice come out all wrong... ideally, it should do something reasonable no matter what the font (well, at least if it's fixed-pitch). At the very least, Pd has to know the correct font metrics... and it seems now not to.
I should add, given my experience, I don't think this is a realistic goal without major surgery. Its something I've put a lot of work into trying to get working. My experience tells me that the best bet is using a default font.
Even better would be making the pd <--> pd-gui communication not deal with pixel values and mouse motion, but instead logical operations. For example, instead of pd knowing anything about the text editing operation, that should happen entirely in the gui. Then once the editing operation is complete, the GUI would send the result to pd.
.hc
Perhaps a solution for cross-platform patching (such as for making help files) could be to say "this will look woerd on other machines unless you use font <blaz> to develope the patch so that you see the canonical sizes.
cheers M
On Wed, Aug 25, 2010 at 04:18:49PM -0400, Hans-Christoph Steiner wrote:
Here is the answer to this font problem:
- use Tcl/Tk 8.5 or newer, Tcl 8.4 is very flawed (see archives for
discussion, basically it makes bad guesses and assigns them to the fontname "courier")
- use one of these fonts: {"Courier 10 Pitch" "DejaVu Sans Mono"
"Bitstream Vera Sans Mono" "Droid Sans Mono" "Andale Mono"Anything else and you'll have strange results. In order to have better font support, we need to do some major surgery.
.hc
On Tue, 2010-08-24 at 13:38 -0700, Miller Puckette wrote:
Long as there's a way to fix a problem I'm having: in message boxes with many lines of text, you can easily click on one character and select one above it... it gets very confusing. (Fedora 13 out-of-box).
I'm guessing that in the current version the GUI simply tells Pd what size the font ought to have had instead of the genuine one. Pd could easily expand the box to the ought-to size (at least optionally for those wishing to make cross-platform patches) but should know about the text's actual size anyway. To be continued...
cheers Miller
On Tue, Aug 24, 2010 at 01:21:08AM -0400, Hans-Christoph Steiner wrote:
On Aug 23, 2010, at 7:01 AM, Frank Barknecht wrote:
Hi,
On Sat, Aug 21, 2010 at 01:39:08PM -0400, Mathieu Bouchard wrote: >BTW I've been using Pd-Extended's Linux/OSX default font >size as the >basis for all my patches for making my last 400 patches or so.
I've used Pd vanilla for all my patches so far, with a "10" font-size, whatever that is in pixels. I know, that Pd-extended uses some different layout for several years now, which makes patches look wrong when you load them in Pd vanilla and the other way around. I have not much interest to discuss the differences between vanilla and Pd-x, as I am hoping the two to unify again with the gui-rewrite. So I'm willing to change my preferences to whatever will be the new vanilla, but I'd prefer to not do again that with every release or with every new Courier-like font that pops up on the Internets' Top 10 console font lists and is so much better than the previous ones.
Unless Miller changes it in the future, Pd 0.43 should have the same boxes sizes that Pd-extended has had for a couple versions. That was one of my goals with the GUI rewrite. Its a bug if that's not the case.
.hc
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Programs should be written for people to read, and only incidentally for machines to execute.
- from Structure and Interpretation of Computer Programs
If you use one of the supported fonts, then it should works much
better, but still with issues on the biggest fonts. Right now the
code just measures the width of the characters, and so you can see the
width is always right. I suppose we also need to measure the height,
but then the width might be wrong. Its maddening.
If Tcl/Tk supports changing the height of a font, then it would be
easy, we could make any font fit into the boxes. I haven't found
that, if only [font metrics] allows you to set and not just query:
http://tcl.tk/man/tcl8.5/TkCmd/font.htm#M11
Matju, have you ever found anything to adjust font height/width
independently in Tcl?
.hc
On Aug 26, 2010, at 2:43 PM, Miller Puckette wrote:
OK.. but for 0.43... is there a stopgap? I can't think of any way to get text editing working (i.e., getting the character you click on to be the one Pd sees you click on) except by going back to status quo.
cheers MIller
On Thu, Aug 26, 2010 at 01:54:15PM -0400, Hans-Christoph Steiner
wrote:On Aug 26, 2010, at 12:52 AM, Miller Puckette wrote:
My machine is running 8.5... but I don't think it's good to have Pd's default font choice come out all wrong... ideally, it should do something reasonable no matter what the font (well, at least if it's fixed-pitch). At the very least, Pd has to know the correct font metrics... and it seems now not to.
I should add, given my experience, I don't think this is a realistic goal without major surgery. Its something I've put a lot of work into trying to get working. My experience tells me that the best bet is using a default font.
Even better would be making the pd <--> pd-gui communication not deal with pixel values and mouse motion, but instead logical operations. For example, instead of pd knowing anything about the text editing operation, that should happen entirely in the gui. Then once the editing operation is complete, the GUI would send the result to pd.
.hc
Perhaps a solution for cross-platform patching (such as for making help files) could be to say "this will look woerd on other machines
unless you use font <blaz> to develope the patch so that you see the canonical sizes.cheers M
On Wed, Aug 25, 2010 at 04:18:49PM -0400, Hans-Christoph Steiner wrote:
Here is the answer to this font problem:
- use Tcl/Tk 8.5 or newer, Tcl 8.4 is very flawed (see archives for
discussion, basically it makes bad guesses and assigns them to the fontname "courier")
- use one of these fonts: {"Courier 10 Pitch" "DejaVu Sans Mono"
"Bitstream Vera Sans Mono" "Droid Sans Mono" "Andale Mono"Anything else and you'll have strange results. In order to have better font support, we need to do some major surgery.
.hc
On Tue, 2010-08-24 at 13:38 -0700, Miller Puckette wrote:
Long as there's a way to fix a problem I'm having: in message boxes with many lines of text, you can easily click on one character and select one above it... it gets very confusing. (Fedora 13 out-of-box).
I'm guessing that in the current version the GUI simply tells Pd what size the font ought to have had instead of the genuine one. Pd could easily expand the box to the ought-to size (at least optionally for those wishing to make cross-platform patches) but should know about the text's actual size anyway. To be continued...
cheers Miller
On Tue, Aug 24, 2010 at 01:21:08AM -0400, Hans-Christoph Steiner wrote:
On Aug 23, 2010, at 7:01 AM, Frank Barknecht wrote:
> Hi, > > On Sat, Aug 21, 2010 at 01:39:08PM -0400, Mathieu Bouchard
> wrote: >> BTW I've been using Pd-Extended's Linux/OSX default font >> size as the >> basis for all my patches for making my last 400 patches or so. > > I've used Pd vanilla for all my patches so far, with a > "10" font-size, > whatever that is in pixels. I know, that Pd-extended uses some > different > layout for several years now, which makes patches look > wrong when you > load them in Pd vanilla and the other way around. I have not
> much > interest to discuss the differences between vanilla and > Pd-x, as I am > hoping the two to unify again with the gui-rewrite. So I'm > willing to > change my preferences to whatever will be the new vanilla, but
> I'd > prefer to not do again that with every release or with every new > Courier-like font that pops up on the Internets' Top 10 > console font > lists and is so much better than the previous ones.Unless Miller changes it in the future, Pd 0.43 should have the same boxes sizes that Pd-extended has had for a couple versions. That was one of my goals with the GUI rewrite. Its a bug if that's
not the case..hc
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Programs should be written for people to read, and only incidentally for machines to execute.
- from Structure and Interpretation of Computer Programs
"It is convenient to imagine a power beyond us because that means we
don't have to examine our own lives.", from "The Idols of
Environmentalism", by Curtis White
I'm going to try adding height measurement code right now and see what
happens. My guess is that the font will fit in the boxes, butlook a
little small sometimes, and therefore be slightly out of alignment in
terms of cursor clicks.
.hc
On Aug 26, 2010, at 2:43 PM, Miller Puckette wrote:
OK.. but for 0.43... is there a stopgap? I can't think of any way to get text editing working (i.e., getting the character you click on to be the one Pd sees you click on) except by going back to status quo.
cheers MIller
On Thu, Aug 26, 2010 at 01:54:15PM -0400, Hans-Christoph Steiner
wrote:On Aug 26, 2010, at 12:52 AM, Miller Puckette wrote:
My machine is running 8.5... but I don't think it's good to have Pd's default font choice come out all wrong... ideally, it should do something reasonable no matter what the font (well, at least if it's fixed-pitch). At the very least, Pd has to know the correct font metrics... and it seems now not to.
I should add, given my experience, I don't think this is a realistic goal without major surgery. Its something I've put a lot of work into trying to get working. My experience tells me that the best bet is using a default font.
Even better would be making the pd <--> pd-gui communication not deal with pixel values and mouse motion, but instead logical operations. For example, instead of pd knowing anything about the text editing operation, that should happen entirely in the gui. Then once the editing operation is complete, the GUI would send the result to pd.
.hc
Perhaps a solution for cross-platform patching (such as for making help files) could be to say "this will look woerd on other machines
unless you use font <blaz> to develope the patch so that you see the canonical sizes.cheers M
On Wed, Aug 25, 2010 at 04:18:49PM -0400, Hans-Christoph Steiner wrote:
Here is the answer to this font problem:
- use Tcl/Tk 8.5 or newer, Tcl 8.4 is very flawed (see archives for
discussion, basically it makes bad guesses and assigns them to the fontname "courier")
- use one of these fonts: {"Courier 10 Pitch" "DejaVu Sans Mono"
"Bitstream Vera Sans Mono" "Droid Sans Mono" "Andale Mono"Anything else and you'll have strange results. In order to have better font support, we need to do some major surgery.
.hc
On Tue, 2010-08-24 at 13:38 -0700, Miller Puckette wrote:
Long as there's a way to fix a problem I'm having: in message boxes with many lines of text, you can easily click on one character and select one above it... it gets very confusing. (Fedora 13 out-of-box).
I'm guessing that in the current version the GUI simply tells Pd what size the font ought to have had instead of the genuine one. Pd could easily expand the box to the ought-to size (at least optionally for those wishing to make cross-platform patches) but should know about the text's actual size anyway. To be continued...
cheers Miller
On Tue, Aug 24, 2010 at 01:21:08AM -0400, Hans-Christoph Steiner wrote:
On Aug 23, 2010, at 7:01 AM, Frank Barknecht wrote:
> Hi, > > On Sat, Aug 21, 2010 at 01:39:08PM -0400, Mathieu Bouchard
> wrote: >> BTW I've been using Pd-Extended's Linux/OSX default font >> size as the >> basis for all my patches for making my last 400 patches or so. > > I've used Pd vanilla for all my patches so far, with a > "10" font-size, > whatever that is in pixels. I know, that Pd-extended uses some > different > layout for several years now, which makes patches look > wrong when you > load them in Pd vanilla and the other way around. I have not
> much > interest to discuss the differences between vanilla and > Pd-x, as I am > hoping the two to unify again with the gui-rewrite. So I'm > willing to > change my preferences to whatever will be the new vanilla, but
> I'd > prefer to not do again that with every release or with every new > Courier-like font that pops up on the Internets' Top 10 > console font > lists and is so much better than the previous ones.Unless Miller changes it in the future, Pd 0.43 should have the same boxes sizes that Pd-extended has had for a couple versions. That was one of my goals with the GUI rewrite. Its a bug if that's
not the case..hc
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Programs should be written for people to read, and only incidentally for machines to execute.
- from Structure and Interpretation of Computer Programs
As we enjoy great advantages from inventions of others, we should be
glad of an opportunity to serve others by any invention of ours; and
this we should do freely and generously. - Benjamin Franklin
Looks like here are the options:
- have boxes fit around fixed font sizes and have different box sizes
on each platform (vanilla up til 0.42)
- have font width fit into fixed box sizes and have long texts overrun
the bottom of boxes (Pd-extended since 0.40)
- hopefully the best for now, have the width, then height fit into the
fixed box sizes, and use fonts that are known to work the best. I
attached a patch which implements this and it seems to work pretty
well. I discovered that the fixed box sizes were different than Pd-
extended so I synced them up so layout should be the same everywhere.
(apply patch with "git am" to accept it as it).
.hc
On Aug 26, 2010, at 2:43 PM, Miller Puckette wrote:
OK.. but for 0.43... is there a stopgap? I can't think of any way to get text editing working (i.e., getting the character you click on to be the one Pd sees you click on) except by going back to status quo.
cheers MIller
On Thu, Aug 26, 2010 at 01:54:15PM -0400, Hans-Christoph Steiner
wrote:On Aug 26, 2010, at 12:52 AM, Miller Puckette wrote:
My machine is running 8.5... but I don't think it's good to have Pd's default font choice come out all wrong... ideally, it should do something reasonable no matter what the font (well, at least if it's fixed-pitch). At the very least, Pd has to know the correct font metrics... and it seems now not to.
I should add, given my experience, I don't think this is a realistic goal without major surgery. Its something I've put a lot of work into trying to get working. My experience tells me that the best bet is using a default font.
Even better would be making the pd <--> pd-gui communication not deal with pixel values and mouse motion, but instead logical operations. For example, instead of pd knowing anything about the text editing operation, that should happen entirely in the gui. Then once the editing operation is complete, the GUI would send the result to pd.
.hc
Perhaps a solution for cross-platform patching (such as for making help files) could be to say "this will look woerd on other machines
unless you use font <blaz> to develope the patch so that you see the canonical sizes.cheers M
On Wed, Aug 25, 2010 at 04:18:49PM -0400, Hans-Christoph Steiner wrote:
Here is the answer to this font problem:
- use Tcl/Tk 8.5 or newer, Tcl 8.4 is very flawed (see archives for
discussion, basically it makes bad guesses and assigns them to the fontname "courier")
- use one of these fonts: {"Courier 10 Pitch" "DejaVu Sans Mono"
"Bitstream Vera Sans Mono" "Droid Sans Mono" "Andale Mono"Anything else and you'll have strange results. In order to have better font support, we need to do some major surgery.
.hc
On Tue, 2010-08-24 at 13:38 -0700, Miller Puckette wrote:
Long as there's a way to fix a problem I'm having: in message boxes with many lines of text, you can easily click on one character and select one above it... it gets very confusing. (Fedora 13 out-of-box).
I'm guessing that in the current version the GUI simply tells Pd what size the font ought to have had instead of the genuine one. Pd could easily expand the box to the ought-to size (at least optionally for those wishing to make cross-platform patches) but should know about the text's actual size anyway. To be continued...
cheers Miller
On Tue, Aug 24, 2010 at 01:21:08AM -0400, Hans-Christoph Steiner wrote:
On Aug 23, 2010, at 7:01 AM, Frank Barknecht wrote:
> Hi, > > On Sat, Aug 21, 2010 at 01:39:08PM -0400, Mathieu Bouchard
> wrote: >> BTW I've been using Pd-Extended's Linux/OSX default font >> size as the >> basis for all my patches for making my last 400 patches or so. > > I've used Pd vanilla for all my patches so far, with a > "10" font-size, > whatever that is in pixels. I know, that Pd-extended uses some > different > layout for several years now, which makes patches look > wrong when you > load them in Pd vanilla and the other way around. I have not
> much > interest to discuss the differences between vanilla and > Pd-x, as I am > hoping the two to unify again with the gui-rewrite. So I'm > willing to > change my preferences to whatever will be the new vanilla, but
> I'd > prefer to not do again that with every release or with every new > Courier-like font that pops up on the Internets' Top 10 > console font > lists and is so much better than the previous ones.Unless Miller changes it in the future, Pd 0.43 should have the same boxes sizes that Pd-extended has had for a couple versions. That was one of my goals with the GUI rewrite. Its a bug if that's
not the case..hc
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Programs should be written for people to read, and only incidentally for machines to execute.
- from Structure and Interpretation of Computer Programs
I have the audacity to believe that peoples everywhere can have three
meals a day for their bodies, education and culture for their minds,
and dignity, equality and freedom for their spirits. - Martin
Luther King, Jr.
Are you planning some kind of colours for some kind of 'syntax colouring' support for the boxes (message/number/audio gen/video etc.) and cords (audio non-audio)? This should be less problematic lhen the font size issue, shouldn't it?
2010/8/26 Hans-Christoph Steiner hans@at.or.at:
Looks like here are the options:
- have boxes fit around fixed font sizes and have different box sizes on
each platform (vanilla up til 0.42)
- have font width fit into fixed box sizes and have long texts overrun the
bottom of boxes (Pd-extended since 0.40)
- hopefully the best for now, have the width, then height fit into the fixed
box sizes, and use fonts that are known to work the best. I attached a patch which implements this and it seems to work pretty well. I discovered that the fixed box sizes were different than Pd-extended so I synced them up so layout should be the same everywhere.
(apply patch with "git am" to accept it as it).
.hc
On Aug 26, 2010, at 2:43 PM, Miller Puckette wrote:
OK.. but for 0.43... is there a stopgap? I can't think of any way to get text editing working (i.e., getting the character you click on to be the one Pd sees you click on) except by going back to status quo.
cheers MIller
On Thu, Aug 26, 2010 at 01:54:15PM -0400, Hans-Christoph Steiner wrote:
On Aug 26, 2010, at 12:52 AM, Miller Puckette wrote:
My machine is running 8.5... but I don't think it's good to have Pd's default font choice come out all wrong... ideally, it should do something reasonable no matter what the font (well, at least if it's fixed-pitch). At the very least, Pd has to know the correct font metrics... and it seems now not to.
I should add, given my experience, I don't think this is a realistic goal without major surgery. Its something I've put a lot of work into trying to get working. My experience tells me that the best bet is using a default font.
Even better would be making the pd <--> pd-gui communication not deal with pixel values and mouse motion, but instead logical operations. For example, instead of pd knowing anything about the text editing operation, that should happen entirely in the gui. Then once the editing operation is complete, the GUI would send the result to pd.
.hc
Perhaps a solution for cross-platform patching (such as for making help files) could be to say "this will look woerd on other machines unless you use font <blaz> to develope the patch so that you see the canonical sizes.
cheers M
On Wed, Aug 25, 2010 at 04:18:49PM -0400, Hans-Christoph Steiner wrote:
Here is the answer to this font problem:
- use Tcl/Tk 8.5 or newer, Tcl 8.4 is very flawed (see archives for
discussion, basically it makes bad guesses and assigns them to the fontname "courier")
- use one of these fonts: {"Courier 10 Pitch" "DejaVu Sans Mono" \
"Bitstream Vera Sans Mono" "Droid Sans Mono" "Andale Mono"
Anything else and you'll have strange results. In order to have better font support, we need to do some major surgery.
.hc
On Tue, 2010-08-24 at 13:38 -0700, Miller Puckette wrote:
Long as there's a way to fix a problem I'm having: in message boxes with many lines of text, you can easily click on one character and select one above it... it gets very confusing. (Fedora 13 out-of-box).
I'm guessing that in the current version the GUI simply tells Pd what size the font ought to have had instead of the genuine one. Pd could easily expand the box to the ought-to size (at least optionally for those wishing to make cross-platform patches) but should know about the text's actual size anyway. To be continued...
cheers Miller
On Tue, Aug 24, 2010 at 01:21:08AM -0400, Hans-Christoph Steiner wrote: > > On Aug 23, 2010, at 7:01 AM, Frank Barknecht wrote: > >> Hi, >> >> On Sat, Aug 21, 2010 at 01:39:08PM -0400, Mathieu Bouchard wrote: >>> >>> BTW I've been using Pd-Extended's Linux/OSX default font >>> size as the >>> basis for all my patches for making my last 400 patches or so. >> >> I've used Pd vanilla for all my patches so far, with a >> "10" font-size, >> whatever that is in pixels. I know, that Pd-extended uses some >> different >> layout for several years now, which makes patches look >> wrong when you >> load them in Pd vanilla and the other way around. I have not much >> interest to discuss the differences between vanilla and >> Pd-x, as I am >> hoping the two to unify again with the gui-rewrite. So I'm >> willing to >> change my preferences to whatever will be the new vanilla, but I'd >> prefer to not do again that with every release or with every new >> Courier-like font that pops up on the Internets' Top 10 >> console font >> lists and is so much better than the previous ones. > > > Unless Miller changes it in the future, Pd 0.43 should have > the same > boxes sizes that Pd-extended has had for a couple versions. That > was one of my goals with the GUI rewrite. Its a bug if that's not > the case. > > .hc > > > > ---------------------------------------------------------------------------- > > The arc of history bends towards justice. - Dr. Martin Luther > King, Jr. > > > > _______________________________________________ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list
Programs should be written for people to read, and only incidentally for machines to execute.
- from Structure and Interpretation of Computer Programs
I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits. - Martin Luther King, Jr.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I plan on porting the Pd-eztended color scheme to the new 0.43 code, nabe some new ideas will come out of that.
.hc
"Bernardo Barros" bernardobarros2@gmail.com wrote:
Are you planning some kind of colours for some kind of 'syntax colouring' support for the boxes (message/number/audio gen/video etc.) and cords (audio non-audio)? This should be less problematic lhen the font size issue, shouldn't it?
2010/8/26 Hans-Christoph Steiner hans@at.or.at:
Looks like here are the options:
- have boxes fit around fixed font sizes and have different box sizes on
each platform (vanilla up til 0.42)
- have font width fit into fixed box sizes and have long texts overrun the
bottom of boxes (Pd-extended since 0.40)
- hopefully the best for now, have the width, then height fit into the fixed
box sizes, and use fonts that are known to work the best. I attached a patch which implements this and it seems to work pretty well. I discovered that the fixed box sizes were different than Pd-extended so I synced them up so layout should be the same everywhere.
(apply patch with "git am" to accept it as it).
.hc
On Aug 26, 2010, at 2:43 PM, Miller Puckette wrote:
OK.. but for 0.43... is there a stopgap? I can't think of any way to get text editing working (i.e., getting the character you click on to be the one Pd sees you click on) except by going back to status quo.
cheers MIller
On Thu, Aug 26, 2010 at 01:54:15PM -0400, Hans-Christoph Steiner wrote:
On Aug 26, 2010, at 12:52 AM, Miller Puckette wrote:
My machine is running 8.5... but I don't think it's good to have Pd's default font choice come out all wrong... ideally, it should do something reasonable no matter what the font (well, at least if it's fixed-pitch). At the very least, Pd has to know the correct font metrics... and it seems now not to.
I should add, given my experience, I don't think this is a realistic goal without major surgery. Its something I've put a lot of work into trying to get working. My experience tells me that the best bet is using a default font.
Even better would be making the pd <--> pd-gui communication not deal with pixel values and mouse motion, but instead logical operations. For example, instead of pd knowing anything about the text editing operation, that should happen entirely in the gui. Then once the editing operation is complete, the GUI would send the result to pd.
.hc
Perhaps a solution for cross-platform patching (such as for making help files) could be to say "this will look woerd on other machines unless you use font <blaz> to develope the patch so that you see the canonical sizes.
cheers M
On Wed, Aug 25, 2010 at 04:18:49PM -0400, Hans-Christoph Steiner wrote:
Here is the answer to this font problem:
- use Tcl/Tk 8.5 or newer, Tcl 8.4 is very flawed (see archives for
discussion, basically it makes bad guesses and assigns them to the fontname "courier")
- use one of these fonts: {"Courier 10 Pitch" "DejaVu Sans Mono" \
"Bitstream Vera Sans Mono" "Droid Sans Mono" "Andale Mono"
Anything else and you'll have strange results. In order to have better font support, we need to do some major surgery.
.hc
On Tue, 2010-08-24 at 13:38 -0700, Miller Puckette wrote: > > Long as there's a way to fix a problem I'm having: in message > boxes with > many lines of text, you can easily click on one character and > select one above > it... it gets very confusing. (Fedora 13 out-of-box). > > I'm guessing that in the current version the GUI simply tells > Pd what size > the font ought to have had instead of the genuine one. Pd > could easily > expand the box to the ought-to size (at least optionally for > those wishing > to make cross-platform patches) but should know about the > text's actual size > anyway. To be continued... > > cheers > Miller > > On Tue, Aug 24, 2010 at 01:21:08AM -0400, Hans-Christoph > Steiner wrote: >> >> On Aug 23, 2010, at 7:01 AM, Frank Barknecht wrote: >> >>> Hi, >>> >>> On Sat, Aug 21, 2010 at 01:39:08PM -0400, Mathieu Bouchard wrote: >>>> >>>> BTW I've been using Pd-Extended's Linux/OSX default font >>>> size as the >>>> basis for all my patches for making my last 400 patches or so. >>> >>> I've used Pd vanilla for all my patches so far, with a >>> "10" font-size, >>> whatever that is in pixels. I know, that Pd-extended uses some >>> different >>> layout for several years now, which makes patches look >>> wrong when you >>> load them in Pd vanilla and the other way around. I have not much >>> interest to discuss the differences between vanilla and >>> Pd-x, as I am >>> hoping the two to unify again with the gui-rewrite. So I'm >>> willing to >>> change my preferences to whatever will be the new vanilla, but I'd >>> prefer to not do again that with every release or with every new >>> Courier-like font that pops up on the Internets' Top 10 >>> console font >>> lists and is so much better than the previous ones. >> >> >> Unless Miller changes it in the future, Pd 0.43 should have >> the same >> boxes sizes that Pd-extended has had for a couple versions. That >> was one of my goals with the GUI rewrite. Its a bug if that's not >> the case. >> >> .hc >> >> >> >> ---------------------------------------------------------------------------- >> >> The arc of history bends towards justice. - Dr. Martin Luther >> King, Jr. >> >> >> >> _______________________________________________ >> Pd-list@iem.at mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list
Programs should be written for people to read, and only incidentally for machines to execute.
- from Structure and Interpretation of Computer Programs
I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits. - Martin Luther King, Jr.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
OK... applied that one, then went in and made the tcl script report the "real" font metrics to Pd so it can draw the boxes correctly (they were still off on 2 of the font sizes in Fedora 13 and anyway I despair of ever being certain that the font sizes are exactly what Pd wished for) ... is the current git upload working on others' machines?
thanks Miller
On Thu, Aug 26, 2010 at 04:43:16PM -0400, Hans-Christoph Steiner wrote:
Looks like here are the options:
- have boxes fit around fixed font sizes and have different box
sizes on each platform (vanilla up til 0.42)
- have font width fit into fixed box sizes and have long texts
overrun the bottom of boxes (Pd-extended since 0.40)
- hopefully the best for now, have the width, then height fit into
the fixed box sizes, and use fonts that are known to work the best. I attached a patch which implements this and it seems to work pretty well. I discovered that the fixed box sizes were different than Pd-extended so I synced them up so layout should be the same everywhere.
(apply patch with "git am" to accept it as it).
.hc
On Aug 26, 2010, at 2:43 PM, Miller Puckette wrote:
OK.. but for 0.43... is there a stopgap? I can't think of any way to get text editing working (i.e., getting the character you click on to be the one Pd sees you click on) except by going back to status quo.
cheers MIller
On Thu, Aug 26, 2010 at 01:54:15PM -0400, Hans-Christoph Steiner wrote:
On Aug 26, 2010, at 12:52 AM, Miller Puckette wrote:
My machine is running 8.5... but I don't think it's good to have Pd's default font choice come out all wrong... ideally, it should do something reasonable no matter what the font (well, at least if it's fixed-pitch). At the very least, Pd has to know the correct font metrics... and it seems now not to.
I should add, given my experience, I don't think this is a realistic goal without major surgery. Its something I've put a lot of work into trying to get working. My experience tells me that the best bet is using a default font.
Even better would be making the pd <--> pd-gui communication not deal with pixel values and mouse motion, but instead logical operations. For example, instead of pd knowing anything about the text editing operation, that should happen entirely in the gui. Then once the editing operation is complete, the GUI would send the result to pd.
.hc
Perhaps a solution for cross-platform patching (such as for making help files) could be to say "this will look woerd on other machines unless you use font <blaz> to develope the patch so that you see the canonical sizes.
cheers M
On Wed, Aug 25, 2010 at 04:18:49PM -0400, Hans-Christoph Steiner wrote:
Here is the answer to this font problem:
- use Tcl/Tk 8.5 or newer, Tcl 8.4 is very flawed (see archives for
discussion, basically it makes bad guesses and assigns them to the fontname "courier")
- use one of these fonts: {"Courier 10 Pitch" "DejaVu Sans Mono"
"Bitstream Vera Sans Mono" "Droid Sans Mono" "Andale Mono"Anything else and you'll have strange results. In order to have better font support, we need to do some major surgery.
.hc
On Tue, 2010-08-24 at 13:38 -0700, Miller Puckette wrote:
Long as there's a way to fix a problem I'm having: in message boxes with many lines of text, you can easily click on one character and select one above it... it gets very confusing. (Fedora 13 out-of-box).
I'm guessing that in the current version the GUI simply tells Pd what size the font ought to have had instead of the genuine one. Pd could easily expand the box to the ought-to size (at least optionally for those wishing to make cross-platform patches) but should know about the text's actual size anyway. To be continued...
cheers Miller
On Tue, Aug 24, 2010 at 01:21:08AM -0400, Hans-Christoph Steiner wrote: > >On Aug 23, 2010, at 7:01 AM, Frank Barknecht wrote: > >>Hi, >> >>On Sat, Aug 21, 2010 at 01:39:08PM -0400, Mathieu >>Bouchard wrote: >>>BTW I've been using Pd-Extended's Linux/OSX default font >>>size as the >>>basis for all my patches for making my last 400 patches or so. >> >>I've used Pd vanilla for all my patches so far, with a >>"10" font-size, >>whatever that is in pixels. I know, that Pd-extended uses some >>different >>layout for several years now, which makes patches look >>wrong when you >>load them in Pd vanilla and the other way around. I >>have not much >>interest to discuss the differences between vanilla and >>Pd-x, as I am >>hoping the two to unify again with the gui-rewrite. So I'm >>willing to >>change my preferences to whatever will be the new >>vanilla, but I'd >>prefer to not do again that with every release or with every new >>Courier-like font that pops up on the Internets' Top 10 >>console font >>lists and is so much better than the previous ones. > > >Unless Miller changes it in the future, Pd 0.43 should have >the same >boxes sizes that Pd-extended has had for a couple versions. That >was one of my goals with the GUI rewrite. Its a bug if >that's not >the case. > >.hc > > >---------------------------------------------------------------------------- > >The arc of history bends towards justice. - Dr. Martin Luther >King, Jr. > > > >_______________________________________________ >Pd-list@iem.at mailing list >UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Programs should be written for people to read, and only incidentally for machines to execute.
- from Structure and Interpretation of Computer Programs
I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits. - Martin Luther King, Jr.
The problem is that sending the measured font sizes via pd init puts us back at square one: the boxes will be different sizes depending on platform and now depending on font. Then patch/GUI layout breaks across different platforms, and now when people use different fonts.
The least of all evils with the current implementation is having the box sizes fixed, and the fonts being a bit too small on the large box/font sizes. That is achieved by undoing the part you just added where it sends the measured sizes rather than the fixed sizes via pd init.
The only way I can see properly doing this is having the pd <--> pd-gui communication be logical not pixel-based, and have pd-gui handle all of the editing operations.
.hc
On Fri, 2010-08-27 at 22:01 -0700, Miller Puckette wrote:
OK... applied that one, then went in and made the tcl script report the "real" font metrics to Pd so it can draw the boxes correctly (they were still off on 2 of the font sizes in Fedora 13 and anyway I despair of ever being certain that the font sizes are exactly what Pd wished for) ... is the current git upload working on others' machines?
thanks Miller
On Thu, Aug 26, 2010 at 04:43:16PM -0400, Hans-Christoph Steiner wrote:
Looks like here are the options:
- have boxes fit around fixed font sizes and have different box
sizes on each platform (vanilla up til 0.42)
- have font width fit into fixed box sizes and have long texts
overrun the bottom of boxes (Pd-extended since 0.40)
- hopefully the best for now, have the width, then height fit into
the fixed box sizes, and use fonts that are known to work the best. I attached a patch which implements this and it seems to work pretty well. I discovered that the fixed box sizes were different than Pd-extended so I synced them up so layout should be the same everywhere.
(apply patch with "git am" to accept it as it).
.hc
On Aug 26, 2010, at 2:43 PM, Miller Puckette wrote:
OK.. but for 0.43... is there a stopgap? I can't think of any way to get text editing working (i.e., getting the character you click on to be the one Pd sees you click on) except by going back to status quo.
cheers MIller
On Thu, Aug 26, 2010 at 01:54:15PM -0400, Hans-Christoph Steiner wrote:
On Aug 26, 2010, at 12:52 AM, Miller Puckette wrote:
My machine is running 8.5... but I don't think it's good to have Pd's default font choice come out all wrong... ideally, it should do something reasonable no matter what the font (well, at least if it's fixed-pitch). At the very least, Pd has to know the correct font metrics... and it seems now not to.
I should add, given my experience, I don't think this is a realistic goal without major surgery. Its something I've put a lot of work into trying to get working. My experience tells me that the best bet is using a default font.
Even better would be making the pd <--> pd-gui communication not deal with pixel values and mouse motion, but instead logical operations. For example, instead of pd knowing anything about the text editing operation, that should happen entirely in the gui. Then once the editing operation is complete, the GUI would send the result to pd.
.hc
Perhaps a solution for cross-platform patching (such as for making help files) could be to say "this will look woerd on other machines unless you use font <blaz> to develope the patch so that you see the canonical sizes.
cheers M
On Wed, Aug 25, 2010 at 04:18:49PM -0400, Hans-Christoph Steiner wrote:
Here is the answer to this font problem:
- use Tcl/Tk 8.5 or newer, Tcl 8.4 is very flawed (see archives for
discussion, basically it makes bad guesses and assigns them to the fontname "courier")
- use one of these fonts: {"Courier 10 Pitch" "DejaVu Sans Mono"
"Bitstream Vera Sans Mono" "Droid Sans Mono" "Andale Mono"Anything else and you'll have strange results. In order to have better font support, we need to do some major surgery.
.hc
On Tue, 2010-08-24 at 13:38 -0700, Miller Puckette wrote: >Long as there's a way to fix a problem I'm having: in message >boxes with >many lines of text, you can easily click on one character and >select one above >it... it gets very confusing. (Fedora 13 out-of-box). > >I'm guessing that in the current version the GUI simply tells >Pd what size >the font ought to have had instead of the genuine one. Pd >could easily >expand the box to the ought-to size (at least optionally for >those wishing >to make cross-platform patches) but should know about the >text's actual size >anyway. To be continued... > >cheers >Miller > >On Tue, Aug 24, 2010 at 01:21:08AM -0400, Hans-Christoph >Steiner wrote: >> >>On Aug 23, 2010, at 7:01 AM, Frank Barknecht wrote: >> >>>Hi, >>> >>>On Sat, Aug 21, 2010 at 01:39:08PM -0400, Mathieu >>>Bouchard wrote: >>>>BTW I've been using Pd-Extended's Linux/OSX default font >>>>size as the >>>>basis for all my patches for making my last 400 patches or so. >>> >>>I've used Pd vanilla for all my patches so far, with a >>>"10" font-size, >>>whatever that is in pixels. I know, that Pd-extended uses some >>>different >>>layout for several years now, which makes patches look >>>wrong when you >>>load them in Pd vanilla and the other way around. I >>>have not much >>>interest to discuss the differences between vanilla and >>>Pd-x, as I am >>>hoping the two to unify again with the gui-rewrite. So I'm >>>willing to >>>change my preferences to whatever will be the new >>>vanilla, but I'd >>>prefer to not do again that with every release or with every new >>>Courier-like font that pops up on the Internets' Top 10 >>>console font >>>lists and is so much better than the previous ones. >> >> >>Unless Miller changes it in the future, Pd 0.43 should have >>the same >>boxes sizes that Pd-extended has had for a couple versions. That >>was one of my goals with the GUI rewrite. Its a bug if >>that's not >>the case. >> >>.hc >> >> >>---------------------------------------------------------------------------- >> >>The arc of history bends towards justice. - Dr. Martin Luther >>King, Jr. >> >> >> >>_______________________________________________ >>Pd-list@iem.at mailing list >>UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Programs should be written for people to read, and only incidentally for machines to execute.
- from Structure and Interpretation of Computer Programs
I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits. - Martin Luther King, Jr.
Or the Mathieu idea - let the text be small, the box be 'standard' size, and let the text not fill the box -- but Pd could still know the true size of the font so editing could work. Clearly we'll never be able to reliably set the font metrics and will have to play with what we're dealt, one way or another.
I'm giving up on getting this out by Sept. 1 -- there's another show-stopper bug that will take me more than 28 hrs. to fix (more confusion as to who's 'visible' versus graph on parent)
d'oh...
M
On Sun, Aug 29, 2010 at 01:45:13PM -0400, Hans-Christoph Steiner wrote:
The problem is that sending the measured font sizes via pd init puts us back at square one: the boxes will be different sizes depending on platform and now depending on font. Then patch/GUI layout breaks across different platforms, and now when people use different fonts.
The least of all evils with the current implementation is having the box sizes fixed, and the fonts being a bit too small on the large box/font sizes. That is achieved by undoing the part you just added where it sends the measured sizes rather than the fixed sizes via pd init.
The only way I can see properly doing this is having the pd <--> pd-gui communication be logical not pixel-based, and have pd-gui handle all of the editing operations.
.hc
On Fri, 2010-08-27 at 22:01 -0700, Miller Puckette wrote:
OK... applied that one, then went in and made the tcl script report the "real" font metrics to Pd so it can draw the boxes correctly (they were still off on 2 of the font sizes in Fedora 13 and anyway I despair of ever being certain that the font sizes are exactly what Pd wished for) ... is the current git upload working on others' machines?
thanks Miller
On Thu, Aug 26, 2010 at 04:43:16PM -0400, Hans-Christoph Steiner wrote:
Looks like here are the options:
- have boxes fit around fixed font sizes and have different box
sizes on each platform (vanilla up til 0.42)
- have font width fit into fixed box sizes and have long texts
overrun the bottom of boxes (Pd-extended since 0.40)
- hopefully the best for now, have the width, then height fit into
the fixed box sizes, and use fonts that are known to work the best. I attached a patch which implements this and it seems to work pretty well. I discovered that the fixed box sizes were different than Pd-extended so I synced them up so layout should be the same everywhere.
(apply patch with "git am" to accept it as it).
.hc
On Aug 26, 2010, at 2:43 PM, Miller Puckette wrote:
OK.. but for 0.43... is there a stopgap? I can't think of any way to get text editing working (i.e., getting the character you click on to be the one Pd sees you click on) except by going back to status quo.
cheers MIller
On Thu, Aug 26, 2010 at 01:54:15PM -0400, Hans-Christoph Steiner wrote:
On Aug 26, 2010, at 12:52 AM, Miller Puckette wrote:
My machine is running 8.5... but I don't think it's good to have Pd's default font choice come out all wrong... ideally, it should do something reasonable no matter what the font (well, at least if it's fixed-pitch). At the very least, Pd has to know the correct font metrics... and it seems now not to.
I should add, given my experience, I don't think this is a realistic goal without major surgery. Its something I've put a lot of work into trying to get working. My experience tells me that the best bet is using a default font.
Even better would be making the pd <--> pd-gui communication not deal with pixel values and mouse motion, but instead logical operations. For example, instead of pd knowing anything about the text editing operation, that should happen entirely in the gui. Then once the editing operation is complete, the GUI would send the result to pd.
.hc
Perhaps a solution for cross-platform patching (such as for making help files) could be to say "this will look woerd on other machines unless you use font <blaz> to develope the patch so that you see the canonical sizes.
cheers M
On Wed, Aug 25, 2010 at 04:18:49PM -0400, Hans-Christoph Steiner wrote: > >Here is the answer to this font problem: > >- use Tcl/Tk 8.5 or newer, Tcl 8.4 is very flawed (see archives for >discussion, basically it makes bad guesses and assigns them to the >fontname "courier") > >- use one of these fonts: {"Courier 10 Pitch" "DejaVu Sans Mono"
> "Bitstream Vera Sans Mono" "Droid Sans Mono" "Andale Mono" > >Anything else and you'll have strange results. In order to have >better >font support, we need to do some major surgery. > >.hc > >On Tue, 2010-08-24 at 13:38 -0700, Miller Puckette wrote: >>Long as there's a way to fix a problem I'm having: in message >>boxes with >>many lines of text, you can easily click on one character and >>select one above >>it... it gets very confusing. (Fedora 13 out-of-box). >> >>I'm guessing that in the current version the GUI simply tells >>Pd what size >>the font ought to have had instead of the genuine one. Pd >>could easily >>expand the box to the ought-to size (at least optionally for >>those wishing >>to make cross-platform patches) but should know about the >>text's actual size >>anyway. To be continued... >> >>cheers >>Miller >> >>On Tue, Aug 24, 2010 at 01:21:08AM -0400, Hans-Christoph >>Steiner wrote: >>> >>>On Aug 23, 2010, at 7:01 AM, Frank Barknecht wrote: >>> >>>>Hi, >>>> >>>>On Sat, Aug 21, 2010 at 01:39:08PM -0400, Mathieu >>>>Bouchard wrote: >>>>>BTW I've been using Pd-Extended's Linux/OSX default font >>>>>size as the >>>>>basis for all my patches for making my last 400 patches or so. >>>> >>>>I've used Pd vanilla for all my patches so far, with a >>>>"10" font-size, >>>>whatever that is in pixels. I know, that Pd-extended uses some >>>>different >>>>layout for several years now, which makes patches look >>>>wrong when you >>>>load them in Pd vanilla and the other way around. I >>>>have not much >>>>interest to discuss the differences between vanilla and >>>>Pd-x, as I am >>>>hoping the two to unify again with the gui-rewrite. So I'm >>>>willing to >>>>change my preferences to whatever will be the new >>>>vanilla, but I'd >>>>prefer to not do again that with every release or with every new >>>>Courier-like font that pops up on the Internets' Top 10 >>>>console font >>>>lists and is so much better than the previous ones. >>> >>> >>>Unless Miller changes it in the future, Pd 0.43 should have >>>the same >>>boxes sizes that Pd-extended has had for a couple versions. That >>>was one of my goals with the GUI rewrite. Its a bug if >>>that's not >>>the case. >>> >>>.hc >>> >>> >>>---------------------------------------------------------------------------- >>> >>>The arc of history bends towards justice. - Dr. Martin Luther >>>King, Jr. >>> >>> >>> >>>_______________________________________________ >>>Pd-list@iem.at mailing list >>>UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list > >
Programs should be written for people to read, and only incidentally for machines to execute.
- from Structure and Interpretation of Computer Programs
I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits. - Martin Luther King, Jr.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Sun, 2010-08-29 at 21:17 -0700, Miller Puckette wrote:
Or the Mathieu idea - let the text be small, the box be 'standard' size, and let the text not fill the box -- but Pd could still know the true size of the font so editing could work. Clearly we'll never be able to reliably set the font metrics and will have to play with what we're dealt, one way or another.
IMHO, I think it would be a fair amount of work to implement Matju's idea, and that time would be better spent on other things. But I wouldn't object to someone doing that.
I'm giving up on getting this out by Sept. 1 -- there's another show-stopper bug that will take me more than 28 hrs. to fix (more confusion as to who's 'visible' versus graph on parent)
d'oh...
Is this the bug I filed in the tracker? I took a look, but I still haven't made sense of all the GOP code so I didn't get far.
donecanvasdialog stops arrays from redrawing until reload http://sourceforge.net/tracker/?func=detail&aid=3052388&group_id=557...
.hc
M
On Sun, Aug 29, 2010 at 01:45:13PM -0400, Hans-Christoph Steiner wrote:
The problem is that sending the measured font sizes via pd init puts us back at square one: the boxes will be different sizes depending on platform and now depending on font. Then patch/GUI layout breaks across different platforms, and now when people use different fonts.
The least of all evils with the current implementation is having the box sizes fixed, and the fonts being a bit too small on the large box/font sizes. That is achieved by undoing the part you just added where it sends the measured sizes rather than the fixed sizes via pd init.
The only way I can see properly doing this is having the pd <--> pd-gui communication be logical not pixel-based, and have pd-gui handle all of the editing operations.
.hc
On Fri, 2010-08-27 at 22:01 -0700, Miller Puckette wrote:
OK... applied that one, then went in and made the tcl script report the "real" font metrics to Pd so it can draw the boxes correctly (they were still off on 2 of the font sizes in Fedora 13 and anyway I despair of ever being certain that the font sizes are exactly what Pd wished for) ... is the current git upload working on others' machines?
thanks Miller
On Thu, Aug 26, 2010 at 04:43:16PM -0400, Hans-Christoph Steiner wrote:
Looks like here are the options:
- have boxes fit around fixed font sizes and have different box
sizes on each platform (vanilla up til 0.42)
- have font width fit into fixed box sizes and have long texts
overrun the bottom of boxes (Pd-extended since 0.40)
- hopefully the best for now, have the width, then height fit into
the fixed box sizes, and use fonts that are known to work the best. I attached a patch which implements this and it seems to work pretty well. I discovered that the fixed box sizes were different than Pd-extended so I synced them up so layout should be the same everywhere.
(apply patch with "git am" to accept it as it).
.hc
On Aug 26, 2010, at 2:43 PM, Miller Puckette wrote:
OK.. but for 0.43... is there a stopgap? I can't think of any way to get text editing working (i.e., getting the character you click on to be the one Pd sees you click on) except by going back to status quo.
cheers MIller
On Thu, Aug 26, 2010 at 01:54:15PM -0400, Hans-Christoph Steiner wrote:
On Aug 26, 2010, at 12:52 AM, Miller Puckette wrote:
>My machine is running 8.5... but I don't think it's good to have >Pd's default font choice come out all wrong... ideally, it should do >something reasonable no matter what the font (well, at least if it's >fixed-pitch). At the very least, Pd has to know the correct font >metrics... and it seems now not to.
I should add, given my experience, I don't think this is a realistic goal without major surgery. Its something I've put a lot of work into trying to get working. My experience tells me that the best bet is using a default font.
Even better would be making the pd <--> pd-gui communication not deal with pixel values and mouse motion, but instead logical operations. For example, instead of pd knowing anything about the text editing operation, that should happen entirely in the gui. Then once the editing operation is complete, the GUI would send the result to pd.
.hc
>Perhaps a solution for cross-platform patching (such as for making >help >files) could be to say "this will look woerd on other machines >unless >you use font <blaz> to develope the patch so that you see the >canonical >sizes. > >cheers >M > >On Wed, Aug 25, 2010 at 04:18:49PM -0400, Hans-Christoph Steiner >wrote: >> >>Here is the answer to this font problem: >> >>- use Tcl/Tk 8.5 or newer, Tcl 8.4 is very flawed (see archives for >>discussion, basically it makes bad guesses and assigns them to the >>fontname "courier") >> >>- use one of these fonts: {"Courier 10 Pitch" "DejaVu Sans Mono"
>> "Bitstream Vera Sans Mono" "Droid Sans Mono" "Andale Mono" >> >>Anything else and you'll have strange results. In order to have >>better >>font support, we need to do some major surgery. >> >>.hc >> >>On Tue, 2010-08-24 at 13:38 -0700, Miller Puckette wrote: >>>Long as there's a way to fix a problem I'm having: in message >>>boxes with >>>many lines of text, you can easily click on one character and >>>select one above >>>it... it gets very confusing. (Fedora 13 out-of-box). >>> >>>I'm guessing that in the current version the GUI simply tells >>>Pd what size >>>the font ought to have had instead of the genuine one. Pd >>>could easily >>>expand the box to the ought-to size (at least optionally for >>>those wishing >>>to make cross-platform patches) but should know about the >>>text's actual size >>>anyway. To be continued... >>> >>>cheers >>>Miller >>> >>>On Tue, Aug 24, 2010 at 01:21:08AM -0400, Hans-Christoph >>>Steiner wrote: >>>> >>>>On Aug 23, 2010, at 7:01 AM, Frank Barknecht wrote: >>>> >>>>>Hi, >>>>> >>>>>On Sat, Aug 21, 2010 at 01:39:08PM -0400, Mathieu >>>>>Bouchard wrote: >>>>>>BTW I've been using Pd-Extended's Linux/OSX default font >>>>>>size as the >>>>>>basis for all my patches for making my last 400 patches or so. >>>>> >>>>>I've used Pd vanilla for all my patches so far, with a >>>>>"10" font-size, >>>>>whatever that is in pixels. I know, that Pd-extended uses some >>>>>different >>>>>layout for several years now, which makes patches look >>>>>wrong when you >>>>>load them in Pd vanilla and the other way around. I >>>>>have not much >>>>>interest to discuss the differences between vanilla and >>>>>Pd-x, as I am >>>>>hoping the two to unify again with the gui-rewrite. So I'm >>>>>willing to >>>>>change my preferences to whatever will be the new >>>>>vanilla, but I'd >>>>>prefer to not do again that with every release or with every new >>>>>Courier-like font that pops up on the Internets' Top 10 >>>>>console font >>>>>lists and is so much better than the previous ones. >>>> >>>> >>>>Unless Miller changes it in the future, Pd 0.43 should have >>>>the same >>>>boxes sizes that Pd-extended has had for a couple versions. That >>>>was one of my goals with the GUI rewrite. Its a bug if >>>>that's not >>>>the case. >>>> >>>>.hc >>>> >>>> >>>>---------------------------------------------------------------------------- >>>> >>>>The arc of history bends towards justice. - Dr. Martin Luther >>>>King, Jr. >>>> >>>> >>>> >>>>_______________________________________________ >>>>Pd-list@iem.at mailing list >>>>UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list >> >>
Programs should be written for people to read, and only incidentally for machines to execute.
- from Structure and Interpretation of Computer Programs
I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits. - Martin Luther King, Jr.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Mon, Aug 30, 2010 at 06:04:55PM -0400, Hans-Christoph Steiner wrote:
On Sun, 2010-08-29 at 21:17 -0700, Miller Puckette wrote:
Or the Mathieu idea - let the text be small, the box be 'standard' size, and let the text not fill the box -- but Pd could still know the true size of the font so editing could work. Clearly we'll never be able to reliably set the font metrics and will have to play with what we're dealt, one way or another.
IMHO, I think it would be a fair amount of work to implement Matju's idea, and that time would be better spent on other things. But I wouldn't object to someone doing that.
Maybe I'm not seeing something but I think I can code it in 1/2 hour... just not right now while I'm getting ready to travel.
I'm giving up on getting this out by Sept. 1 -- there's another show-stopper bug that will take me more than 28 hrs. to fix (more confusion as to who's 'visible' versus graph on parent)
d'oh...
Is this the bug I filed in the tracker? I took a look, but I still haven't made sense of all the GOP code so I didn't get far.
donecanvasdialog stops arrays from redrawing until reload http://sourceforge.net/tracker/?func=detail&aid=3052388&group_id=557...
Not sure. It's a whole complex of bugginess that has to do with the order in which things are drawn and erased, that I had sort of swept under the rug for 0.42 but which came bounding back when i 'fixed' SF patch 2913280 (at least I think that's where it's coming from). fun fun...
.hc
M
On Sun, Aug 29, 2010 at 01:45:13PM -0400, Hans-Christoph Steiner wrote:
The problem is that sending the measured font sizes via pd init puts us back at square one: the boxes will be different sizes depending on platform and now depending on font. Then patch/GUI layout breaks across different platforms, and now when people use different fonts.
The least of all evils with the current implementation is having the box sizes fixed, and the fonts being a bit too small on the large box/font sizes. That is achieved by undoing the part you just added where it sends the measured sizes rather than the fixed sizes via pd init.
The only way I can see properly doing this is having the pd <--> pd-gui communication be logical not pixel-based, and have pd-gui handle all of the editing operations.
.hc
On Fri, 2010-08-27 at 22:01 -0700, Miller Puckette wrote:
OK... applied that one, then went in and made the tcl script report the "real" font metrics to Pd so it can draw the boxes correctly (they were still off on 2 of the font sizes in Fedora 13 and anyway I despair of ever being certain that the font sizes are exactly what Pd wished for) ... is the current git upload working on others' machines?
thanks Miller
On Thu, Aug 26, 2010 at 04:43:16PM -0400, Hans-Christoph Steiner wrote:
Looks like here are the options:
- have boxes fit around fixed font sizes and have different box
sizes on each platform (vanilla up til 0.42)
- have font width fit into fixed box sizes and have long texts
overrun the bottom of boxes (Pd-extended since 0.40)
- hopefully the best for now, have the width, then height fit into
the fixed box sizes, and use fonts that are known to work the best. I attached a patch which implements this and it seems to work pretty well. I discovered that the fixed box sizes were different than Pd-extended so I synced them up so layout should be the same everywhere.
(apply patch with "git am" to accept it as it).
.hc
On Aug 26, 2010, at 2:43 PM, Miller Puckette wrote:
OK.. but for 0.43... is there a stopgap? I can't think of any way to get text editing working (i.e., getting the character you click on to be the one Pd sees you click on) except by going back to status quo.
cheers MIller
On Thu, Aug 26, 2010 at 01:54:15PM -0400, Hans-Christoph Steiner wrote: > >On Aug 26, 2010, at 12:52 AM, Miller Puckette wrote: > >>My machine is running 8.5... but I don't think it's good to have >>Pd's default font choice come out all wrong... ideally, it should do >>something reasonable no matter what the font (well, at least if it's >>fixed-pitch). At the very least, Pd has to know the correct font >>metrics... and it seems now not to. > >I should add, given my experience, I don't think this is a realistic >goal without major surgery. Its something I've put a lot of work >into trying to get working. My experience tells me that the best >bet is using a default font. > >Even better would be making the pd <--> pd-gui communication not >deal with pixel values and mouse motion, but instead logical >operations. For example, instead of pd knowing anything about the >text editing operation, that should happen entirely in the gui. >Then once the editing operation is complete, the GUI would send the >result to pd. > >.hc > >>Perhaps a solution for cross-platform patching (such as for making >>help >>files) could be to say "this will look woerd on other machines >>unless >>you use font <blaz> to develope the patch so that you see the >>canonical >>sizes. >> >>cheers >>M >> >>On Wed, Aug 25, 2010 at 04:18:49PM -0400, Hans-Christoph Steiner >>wrote: >>> >>>Here is the answer to this font problem: >>> >>>- use Tcl/Tk 8.5 or newer, Tcl 8.4 is very flawed (see archives for >>>discussion, basically it makes bad guesses and assigns them to the >>>fontname "courier") >>> >>>- use one of these fonts: {"Courier 10 Pitch" "DejaVu Sans Mono"
>>> "Bitstream Vera Sans Mono" "Droid Sans Mono" "Andale Mono" >>> >>>Anything else and you'll have strange results. In order to have >>>better >>>font support, we need to do some major surgery. >>> >>>.hc >>> >>>On Tue, 2010-08-24 at 13:38 -0700, Miller Puckette wrote: >>>>Long as there's a way to fix a problem I'm having: in message >>>>boxes with >>>>many lines of text, you can easily click on one character and >>>>select one above >>>>it... it gets very confusing. (Fedora 13 out-of-box). >>>> >>>>I'm guessing that in the current version the GUI simply tells >>>>Pd what size >>>>the font ought to have had instead of the genuine one. Pd >>>>could easily >>>>expand the box to the ought-to size (at least optionally for >>>>those wishing >>>>to make cross-platform patches) but should know about the >>>>text's actual size >>>>anyway. To be continued... >>>> >>>>cheers >>>>Miller >>>> >>>>On Tue, Aug 24, 2010 at 01:21:08AM -0400, Hans-Christoph >>>>Steiner wrote: >>>>> >>>>>On Aug 23, 2010, at 7:01 AM, Frank Barknecht wrote: >>>>> >>>>>>Hi, >>>>>> >>>>>>On Sat, Aug 21, 2010 at 01:39:08PM -0400, Mathieu >>>>>>Bouchard wrote: >>>>>>>BTW I've been using Pd-Extended's Linux/OSX default font >>>>>>>size as the >>>>>>>basis for all my patches for making my last 400 patches or so. >>>>>> >>>>>>I've used Pd vanilla for all my patches so far, with a >>>>>>"10" font-size, >>>>>>whatever that is in pixels. I know, that Pd-extended uses some >>>>>>different >>>>>>layout for several years now, which makes patches look >>>>>>wrong when you >>>>>>load them in Pd vanilla and the other way around. I >>>>>>have not much >>>>>>interest to discuss the differences between vanilla and >>>>>>Pd-x, as I am >>>>>>hoping the two to unify again with the gui-rewrite. So I'm >>>>>>willing to >>>>>>change my preferences to whatever will be the new >>>>>>vanilla, but I'd >>>>>>prefer to not do again that with every release or with every new >>>>>>Courier-like font that pops up on the Internets' Top 10 >>>>>>console font >>>>>>lists and is so much better than the previous ones. >>>>> >>>>> >>>>>Unless Miller changes it in the future, Pd 0.43 should have >>>>>the same >>>>>boxes sizes that Pd-extended has had for a couple versions. That >>>>>was one of my goals with the GUI rewrite. Its a bug if >>>>>that's not >>>>>the case. >>>>> >>>>>.hc >>>>> >>>>> >>>>>---------------------------------------------------------------------------- >>>>> >>>>>The arc of history bends towards justice. - Dr. Martin Luther >>>>>King, Jr. >>>>> >>>>> >>>>> >>>>>_______________________________________________ >>>>>Pd-list@iem.at mailing list >>>>>UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list >>> >>> > > > > > >---------------------------------------------------------------------------- > >Programs should be written for people to read, and only incidentally >for machines to execute. >- from Structure and Interpretation of Computer Programs >
I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits. - Martin Luther King, Jr.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Mon, 2010-08-30 at 17:31 -0700, Miller Puckette wrote:
On Mon, Aug 30, 2010 at 06:04:55PM -0400, Hans-Christoph Steiner wrote:
On Sun, 2010-08-29 at 21:17 -0700, Miller Puckette wrote:
Or the Mathieu idea - let the text be small, the box be 'standard' size, and let the text not fill the box -- but Pd could still know the true size of the font so editing could work. Clearly we'll never be able to reliably set the font metrics and will have to play with what we're dealt, one way or another.
IMHO, I think it would be a fair amount of work to implement Matju's idea, and that time would be better spent on other things. But I wouldn't object to someone doing that.
Maybe I'm not seeing something but I think I can code it in 1/2 hour... just not right now while I'm getting ready to travel.
I'm giving up on getting this out by Sept. 1 -- there's another show-stopper bug that will take me more than 28 hrs. to fix (more confusion as to who's 'visible' versus graph on parent)
d'oh...
Is this the bug I filed in the tracker? I took a look, but I still haven't made sense of all the GOP code so I didn't get far.
donecanvasdialog stops arrays from redrawing until reload http://sourceforge.net/tracker/?func=detail&aid=3052388&group_id=557...
Not sure. It's a whole complex of bugginess that has to do with the order in which things are drawn and erased, that I had sort of swept under the rug for 0.42 but which came bounding back when i 'fixed' SF patch 2913280 (at least I think that's where it's coming from). fun fun...
I reverted patch 2913280 and tested the bug, its still there, so its something earlier that is triggering this. So something between the end of pd-gui-rewrite and this patch.
.hc
.hc
M
On Sun, Aug 29, 2010 at 01:45:13PM -0400, Hans-Christoph Steiner wrote:
The problem is that sending the measured font sizes via pd init puts us back at square one: the boxes will be different sizes depending on platform and now depending on font. Then patch/GUI layout breaks across different platforms, and now when people use different fonts.
The least of all evils with the current implementation is having the box sizes fixed, and the fonts being a bit too small on the large box/font sizes. That is achieved by undoing the part you just added where it sends the measured sizes rather than the fixed sizes via pd init.
The only way I can see properly doing this is having the pd <--> pd-gui communication be logical not pixel-based, and have pd-gui handle all of the editing operations.
.hc
On Fri, 2010-08-27 at 22:01 -0700, Miller Puckette wrote:
OK... applied that one, then went in and made the tcl script report the "real" font metrics to Pd so it can draw the boxes correctly (they were still off on 2 of the font sizes in Fedora 13 and anyway I despair of ever being certain that the font sizes are exactly what Pd wished for) ... is the current git upload working on others' machines?
thanks Miller
On Thu, Aug 26, 2010 at 04:43:16PM -0400, Hans-Christoph Steiner wrote:
Looks like here are the options:
- have boxes fit around fixed font sizes and have different box
sizes on each platform (vanilla up til 0.42)
- have font width fit into fixed box sizes and have long texts
overrun the bottom of boxes (Pd-extended since 0.40)
- hopefully the best for now, have the width, then height fit into
the fixed box sizes, and use fonts that are known to work the best. I attached a patch which implements this and it seems to work pretty well. I discovered that the fixed box sizes were different than Pd-extended so I synced them up so layout should be the same everywhere.
(apply patch with "git am" to accept it as it).
.hc
On Aug 26, 2010, at 2:43 PM, Miller Puckette wrote:
>OK.. but for 0.43... is there a stopgap? I can't think of any way to >get text editing working (i.e., getting the character you click on to >be the one Pd sees you click on) except by going back to status quo. > >cheers >MIller > >On Thu, Aug 26, 2010 at 01:54:15PM -0400, Hans-Christoph Steiner >wrote: >> >>On Aug 26, 2010, at 12:52 AM, Miller Puckette wrote: >> >>>My machine is running 8.5... but I don't think it's good to have >>>Pd's default font choice come out all wrong... ideally, it should do >>>something reasonable no matter what the font (well, at least if it's >>>fixed-pitch). At the very least, Pd has to know the correct font >>>metrics... and it seems now not to. >> >>I should add, given my experience, I don't think this is a realistic >>goal without major surgery. Its something I've put a lot of work >>into trying to get working. My experience tells me that the best >>bet is using a default font. >> >>Even better would be making the pd <--> pd-gui communication not >>deal with pixel values and mouse motion, but instead logical >>operations. For example, instead of pd knowing anything about the >>text editing operation, that should happen entirely in the gui. >>Then once the editing operation is complete, the GUI would send the >>result to pd. >> >>.hc >> >>>Perhaps a solution for cross-platform patching (such as for making >>>help >>>files) could be to say "this will look woerd on other machines >>>unless >>>you use font <blaz> to develope the patch so that you see the >>>canonical >>>sizes. >>> >>>cheers >>>M >>> >>>On Wed, Aug 25, 2010 at 04:18:49PM -0400, Hans-Christoph Steiner >>>wrote: >>>> >>>>Here is the answer to this font problem: >>>> >>>>- use Tcl/Tk 8.5 or newer, Tcl 8.4 is very flawed (see archives for >>>>discussion, basically it makes bad guesses and assigns them to the >>>>fontname "courier") >>>> >>>>- use one of these fonts: {"Courier 10 Pitch" "DejaVu Sans Mono"
>>>> "Bitstream Vera Sans Mono" "Droid Sans Mono" "Andale Mono" >>>> >>>>Anything else and you'll have strange results. In order to have >>>>better >>>>font support, we need to do some major surgery. >>>> >>>>.hc >>>> >>>>On Tue, 2010-08-24 at 13:38 -0700, Miller Puckette wrote: >>>>>Long as there's a way to fix a problem I'm having: in message >>>>>boxes with >>>>>many lines of text, you can easily click on one character and >>>>>select one above >>>>>it... it gets very confusing. (Fedora 13 out-of-box). >>>>> >>>>>I'm guessing that in the current version the GUI simply tells >>>>>Pd what size >>>>>the font ought to have had instead of the genuine one. Pd >>>>>could easily >>>>>expand the box to the ought-to size (at least optionally for >>>>>those wishing >>>>>to make cross-platform patches) but should know about the >>>>>text's actual size >>>>>anyway. To be continued... >>>>> >>>>>cheers >>>>>Miller >>>>> >>>>>On Tue, Aug 24, 2010 at 01:21:08AM -0400, Hans-Christoph >>>>>Steiner wrote: >>>>>> >>>>>>On Aug 23, 2010, at 7:01 AM, Frank Barknecht wrote: >>>>>> >>>>>>>Hi, >>>>>>> >>>>>>>On Sat, Aug 21, 2010 at 01:39:08PM -0400, Mathieu >>>>>>>Bouchard wrote: >>>>>>>>BTW I've been using Pd-Extended's Linux/OSX default font >>>>>>>>size as the >>>>>>>>basis for all my patches for making my last 400 patches or so. >>>>>>> >>>>>>>I've used Pd vanilla for all my patches so far, with a >>>>>>>"10" font-size, >>>>>>>whatever that is in pixels. I know, that Pd-extended uses some >>>>>>>different >>>>>>>layout for several years now, which makes patches look >>>>>>>wrong when you >>>>>>>load them in Pd vanilla and the other way around. I >>>>>>>have not much >>>>>>>interest to discuss the differences between vanilla and >>>>>>>Pd-x, as I am >>>>>>>hoping the two to unify again with the gui-rewrite. So I'm >>>>>>>willing to >>>>>>>change my preferences to whatever will be the new >>>>>>>vanilla, but I'd >>>>>>>prefer to not do again that with every release or with every new >>>>>>>Courier-like font that pops up on the Internets' Top 10 >>>>>>>console font >>>>>>>lists and is so much better than the previous ones. >>>>>> >>>>>> >>>>>>Unless Miller changes it in the future, Pd 0.43 should have >>>>>>the same >>>>>>boxes sizes that Pd-extended has had for a couple versions. That >>>>>>was one of my goals with the GUI rewrite. Its a bug if >>>>>>that's not >>>>>>the case. >>>>>> >>>>>>.hc >>>>>> >>>>>> >>>>>>---------------------------------------------------------------------------- >>>>>> >>>>>>The arc of history bends towards justice. - Dr. Martin Luther >>>>>>King, Jr. >>>>>> >>>>>> >>>>>> >>>>>>_______________________________________________ >>>>>>Pd-list@iem.at mailing list >>>>>>UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list >>>> >>>> >> >> >> >> >> >>---------------------------------------------------------------------------- >> >>Programs should be written for people to read, and only incidentally >>for machines to execute. >>- from Structure and Interpretation of Computer Programs >>
I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits. - Martin Luther King, Jr.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Bernardo Barros -
cyrille henry -
Frank Barknecht -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Jack -
Mathieu Bouchard -
Miller Puckette -
Roman Haefeli