hi,
started to experiment with fonts under tk, and while reading the tk manual, i found this:
http://www.tcl.tk/man/tcl8.5/TkCmd/tk.htm#M7 "tk scaling ?-displayof window? ?number? Sets and queries the current scaling factor used by Tk to convert between physical units (for example, points, inches, or millimeters) and pixels. The number argument is a floating point number that specifies the number of pixels per point on window's display. If the window argument is omitted, it defaults to the main window. If the number argument is omitted, the current value of the scaling factor is returned. A ``point'' is a unit of measurement equal to 1/72 inch. A scaling factor of 1.0 corresponds to 1 pixel per point, which is equivalent to a standard 72 dpi monitor. A scaling factor of 1.25 would mean 1.25 pixels per point, which is the setting for a 90 dpi monitor; setting the scaling factor to 1.25 on a 72 dpi monitor would cause everything in the application to be displayed 1.25 times as large as normal. The initial value for the scaling factor is set when the application starts, based on properties of the installed monitor, but it can be changed at any time. Measurements made after the scaling factor is changed will use the new scaling factor, but it is undefined whether existing widgets will resize themselves dynamically to accomodate the new scaling factor."
wouldnt this mean that we could do pixel accurate, measurements and finetuning (calibration) on the client to get the desired font size ?
i made a test and added "tk scaling 1.5" in the beginning of "pd.tk" made a test pacth with all gui objects having font size 10... but it seems to affect only labels, and nmb2 : http://osku.de/allgui.png
well, didnt find out how to get it work with the other gui stuff (and im tired), so i desided to ask before i continue my... quest :)
font agent ;) andre "oskude" schmidt
ps. attached is that allgui.pd pss. pd is devel 0.39-1test1
Hallo, Andre Schmidt hat gesagt: // Andre Schmidt wrote:
started to experiment with fonts under tk, and while reading the tk manual, i found this:
i made a test and added "tk scaling 1.5" in the beginning of "pd.tk" made a test pacth with all gui objects having font size 10... but it seems to affect only labels, and nmb2 : http://osku.de/allgui.png
Hm, here are two Linux screenshots: no-scaling.png is the default, 1.5-scaling.png is with "tk scaling 1.5" as first line in pd.tk. Note that I used fontsize 8 in the IEM guis.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Nov 22, 2005, at 8:46 PM, Frank Barknecht wrote:
Hallo, Andre Schmidt hat gesagt: // Andre Schmidt wrote:
started to experiment with fonts under tk, and while reading the tk manual, i found this:
i made a test and added "tk scaling 1.5" in the beginning of "pd.tk" made a test pacth with all gui objects having font size 10... but it seems to affect only labels, and nmb2 :
http://osku.de/allgui.pngHm, here are two Linux screenshots: no-scaling.png is the default, 1.5-scaling.png is with "tk scaling 1.5" as first line in pd.tk. Note that I used fontsize 8 in the IEM guis.
Arg, so close yet so far. Looks like it only affects the fonts in GUIs.
If everything worked with tk scaling, that would be amazing. It would
make a nice thing to have as a preference.
.hc
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__ <no-scaling.png><1.5- scaling.png>_______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
There is no way to peace, peace is the way.
-A.J. Muste
does this mean the "objects" where tk scaling does not affect, arent made with "tk" ?
and if tk scaling doesnt work, me thinks theres something "wrong" in pd "coding"... ;)
i mean, tk scaling _IS_ what we want. no ?
.andre
On Wed, 2005-11-23 at 00:45 -0500, Hans-Christoph Steiner wrote:
On Nov 22, 2005, at 8:46 PM, Frank Barknecht wrote:
Hallo, Andre Schmidt hat gesagt: // Andre Schmidt wrote:
started to experiment with fonts under tk, and while reading the tk manual, i found this:
i made a test and added "tk scaling 1.5" in the beginning of "pd.tk" made a test pacth with all gui objects having font size 10... but it seems to affect only labels, and nmb2 :
http://osku.de/allgui.pngHm, here are two Linux screenshots: no-scaling.png is the default, 1.5-scaling.png is with "tk scaling 1.5" as first line in pd.tk. Note that I used fontsize 8 in the IEM guis.
Arg, so close yet so far. Looks like it only affects the fonts in GUIs.
If everything worked with tk scaling, that would be amazing. It would
make a nice thing to have as a preference..hc
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__ <no-scaling.png><1.5- scaling.png>_______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
There is no way to peace, peace is the way. -A.J. Muste
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Sounds like tk scaling is what we want, but I don't know enough about
Tk to say why it only works on the fonts.
.hc
On Nov 23, 2005, at 7:39 AM, Andre Schmidt wrote:
does this mean the "objects" where tk scaling does not affect, arent made with "tk" ?
and if tk scaling doesnt work, me thinks theres something "wrong" in pd "coding"... ;)
i mean, tk scaling _IS_ what we want. no ?
.andre
On Wed, 2005-11-23 at 00:45 -0500, Hans-Christoph Steiner wrote:
On Nov 22, 2005, at 8:46 PM, Frank Barknecht wrote:
Hallo, Andre Schmidt hat gesagt: // Andre Schmidt wrote:
started to experiment with fonts under tk, and while reading the tk manual, i found this:
i made a test and added "tk scaling 1.5" in the beginning of "pd.tk" made a test pacth with all gui objects having font size 10... but it seems to affect only labels, and nmb2 : http://osku.de/allgui.png
Hm, here are two Linux screenshots: no-scaling.png is the default, 1.5-scaling.png is with "tk scaling 1.5" as first line in pd.tk. Note that I used fontsize 8 in the IEM guis.
Arg, so close yet so far. Looks like it only affects the fonts in
GUIs.If everything worked with tk scaling, that would be amazing. It would make a nice thing to have as a preference.
.hc
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__ <no-scaling.png><1.5- scaling.png>_______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
__ ____
There is no way to peace, peace is the way. -A.J. Muste
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
¡El pueblo unido jamás será vencido!
On Wed, 23 Nov 2005, Andre Schmidt wrote:
http://www.tcl.tk/man/tcl8.5/TkCmd/tk.htm#M7 "tk scaling ?-displayof window? ?number?
[...]
wouldnt this mean that we could do pixel accurate, measurements and finetuning (calibration) on the client to get the desired font size ?
This only applies to distances not specified in pixels.
i made a test and added "tk scaling 1.5" in the beginning of "pd.tk" made a test pacth with all gui objects having font size 10... but it seems to affect only labels, and nmb2 : http://osku.de/allgui.png
So now you know which are the things currently specified in pixels... that is, almost everything. I don't think "tk scaling" will help us.
Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada
On Nov 26, 2005, at 1:03 PM, Mathieu Bouchard wrote:
On Wed, 23 Nov 2005, Andre Schmidt wrote:
http://www.tcl.tk/man/tcl8.5/TkCmd/tk.htm#M7 "tk scaling ?-displayof window? ?number?
[...]
wouldnt this mean that we could do pixel accurate, measurements and finetuning (calibration) on the client to get the desired font size ?
This only applies to distances not specified in pixels.
i made a test and added "tk scaling 1.5" in the beginning of "pd.tk" made a test pacth with all gui objects having font size 10... but it seems to affect only labels, and nmb2 : http://osku.de/allgui.png
So now you know which are the things currently specified in pixels...
that is, almost everything. I don't think "tk scaling" will help us.
So that means that the comment font is being specified in pixels
somewhere. That is something that I don't remmeber seeing at all.
AFAIK, all of the font definitions in pd.tk/u_main.tk using point
numbers. Where are the point numbers being converted into pixels?
.hc
There is no way to peace, peace is the way.
-A.J. Muste
Well, they're given to TK as "points", but then in s_main.c, a setup routine, glob_initfromgui(), actually searches through the fonts for those closest to the desired _pixel_ size. At tha time I believe TK had no way of specifying pixel size. I'm not sure what the truth is now; you can feed TK negative "point sizes" that are supposed to generate known pixel sizes, but there are at least three dimensions to a font size and I don't know how the single number maps to them. Ugh...
Miller
On Sat, Nov 26, 2005 at 01:24:59PM -0500, Hans-Christoph Steiner wrote:
On Nov 26, 2005, at 1:03 PM, Mathieu Bouchard wrote:
On Wed, 23 Nov 2005, Andre Schmidt wrote:
http://www.tcl.tk/man/tcl8.5/TkCmd/tk.htm#M7 "tk scaling ?-displayof window? ?number?
[...]
wouldnt this mean that we could do pixel accurate, measurements and finetuning (calibration) on the client to get the desired font size ?
This only applies to distances not specified in pixels.
i made a test and added "tk scaling 1.5" in the beginning of "pd.tk" made a test pacth with all gui objects having font size 10... but it seems to affect only labels, and nmb2 : http://osku.de/allgui.png
So now you know which are the things currently specified in pixels...
that is, almost everything. I don't think "tk scaling" will help us.So that means that the comment font is being specified in pixels
somewhere. That is something that I don't remmeber seeing at all.
AFAIK, all of the font definitions in pd.tk/u_main.tk using point
numbers. Where are the point numbers being converted into pixels?.hc
There is no way to peace, peace is the way. -A.J. Muste
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi Miller,
how easy would it be to change all the point sizes in TK and then remove the C function to do the pixel conversion?
I don't see how the point size will be somehow different in aspect ratio from the pixel size?
If courier 12 is say 10pixels wide then it should be identical to courier -10 visually, since the aspect *should* be the same.
Or am I misunderstanding what you mean by the "at least three dimensions to a font size"?
The font issue is really a stumbling block for trying to make anything look constant accross platforms. The current PD documentation is a great example of this, where, depending on the platform, many help-patches open with overlapping messages/comments. :(
Will you be able to attend the next PD documentation meeting on tuesday the 29th of November?
.b.
Miller Puckette wrote:
Well, they're given to TK as "points", but then in s_main.c, a setup routine, glob_initfromgui(), actually searches through the fonts for those closest to the desired _pixel_ size. At tha time I believe TK had no way of specifying pixel size. I'm not sure what the truth is now; you can feed TK negative "point sizes" that are supposed to generate known pixel sizes, but there are at least three dimensions to a font size and I don't know how the single number maps to them. Ugh...
Miller
On Sat, Nov 26, 2005 at 01:24:59PM -0500, Hans-Christoph Steiner wrote:
On Nov 26, 2005, at 1:03 PM, Mathieu Bouchard wrote:
On Wed, 23 Nov 2005, Andre Schmidt wrote:
http://www.tcl.tk/man/tcl8.5/TkCmd/tk.htm#M7 "tk scaling ?-displayof window? ?number?
[...]
wouldnt this mean that we could do pixel accurate, measurements and finetuning (calibration) on the client to get the desired font size ?
This only applies to distances not specified in pixels.
i made a test and added "tk scaling 1.5" in the beginning of "pd.tk" made a test pacth with all gui objects having font size 10... but it seems to affect only labels, and nmb2 : http://osku.de/allgui.png
So now you know which are the things currently specified in pixels... that is, almost everything. I don't think "tk scaling" will help us.
So that means that the comment font is being specified in pixels somewhere. That is something that I don't remmeber seeing at all. AFAIK, all of the font definitions in pd.tk/u_main.tk using point numbers. Where are the point numbers being converted into pixels?
.hc
There is no way to peace, peace is the way. -A.J. Muste
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 don't see how the point size will be somehow different in aspect ratio from the pixel size?
why point/pixel sizes at all? for years the way to specify a font size for web is in "em" units. 1.0em 0.8em etc..
If courier 12 is say 10pixels wide then it should be identical to courier -10 visually, since the aspect *should* be the same.
even a 12 point font can be different on the same platform depending on which DPI you launched your X server at, which toolkit you are using, etc..
Or am I misunderstanding what you mean by the "at least three dimensions to a font size"?
id say theres at least 4... platform, dpi, font, fontsize
The font issue is really a stumbling block for trying to make anything look constant accross platforms. The current PD documentation is a great example of this, where, depending on the platform, many help-patches open with overlapping messages/comments. :(
how about a scalable canvas with a client-side algo to make sure nothing overlaps? something like http://whats-your.name/pd/chokun.png but with less ugly colours?
I think I found something: if you change the fontspec from Xwindows
style ( -*-courier-bold--normal--10-) to standard Tk style { courier 10
bold }, then it looks like the fonts are the same size on MacOSX and
Windows. But then, the only problem is that the object boxes don't
adjust, and are too short for the object text.
It actually swings it the other way, with the same font being bigger on
Windows than on OSX.
.hc
On Nov 26, 2005, at 3:37 PM, carmen wrote:
I don't see how the point size will be somehow different in aspect
ratio from the pixel size?why point/pixel sizes at all? for years the way to specify a font size
for web is in "em" units. 1.0em 0.8em etc..If courier 12 is say 10pixels wide then it should be identical to courier -10 visually, since the aspect *should* be the same.
even a 12 point font can be different on the same platform depending
on which DPI you launched your X server at, which toolkit you are
using, etc..Or am I misunderstanding what you mean by the "at least three
dimensions to a font size"?id say theres at least 4... platform, dpi, font, fontsize
The font issue is really a stumbling block for trying to make anything look constant accross platforms. The current PD documentation is a
great example of this, where, depending on the platform, many help-patches open with overlapping messages/comments. :(how about a scalable canvas with a client-side algo to make sure
nothing overlaps? something like http://whats-your.name/pd/chokun.png
but with less ugly colours?
PD-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
There is no way to peace, peace is the way.
-A.J. Muste
hmmm, and did you try with the -10 pixel based font size?
if the pixel (width) of the font is known then it would be easy to scale the object box based on the number of characters/spaces.
Is that how this how it works now Miller?
Should be easy to adapt that code to work with a consistant font.
Good work Hans!
b.
Hans-Christoph Steiner wrote:
I think I found something: if you change the fontspec from Xwindows style ( -*-courier-bold--normal--10-) to standard Tk style { courier 10 bold }, then it looks like the fonts are the same size on MacOSX and Windows. But then, the only problem is that the object boxes don't adjust, and are too short for the object text.
It actually swings it the other way, with the same font being bigger on Windows than on OSX.
.hc
On Nov 26, 2005, at 3:37 PM, carmen wrote:
I don't see how the point size will be somehow different in aspect ratio from the pixel size?
why point/pixel sizes at all? for years the way to specify a font size for web is in "em" units. 1.0em 0.8em etc..
If courier 12 is say 10pixels wide then it should be identical to courier -10 visually, since the aspect *should* be the same.
even a 12 point font can be different on the same platform depending on which DPI you launched your X server at, which toolkit you are using, etc..
Or am I misunderstanding what you mean by the "at least three dimensions to a font size"?
id say theres at least 4... platform, dpi, font, fontsize
The font issue is really a stumbling block for trying to make anything look constant accross platforms. The current PD documentation is a great example of this, where, depending on the platform, many help-patches open with overlapping messages/comments. :(
how about a scalable canvas with a client-side algo to make sure nothing overlaps? something like http://whats-your.name/pd/chokun.png but with less ugly colours?
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
There is no way to peace, peace is the way. -A.J. Muste
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Duh, why didn't I remember the -10 thing. Anyway, I tried that, and it
does indeed work! The font sizes are very similar in size on Windows
and Mac OS X. But now the problem is that the boxes on Mac OS X a
being created too large. I think that this shouldn't be too hard to
figure out, it might just be a matter of replacing all of the Xwindows
font specs with { courier -12 bold } Tk-style font specs.
It would be great to get this into the upcoming Pd-extended release.
.hc
On Nov 28, 2005, at 10:38 AM, B. Bogart wrote:
hmmm, and did you try with the -10 pixel based font size?
if the pixel (width) of the font is known then it would be easy to
scale the object box based on the number of characters/spaces.Is that how this how it works now Miller?
Should be easy to adapt that code to work with a consistant font.
Good work Hans!
b.
Hans-Christoph Steiner wrote:
I think I found something: if you change the fontspec from Xwindows style ( -*-courier-bold--normal--10-) to standard Tk style { courier
10 bold }, then it looks like the fonts are the same size on MacOSX and Windows. But then, the only problem is that the object boxes don't adjust, and are too short for the object text.It actually swings it the other way, with the same font being bigger
on Windows than on OSX..hc
On Nov 26, 2005, at 3:37 PM, carmen wrote:
I don't see how the point size will be somehow different in aspect ratio from the pixel size?
why point/pixel sizes at all? for years the way to specify a font size for web is in "em" units. 1.0em 0.8em etc..
If courier 12 is say 10pixels wide then it should be identical to courier -10 visually, since the aspect *should* be the same.
even a 12 point font can be different on the same platform depending on which DPI you launched your X server at, which toolkit you are using, etc..
Or am I misunderstanding what you mean by the "at least three dimensions to a font size"?
id say theres at least 4... platform, dpi, font, fontsize
The font issue is really a stumbling block for trying to make
anything look constant accross platforms. The current PD documentation is a great example of this, where, depending on the platform, many help-patches open with overlapping messages/comments. :(how about a scalable canvas with a client-side algo to make sure nothing overlaps? something like http://whats-your.name/pd/chokun.png but with less ugly colours?
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
__ ____
There is no way to peace, peace is the way. -A.J. Muste
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
http://at.or.at/hans/
Woo hoo!!!!
Miller, how does PD size object boxes?
b.
Hans-Christoph Steiner wrote:
Duh, why didn't I remember the -10 thing. Anyway, I tried that, and it does indeed work! The font sizes are very similar in size on Windows and Mac OS X. But now the problem is that the boxes on Mac OS X a being created too large. I think that this shouldn't be too hard to figure out, it might just be a matter of replacing all of the Xwindows font specs with { courier -12 bold } Tk-style font specs.
It would be great to get this into the upcoming Pd-extended release.
.hc
On Nov 28, 2005, at 10:38 AM, B. Bogart wrote:
hmmm, and did you try with the -10 pixel based font size?
if the pixel (width) of the font is known then it would be easy to scale the object box based on the number of characters/spaces.
Is that how this how it works now Miller?
Should be easy to adapt that code to work with a consistant font.
Good work Hans!
b.
Hans-Christoph Steiner wrote:
I think I found something: if you change the fontspec from Xwindows style ( -*-courier-bold--normal--10-) to standard Tk style { courier 10 bold }, then it looks like the fonts are the same size on MacOSX and Windows. But then, the only problem is that the object boxes don't adjust, and are too short for the object text.
It actually swings it the other way, with the same font being bigger on Windows than on OSX.
.hc
On Nov 26, 2005, at 3:37 PM, carmen wrote:
I don't see how the point size will be somehow different in aspect ratio from the pixel size?
why point/pixel sizes at all? for years the way to specify a font size for web is in "em" units. 1.0em 0.8em etc..
If courier 12 is say 10pixels wide then it should be identical to courier -10 visually, since the aspect *should* be the same.
even a 12 point font can be different on the same platform depending on which DPI you launched your X server at, which toolkit you are using, etc..
Or am I misunderstanding what you mean by the "at least three dimensions to a font size"?
id say theres at least 4... platform, dpi, font, fontsize
The font issue is really a stumbling block for trying to make anything look constant accross platforms. The current PD documentation is a great example of this, where, depending on the platform, many help-patches open with overlapping messages/comments. :(
how about a scalable canvas with a client-side algo to make sure nothing overlaps? something like http://whats-your.name/pd/chokun.png but with less ugly colours?
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
__ ____
There is no way to peace, peace is the way. -A.J. Muste
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
http://at.or.at/hans/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Looks like that is done here (in u_main.tk aka pd.tk):
proc pdtk_pd_startup {version apilist} { global pd_myversion pd_apilist set pd_myversion $version set pd_apilist $apilist
set width1 [font measure -*-courier-bold--normal--8-* x]
set height1 [lindex [font metrics -*-courier-bold--normal--8-*] 5]
set width2 [font measure -*-courier-bold--normal--10-* x]
set height2 [lindex [font metrics -*-courier-bold--normal--10-*] 5]
set width3 [font measure -*-courier-bold--normal--12-* x]
set height3 [lindex [font metrics -*-courier-bold--normal--12-*] 5]
set width4 [font measure -*-courier-bold--normal--14-* x]
set height4 [lindex [font metrics -*-courier-bold--normal--14-*] 5]
set width5 [font measure -*-courier-bold--normal--16-* x]
set height5 [lindex [font metrics -*-courier-bold--normal--16-*] 5]
set width6 [font measure -*-courier-bold--normal--24-* x]
set height6 [lindex [font metrics -*-courier-bold--normal--24-*] 5]
set width7 [font measure -*-courier-bold--normal--36-* x]
set height7 [lindex [font metrics -*-courier-bold--normal--36-*] 5]
I don't have time to mess with it now, anyone else want to try?
.hc
On Nov 28, 2005, at 2:25 PM, B. Bogart wrote:
Woo hoo!!!!
Miller, how does PD size object boxes?
b.
Hans-Christoph Steiner wrote:
Duh, why didn't I remember the -10 thing. Anyway, I tried that, and
it does indeed work! The font sizes are very similar in size on Windows and Mac OS X. But now the problem is that the boxes on Mac OS X a being created too large. I think that this shouldn't be too hard to figure out, it might just be a matter of replacing all of the Xwindows font specs with { courier -12 bold } Tk-style font specs.It would be great to get this into the upcoming Pd-extended release.
.hc
On Nov 28, 2005, at 10:38 AM, B. Bogart wrote:
hmmm, and did you try with the -10 pixel based font size?
if the pixel (width) of the font is known then it would be easy to
scale the object box based on the number of characters/spaces.Is that how this how it works now Miller?
Should be easy to adapt that code to work with a consistant font.
Good work Hans!
b.
Hans-Christoph Steiner wrote:
I think I found something: if you change the fontspec from
Xwindows style ( -*-courier-bold--normal--10-) to standard Tk style {
courier 10 bold }, then it looks like the fonts are the same size on MacOSX
and Windows. But then, the only problem is that the object boxes don't adjust, and are too short for the object text.It actually swings it the other way, with the same font being
bigger on Windows than on OSX..hc
On Nov 26, 2005, at 3:37 PM, carmen wrote:
> I don't see how the point size will be somehow different in
> aspect > ratio > from the pixel size?why point/pixel sizes at all? for years the way to specify a font size for web is in "em" units. 1.0em 0.8em etc..
> If courier 12 is say 10pixels wide then it should be identical to > courier -10 visually, since the aspect *should* be the same.
even a 12 point font can be different on the same platform
depending on which DPI you launched your X server at, which toolkit you are using, etc..> Or am I misunderstanding what you mean by the "at least three > dimensions > to a font size"?
id say theres at least 4... platform, dpi, font, fontsize
> The font issue is really a stumbling block for trying to make > anything > look constant accross platforms. The current PD documentation is
> a > great > example of this, where, depending on the platform, many
> help-patches > open with overlapping messages/comments. :(how about a scalable canvas with a client-side algo to make sure nothing overlaps? something like
http://whats-your.name/pd/chokun.png but with less ugly colours?
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
__ ____
There is no way to peace, peace is the way. -A.J. Muste
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
__ ____
http://at.or.at/hans/
"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
i remember someone saying "-*-courier-bold--normal--*-8" would be using pixel sizes (instead of point sizes). made a little test and font bomb didnt resize the fonts at all... (ill try more later)
btw. the code in miller cvs looked a little different... (pd devel cvs had issues, so i used millers cvs;)
but i found something else (that i allways wanted to do:) http://wiki.tcl.tk/470 adding 'option add *font "Helvetica 10"' in top of 'pd.tk' changes all the tk widget fonts and 'option add *font "Helvetica -10"' seems to even use pixel sizes...
that wiki seems to be good resource, where i found about "tk scaling" too: http://wiki.tcl.tk/8484
btw. the little (useless?) tk scaling gallery is here: http://osku.de/pd/tst01/index.html
getting font confused :) andre
On Mon, 2005-11-28 at 15:37 -0500, Hans-Christoph Steiner wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Looks like that is done here (in u_main.tk aka pd.tk):
proc pdtk_pd_startup {version apilist} { global pd_myversion pd_apilist set pd_myversion $version set pd_apilist $apilist
set width1 [font measure -*-courier-bold--normal--8-* x] set height1 [lindex [font metrics -*-courier-bold--normal--8-*] 5] set width2 [font measure -*-courier-bold--normal--10-* x] set height2 [lindex [font metrics -*-courier-bold--normal--10-*] 5] set width3 [font measure -*-courier-bold--normal--12-* x] set height3 [lindex [font metrics -*-courier-bold--normal--12-*] 5] set width4 [font measure -*-courier-bold--normal--14-* x] set height4 [lindex [font metrics -*-courier-bold--normal--14-*] 5] set width5 [font measure -*-courier-bold--normal--16-* x] set height5 [lindex [font metrics -*-courier-bold--normal--16-*] 5] set width6 [font measure -*-courier-bold--normal--24-* x] set height6 [lindex [font metrics -*-courier-bold--normal--24-*] 5] set width7 [font measure -*-courier-bold--normal--36-* x] set height7 [lindex [font metrics -*-courier-bold--normal--36-*] 5]I don't have time to mess with it now, anyone else want to try?
.hc
On Nov 28, 2005, at 2:25 PM, B. Bogart wrote:
Woo hoo!!!!
Miller, how does PD size object boxes?
b.
Hans-Christoph Steiner wrote:
Duh, why didn't I remember the -10 thing. Anyway, I tried that, and
it does indeed work! The font sizes are very similar in size on Windows and Mac OS X. But now the problem is that the boxes on Mac OS X a being created too large. I think that this shouldn't be too hard to figure out, it might just be a matter of replacing all of the Xwindows font specs with { courier -12 bold } Tk-style font specs.It would be great to get this into the upcoming Pd-extended release.
.hc
On Nov 28, 2005, at 10:38 AM, B. Bogart wrote:
hmmm, and did you try with the -10 pixel based font size?
if the pixel (width) of the font is known then it would be easy to
scale the object box based on the number of characters/spaces.Is that how this how it works now Miller?
Should be easy to adapt that code to work with a consistant font.
Good work Hans!
b.
Hans-Christoph Steiner wrote:
I think I found something: if you change the fontspec from
Xwindows style ( -*-courier-bold--normal--10-) to standard Tk style {
courier 10 bold }, then it looks like the fonts are the same size on MacOSX
and Windows. But then, the only problem is that the object boxes don't adjust, and are too short for the object text.It actually swings it the other way, with the same font being
bigger on Windows than on OSX..hc
On Nov 26, 2005, at 3:37 PM, carmen wrote:
>> I don't see how the point size will be somehow different in
>> aspect >> ratio >> from the pixel size? > > > > why point/pixel sizes at all? for years the way to specify a font > size for web is in "em" units. 1.0em 0.8em etc.. > >> If courier 12 is say 10pixels wide then it should be identical to >> courier -10 visually, since the aspect *should* be the same. > > > > even a 12 point font can be different on the same platform
> depending > on which DPI you launched your X server at, which toolkit you are > using, etc.. > >> Or am I misunderstanding what you mean by the "at least three >> dimensions >> to a font size"? > > > > id say theres at least 4... platform, dpi, font, fontsize > >> The font issue is really a stumbling block for trying to make >> anything >> look constant accross platforms. The current PD documentation is
>> a >> great >> example of this, where, depending on the platform, many
>> help-patches >> open with overlapping messages/comments. :( > > > > how about a scalable canvas with a client-side algo to make sure > nothing overlaps? something like
> http://whats-your.name/pd/chokun.png > but with less ugly colours? > > _______________________________________________ > PD-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list >
__ ____
There is no way to peace, peace is the way. -A.J. Muste
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
__ ____
http://at.or.at/hans/
"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-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (Darwin)
iD8DBQFDi2qKN4PEFRUrWIsRApQDAKD39SFP7EUdZfOP28/hQZA1ZtH8LwCdGSnl HntjkiR8va7FPBeukrQTUxk= =+XBX -----END PGP SIGNATURE-----
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Nov 29, 2005, at 3:41 AM, Andre Schmidt wrote:
i remember someone saying "-*-courier-bold--normal--*-8" would be using pixel sizes (instead of point sizes). made a little test and font bomb didnt resize the fonts at all... (ill try more later)
btw. the code in miller cvs looked a little different... (pd devel cvs had issues, so i used millers cvs;)
I think I found something else. It seems that tk scaling only works
when fonts are specified using the tk font spec (courier 8 bold). The
fonts specified X-style (-*-courier-bold--normal--*-8) don't seem to
get scaled.
but i found something else (that i allways wanted to do:) http://wiki.tcl.tk/470 adding 'option add *font "Helvetica 10"' in top of 'pd.tk' changes all the tk widget fonts and 'option add *font "Helvetica -10"' seems to even use pixel sizes...
that wiki seems to be good resource, where i found about "tk scaling" too: http://wiki.tcl.tk/8484
btw. the little (useless?) tk scaling gallery is here: http://osku.de/pd/tst01/index.html
Nice, it does clearly demonstrate the variations on systems. It would
be really great to have everything controlled by tk scaling, then have
the tk scaling factor be a preference. Plus, you can get the current
screen DPI in Tk, so then you could have some level of automatic tk
scaling based on screen DPI.
.hc
getting font confused :) andre
On Mon, 2005-11-28 at 15:37 -0500, Hans-Christoph Steiner wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Looks like that is done here (in u_main.tk aka pd.tk):
proc pdtk_pd_startup {version apilist} { global pd_myversion pd_apilist set pd_myversion $version set pd_apilist $apilist
set width1 [font measure -*-courier-bold--normal--8-* x] set height1 [lindex [font metrics -*-courier-bold--normal--8-*]5]
set width2 [font measure -*-courier-bold--normal--10-* x] set height2 [lindex [font metrics -*-courier-bold--normal--10-*]5]
set width3 [font measure -*-courier-bold--normal--12-* x] set height3 [lindex [font metrics -*-courier-bold--normal--12-*]5]
set width4 [font measure -*-courier-bold--normal--14-* x] set height4 [lindex [font metrics -*-courier-bold--normal--14-*]5]
set width5 [font measure -*-courier-bold--normal--16-* x] set height5 [lindex [font metrics -*-courier-bold--normal--16-*]5]
set width6 [font measure -*-courier-bold--normal--24-* x] set height6 [lindex [font metrics -*-courier-bold--normal--24-*]5]
set width7 [font measure -*-courier-bold--normal--36-* x] set height7 [lindex [font metrics -*-courier-bold--normal--36-*]5]
I don't have time to mess with it now, anyone else want to try?
.hc
On Nov 28, 2005, at 2:25 PM, B. Bogart wrote:
Woo hoo!!!!
Miller, how does PD size object boxes?
b.
Hans-Christoph Steiner wrote:
Duh, why didn't I remember the -10 thing. Anyway, I tried that, and it does indeed work! The font sizes are very similar in size on
Windows and Mac OS X. But now the problem is that the boxes on Mac OS X a being created too large. I think that this shouldn't be too hard to figure out, it might just be a matter of replacing all of the
Xwindows font specs with { courier -12 bold } Tk-style font specs.It would be great to get this into the upcoming Pd-extended release.
.hc
On Nov 28, 2005, at 10:38 AM, B. Bogart wrote:
hmmm, and did you try with the -10 pixel based font size?
if the pixel (width) of the font is known then it would be easy to scale the object box based on the number of characters/spaces.
Is that how this how it works now Miller?
Should be easy to adapt that code to work with a consistant font.
Good work Hans!
b.
Hans-Christoph Steiner wrote:
> > I think I found something: if you change the fontspec from > Xwindows > style ( -*-courier-bold--normal--10-) to standard Tk style { > courier 10 > bold }, then it looks like the fonts are the same size on MacOSX > and > Windows. But then, the only problem is that the object boxes
> don't > adjust, and are too short for the object text. > > It actually swings it the other way, with the same font being > bigger on > Windows than on OSX. > > > .hc > > On Nov 26, 2005, at 3:37 PM, carmen wrote: > >>> I don't see how the point size will be somehow different in >>> aspect >>> ratio >>> from the pixel size? >> >> >> >> why point/pixel sizes at all? for years the way to specify a
>> font >> size for web is in "em" units. 1.0em 0.8em etc.. >> >>> If courier 12 is say 10pixels wide then it should be identical
>>> to >>> courier -10 visually, since the aspect *should* be the same. >> >> >> >> even a 12 point font can be different on the same platform >> depending >> on which DPI you launched your X server at, which toolkit you
>> are >> using, etc.. >> >>> Or am I misunderstanding what you mean by the "at least three >>> dimensions >>> to a font size"? >> >> >> >> id say theres at least 4... platform, dpi, font, fontsize >> >>> The font issue is really a stumbling block for trying to make >>> anything >>> look constant accross platforms. The current PD documentation
>>> is >>> a >>> great >>> example of this, where, depending on the platform, many >>> help-patches >>> open with overlapping messages/comments. :( >> >> >> >> how about a scalable canvas with a client-side algo to make sure >> nothing overlaps? something like >> http://whats-your.name/pd/chokun.png >> but with less ugly colours? >> >> _______________________________________________ >> PD-list@iem.at mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list >> > > _________________________________________________________________ > __ > ___ > __ > ____ > > There is no way to peace, peace is the way. > -A.J. Muste > > > _______________________________________________ > PD-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > >
__ __ ____
http://at.or.at/hans/
__ ____
"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-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (Darwin)
iD8DBQFDi2qKN4PEFRUrWIsRApQDAKD39SFP7EUdZfOP28/hQZA1ZtH8LwCdGSnl HntjkiR8va7FPBeukrQTUxk= =+XBX -----END PGP SIGNATURE-----
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
"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
heres also a cute script for a dpi calculator :) (for tk scaling) http://wiki.tcl.tk/8484
On Tue, 2005-11-29 at 11:57 -0500, Hans-Christoph Steiner wrote:
On Nov 29, 2005, at 3:41 AM, Andre Schmidt wrote:
i remember someone saying "-*-courier-bold--normal--*-8" would be using pixel sizes (instead of point sizes). made a little test and font bomb didnt resize the fonts at all... (ill try more later)
btw. the code in miller cvs looked a little different... (pd devel cvs had issues, so i used millers cvs;)
I think I found something else. It seems that tk scaling only works
when fonts are specified using the tk font spec (courier 8 bold). The
fonts specified X-style (-*-courier-bold--normal--*-8) don't seem to
get scaled.but i found something else (that i allways wanted to do:) http://wiki.tcl.tk/470 adding 'option add *font "Helvetica 10"' in top of 'pd.tk' changes all the tk widget fonts and 'option add *font "Helvetica -10"' seems to even use pixel sizes...
that wiki seems to be good resource, where i found about "tk scaling" too: http://wiki.tcl.tk/8484
btw. the little (useless?) tk scaling gallery is here: http://osku.de/pd/tst01/index.html
Nice, it does clearly demonstrate the variations on systems. It would
be really great to have everything controlled by tk scaling, then have
the tk scaling factor be a preference. Plus, you can get the current
screen DPI in Tk, so then you could have some level of automatic tk
scaling based on screen DPI..hc
getting font confused :) andre
On Mon, 2005-11-28 at 15:37 -0500, Hans-Christoph Steiner wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Looks like that is done here (in u_main.tk aka pd.tk):
proc pdtk_pd_startup {version apilist} { global pd_myversion pd_apilist set pd_myversion $version set pd_apilist $apilist
set width1 [font measure -*-courier-bold--normal--8-* x] set height1 [lindex [font metrics -*-courier-bold--normal--8-*]5]
set width2 [font measure -*-courier-bold--normal--10-* x] set height2 [lindex [font metrics -*-courier-bold--normal--10-*]5]
set width3 [font measure -*-courier-bold--normal--12-* x] set height3 [lindex [font metrics -*-courier-bold--normal--12-*]5]
set width4 [font measure -*-courier-bold--normal--14-* x] set height4 [lindex [font metrics -*-courier-bold--normal--14-*]5]
set width5 [font measure -*-courier-bold--normal--16-* x] set height5 [lindex [font metrics -*-courier-bold--normal--16-*]5]
set width6 [font measure -*-courier-bold--normal--24-* x] set height6 [lindex [font metrics -*-courier-bold--normal--24-*]5]
set width7 [font measure -*-courier-bold--normal--36-* x] set height7 [lindex [font metrics -*-courier-bold--normal--36-*]5]
I don't have time to mess with it now, anyone else want to try?
.hc
On Nov 28, 2005, at 2:25 PM, B. Bogart wrote:
Woo hoo!!!!
Miller, how does PD size object boxes?
b.
Hans-Christoph Steiner wrote:
Duh, why didn't I remember the -10 thing. Anyway, I tried that, and it does indeed work! The font sizes are very similar in size on
Windows and Mac OS X. But now the problem is that the boxes on Mac OS X a being created too large. I think that this shouldn't be too hard to figure out, it might just be a matter of replacing all of the
Xwindows font specs with { courier -12 bold } Tk-style font specs.It would be great to get this into the upcoming Pd-extended release.
.hc
On Nov 28, 2005, at 10:38 AM, B. Bogart wrote:
> hmmm, and did you try with the -10 pixel based font size? > > if the pixel (width) of the font is known then it would be easy to > scale > the object box based on the number of characters/spaces. > > Is that how this how it works now Miller? > > Should be easy to adapt that code to work with a consistant font. > > Good work Hans! > > b. > > Hans-Christoph Steiner wrote: > >> >> I think I found something: if you change the fontspec from >> Xwindows >> style ( -*-courier-bold--normal--10-) to standard Tk style { >> courier 10 >> bold }, then it looks like the fonts are the same size on MacOSX >> and >> Windows. But then, the only problem is that the object boxes
>> don't >> adjust, and are too short for the object text. >> >> It actually swings it the other way, with the same font being >> bigger on >> Windows than on OSX. >> >> >> .hc >> >> On Nov 26, 2005, at 3:37 PM, carmen wrote: >> >>>> I don't see how the point size will be somehow different in >>>> aspect >>>> ratio >>>> from the pixel size? >>> >>> >>> >>> why point/pixel sizes at all? for years the way to specify a
>>> font >>> size for web is in "em" units. 1.0em 0.8em etc.. >>> >>>> If courier 12 is say 10pixels wide then it should be identical
>>>> to >>>> courier -10 visually, since the aspect *should* be the same. >>> >>> >>> >>> even a 12 point font can be different on the same platform >>> depending >>> on which DPI you launched your X server at, which toolkit you
>>> are >>> using, etc.. >>> >>>> Or am I misunderstanding what you mean by the "at least three >>>> dimensions >>>> to a font size"? >>> >>> >>> >>> id say theres at least 4... platform, dpi, font, fontsize >>> >>>> The font issue is really a stumbling block for trying to make >>>> anything >>>> look constant accross platforms. The current PD documentation
>>>> is >>>> a >>>> great >>>> example of this, where, depending on the platform, many >>>> help-patches >>>> open with overlapping messages/comments. :( >>> >>> >>> >>> how about a scalable canvas with a client-side algo to make sure >>> nothing overlaps? something like >>> http://whats-your.name/pd/chokun.png >>> but with less ugly colours? >>> >>> _______________________________________________ >>> PD-list@iem.at mailing list >>> UNSUBSCRIBE and account-management -> >>> http://lists.puredata.info/listinfo/pd-list >>> >> >> _________________________________________________________________ >> __ >> ___ >> __ >> ____ >> >> There is no way to peace, peace is the way. >> -A.J. Muste >> >> >> _______________________________________________ >> PD-list@iem.at mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list >> >>
__ __ ____
http://at.or.at/hans/
__ ____
"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-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (Darwin)
iD8DBQFDi2qKN4PEFRUrWIsRApQDAKD39SFP7EUdZfOP28/hQZA1ZtH8LwCdGSnl HntjkiR8va7FPBeukrQTUxk= =+XBX -----END PGP SIGNATURE-----
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
"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
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
does this affect us too ? (its from millers cvs. devel has still issues)
in 's_main.c'
/* these give the nominal point size and maximum height of the
characters in the six fonts. */
static t_fontinfo sys_fontlist[] = { {8, 5, 9, 0, 0, 0}, {10, 7, 13, 0, 0, 0}, {12, 9, 16, 0, 0, 0}, {16, 10, 20, 0, 0, 0}, {24, 15, 25, 0, 0, 0}, {36, 25, 45, 0, 0, 0}}; #define NFONT (sizeof(sys_fontlist)/sizeof(*sys_fontlist))
On Mon, 2005-11-28 at 15:37 -0500, Hans-Christoph Steiner wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Looks like that is done here (in u_main.tk aka pd.tk):
proc pdtk_pd_startup {version apilist} { global pd_myversion pd_apilist set pd_myversion $version set pd_apilist $apilist
set width1 [font measure -*-courier-bold--normal--8-* x] set height1 [lindex [font metrics -*-courier-bold--normal--8-*] 5] set width2 [font measure -*-courier-bold--normal--10-* x] set height2 [lindex [font metrics -*-courier-bold--normal--10-*] 5] set width3 [font measure -*-courier-bold--normal--12-* x] set height3 [lindex [font metrics -*-courier-bold--normal--12-*] 5] set width4 [font measure -*-courier-bold--normal--14-* x] set height4 [lindex [font metrics -*-courier-bold--normal--14-*] 5] set width5 [font measure -*-courier-bold--normal--16-* x] set height5 [lindex [font metrics -*-courier-bold--normal--16-*] 5] set width6 [font measure -*-courier-bold--normal--24-* x] set height6 [lindex [font metrics -*-courier-bold--normal--24-*] 5] set width7 [font measure -*-courier-bold--normal--36-* x] set height7 [lindex [font metrics -*-courier-bold--normal--36-*] 5]I don't have time to mess with it now, anyone else want to try?
.hc
On Nov 28, 2005, at 2:25 PM, B. Bogart wrote:
Woo hoo!!!!
Miller, how does PD size object boxes?
b.
Hans-Christoph Steiner wrote:
Duh, why didn't I remember the -10 thing. Anyway, I tried that, and
it does indeed work! The font sizes are very similar in size on Windows and Mac OS X. But now the problem is that the boxes on Mac OS X a being created too large. I think that this shouldn't be too hard to figure out, it might just be a matter of replacing all of the Xwindows font specs with { courier -12 bold } Tk-style font specs.It would be great to get this into the upcoming Pd-extended release.
.hc
On Nov 28, 2005, at 10:38 AM, B. Bogart wrote:
hmmm, and did you try with the -10 pixel based font size?
if the pixel (width) of the font is known then it would be easy to
scale the object box based on the number of characters/spaces.Is that how this how it works now Miller?
Should be easy to adapt that code to work with a consistant font.
Good work Hans!
b.
Hans-Christoph Steiner wrote:
I think I found something: if you change the fontspec from
Xwindows style ( -*-courier-bold--normal--10-) to standard Tk style {
courier 10 bold }, then it looks like the fonts are the same size on MacOSX
and Windows. But then, the only problem is that the object boxes don't adjust, and are too short for the object text.It actually swings it the other way, with the same font being
bigger on Windows than on OSX..hc
On Nov 26, 2005, at 3:37 PM, carmen wrote:
>> I don't see how the point size will be somehow different in
>> aspect >> ratio >> from the pixel size? > > > > why point/pixel sizes at all? for years the way to specify a font > size for web is in "em" units. 1.0em 0.8em etc.. > >> If courier 12 is say 10pixels wide then it should be identical to >> courier -10 visually, since the aspect *should* be the same. > > > > even a 12 point font can be different on the same platform
> depending > on which DPI you launched your X server at, which toolkit you are > using, etc.. > >> Or am I misunderstanding what you mean by the "at least three >> dimensions >> to a font size"? > > > > id say theres at least 4... platform, dpi, font, fontsize > >> The font issue is really a stumbling block for trying to make >> anything >> look constant accross platforms. The current PD documentation is
>> a >> great >> example of this, where, depending on the platform, many
>> help-patches >> open with overlapping messages/comments. :( > > > > how about a scalable canvas with a client-side algo to make sure > nothing overlaps? something like
> http://whats-your.name/pd/chokun.png > but with less ugly colours? > > _______________________________________________ > PD-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list >
__ ____
There is no way to peace, peace is the way. -A.J. Muste
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
__ ____
http://at.or.at/hans/
"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-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (Darwin)
iD8DBQFDi2qKN4PEFRUrWIsRApQDAKD39SFP7EUdZfOP28/hQZA1ZtH8LwCdGSnl HntjkiR8va7FPBeukrQTUxk= =+XBX -----END PGP SIGNATURE-----
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I don't know exactly what its used for, but it is font sizing info. It
looks to me that its for sizing things based on font size, which might
be what we need for the boxes.
.hc
On Nov 29, 2005, at 3:58 AM, Andre Schmidt wrote:
does this affect us too ? (its from millers cvs. devel has still
issues)in 's_main.c'
/* these give the nominal point size and maximum height of thecharacters in the six fonts. */
static t_fontinfo sys_fontlist[] = { {8, 5, 9, 0, 0, 0}, {10, 7, 13, 0, 0, 0}, {12, 9, 16, 0, 0, 0}, {16, 10, 20, 0, 0, 0}, {24, 15, 25, 0, 0, 0}, {36, 25, 45, 0, 0, 0}}; #define NFONT (sizeof(sys_fontlist)/sizeof(*sys_fontlist))
On Mon, 2005-11-28 at 15:37 -0500, Hans-Christoph Steiner wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Looks like that is done here (in u_main.tk aka pd.tk):
proc pdtk_pd_startup {version apilist} { global pd_myversion pd_apilist set pd_myversion $version set pd_apilist $apilist
set width1 [font measure -*-courier-bold--normal--8-* x] set height1 [lindex [font metrics -*-courier-bold--normal--8-*]5]
set width2 [font measure -*-courier-bold--normal--10-* x] set height2 [lindex [font metrics -*-courier-bold--normal--10-*]5]
set width3 [font measure -*-courier-bold--normal--12-* x] set height3 [lindex [font metrics -*-courier-bold--normal--12-*]5]
set width4 [font measure -*-courier-bold--normal--14-* x] set height4 [lindex [font metrics -*-courier-bold--normal--14-*]5]
set width5 [font measure -*-courier-bold--normal--16-* x] set height5 [lindex [font metrics -*-courier-bold--normal--16-*]5]
set width6 [font measure -*-courier-bold--normal--24-* x] set height6 [lindex [font metrics -*-courier-bold--normal--24-*]5]
set width7 [font measure -*-courier-bold--normal--36-* x] set height7 [lindex [font metrics -*-courier-bold--normal--36-*]5]
I don't have time to mess with it now, anyone else want to try?
.hc
On Nov 28, 2005, at 2:25 PM, B. Bogart wrote:
Woo hoo!!!!
Miller, how does PD size object boxes?
b.
Hans-Christoph Steiner wrote:
Duh, why didn't I remember the -10 thing. Anyway, I tried that, and it does indeed work! The font sizes are very similar in size on
Windows and Mac OS X. But now the problem is that the boxes on Mac OS X a being created too large. I think that this shouldn't be too hard to figure out, it might just be a matter of replacing all of the
Xwindows font specs with { courier -12 bold } Tk-style font specs.It would be great to get this into the upcoming Pd-extended release.
.hc
On Nov 28, 2005, at 10:38 AM, B. Bogart wrote:
hmmm, and did you try with the -10 pixel based font size?
if the pixel (width) of the font is known then it would be easy to scale the object box based on the number of characters/spaces.
Is that how this how it works now Miller?
Should be easy to adapt that code to work with a consistant font.
Good work Hans!
b.
Hans-Christoph Steiner wrote:
> > I think I found something: if you change the fontspec from > Xwindows > style ( -*-courier-bold--normal--10-) to standard Tk style { > courier 10 > bold }, then it looks like the fonts are the same size on MacOSX > and > Windows. But then, the only problem is that the object boxes
> don't > adjust, and are too short for the object text. > > It actually swings it the other way, with the same font being > bigger on > Windows than on OSX. > > > .hc > > On Nov 26, 2005, at 3:37 PM, carmen wrote: > >>> I don't see how the point size will be somehow different in >>> aspect >>> ratio >>> from the pixel size? >> >> >> >> why point/pixel sizes at all? for years the way to specify a
>> font >> size for web is in "em" units. 1.0em 0.8em etc.. >> >>> If courier 12 is say 10pixels wide then it should be identical
>>> to >>> courier -10 visually, since the aspect *should* be the same. >> >> >> >> even a 12 point font can be different on the same platform >> depending >> on which DPI you launched your X server at, which toolkit you
>> are >> using, etc.. >> >>> Or am I misunderstanding what you mean by the "at least three >>> dimensions >>> to a font size"? >> >> >> >> id say theres at least 4... platform, dpi, font, fontsize >> >>> The font issue is really a stumbling block for trying to make >>> anything >>> look constant accross platforms. The current PD documentation
>>> is >>> a >>> great >>> example of this, where, depending on the platform, many >>> help-patches >>> open with overlapping messages/comments. :( >> >> >> >> how about a scalable canvas with a client-side algo to make sure >> nothing overlaps? something like >> http://whats-your.name/pd/chokun.png >> but with less ugly colours? >> >> _______________________________________________ >> PD-list@iem.at mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list >> > > _________________________________________________________________ > __ > ___ > __ > ____ > > There is no way to peace, peace is the way. > -A.J. Muste > > > _______________________________________________ > PD-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > >
__ __ ____
http://at.or.at/hans/
__ ____
"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-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (Darwin)
iD8DBQFDi2qKN4PEFRUrWIsRApQDAKD39SFP7EUdZfOP28/hQZA1ZtH8LwCdGSnl HntjkiR8va7FPBeukrQTUxk= =+XBX -----END PGP SIGNATURE-----
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
"If nature has made any one thing less susceptible than all others of
exclusive property, it is the action of the thinking power called an
idea, which an individual may exclusively possess as long as he keeps
it to himself; but the moment it is divulged, it forces itself into the
possession of everyone, and the receiver cannot dispossess himself of
it."
- Thomas
Jefferson
This is used for sys_initfromgui() to search for fonts with acceptable size, among the ones TK gave us. Naturally I'd love to throw that out and really select fonts of the desired pixel sizes, once I know a way to get TK to do that...
cheers Miller
On Tue, Nov 29, 2005 at 09:49:45PM -0500, Hans-Christoph Steiner wrote:
I don't know exactly what its used for, but it is font sizing info. It
looks to me that its for sizing things based on font size, which might
be what we need for the boxes..hc
On Nov 29, 2005, at 3:58 AM, Andre Schmidt wrote:
does this affect us too ? (its from millers cvs. devel has still
issues)in 's_main.c'
/* these give the nominal point size and maximum height of the characters in the six fonts. */
static t_fontinfo sys_fontlist[] = { {8, 5, 9, 0, 0, 0}, {10, 7, 13, 0, 0, 0}, {12, 9, 16, 0, 0, 0}, {16, 10, 20, 0, 0, 0}, {24, 15, 25, 0, 0, 0}, {36, 25, 45, 0, 0, 0}}; #define NFONT (sizeof(sys_fontlist)/sizeof(*sys_fontlist))
On Mon, 2005-11-28 at 15:37 -0500, Hans-Christoph Steiner wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Looks like that is done here (in u_main.tk aka pd.tk):
proc pdtk_pd_startup {version apilist} { global pd_myversion pd_apilist set pd_myversion $version set pd_apilist $apilist
set width1 [font measure -*-courier-bold--normal--8-* x] set height1 [lindex [font metrics -*-courier-bold--normal--8-*]5]
set width2 [font measure -*-courier-bold--normal--10-* x] set height2 [lindex [font metrics -*-courier-bold--normal--10-*]5]
set width3 [font measure -*-courier-bold--normal--12-* x] set height3 [lindex [font metrics -*-courier-bold--normal--12-*]5]
set width4 [font measure -*-courier-bold--normal--14-* x] set height4 [lindex [font metrics -*-courier-bold--normal--14-*]5]
set width5 [font measure -*-courier-bold--normal--16-* x] set height5 [lindex [font metrics -*-courier-bold--normal--16-*]5]
set width6 [font measure -*-courier-bold--normal--24-* x] set height6 [lindex [font metrics -*-courier-bold--normal--24-*]5]
set width7 [font measure -*-courier-bold--normal--36-* x] set height7 [lindex [font metrics -*-courier-bold--normal--36-*]5]
I don't have time to mess with it now, anyone else want to try?
.hc
On Nov 28, 2005, at 2:25 PM, B. Bogart wrote:
Woo hoo!!!!
Miller, how does PD size object boxes?
b.
Hans-Christoph Steiner wrote:
Duh, why didn't I remember the -10 thing. Anyway, I tried that, and it does indeed work! The font sizes are very similar in size on
Windows and Mac OS X. But now the problem is that the boxes on Mac OS X a being created too large. I think that this shouldn't be too hard to figure out, it might just be a matter of replacing all of the
Xwindows font specs with { courier -12 bold } Tk-style font specs.It would be great to get this into the upcoming Pd-extended release.
.hc
On Nov 28, 2005, at 10:38 AM, B. Bogart wrote:
>hmmm, and did you try with the -10 pixel based font size? > >if the pixel (width) of the font is known then it would be easy to >scale >the object box based on the number of characters/spaces. > >Is that how this how it works now Miller? > >Should be easy to adapt that code to work with a consistant font. > >Good work Hans! > >b. > >Hans-Christoph Steiner wrote: > >> >>I think I found something: if you change the fontspec from >>Xwindows >>style ( -*-courier-bold--normal--10-) to standard Tk style { >>courier 10 >>bold }, then it looks like the fonts are the same size on MacOSX >>and >>Windows. But then, the only problem is that the object boxes
>>don't >>adjust, and are too short for the object text. >> >>It actually swings it the other way, with the same font being >>bigger on >>Windows than on OSX. >> >> >>.hc >> >>On Nov 26, 2005, at 3:37 PM, carmen wrote: >> >>>>I don't see how the point size will be somehow different in >>>>aspect >>>>ratio >>>> from the pixel size? >>> >>> >>> >>>why point/pixel sizes at all? for years the way to specify a
>>>font >>>size for web is in "em" units. 1.0em 0.8em etc.. >>> >>>>If courier 12 is say 10pixels wide then it should be identical
>>>>to >>>>courier -10 visually, since the aspect *should* be the same. >>> >>> >>> >>>even a 12 point font can be different on the same platform >>>depending >>>on which DPI you launched your X server at, which toolkit you
>>>are >>>using, etc.. >>> >>>>Or am I misunderstanding what you mean by the "at least three >>>>dimensions >>>>to a font size"? >>> >>> >>> >>>id say theres at least 4... platform, dpi, font, fontsize >>> >>>>The font issue is really a stumbling block for trying to make >>>>anything >>>>look constant accross platforms. The current PD documentation
>>>>is >>>>a >>>>great >>>>example of this, where, depending on the platform, many >>>>help-patches >>>>open with overlapping messages/comments. :( >>> >>> >>> >>>how about a scalable canvas with a client-side algo to make sure >>>nothing overlaps? something like >>>http://whats-your.name/pd/chokun.png >>>but with less ugly colours? >>> >>>_______________________________________________ >>>PD-list@iem.at mailing list >>>UNSUBSCRIBE and account-management -> >>>http://lists.puredata.info/listinfo/pd-list >>> >> >>_________________________________________________________________ >>__ >>___ >>__ >>____ >> >> There is no way to peace, peace is the way. >> -A.J. Muste >> >> >>_______________________________________________ >>PD-list@iem.at mailing list >>UNSUBSCRIBE and account-management -> >>http://lists.puredata.info/listinfo/pd-list >> >>
__ __ ____
http://at.or.at/hans/
__ ____
"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-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (Darwin)
iD8DBQFDi2qKN4PEFRUrWIsRApQDAKD39SFP7EUdZfOP28/hQZA1ZtH8LwCdGSnl HntjkiR8va7FPBeukrQTUxk= =+XBX -----END PGP SIGNATURE-----
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
"If nature has made any one thing less susceptible than all others of
exclusive property, it is the action of the thinking power called an
idea, which an individual may exclusively possess as long as he keeps
it to himself; but the moment it is divulged, it forces itself into the
possession of everyone, and the receiver cannot dispossess himself of
it." - Thomas
Jefferson
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Something that allows the use of tk scaling would be really nice. Then
you could scale the patch and everything would remain proportional.
This would be a really nice way to support all the varying screen
sizes, and it seem to be already built into Tk. It sounds like its a
matter of letting Tk do the box sizing. It'll already handle the fonts
fine if you switch to Tk-style font specs from Xwindows font specs.
.hc
On Nov 29, 2005, at 11:51 PM, Miller Puckette wrote:
This is used for sys_initfromgui() to search for fonts with acceptable size, among the ones TK gave us. Naturally I'd love to throw that out and really select fonts of the desired pixel sizes, once I know a way to get TK to do that...
cheers Miller
On Tue, Nov 29, 2005 at 09:49:45PM -0500, Hans-Christoph Steiner wrote:
I don't know exactly what its used for, but it is font sizing info.
It looks to me that its for sizing things based on font size, which might be what we need for the boxes..hc
On Nov 29, 2005, at 3:58 AM, Andre Schmidt wrote:
does this affect us too ? (its from millers cvs. devel has still issues)
in 's_main.c'
/* these give the nominal point size and maximum height of the characters in the six fonts. */
static t_fontinfo sys_fontlist[] = { {8, 5, 9, 0, 0, 0}, {10, 7, 13, 0, 0, 0}, {12, 9, 16, 0, 0, 0}, {16, 10, 20, 0, 0, 0}, {24, 15, 25, 0, 0, 0}, {36, 25, 45, 0, 0, 0}}; #define NFONT (sizeof(sys_fontlist)/sizeof(*sys_fontlist))
On Mon, 2005-11-28 at 15:37 -0500, Hans-Christoph Steiner wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Looks like that is done here (in u_main.tk aka pd.tk):
proc pdtk_pd_startup {version apilist} { global pd_myversion pd_apilist set pd_myversion $version set pd_apilist $apilist
set width1 [font measure -*-courier-bold--normal--8-* x] set height1 [lindex [font metrics -*-courier-bold--normal--8-*]5]
set width2 [font measure -*-courier-bold--normal--10-* x] set height2 [lindex [font metrics -*-courier-bold--normal--10-*]5]
set width3 [font measure -*-courier-bold--normal--12-* x] set height3 [lindex [font metrics -*-courier-bold--normal--12-*]5]
set width4 [font measure -*-courier-bold--normal--14-* x] set height4 [lindex [font metrics -*-courier-bold--normal--14-*]5]
set width5 [font measure -*-courier-bold--normal--16-* x] set height5 [lindex [font metrics -*-courier-bold--normal--16-*]5]
set width6 [font measure -*-courier-bold--normal--24-* x] set height6 [lindex [font metrics -*-courier-bold--normal--24-*]5]
set width7 [font measure -*-courier-bold--normal--36-* x] set height7 [lindex [font metrics -*-courier-bold--normal--36-*]5]
I don't have time to mess with it now, anyone else want to try?
.hc
On Nov 28, 2005, at 2:25 PM, B. Bogart wrote:
Woo hoo!!!!
Miller, how does PD size object boxes?
b.
Hans-Christoph Steiner wrote:
Duh, why didn't I remember the -10 thing. Anyway, I tried that,
and it does indeed work! The font sizes are very similar in size on Windows and Mac OS X. But now the problem is that the boxes on Mac OS X a being created too large. I think that this shouldn't be too hard
to figure out, it might just be a matter of replacing all of the Xwindows font specs with { courier -12 bold } Tk-style font specs.It would be great to get this into the upcoming Pd-extended
release..hc
On Nov 28, 2005, at 10:38 AM, B. Bogart wrote:
>> hmmm, and did you try with the -10 pixel based font size? >> >> if the pixel (width) of the font is known then it would be easy
>> to >> scale >> the object box based on the number of characters/spaces. >> >> Is that how this how it works now Miller? >> >> Should be easy to adapt that code to work with a consistant
>> font. >> >> Good work Hans! >> >> b. >> >> Hans-Christoph Steiner wrote: >> >>> >>> I think I found something: if you change the fontspec from >>> Xwindows >>> style ( -*-courier-bold--normal--10-) to standard Tk style { >>> courier 10 >>> bold }, then it looks like the fonts are the same size on
>>> MacOSX >>> and >>> Windows. But then, the only problem is that the object boxes >>> don't >>> adjust, and are too short for the object text. >>> >>> It actually swings it the other way, with the same font being >>> bigger on >>> Windows than on OSX. >>> >>> >>> .hc >>> >>> On Nov 26, 2005, at 3:37 PM, carmen wrote: >>> >>>>> I don't see how the point size will be somehow different in >>>>> aspect >>>>> ratio >>>>> from the pixel size? >>>> >>>> >>>> >>>> why point/pixel sizes at all? for years the way to specify a >>>> font >>>> size for web is in "em" units. 1.0em 0.8em etc.. >>>> >>>>> If courier 12 is say 10pixels wide then it should be
>>>>> identical >>>>> to >>>>> courier -10 visually, since the aspect *should* be the same. >>>> >>>> >>>> >>>> even a 12 point font can be different on the same platform >>>> depending >>>> on which DPI you launched your X server at, which toolkit you >>>> are >>>> using, etc.. >>>> >>>>> Or am I misunderstanding what you mean by the "at least three >>>>> dimensions >>>>> to a font size"? >>>> >>>> >>>> >>>> id say theres at least 4... platform, dpi, font, fontsize >>>> >>>>> The font issue is really a stumbling block for trying to make >>>>> anything >>>>> look constant accross platforms. The current PD documentation >>>>> is >>>>> a >>>>> great >>>>> example of this, where, depending on the platform, many >>>>> help-patches >>>>> open with overlapping messages/comments. :( >>>> >>>> >>>> >>>> how about a scalable canvas with a client-side algo to make
>>>> sure >>>> nothing overlaps? something like >>>> http://whats-your.name/pd/chokun.png >>>> but with less ugly colours? >>>> >>>> _______________________________________________ >>>> PD-list@iem.at mailing list >>>> UNSUBSCRIBE and account-management -> >>>> http://lists.puredata.info/listinfo/pd-list >>>> >>> >>> _______________________________________________________________ >>> __ >>> __ >>> ___ >>> __ >>> ____ >>> >>> There is no way to peace, peace is the way. >>> -A.J. Muste >>> >>> >>> _______________________________________________ >>> PD-list@iem.at mailing list >>> UNSUBSCRIBE and account-management -> >>> http://lists.puredata.info/listinfo/pd-list >>> >>>
__ __ __ ____
http://at.or.at/hans/
__ __ ____
"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-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (Darwin)
iD8DBQFDi2qKN4PEFRUrWIsRApQDAKD39SFP7EUdZfOP28/hQZA1ZtH8LwCdGSnl HntjkiR8va7FPBeukrQTUxk= =+XBX -----END PGP SIGNATURE-----
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
__ ____
"If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into
the possession of everyone, and the receiver cannot dispossess himself of it." - Thomas Jefferson
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
"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
Well, the "courier" font on Windows is much taller for the same width than on Linux or Mac. I think most of the difference isn't the height of the characters but the empty space between lines.
Tuesday mornings are difficult for me -- office hours and teaching.
cheers Miller
On Sat, Nov 26, 2005 at 02:16:19PM -0500, B. Bogart wrote:
Hi Miller,
how easy would it be to change all the point sizes in TK and then remove the C function to do the pixel conversion?
I don't see how the point size will be somehow different in aspect ratio from the pixel size?
If courier 12 is say 10pixels wide then it should be identical to courier -10 visually, since the aspect *should* be the same.
Or am I misunderstanding what you mean by the "at least three dimensions to a font size"?
The font issue is really a stumbling block for trying to make anything look constant accross platforms. The current PD documentation is a great example of this, where, depending on the platform, many help-patches open with overlapping messages/comments. :(
Will you be able to attend the next PD documentation meeting on tuesday the 29th of November?
.b.
Miller Puckette wrote:
Well, they're given to TK as "points", but then in s_main.c, a setup routine, glob_initfromgui(), actually searches through the fonts for those closest to the desired _pixel_ size. At tha time I believe TK had no way of specifying pixel size. I'm not sure what the truth is now; you can feed TK negative "point sizes" that are supposed to generate known pixel sizes, but there are at least three dimensions to a font size and I don't know how the single number maps to them. Ugh...
Miller
On Sat, Nov 26, 2005 at 01:24:59PM -0500, Hans-Christoph Steiner wrote:
On Nov 26, 2005, at 1:03 PM, Mathieu Bouchard wrote:
On Wed, 23 Nov 2005, Andre Schmidt wrote:
http://www.tcl.tk/man/tcl8.5/TkCmd/tk.htm#M7 "tk scaling ?-displayof window? ?number?
[...]
wouldnt this mean that we could do pixel accurate, measurements and finetuning (calibration) on the client to get the desired font size ?
This only applies to distances not specified in pixels.
i made a test and added "tk scaling 1.5" in the beginning of "pd.tk" made a test pacth with all gui objects having font size 10... but it seems to affect only labels, and nmb2 : http://osku.de/allgui.png
So now you know which are the things currently specified in pixels... that is, almost everything. I don't think "tk scaling" will help us.
So that means that the comment font is being specified in pixels somewhere. That is something that I don't remmeber seeing at all. AFAIK, all of the font definitions in pd.tk/u_main.tk using point numbers. Where are the point numbers being converted into pixels?
.hc
There is no way to peace, peace is the way. -A.J. Muste
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
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hmmm, maybe we should not be using a system font then... (use a single GPL ttf we can distribute with PD?)
If the same font is not consistant accross platforms then no tk fiddling will fix the issue.
Thanks for the clarification Miller.
Friday morning's are the best for your then Miller? Any other mornings?
b.
Miller Puckette wrote:
Well, the "courier" font on Windows is much taller for the same width than on Linux or Mac. I think most of the difference isn't the height of the characters but the empty space between lines.
Tuesday mornings are difficult for me -- office hours and teaching.
cheers Miller
On Sat, Nov 26, 2005 at 02:16:19PM -0500, B. Bogart wrote:
Hi Miller,
how easy would it be to change all the point sizes in TK and then remove the C function to do the pixel conversion?
I don't see how the point size will be somehow different in aspect ratio from the pixel size?
If courier 12 is say 10pixels wide then it should be identical to courier -10 visually, since the aspect *should* be the same.
Or am I misunderstanding what you mean by the "at least three dimensions to a font size"?
The font issue is really a stumbling block for trying to make anything look constant accross platforms. The current PD documentation is a great example of this, where, depending on the platform, many help-patches open with overlapping messages/comments. :(
Will you be able to attend the next PD documentation meeting on tuesday the 29th of November?
.b.
Miller Puckette wrote:
Well, they're given to TK as "points", but then in s_main.c, a setup routine, glob_initfromgui(), actually searches through the fonts for those closest to the desired _pixel_ size. At tha time I believe TK had no way of specifying pixel size. I'm not sure what the truth is now; you can feed TK negative "point sizes" that are supposed to generate known pixel sizes, but there are at least three dimensions to a font size and I don't know how the single number maps to them. Ugh...
Miller
On Sat, Nov 26, 2005 at 01:24:59PM -0500, Hans-Christoph Steiner wrote:
On Nov 26, 2005, at 1:03 PM, Mathieu Bouchard wrote:
On Wed, 23 Nov 2005, Andre Schmidt wrote:
http://www.tcl.tk/man/tcl8.5/TkCmd/tk.htm#M7 "tk scaling ?-displayof window? ?number?
[...]
wouldnt this mean that we could do pixel accurate, measurements and finetuning (calibration) on the client to get the desired font size ?
This only applies to distances not specified in pixels.
i made a test and added "tk scaling 1.5" in the beginning of "pd.tk" made a test pacth with all gui objects having font size 10... but it seems to affect only labels, and nmb2 : http://osku.de/allgui.png
So now you know which are the things currently specified in pixels... that is, almost everything. I don't think "tk scaling" will help us.
So that means that the comment font is being specified in pixels somewhere. That is something that I don't remmeber seeing at all. AFAIK, all of the font definitions in pd.tk/u_main.tk using point numbers. Where are the point numbers being converted into pixels?
.hc
There is no way to peace, peace is the way. -A.J. Muste
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
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 Sat, 2005-11-26 at 16:38 -0500, B. Bogart wrote:
Hmmm, maybe we should not be using a system font then... (use a single GPL ttf we can distribute with PD?)
i would prefer a bitmap font over ttf font... but then again, tk/tcl also "scales" bitmap fonts... doh. http://osku.de/ext-stuff/pd_font_trouble01.png
If the same font is not consistant accross platforms then no tk fiddling will fix the issue.
Thanks for the clarification Miller.
Friday morning's are the best for your then Miller? Any other mornings?
b.
Miller Puckette wrote:
Well, the "courier" font on Windows is much taller for the same width than on Linux or Mac. I think most of the difference isn't the height of the characters but the empty space between lines.
Tuesday mornings are difficult for me -- office hours and teaching.
cheers Miller
On Sat, Nov 26, 2005 at 02:16:19PM -0500, B. Bogart wrote:
Hi Miller,
how easy would it be to change all the point sizes in TK and then remove the C function to do the pixel conversion?
I don't see how the point size will be somehow different in aspect ratio from the pixel size?
If courier 12 is say 10pixels wide then it should be identical to courier -10 visually, since the aspect *should* be the same.
Or am I misunderstanding what you mean by the "at least three dimensions to a font size"?
The font issue is really a stumbling block for trying to make anything look constant accross platforms. The current PD documentation is a great example of this, where, depending on the platform, many help-patches open with overlapping messages/comments. :(
Will you be able to attend the next PD documentation meeting on tuesday the 29th of November?
.b.
Miller Puckette wrote:
Well, they're given to TK as "points", but then in s_main.c, a setup routine, glob_initfromgui(), actually searches through the fonts for those closest to the desired _pixel_ size. At tha time I believe TK had no way of specifying pixel size. I'm not sure what the truth is now; you can feed TK negative "point sizes" that are supposed to generate known pixel sizes, but there are at least three dimensions to a font size and I don't know how the single number maps to them. Ugh...
Miller
On Sat, Nov 26, 2005 at 01:24:59PM -0500, Hans-Christoph Steiner wrote:
On Nov 26, 2005, at 1:03 PM, Mathieu Bouchard wrote:
On Wed, 23 Nov 2005, Andre Schmidt wrote:
>http://www.tcl.tk/man/tcl8.5/TkCmd/tk.htm#M7 >"tk scaling ?-displayof window? ?number?
[...]
>wouldnt this mean that we could do pixel accurate, measurements and >finetuning (calibration) on the client to get the desired font size ?
This only applies to distances not specified in pixels.
>i made a test and added "tk scaling 1.5" in the beginning of "pd.tk" >made a test pacth with all gui objects having font size 10... but it >seems to affect only labels, and nmb2 : http://osku.de/allgui.png
So now you know which are the things currently specified in pixels... that is, almost everything. I don't think "tk scaling" will help us.
So that means that the comment font is being specified in pixels somewhere. That is something that I don't remmeber seeing at all. AFAIK, all of the font definitions in pd.tk/u_main.tk using point numbers. Where are the point numbers being converted into pixels?
.hc
There is no way to peace, peace is the way. -A.J. Muste
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
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
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Andre Schmidt -
B. Bogart -
carmen -
Frank Barknecht -
Hans-Christoph Steiner -
Mathieu Bouchard -
Miller Puckette