This was fixed in extended years ago and the font handling improvements have simply not been ported to Vanilla. Your point is clear, what is not clear is (as usual) who is going to spend the time to port Hans' working solution to vanilla and in such a way as to have it accepted.
On Feb 11, 2017, at 10:07 PM, pd-list-request@lists.iem.at wrote:
From: Alexandre Torres Porres <porres@gmail.com mailto:porres@gmail.com> Subject: Re: [PD] cross platforms issues with displaying fonts in vanilla but not in Purr Data Date: February 11, 2017 at 10:07:44 PM MST To: Lucas Cordiviola <lucarda27@hotmail.com mailto:lucarda27@hotmail.com> Cc: "pd-list@lists.iem.at mailto:pd-list@lists.iem.at" <pd-list@lists.iem.at mailto:pd-list@lists.iem.at>
please let me reinforce something, cause I feel like I'm repeating myself a lot... maybe I'm not making myself clear, maybe I'm a very confusing guy and troubled mind, but it's been over 30 messages and all I'm really saying (all along, from the very first message) is this:
hey: 1- Purr Data and Extended look like and consistent... they give you fonts you need, and all patches look nice in cross platforms. 2- vanilla doesn't give you fonts you need and when you get them, it looks bad, inconsistent in between different platforms and even different than in Extended/Purr Data with the same fonts...
and all I have is a request: - please lets fix this vanilla issue
sorry, dont get me wrong, I love that you're with me here and I'm also willing to help and investigate this, but it's just that it seems we're not making much progress and that I'm not making my point clear.
cheers
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
2017-02-12 4:00 GMT-02:00 Dan Wilcox danomatika@gmail.com:
This was fixed in extended years ago and the font handling improvements have simply not been ported to Vanilla. Your point is clear, what is not clear is (as usual) who is going to spend the time to port Hans' working solution to vanilla and in such a way as to have it accepted.
😕
What I was referring to was also the pixel & font sizing based on the platform. The default font search stuff from extended is in vanilla, at least in the tk side of things AFAICT. Monaco is the default on OS X because it’s pretty much guaranteed to be there. Deja Vu is not, but I would think the font search would check for that first…
If you only want that font, it shouldn’t be too hard to change the defaults. Perhaps a better solution is to ship with the font itself on Win/Mac. I do this with PdParty on iOS which displays using Deja Vu Sans Mono ...
On Feb 11, 2017, at 11:51 PM, Alexandre Torres Porres porres@gmail.com wrote:
2017-02-12 4:00 GMT-02:00 Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com>: This was fixed in extended years ago and the font handling improvements have simply not been ported to Vanilla. Your point is clear, what is not clear is (as usual) who is going to spend the time to port Hans' working solution to vanilla and in such a way as to have it accepted.
😕
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
As a followup after checking pd-gui.tcl, the default font is Deja Vu Sans Mono in the find_default_font method, followed buy Bitstream Vera Sands Mono, Inconsolata, etc.
The problem is that this method is only called in startup if tk 8.5 is being used, as it is right now, the precompiled Vanilla is built using the older tk 8.4 Wish app so the font finding method is not used.
Alex, can you try one of my vanilla builds that uses tk 8.6? http://docs.danomatika.com/pdbuilds/ http://docs.danomatika.com/pdbuilds/
Since you have Deja Vu installed on the system, it should be picked up automatically (in theory).
On Feb 12, 2017, at 12:15 AM, Dan Wilcox danomatika@gmail.com wrote:
What I was referring to was also the pixel & font sizing based on the platform. The default font search stuff from extended is in vanilla, at least in the tk side of things AFAICT. Monaco is the default on OS X because it’s pretty much guaranteed to be there. Deja Vu is not, but I would think the font search would check for that first…
If you only want that font, it shouldn’t be too hard to change the defaults. Perhaps a better solution is to ship with the font itself on Win/Mac. I do this with PdParty on iOS which displays using Deja Vu Sans Mono ...
On Feb 11, 2017, at 11:51 PM, Alexandre Torres Porres <porres@gmail.com mailto:porres@gmail.com> wrote:
2017-02-12 4:00 GMT-02:00 Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com>: This was fixed in extended years ago and the font handling improvements have simply not been ported to Vanilla. Your point is clear, what is not clear is (as usual) who is going to spend the time to port Hans' working solution to vanilla and in such a way as to have it accepted.
😕
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
2017-02-12 5:52 GMT-02:00 Dan Wilcox danomatika@gmail.com:
As a followup after checking pd-gui.tcl, the default font is Deja Vu Sans Mono in the find_default_font method, followed buy Bitstream Vera Sands Mono, Inconsolata, etc.
The problem is that this method is only called in startup if tk 8.5 is being used, as it is right now, the precompiled Vanilla is built using the older tk 8.4 Wish app so the font finding method is not used.
Alex, can you try one of my vanilla builds that uses tk 8.6? http://docs.danomatika.com/pdbuilds/
Since you have Deja Vu installed on the system, it should be picked up automatically (in theory).
here's my test, got the tcl/tk86 pd 0.47-1 64 bits version...
first thing I notice is that fonts printed in the terminal look different, there's no warning saying it didnt find DejaVu Sans and loaded something else as well... the new tcl/tk is the left one, regular vanilla on the right!
[image: Imagem inline 1]
Onto opening a patch... now, whay I do is I get into the preferences of a GUI, and if I see DejaVu there, I know it's loaded, but what happened is that I still found MONACO in the new tcl/tk version
So I even put two labels in canvases to compare them, and, well, the new tcl/tk renders it pretty well, looks much nicer, I like it. Her'es the print. Same thing, tk86 on the left, regular on the right.
[image: Imagem inline 2]
so, anyway, if the new tk86 is loading Monaco as the font of comments in vanilla... as it seems I must say, well, it's kinda tinier!
2017-02-12 12:49 GMT-02:00 Alexandre Torres Porres porres@gmail.com:
2017-02-12 5:52 GMT-02:00 Dan Wilcox danomatika@gmail.com:
As a followup after checking pd-gui.tcl, the default font is Deja Vu Sans Mono in the find_default_font method, followed buy Bitstream Vera Sands Mono, Inconsolata, etc.
The problem is that this method is only called in startup if tk 8.5 is being used, as it is right now, the precompiled Vanilla is built using the older tk 8.4 Wish app so the font finding method is not used.
Alex, can you try one of my vanilla builds that uses tk 8.6? http://docs.danomatika.com/pdbuilds/
Since you have Deja Vu installed on the system, it should be picked up automatically (in theory).
here's my test, got the tcl/tk86 pd 0.47-1 64 bits version...
first thing I notice is that fonts printed in the terminal look different, there's no warning saying it didnt find DejaVu Sans and loaded something else as well... the new tcl/tk is the left one, regular vanilla on the right!
[image: Imagem inline 1]
Onto opening a patch... now, whay I do is I get into the preferences of a GUI, and if I see DejaVu there, I know it's loaded, but what happened is that I still found MONACO in the new tcl/tk version
So I even put two labels in canvases to compare them, and, well, the new tcl/tk renders it pretty well, looks much nicer, I like it. Her'es the print. Same thing, tk86 on the left, regular on the right.
[image: Imagem inline 2]
2017-02-12 12:51 GMT-02:00 Alexandre Torres Porres porres@gmail.com:
so, anyway, if the new tk86 is loading Monaco
it is, I deleted DVSM and reopened it, got the same result, and no warning saying (couldn't load DVSM)
so, it's monaco, and it looks smaller
This was fixed in extended years ago and the font handling improvements have simply not been ported to Vanilla. Your point is clear, what is not clear is (as usual) who is going to spend the time to port Hans' working solution to vanilla and in such a way as to have it accepted.
There is a problem with Hans' solution. It fits the boxes tightly around the fonts as measured at runtime. This makes it impossible for a user to know if the same patch with a different font will have overlapping objects on another user's machine. (Or the same font with a different font-rendering stack, or even a different version of the same stack!) Boxes should be sized based on hard-coded metrics for each font size for a chosen reference font, and then fonts measured at runtime to fit within that box. For some fonts/font sizes the best fit will inevitably leave some extra space at the right of the box inside the border. But that space is visually required to keep users from placing two boxes so close together that they overlap on a platform that renders the same font slightly wider.
Otherwise you get users caught up in a vicious cycle of breaking/fixing each other's object spacing in patches. -Jonathan
Good to know the reasoning why the pixel fiddling stuff didn’t make it over with the guy update into vanilla.
I’m seeing the padding issue with the object boxes when rendered in high dpi on OSX and now I know what it is.
I do agree with Alexandre that using the same font on all platforms would help in regards to layout in patches between OSs.
On Feb 12, 2017, at 12:20 AM, Jonathan Wilkes jancsika@yahoo.com wrote:
For some fonts/font sizes the best fit will inevitably leave some extra space at the right of the box inside the border. But that space is visually required to keep users from placing two boxes so close together that they overlap on a platform that renders the same font slightly wider.
Otherwise you get users caught up in a vicious cycle of breaking/fixing each other's object spacing in patches.
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Looks like the cavalry has arrived to the south.
Alex, do we have 44-40 ammunition for the gentlemans?
We are just holding Miller`s Bridge!!!.
@ Jonathan:
There is a problem with Hans' solution. It fits the boxes tightly around the
fonts as measured at runtime. This makes it impossible for a user to know
if the same patch with a different font will have overlapping objects on another user's machine.
If is impossible to know what happens on a different font why don’t we stick to “one” for a standard.
(Or the same font with a different font-rendering stack, or even
a different version of the same stack!)
I trust in you but this is out of scope for me. How this translate on using just one “font” on just one “vanilla”?
Mensaje telepatico asistido por maquinas.
From: Pd-list pd-list-bounces@lists.iem.at on behalf of Dan Wilcox danomatika@gmail.com Sent: Sunday, February 12, 2017 7:45 AM To: Jonathan Wilkes Cc: Pd-List Subject: Re: [PD] cross platforms issues with displaying fonts in vanilla but not in Purr Data
Good to know the reasoning why the pixel fiddling stuff didn’t make it over with the guy update into vanilla.
I’m seeing the padding issue with the object boxes when rendered in high dpi on OSX and now I know what it is.
I do agree with Alexandre that using the same font on all platforms would help in regards to layout in patches between OSs.
On Feb 12, 2017, at 12:20 AM, Jonathan Wilkes <jancsika@yahoo.commailto:jancsika@yahoo.com> wrote:
For some fonts/font sizes the best fit will inevitably leave some extra space at the right of the box inside the border. But that space is visually required to keep users from placing two boxes so close together that they overlap on a platform that renders the same font slightly wider.
Otherwise you get users caught up in a vicious cycle of breaking/fixing each other's object spacing in patches.
Dan Wilcox @danomatikahttp://twitter.com/danomatika danomatika.comhttp://danomatika.com robotcowboy.comhttp://robotcowboy.com
Bad metaphor, not a fight.
On Feb 12, 2017, at 12:52 AM, Lucas Cordiviola lucarda27@hotmail.com wrote:
We are just holding Miller`s Bridge!!!.
The actual culprit is that sys_font & sys_fontweight are set as Monaco (normal) when building for Mac and Deja Vu Sans Mono (bold) when building for the other platforms in s_main.c.
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Bad metaphor, not a fight.
You’re right!!!
Is just because there are no girls on this list. And this is a typical masculine joke.
The actual culprit is that sys_font & sys_fontweight are set as Monaco (normal) when building for Mac and Deja Vu Sans Mono (bold) when building for the other platforms in s_main.c.
How difficult is to deploy DejaVu on Mac?
On Windows it needs an installer that puts it on the c:\windows\fonts and add some registry-keys.
Mensaje telepatico asistido por maquinas.
From: Dan Wilcox danomatika@gmail.com Sent: Sunday, February 12, 2017 8:05 AM To: Lucas Cordiviola Cc: Jonathan Wilkes; Pd-List; Alexandre Torres Porres Subject: Re: [PD] cross platforms issues with displaying fonts in vanilla but not in Purr Data
Bad metaphor, not a fight.
On Feb 12, 2017, at 12:52 AM, Lucas Cordiviola <lucarda27@hotmail.commailto:lucarda27@hotmail.com> wrote:
We are just holding Miller`s Bridge!!!.
The actual culprit is that sys_font & sys_fontweight are set as Monaco (normal) when building for Mac and Deja Vu Sans Mono (bold) when building for the other platforms in s_main.c.
Dan Wilcox @danomatikahttp://twitter.com/danomatika danomatika.comhttp://danomatika.com robotcowboy.comhttp://robotcowboy.com
Or on Windows you can manually install it by a double-click on the TTF and select to install.
Mensaje telepatico asistido por maquinas.
From: Pd-list pd-list-bounces@lists.iem.at on behalf of Lucas Cordiviola lucarda27@hotmail.com Sent: Sunday, February 12, 2017 8:21 AM To: Dan Wilcox; Pd-List; Jonathan Wilkes; Alexandre Torres Porres Subject: Re: [PD] cross platforms issues with displaying fonts in vanilla but not in Purr Data
Bad metaphor, not a fight.
You’re right!!!
Is just because there are no girls on this list. And this is a typical masculine joke.
The actual culprit is that sys_font & sys_fontweight are set as Monaco (normal) when building for Mac and Deja Vu Sans Mono (bold) when building for the other platforms in s_main.c.
How difficult is to deploy DejaVu on Mac?
On Windows it needs an installer that puts it on the c:\windows\fonts and add some registry-keys.
Mensaje telepatico asistido por maquinas.
From: Dan Wilcox danomatika@gmail.com Sent: Sunday, February 12, 2017 8:05 AM To: Lucas Cordiviola Cc: Jonathan Wilkes; Pd-List; Alexandre Torres Porres Subject: Re: [PD] cross platforms issues with displaying fonts in vanilla but not in Purr Data
Bad metaphor, not a fight.
On Feb 12, 2017, at 12:52 AM, Lucas Cordiviola <lucarda27@hotmail.commailto:lucarda27@hotmail.com> wrote:
We are just holding Miller`s Bridge!!!.
The actual culprit is that sys_font & sys_fontweight are set as Monaco (normal) when building for Mac and Deja Vu Sans Mono (bold) when building for the other platforms in s_main.c.
Dan Wilcox @danomatikahttp://twitter.com/danomatika danomatika.comhttp://danomatika.com robotcowboy.comhttp://robotcowboy.com
On Feb 12, 2017, at 1:21 AM, Lucas Cordiviola lucarda27@hotmail.com wrote:
Bad metaphor, not a fight.
You’re right!!!
Is just because there are no girls on this list. And this is a typical masculine joke.
Oh I got it, didn’t want it. There are women (not girls) on this list.
The actual culprit is that sys_font & sys_fontweight are set as Monaco (normal) when building for Mac and Deja Vu Sans Mono (bold) when building for the other platforms in s_main.c.
How difficult is to deploy DejaVu on Mac?
On Windows it needs an installer that puts it on the c:\windows\fonts and add some registry-keys.
Typically, add a key to the app bundle Info.plist and include the font in the app bundle's Resource folder. This means the font does not have to be installed system- or user- wide but only used by the app itself. This assumes Tk’s handling of app bundles picks up on registered fonts from the plist (it should).
As for Windows, it looks like it’s possible to load a font that comes with the app (the Windows API alls this a Private Font Collection https://msdn.microsoft.com/en-us/library/windows/desktop/ms533820(v=vs.85).aspx): http://code.activestate.com/lists/tcl-core/8158/#sthash.qJEhQALT.dpuf http://code.activestate.com/lists/tcl-core/8158/#sthash.qJEhQALT.dpuf
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Cool,
Do you think this needs further testing before implementation?
Alex can come with some news tomorrow testing DejaVu on all platforms.
Mensaje telepatico asistido por maquinas.
From: Dan Wilcox danomatika@gmail.com Sent: Sunday, February 12, 2017 8:39 AM To: Lucas Cordiviola Cc: Pd-List; Jonathan Wilkes; Alexandre Torres Porres Subject: Re: [PD] cross platforms issues with displaying fonts in vanilla but not in Purr Data
On Feb 12, 2017, at 1:21 AM, Lucas Cordiviola <lucarda27@hotmail.commailto:lucarda27@hotmail.com> wrote:
Bad metaphor, not a fight.
You’re right!!!
Is just because there are no girls on this list. And this is a typical masculine joke.
Oh I got it, didn’t want it. There are women (not girls) on this list.
The actual culprit is that sys_font & sys_fontweight are set as Monaco (normal) when building for Mac and Deja Vu Sans Mono (bold) when building for the other platforms in s_main.c.
How difficult is to deploy DejaVu on Mac?
On Windows it needs an installer that puts it on the c:\windows\fonts and add some registry-keys.
Typically, add a key to the app bundle Info.plist and include the font in the app bundle's Resource folder. This means the font does not have to be installed system- or user- wide but only used by the app itself. This assumes Tk’s handling of app bundles picks up on registered fonts from the plist (it should).
As for Windows, it looks like it’s possible to load a font that comes with the app (the Windows API alls this a Private Font Collectionhttps://msdn.microsoft.com/en-us/library/windows/desktop/ms533820(v=vs.85).aspx): http://code.activestate.com/lists/tcl-core/8158/#sthash.qJEhQALT.dpuf
Dan Wilcox @danomatikahttp://twitter.com/danomatika danomatika.comhttp://danomatika.com robotcowboy.comhttp://robotcowboy.com
As for comparisons, here’s the same patch using Deja Vu Sans Mono and Monaco, both with Tk 8.4 & with Tk 8.6 Retina HiDPI rendering: https://flic.kr/p/QLGphN https://flic.kr/p/QLGphN (zoom in or download & view at full size)
Jonathan: One of the remaining problems I have with the Tk 8.6 build is the padding added to the object box width in HiDPI. Any clues on what to look into to fix this? The object arguments are clearly the same width… or appear to be.
On Feb 12, 2017, at 2:03 AM, Lucas Cordiviola lucarda27@hotmail.com wrote:
Cool,
Do you think this needs further testing before implementation?
Yup.
At the very least, changing the default font for macOS users means causing possible layout issues in their patches, especially when it comes to GOP. I loaded a couple of my fancier ones and noticed a few issues such as symbol atoms not appearing on GOP since they are slightly wider using Deja Vu Sans Mono than with Monaco. I noticed this in the past when I transitioned from Linux to Mac as well, except in that case I had more room.
Another issue is that, for many, the rendering of a bolded DVSM will simply look *ulgy* to those used to a normal-weight Monaco, especially if they never used an earlier version of Pd or Pd on Linux.
OTOH having consistent font width on all platforms would be a big plus overall. Changing the default font on Mac could be a Pd compatibility mode option as well.
IMHO I think the default font shouldn’t really be set in the C core anyway but in the Tcl which already detects the platforms.
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Feb 12, 2017, at 2:39 AM, Dan Wilcox danomatika@gmail.com wrote:
As for comparisons, here’s the same patch using Deja Vu Sans Mono and Monaco, both with Tk 8.4 & with Tk 8.6 Retina HiDPI rendering: https://flic.kr/p/QLGphN https://flic.kr/p/QLGphN (zoom in or download & view at full size)
Also, here’s an animated GIF comparing DJVSM vs. Monaco: https://www.flickr.com/photos/danomatika/32854359825/sizes/o/ https://www.flickr.com/photos/danomatika/32854359825/sizes/o/
Jonathan: One of the remaining problems I have with the Tk 8.6 build is the padding added to the object box width in HiDPI. Any clues on what to look into to fix this? The object arguments are clearly the same width… or appear to be.
Here’s an animated GIF showing width difference using the same font on Tk 8.4 & 8.6: https://www.flickr.com/photos/danomatika/32854378005/sizes/o/ https://www.flickr.com/photos/danomatika/32854378005/sizes/o/
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Anyway, it’s very late and I’m still wondering how I find myself working on this after a Saturday spent on a glacier at 11000 ft (Colorado!). :)
I may look into this again sometime later this week.
On Feb 12, 2017, at 2:54 AM, Dan Wilcox danomatika@gmail.com wrote:
On Feb 12, 2017, at 2:39 AM, Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com> wrote:
As for comparisons, here’s the same patch using Deja Vu Sans Mono and Monaco, both with Tk 8.4 & with Tk 8.6 Retina HiDPI rendering: https://flic.kr/p/QLGphN https://flic.kr/p/QLGphN (zoom in or download & view at full size)
Also, here’s an animated GIF comparing DJVSM vs. Monaco: https://www.flickr.com/photos/danomatika/32854359825/sizes/o/ https://www.flickr.com/photos/danomatika/32854359825/sizes/o/
Jonathan: One of the remaining problems I have with the Tk 8.6 build is the padding added to the object box width in HiDPI. Any clues on what to look into to fix this? The object arguments are clearly the same width… or appear to be.
Here’s an animated GIF showing width difference using the same font on Tk 8.4 & 8.6: https://www.flickr.com/photos/danomatika/32854378005/sizes/o/ https://www.flickr.com/photos/danomatika/32854378005/sizes/o/
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
About that padding - the Tcl code sends Pd the font metrics on startup, and Pd follows them in setting the dimensions of boxes. So I guess the new version of Tcl/Tk is overstating the font width by one pixel. Perhaps height is also wrong in the same way (make a mesages box with 20-ish lines in it and see if the box is 20 pixels too tall).
cheers M
On Sun, Feb 12, 2017 at 02:39:32AM -0700, Dan Wilcox wrote:
As for comparisons, here’s the same patch using Deja Vu Sans Mono and Monaco, both with Tk 8.4 & with Tk 8.6 Retina HiDPI rendering: https://flic.kr/p/QLGphN https://flic.kr/p/QLGphN (zoom in or download & view at full size)
Jonathan: One of the remaining problems I have with the Tk 8.6 build is the padding added to the object box width in HiDPI. Any clues on what to look into to fix this? The object arguments are clearly the same width… or appear to be.
Looks like you’re right. I checked the debug output of the fit_font_into_metrics proc:
In Tk 8.4 with Monaco, I get
6 4 7 7 4 9 8 5 10 9 7 11 10 6 13 …
And in Tk 8.6:
6 4 9 7 5 10 8 5 11 9 6 12 10 7 14 …
I wonder if this is a rounding error?
On Feb 12, 2017, at 9:20 AM, Miller Puckette msp@ucsd.edu wrote:
About that padding - the Tcl code sends Pd the font metrics on startup, and Pd follows them in setting the dimensions of boxes. So I guess the new version of Tcl/Tk is overstating the font width by one pixel. Perhaps height is also wrong in the same way (make a mesages box with 20-ish lines in it and see if the box is 20 pixels too tall).
cheers M
On Sun, Feb 12, 2017 at 02:39:32AM -0700, Dan Wilcox wrote:
As for comparisons, here’s the same patch using Deja Vu Sans Mono and Monaco, both with Tk 8.4 & with Tk 8.6 Retina HiDPI rendering: https://flic.kr/p/QLGphN https://flic.kr/p/QLGphN (zoom in or download & view at full size)
Jonathan: One of the remaining problems I have with the Tk 8.6 build is the padding added to the object box width in HiDPI. Any clues on what to look into to fix this? The object arguments are clearly the same width… or appear to be.
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On further digging, I think the culprit is a slightly different tk scaling value:
Tk 8.4 -> scaling: 0.999016715831
Tk 8.6 -> scaling: 0.9990167158308751
Looks like a precision/rounding issue after all w/ 11 digits versus 17.
On Feb 15, 2017, at 12:16 AM, Dan Wilcox danomatika@gmail.com wrote:
Looks like you’re right. I checked the debug output of the fit_font_into_metrics proc:
In Tk 8.4 with Monaco, I get
6 4 7 7 4 9 8 5 10 9 7 11 10 6 13 …
And in Tk 8.6:
6 4 9 7 5 10 8 5 11 9 6 12 10 7 14 …
I wonder if this is a rounding error?
On Feb 12, 2017, at 9:20 AM, Miller Puckette <msp@ucsd.edu mailto:msp@ucsd.edu> wrote:
About that padding - the Tcl code sends Pd the font metrics on startup, and Pd follows them in setting the dimensions of boxes. So I guess the new version of Tcl/Tk is overstating the font width by one pixel. Perhaps height is also wrong in the same way (make a mesages box with 20-ish lines in it and see if the box is 20 pixels too tall).
cheers M
On Sun, Feb 12, 2017 at 02:39:32AM -0700, Dan Wilcox wrote:
As for comparisons, here’s the same patch using Deja Vu Sans Mono and Monaco, both with Tk 8.4 & with Tk 8.6 Retina HiDPI rendering: https://flic.kr/p/QLGphN https://flic.kr/p/QLGphN <https://flic.kr/p/QLGphN https://flic.kr/p/QLGphN> (zoom in or download & view at full size)
Jonathan: One of the remaining problems I have with the Tk 8.6 build is the padding added to the object box width in HiDPI. Any clues on what to look into to fix this? The object arguments are clearly the same width… or appear to be.
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
I could be wrong but I believe that when you ask for a negative font size that inhibits scaling... so the line in pd-gui.tcl:
set foo [list $::font_family -$fsize bold]
is asking for pixel-deterministic font sizes.
I think that TCL/TK 8.6 is in fact misrepresenting the true font size by 1 pixel. What I don't know is whether to throw in a workaround (test for TCL version and adjust ifit's 8.6???) or to try to dig up the problem in tcl/tk itself...
cheers Miller
On Wed, Feb 15, 2017 at 12:52:00AM -0700, Dan Wilcox wrote:
On further digging, I think the culprit is a slightly different tk scaling value:
Tk 8.4 -> scaling: 0.999016715831
Tk 8.6 -> scaling: 0.9990167158308751
Looks like a precision/rounding issue after all w/ 11 digits versus 17.
On Feb 15, 2017, at 12:16 AM, Dan Wilcox danomatika@gmail.com wrote:
Looks like you’re right. I checked the debug output of the fit_font_into_metrics proc:
In Tk 8.4 with Monaco, I get
6 4 7 7 4 9 8 5 10 9 7 11 10 6 13 …
And in Tk 8.6:
6 4 9 7 5 10 8 5 11 9 6 12 10 7 14 …
I wonder if this is a rounding error?
On Feb 12, 2017, at 9:20 AM, Miller Puckette <msp@ucsd.edu mailto:msp@ucsd.edu> wrote:
About that padding - the Tcl code sends Pd the font metrics on startup, and Pd follows them in setting the dimensions of boxes. So I guess the new version of Tcl/Tk is overstating the font width by one pixel. Perhaps height is also wrong in the same way (make a mesages box with 20-ish lines in it and see if the box is 20 pixels too tall).
cheers M
On Sun, Feb 12, 2017 at 02:39:32AM -0700, Dan Wilcox wrote:
As for comparisons, here’s the same patch using Deja Vu Sans Mono and Monaco, both with Tk 8.4 & with Tk 8.6 Retina HiDPI rendering: https://flic.kr/p/QLGphN https://flic.kr/p/QLGphN <https://flic.kr/p/QLGphN https://flic.kr/p/QLGphN> (zoom in or download & view at full size)
Jonathan: One of the remaining problems I have with the Tk 8.6 build is the padding added to the object box width in HiDPI. Any clues on what to look into to fix this? The object arguments are clearly the same width… or appear to be.
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
2017-02-15 14:19 GMT-02:00 Miller Puckette msp@ucsd.edu:
I could be wrong but I believe that when you ask for a negative font size that inhibits scaling... so the line in pd-gui.tcl:
set foo [list $::font_family -$fsize bold]
Actually, we just fixed such an issue in cyclone with that, regarding [cyclone/comment] we were seeing issues in cross platforms, where fonts in windows/linux were much greater/bigger than in Mac OS.
So Matt did that trick and it fixed it!!!
I could be wrong but I believe that when you ask for a negative font size
that inhibits scaling... so the line in pd-gui.tcl:
negative font-size numbers in tk mean pixel sizing instead of point sizing.
set foo [list $::font_family -$fsize bold]
is asking for pixel-deterministic font sizes.
Pixel sizes do not guarantee that the text will fit into a particular pixel-based sizing spec.
I think that TCL/TK 8.6 is in fact misrepresenting the true font size by 1
pixel. What I don't know is whether to throw in a workaround (test for TCL version and adjust ifit's 8.6???) or to try to dig up the problem in tcl/tk itself... Determine the sizes for object and message boxes using fontspec heights/widths instead of the ones particular to the font tcl/tk measured. Otherwise users will not be able to tell the difference between a font-rendering bug on their system and a patch where the author happened to create collisions. -Jonathan
cheers Miller
On Wed, Feb 15, 2017 at 12:52:00AM -0700, Dan Wilcox wrote:
On further digging, I think the culprit is a slightly different tk scaling value:
Tk 8.4 -> scaling: 0.999016715831
Tk 8.6 -> scaling: 0.9990167158308751
Looks like a precision/rounding issue after all w/ 11 digits versus 17.
On Feb 15, 2017, at 12:16 AM, Dan Wilcox danomatika@gmail.com wrote:
Looks like you’re right. I checked the debug output of the fit_font_into_metrics proc:
In Tk 8.4 with Monaco, I get
6 4 7 7 4 9 8 5 10 9 7 11 10 6 13 …
And in Tk 8.6:
6 4 9 7 5 10 8 5 11 9 6 12 10 7 14 …
I wonder if this is a rounding error?
On Feb 12, 2017, at 9:20 AM, Miller Puckette <msp@ucsd.edu mailto:msp@ucsd.edu> wrote:
About that padding - the Tcl code sends Pd the font metrics on startup, and Pd follows them in setting the dimensions of boxes. So I guess the new version of Tcl/Tk is overstating the font width by one pixel. Perhaps height is also wrong in the same way (make a mesages box with 20-ish lines in it and see if the box is 20 pixels too tall).
cheers M
On Sun, Feb 12, 2017 at 02:39:32AM -0700, Dan Wilcox wrote:
As for comparisons, here’s the same patch using Deja Vu Sans Mono and Monaco, both with Tk 8.4 & with Tk 8.6 Retina HiDPI rendering: https://flic.kr/p/QLGphN https://flic.kr/p/QLGphN <https://flic.kr/p/QLGphN https://flic.kr/p/QLGphN> (zoom in or download & view at full size)
Jonathan: One of the remaining problems I have with the Tk 8.6 build is the padding added to the object box width in HiDPI. Any clues on what to look into to fix this? The object arguments are clearly the same width… or appear to be.
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
As for comparisons, here’s the same patch using Deja Vu Sans Mono and Monaco, both with Tk 8.4 & with Tk 8.6 Retina HiDPI rendering: https://flic.kr/p/QLGphN%C2%A0(zoom in or download & view at full size)
Jonathan: One of the remaining problems I have with the Tk 8.6 build is the padding added to the object box width in HiDPI. Any clues on what to look into to fix this? The object arguments are clearly the same width… or appear to be.
Pd Vanilla has a different font-sizing/box-sizing algorithm than the one I described. Instead of fitting font sizes to a spec, it amends the spec to accommodate the actual font sizes.
Look at the Tk 8.6 DejuVu Sans Mono bold retina text, for example. Even if you had no padding, the text "tabread~ 29-envelope" is actually wider than the box that contains that text in all the other examples. Probably Vanilla works that way because of the limitation of integer-based font sizing in Tk. Even though the text in that example is wider than the others, it still appears to my eye to be roughly similar size. If instead you kept the box width constant and chose the next smallest integer to fit that text, the whole patch would appear to contain smaller text than other examples. -Jonathan
Another issue is that, for many, the rendering of a bolded DVSM will simply look *ulgy* to those used to a normal-weight Monaco, especially if they never used an earlier version of Pd or Pd on Linux.
IMO the default cross platform font should NOT be Bold. As Dan said OSX users will most likely find it ugly, and it was not bold in Pd-extended nor is in Purr-Data.
OTOH having consistent font width on all platforms would be a big plus overall. Changing the default font on Mac could be a Pd compatibility mode option as well.
Yes, anyway is rather easy to switch back to Monaco from Pds startupflags. And to go back to DVMS you simply delete the flag. (we have trouble with font names with spaces on Mac & Windows)
How difficult is to deploy DejaVu on Mac?
Typically, add a key to the app bundle Info.plist and include the font in the app bundle's Resource folder. This means the font does not have to be installed system- or user- wide but only used by the app itself. This assumes Tk’s handling of app bundles picks up on registered fonts from the plist (it should).
As for Windows, it looks like it’s possible to load a font that comes with the app (the Windows API alls this a:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms533820(v=vs.85).a...
http://code.activestate.com/lists/tcl-core/8158/#sthash.qJEhQALT.dpuf
@Dan:
The Tcl thing is just for Windows? Or Cross-platform?
On the Tcl link the guy is asking for something that works for Windows & Linux.
Mensaje telepatico asistido por maquinas.
On Feb 12, 2017, at 6:49 PM, Lucas Cordiviola lucarda27@hotmail.com wrote:
Another issue is that, for many, the rendering of a bolded DVSM will simply look *ulgy* to those used to a normal-weight Monaco, especially if they never used an earlier version of Pd or Pd on Linux.
IMO the default cross platform font should NOT be Bold. As Dan said OSX users will most likely find it ugly, and it was not bold in Pd-extended nor is in Purr-Data.
I tested with bold as that is the default font weight for vanilla on Linux AFAICT.
How difficult is to deploy DejaVu on Mac?
Typically, add a key to the app bundle Info.plist and include the font in the app bundle's Resource folder. This means the font does not have to be installed system- or user- wide but only used by the app itself. This assumes Tk’s handling of app bundles picks up on registered fonts from the plist (it should).
As for Windows, it looks like it’s possible to load a font that comes with the app (the Windows API alls this a:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms533820(v=vs.85).a... https://msdn.microsoft.com/en-us/library/windows/desktop/ms533820(v=vs.85).aspx
http://code.activestate.com/lists/tcl-core/8158/#sthash.qJEhQALT.dpuf http://code.activestate.com/lists/tcl-core/8158/#sthash.qJEhQALT.dpuf
@Dan:
The Tcl thing is just for Windows?
Yes as it’s using the Window’s API.
Or Cross-platform?
No. See above.
I know the Mac solution. Deja Vu is usually installed on Linux systems and, if not, can be an install requirement by whatever package manager is being used. There is no need to distribute and install a copy of the font on Linux.
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Ok,
Following Dan`s suggestion to ship & use a font without installing it, I came to a very straight-forward method for w32.
Tested & working.
It uses a Tcl Windows API extension. (600KB)
twapi web: http://twapi.sourceforge.net/v4.1/installation.html
twapi package: https://sourceforge.net/projects/twapi/files/Current%20Releases/Tcl%20Window...
added lines on "pd-gui.tcl" @line 24:
# adding dejavu fonts on mswindows package require twapi twapi::AddFontResourceEx DejaVuSansMono.ttf twapi::AddFontResourceEx DejaVuSansMono-Bold.ttf
0000000
Don't know how to exclude this "package require" for the other OSs. The .ttf were placed on pd/bin for simplicity.
Mensaje telepatico asistido por maquinas.
From: Dan Wilcox danomatika@gmail.com Sent: Monday, February 13, 2017 5:06 AM To: Lucas Cordiviola Cc: Jonathan Wilkes; Alexandre Torres Porres; Pd-List; Miller Puckette Subject: Re: [PD] cross platforms issues with displaying fonts in vanilla but not in Purr Data
On Feb 12, 2017, at 6:49 PM, Lucas Cordiviola <lucarda27@hotmail.commailto:lucarda27@hotmail.com> wrote:
Another issue is that, for many, the rendering of a bolded DVSM will simply look *ulgy* to those used to a normal-weight Monaco, especially if they never used an earlier version of Pd or Pd on Linux.
IMO the default cross platform font should NOT be Bold. As Dan said OSX users will most likely find it ugly, and it was not bold in Pd-extended nor is in Purr-Data.
I tested with bold as that is the default font weight for vanilla on Linux AFAICT.
How difficult is to deploy DejaVu on Mac?
Typically, add a key to the app bundle Info.plist and include the font in the app bundle's Resource folder. This means the font does not have to be installed system- or user- wide but only used by the app itself. This assumes Tk’s handling of app bundles picks up on registered fonts from the plist (it should).
As for Windows, it looks like it’s possible to load a font that comes with the app (the Windows API alls this a:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms533820(v=vs.85).a...
http://code.activestate.com/lists/tcl-core/8158/#sthash.qJEhQALT.dpuf
@Dan:
The Tcl thing is just for Windows?
Yes as it’s using the Window’s API.
Or Cross-platform?
No. See above.
I know the Mac solution. Deja Vu is usually installed on Linux systems and, if not, can be an install requirement by whatever package manager is being used. There is no need to distribute and install a copy of the font on Linux.
Dan Wilcox @danomatikahttp://twitter.com/danomatika danomatika.comhttp://danomatika.com robotcowboy.comhttp://robotcowboy.com
More:
For this test i used “twapi-bin-4.1.27.zip ” and extracted it to pd\lib.
Mensaje telepatico asistido por maquinas.
From: Pd-list pd-list-bounces@lists.iem.at on behalf of Lucas Cordiviola lucarda27@hotmail.com Sent: Monday, February 13, 2017 4:40 PM To: Dan Wilcox; Miller Puckette Cc: Pd-List Subject: Re: [PD] cross platforms issues with displaying fonts in vanilla but not in Purr Data
Ok,
Following Dan`s suggestion to ship & use a font without installing it, I came to a very straight-forward method for w32.
Tested & working.
It uses a Tcl Windows API extension. (600KB)
twapi web: http://twapi.sourceforge.net/v4.1/installation.html
twapi package: https://sourceforge.net/projects/twapi/files/Current%20Releases/Tcl%20Window...
added lines on "pd-gui.tcl" @line 24:
# adding dejavu fonts on mswindows package require twapi twapi::AddFontResourceEx DejaVuSansMono.ttf twapi::AddFontResourceEx DejaVuSansMono-Bold.ttf
0000000
Don't know how to exclude this "package require" for the other OSs. The .ttf were placed on pd/bin for simplicity.
Mensaje telepatico asistido por maquinas.
From: Dan Wilcox danomatika@gmail.com Sent: Monday, February 13, 2017 5:06 AM To: Lucas Cordiviola Cc: Jonathan Wilkes; Alexandre Torres Porres; Pd-List; Miller Puckette Subject: Re: [PD] cross platforms issues with displaying fonts in vanilla but not in Purr Data
On Feb 12, 2017, at 6:49 PM, Lucas Cordiviola <lucarda27@hotmail.commailto:lucarda27@hotmail.com> wrote:
Another issue is that, for many, the rendering of a bolded DVSM will simply look *ulgy* to those used to a normal-weight Monaco, especially if they never used an earlier version of Pd or Pd on Linux.
IMO the default cross platform font should NOT be Bold. As Dan said OSX users will most likely find it ugly, and it was not bold in Pd-extended nor is in Purr-Data.
I tested with bold as that is the default font weight for vanilla on Linux AFAICT.
How difficult is to deploy DejaVu on Mac?
Typically, add a key to the app bundle Info.plist and include the font in the app bundle's Resource folder. This means the font does not have to be installed system- or user- wide but only used by the app itself. This assumes Tk’s handling of app bundles picks up on registered fonts from the plist (it should).
As for Windows, it looks like it’s possible to load a font that comes with the app (the Windows API alls this a:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms533820(v=vs.85).a...
http://code.activestate.com/lists/tcl-core/8158/#sthash.qJEhQALT.dpuf
@Dan:
The Tcl thing is just for Windows?
Yes as it’s using the Window’s API.
Or Cross-platform?
No. See above.
I know the Mac solution. Deja Vu is usually installed on Linux systems and, if not, can be an install requirement by whatever package manager is being used. There is no need to distribute and install a copy of the font on Linux.
Dan Wilcox @danomatikahttp://twitter.com/danomatika danomatika.comhttp://danomatika.com robotcowboy.comhttp://robotcowboy.com
Cool, good to know that in theory it works. I also found a related solution which uses a different extension do the same thing: http://wiki.tcl.tk/22262 http://wiki.tcl.tk/22262
However, I’d say that requiring a tcl/tk extension may not be the best overall solution since historically Pd has avoided requiring anything beyond the base tcl/tk.
A possible best approach is take the example C code for the forum post and make a *tiny* custom extension that is built only on Windows and loaded by the tk gui in order to load the private font. I don’t think we can simply add the font loading code to the core itself since it’s a separate process from the gui.
In any case, this is something I can look into after I put together a triple boot machine to test some things on different platforms, including the vanilla autotools build on win.
On Feb 13, 2017, at 10:43 AM, Lucas Cordiviola lucarda27@hotmail.com wrote:
Following Dan`s suggestion to ship & use a font without installing it, I came to a very straight-forward method for w32.
Tested & working.
It uses a Tcl Windows API extension. (600KB)
twapi web: http://twapi.sourceforge.net/v4.1/installation.html http://twapi.sourceforge.net/v4.1/installation.html
twapi package: https://sourceforge.net/projects/twapi/files/Current%20Releases/Tcl%20Window... https://sourceforge.net/projects/twapi/files/Current%20Releases/Tcl%20Windows%20API/twapi-4.1.27/
added lines on "pd-gui.tcl" @line 24:
# adding dejavu fonts on mswindows package require twapi twapi::AddFontResourceEx DejaVuSansMono.ttf twapi::AddFontResourceEx DejaVuSansMono-Bold.ttf
0000000
Don't know how to exclude this "package require" for the other OSs. The .ttf were placed on pd/bin for simplicity.
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Hi Dan,
I've just visited the pure-data repo on github and it seems like your auto-tools branch is now merged in. I cloned the repo and I could compile without errors (last time I got stuck in the extra folder, if you remember) but the only files in the bin folder are: pd.exe, pd-gui, pdreceive.exe and pdsend.exe. So I'm missing some files, most notably pd.dll and wish85.exe. Any ideas? Not that it's urgent, just wanted to point it out. I'm on Windows 7 + msys2 and I'm always happy to test stuff.
Christof
Yes, it doesn’t work completely on windows yet. I’m going to setup a windows box to smooth that out. In the meantime, IOhannes might have some info on building the pd.dll.
On Feb 13, 2017, at 5:05 PM, Christof Ressi christof.ressi@gmx.at wrote:
Hi Dan,
I've just visited the pure-data repo on github and it seems like your auto-tools branch is now merged in. I cloned the repo and I could compile without errors (last time I got stuck in the extra folder, if you remember) but the only files in the bin folder are: pd.exe, pd-gui, pdreceive.exe and pdsend.exe. So I'm missing some files, most notably pd.dll and wish85.exe. Any ideas? Not that it's urgent, just wanted to point it out. I'm on Windows 7 + msys2 and I'm always happy to test stuff.
Christof
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Thanks a lot, Dan! Maybe throw a message on the list once you think it shall work, so those with a Windows machine can test.
Christof
Gesendet: Dienstag, 14. Februar 2017 um 01:06 Uhr Von: "Dan Wilcox" danomatika@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: pd-list pd-list@iem.at Betreff: Re: compiling Pd on Windows 7 with MinGW
Yes, it doesn’t work completely on windows yet. I’m going to setup a windows box to smooth that out. In the meantime, IOhannes might have some info on building the pd.dll.
On Feb 13, 2017, at 5:05 PM, Christof Ressi <christof.ressi@gmx.at[mailto:christof.ressi@gmx.at]> wrote:
Hi Dan,
I've just visited the pure-data repo on github and it seems like your auto-tools branch is now merged in. I cloned the repo and I could compile without errors (last time I got stuck in the extra folder, if you remember) but the only files in the bin folder are: pd.exe, pd-gui, pdreceive.exe and pdsend.exe. So I'm missing some files, most notably pd.dll and wish85.exe. Any ideas? Not that it's urgent, just wanted to point it out. I'm on Windows 7 + msys2 and I'm always happy to test stuff.
Christof
Dan Wilcox @danomatika[http://twitter.com/danomatika] danomatika.com[http://danomatika.com] robotcowboy.com[http://robotcowboy.com]
Just to confirm: your build setup is msys2 with gcc, getetext, & autotools installed?
I have a Windows install for testing now and am at the same point you are. :)
On Feb 13, 2017, at 5:05 PM, Christof Ressi christof.ressi@gmx.at wrote:
Hi Dan,
I've just visited the pure-data repo on github and it seems like your auto-tools branch is now merged in. I cloned the repo and I could compile without errors (last time I got stuck in the extra folder, if you remember) but the only files in the bin folder are: pd.exe, pd-gui, pdreceive.exe and pdsend.exe. So I'm missing some files, most notably pd.dll and wish85.exe. Any ideas? Not that it's urgent, just wanted to point it out. I'm on Windows 7 + msys2 and I'm always happy to test stuff.
Christof
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Ok, cool.
I add the previous code links here for us to remember:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms533820(v=vs.85).a...
http://code.activestate.com/lists/tcl-core/8158/#sthash.qJEhQALT.dpufhttp://code.activestate.com/lists/tcl-core/8158/#sthash.qJEhQALT.dpuf
Mensaje telepatico asistido por maquinas.
From: Dan Wilcox danomatika@gmail.com Sent: Monday, February 13, 2017 8:48 PM To: Lucas Cordiviola Cc: Miller Puckette; Pd-List Subject: Re: DejaVu Font: Shipping & using on W32
Cool, good to know that in theory it works. I also found a related solution which uses a different extension do the same thing: http://wiki.tcl.tk/22262
However, I’d say that requiring a tcl/tk extension may not be the best overall solution since historically Pd has avoided requiring anything beyond the base tcl/tk.
A possible best approach is take the example C code for the forum post and make a *tiny* custom extension that is built only on Windows and loaded by the tk gui in order to load the private font. I don’t think we can simply add the font loading code to the core itself since it’s a separate process from the gui.
In any case, this is something I can look into after I put together a triple boot machine to test some things on different platforms, including the vanilla autotools build on win.
On Feb 13, 2017, at 10:43 AM, Lucas Cordiviola <lucarda27@hotmail.commailto:lucarda27@hotmail.com> wrote:
Following Dan`s suggestion to ship & use a font without installing it, I came to a very straight-forward method for w32.
Tested & working.
It uses a Tcl Windows API extension. (600KB)
twapi web: http://twapi.sourceforge.net/v4.1/installation.html
twapi package: https://sourceforge.net/projects/twapi/files/Current%20Releases/Tcl%20Window...
added lines on "pd-gui.tcl" @line 24:
# adding dejavu fonts on mswindows package require twapi twapi::AddFontResourceEx DejaVuSansMono.ttf twapi::AddFontResourceEx DejaVuSansMono-Bold.ttf
0000000
Don't know how to exclude this "package require" for the other OSs. The .ttf were placed on pd/bin for simplicity.
Dan Wilcox @danomatikahttp://twitter.com/danomatika danomatika.comhttp://danomatika.com robotcowboy.comhttp://robotcowboy.com
howdy, I'll insist here as well, again, I like that we're looking in to how to install the same fonts for all platforms, but I'm really concerned about patches not looking the same in vanilla and in Extended/Purr Data.
what are the challenges in making it not only work well in cross platforms, but also in this different pd flavors?
cheers
2017-02-14 9:35 GMT-02:00 Lucas Cordiviola lucarda27@hotmail.com:
Ok, cool.
I add the previous code links here for us to remember:
https://msdn.microsoft.com/en-us/library/windows/desktop/ ms533820(v=vs.85).aspx
http://code.activestate.com/lists/tcl-core/8158/#sthash.qJEhQALT.dpuf http://code.activestate.com/lists/tcl-core/8158/#sthash.qJEhQALT.dpuf
Mensaje telepatico asistido por maquinas.
*From:* Dan Wilcox danomatika@gmail.com *Sent:* Monday, February 13, 2017 8:48 PM *To:* Lucas Cordiviola *Cc:* Miller Puckette; Pd-List *Subject:* Re: DejaVu Font: Shipping & using on W32
Cool, good to know that in theory it works. I also found a related solution which uses a different extension do the same thing: http://wiki.tcl.tk/22262
However, I’d say that requiring a tcl/tk extension may not be the best overall solution since historically Pd has avoided requiring anything beyond the base tcl/tk.
A possible best approach is take the example C code for the forum post and make a *tiny* custom extension that is built only on Windows and loaded by the tk gui in order to load the private font. I don’t think we can simply add the font loading code to the core itself since it’s a separate process from the gui.
In any case, this is something I can look into after I put together a triple boot machine to test some things on different platforms, including the vanilla autotools build on win.
On Feb 13, 2017, at 10:43 AM, Lucas Cordiviola lucarda27@hotmail.com wrote:
Following Dan`s suggestion to ship & use a font without installing it, I came to a very straight-forward method for w32.
Tested & working.
It uses a Tcl Windows API extension. (600KB)
twapi web: http://twapi.sourceforge.net/v4.1/installation.html
twapi package: https://sourceforge.net/projects/twapi/files/Current% 20Releases/Tcl%20Windows%20API/twapi-4.1.27/
added lines on "pd-gui.tcl" @line 24:
# adding dejavu fonts on mswindows package require twapi twapi::AddFontResourceEx DejaVuSansMono.ttf twapi::AddFontResourceEx DejaVuSansMono-Bold.ttf
0000000
Don't know how to exclude this "package require" for the other OSs. The .ttf were placed on pd/bin for simplicity.
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com robotcowboy.com
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list
On 12/02/17 16:21, Lucas Cordiviola wrote:
there are no girls on this list.
False.
This is a harmful falsehood to propagate.
Cheers,
Chris.
2017-02-12 6:05 GMT-02:00 Dan Wilcox danomatika@gmail.com:
The actual culprit is that sys_font & sys_fontweight are set as Monaco (normal) when building for Mac and Deja Vu Sans Mono (bold) when building for the other platforms in s_main.c.
cool, that's what I noticed, at least this could be simply worked out, right?
I think they both need to be either normal or bold by default in every system, and I like "normal" much better, that's how it's always been in Extended and now in Purr Data as well anyway ;)
cheers
I added two builds that include Dejavu Sans Mono within the app bundle, so it works without needing to manually install the font: http://docs.danomatika.com/pdbuilds/ http://docs.danomatika.com/pdbuilds/
The font itself is only 320Kb. This seems to be working for me using both Tk 8.4 & 8.6, although the latter still exhibit the object box width issue (a separate problem).
Technically, as I mentioned in an earlier email, the solution is to add a key to the app bundle Info.plist and include the font file in the app bundle’s resource list. When the app is launched, the font is loaded automatically and available for use with Tk.
On Feb 12, 2017, at 8:23 AM, Alexandre Torres Porres porres@gmail.com wrote:
2017-02-12 6:05 GMT-02:00 Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com>:
The actual culprit is that sys_font & sys_fontweight are set as Monaco (normal) when building for Mac and Deja Vu Sans Mono (bold) when building for the other platforms in s_main.c.
cool, that's what I noticed, at least this could be simply worked out, right?
I think they both need to be either normal or bold by default in every system, and I like "normal" much better, that's how it's always been in Extended and now in Purr Data as well anyway ;)
cheers
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
2017-02-13 3:11 GMT-02:00 Dan Wilcox danomatika@gmail.com:
I added two builds that include Dejavu Sans Mono within the app bundle
see screenshot attached, looks just like what vanilla looks in linux and windows with the same font set to normal instead of bold.
So, I like where this is going, where the 3 of them have the same font and spacing and everything.
what I dont like is that it still looks quite different than Extended and Purr Data with the same DVSM font...
and I still dont get what's up with that
cheers
http://%20https://msdn.microsoft.com/en-us/library/windows/desktop/ms533820(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/ms533820(v=vs.85).a...http://%20https://msdn.microsoft.com/en-us/library/windows/desktop/ms533820(v=vs.85).aspx
http://code.activestate.com/lists/tcl-core/8158/#sthash.qJEhQALT.dpuf
@Dan:
The Tcl thing is just for Windows?
Yes as it’s using the Window’s API.
What can I do to test if this work?
Put the tcl code where?
Can you guide me?
Or IOhannes?
Mensaje telepatico asistido por maquinas.
This chunk of code has to be placed on “pd-gui.tcl” @line 433?
////////////////
critcl::cproc AddFontResource {Tcl_Interp* interp Tcl_Obj* pathObj} ok {
Tcl_DString ds;
Tcl_Encoding unicode;
int len, r = TCL_OK;
const char *path = Tcl_GetStringFromObj(pathObj, &len);
Tcl_DStringInit(&ds);
unicode = Tcl_GetEncoding(interp, "unicode");
Tcl_UtfToExternalDString(unicode, path, len, &ds);
if (AddFontResourceExW(Tcl_DStringValue(&ds), FR_PRIVATE, NULL)
== 0) { r = TCL_ERROR; } Tcl_DStringFree(&ds); Tcl_FreeEncoding(unicode); return r; }
//////////////////////////
Of course needs a path to the .ttf and other tweaks right?
Mensaje telepatico asistido por maquinas.
From: Pd-list pd-list-bounces@lists.iem.at on behalf of Lucas Cordiviola lucarda27@hotmail.com Sent: Monday, February 13, 2017 10:29 AM To: Alexandre Torres Porres; Dan Wilcox; Jonathan Wilkes; Pd-List Subject: Re: [PD] cross platforms issues with displaying fonts in vanilla but not in Purr Data
http://%20https://msdn.microsoft.com/en-us/library/windows/desktop/ms533820(v=vs.85).aspx http://%20https://msdn.microsoft.com/en-us/library/windows/desktop/ms533820(v=vs.85).aspxhttps://msdn.microsoft.com/en-us/library/windows/desktop/ms533820(v=vs.85).a...
http://code.activestate.com/lists/tcl-core/8158/#sthash.qJEhQALT.dpufhttp://code.activestate.com/lists/tcl-core/8158/#sthash.qJEhQALT.dpuf
@Dan:
The Tcl thing is just for Windows?
Yes as it’s using the Window’s API.
What can I do to test if this work?
Put the tcl code where?
Can you guide me?
Or IOhannes?
Mensaje telepatico asistido por maquinas.
I`m changing the thread back here as this is not “DejaVu Font: Shipping & using on W32 ”
Alexandre Torres Porres porres@gmail.com wrote:
howdy, I'll insist here as well, again, I like that we're looking in to how to install the same fonts for all platforms, but I'm really concerned about patches not looking the same in vanilla and in Extended/Purr Data.
what are the challenges in making it not only work well in cross platforms, but also in this different pd flavors?
We can leave out “Extended”, and we can ask Jonathan to make Purr-Data look as Vanilla.
Or in other words, lets forget about extended look cuz there was a special gui rewrite/gui port that is not used anymore.
I think this is the easiest way to get that challenge.
But is just an opinion.
Mensaje telepatico asistido por maquinas.
2017-02-14 13:33 GMT-02:00 Lucas Cordiviola lucarda27@hotmail.com:
I`m changing the thread back here as this is not “DejaVu Font: Shipping & using on W32 ”
*>Alexandre Torres Porres <porres@gmail.com porres@gmail.com> wrote:*
*>howdy, I'll insist here as well, again, I like that we're looking in to how to install the same fonts for all platforms, but I'm really concerned about patches not looking the same in vanilla and in Extended/Purr Data.*
*>what are the challenges in making it not only work well in cross platforms, but also in this different pd flavors? *
We can leave out “Extended”, and we can ask Jonathan to make Purr-Data look as Vanilla.
Or in other words, lets forget about extended look cuz there was a special gui rewrite/gui port that is not used anymore.
I think this is the easiest way to get that challenge.
I'm fine with either way, whatever is easiest... but now all my stuff is formatted to fit the Purr Data/Pd-L2ork/Extended style, and I mean over 200 help files from the cyclone library, 50 help files from another library I'm creating plus a personal didactic material with over 350 examples, that's over 600 files and patches I needed to fix, plus other personal patches that I personally use myself... so, yeah, for me it'd be much more convenient if vanilla would magically just look exactly like l2ork/purr data...
but anyway, this depends vanilla & l2ork/purr data people reaching a consensus and working together, so I took the liberty of copying this message to ico and jonathan
cheers
Did "Extended" used Dejavu on Mac?
Most of your patches have been made with Monaco, at least the Cyclone ones, correct?
Mensaje telepatico asistido por maquinas.
I'm fine with either way, whatever is easiest... but now all my stuff is formatted to fit the Purr Data/Pd-L2ork/Extended style, and I mean over 200 help files from the cyclone library, 50 help files from another library I'm creating plus a personal didactic material with over 350 examples, that's over 600 files and patches I needed to fix, plus other personal patches that I personally use myself... so, yeah, for me it'd be much more convenient if vanilla would magically just look exactly like l2ork/purr data...
but anyway, this depends vanilla & l2ork/purr data people reaching a consensus and working together, so I took the liberty of copying this message to ico and jonathan
2017-02-14 14:42 GMT-02:00 Lucas Cordiviola lucarda27@hotmail.com:
Did "Extended" used Dejavu on Mac?
No, but here's the deal... it looks exactly like DejaVu in Extended anyway...
If you get Extended in Windows with DejaVu and compare it to Extended in Mac Os with Monaco, they look virtually the same.
The kind of conflict I'm raising here between vanilla and purr data is not only about different fonts and the idea that they are too different. Monaco is supposed to be a good replacement for DejaVu...
the only point is that DejaVu, Monaco, or whatever, doesn't really look the same when you open the same patch, with the same font in vanilla or purr data - I thought I made that clear from my first message :)
Most of your patches have been made with Monaco, at least the Cyclone ones, correct?
all of them I should say...
cheers
2017-02-14 13:33 GMT-02:00 Lucas Cordiviola lucarda27@hotmail.com:
We can leave out “Extended”, and we can ask Jonathan to make Purr-Data look as Vanilla.
here's my reasoning, the issue now is that vanilla is stretching the text a lot, making the text go over and outside the patch area as in many of my help files. So this is the visual issue, things like objects, GUIs and text may overlap in vanilla if a patch was done in extended for instance (and there are still plenty of those around).
On the other hand, old patches from vanilla won't suffer any issue with the text and fonts getting narrower, it'll still look nice. So i vote that vanilla gets to make such changes for the advantage of keeping the Pd environment more cohesive.
cheers
what is the bottom left one?
Sorry I mistook-it for the right one, is dejavu not bold.
. So i vote that vanilla gets to make such changes for the advantage of keeping the Pd environment more cohesive.
Yes, I agree, probably there are more patches done on Extended than Vanilla.
Please test the “pd-gui.tcl” to see if is that easy to change Vanilla behavior.
Specially on OSX as it apparently always used Monaco. Force it to use Dejavu.
Salutti,
Lucarda.
Mensaje telepatico asistido por maquinas.
From: Alexandre Torres Porres porres@gmail.com Sent: Tuesday, February 14, 2017 11:00 PM To: Lucas Cordiviola; danomatika Cc: Pd-List Subject: Re: [PD] cross platforms issues with displaying fonts in vanilla but not in Purr Data
2017-02-14 13:33 GMT-02:00 Lucas Cordiviola <lucarda27@hotmail.commailto:lucarda27@hotmail.com>:
We can leave out “Extended”, and we can ask Jonathan to make Purr-Data look as Vanilla.
here's my reasoning, the issue now is that vanilla is stretching the text a lot, making the text go over and outside the patch area as in many of my help files. So this is the visual issue, things like objects, GUIs and text may overlap in vanilla if a patch was done in extended for instance (and there are still plenty of those around).
On the other hand, old patches from vanilla won't suffer any issue with the text and fonts getting narrower, it'll still look nice. So i vote that vanilla gets to make such changes for the advantage of keeping the Pd environment more cohesive.
cheers
Based on what Matt told you for OSX:
./pd -font-face "DejaVu Sans Mono"
And for not bold will be:
./pd -font-face "DejaVu Sans Mono" -font-weight normal
But “-font-weight normal” can be set on pd`s startup pref.
Salutti, Lucarda.
Mensaje telepatico asistido por maquinas.
From: Pd-list pd-list-bounces@lists.iem.at on behalf of Lucas Cordiviola lucarda27@hotmail.com Sent: Tuesday, February 14, 2017 11:18 PM To: Alexandre Torres Porres; danomatika Cc: Pd-List Subject: Re: [PD] cross platforms issues with displaying fonts in vanilla but not in Purr Data
what is the bottom left one?
Sorry I mistook-it for the right one, is dejavu not bold.
. So i vote that vanilla gets to make such changes for the advantage of keeping the Pd environment more cohesive.
Yes, I agree, probably there are more patches done on Extended than Vanilla.
Please test the “pd-gui.tcl” to see if is that easy to change Vanilla behavior.
Specially on OSX as it apparently always used Monaco. Force it to use Dejavu.
Salutti,
Lucarda.
Mensaje telepatico asistido por maquinas.
From: Alexandre Torres Porres porres@gmail.com Sent: Tuesday, February 14, 2017 11:00 PM To: Lucas Cordiviola; danomatika Cc: Pd-List Subject: Re: [PD] cross platforms issues with displaying fonts in vanilla but not in Purr Data
2017-02-14 13:33 GMT-02:00 Lucas Cordiviola <lucarda27@hotmail.commailto:lucarda27@hotmail.com>:
We can leave out “Extended”, and we can ask Jonathan to make Purr-Data look as Vanilla.
here's my reasoning, the issue now is that vanilla is stretching the text a lot, making the text go over and outside the patch area as in many of my help files. So this is the visual issue, things like objects, GUIs and text may overlap in vanilla if a patch was done in extended for instance (and there are still plenty of those around).
On the other hand, old patches from vanilla won't suffer any issue with the text and fonts getting narrower, it'll still look nice. So i vote that vanilla gets to make such changes for the advantage of keeping the Pd environment more cohesive.
cheers
-
Alexandre Torres Porres -
Chris McCormick -
Christof Ressi -
Dan Wilcox -
Jonathan Wilkes -
Lucas Cordiviola -
Miller Puckette