Well the modifided tcl AFAWCT gives uniform patch rendering on all OS with the same font.
Also this tweek is compatible with Purr-Data.
It came from a long discussion we had with Alex, he was mad cuz his help-patches done on OSX were bad on linux & windows.
We concluded that:
Each OS was using a different font: dejavu:linux, monaco:macOS, courier:windows.
So we started testing all on DejaVU and we still got his help-patches bad.
Then we use extended metrics and “All solved”.
Obscure why vanilla:monaco:osx fits for vanilla:dejavu:linux:mod.tcl
But anyway this tcl mod renders perfectly patches that were done with extended, or with Purr-Data.
GOP needs testing, but surely vanilla will behave as if it was extended.
Only changes are : @ pd-gui.tcl line 127 you will find the Pd vanilla font metrics
The actual real pixel dimensions of the font are none of our business and irrelevant cuz patches render the same or really close on all OS.
Mensaje telepatico asistido por maquinas.
From: Jonathan Wilkes jancsika@yahoo.com Sent: Monday, February 20, 2017 5:16 PM To: Lucas Cordiviola; pd-list@lists.iem.at Subject: Re: [PD] (wip) Preferences file.
But you are taking an internal format passed between the GUI and the core and exposing it to become a public API. And that format virtually guarantees that users will misunderstand how it works:
Ok, so then a new flag?
-fontmetrics <name> … vanilla or extended
Or something like that?
I'm still not convinced anyone actually understands what the font sizing algorithms are doing, or whether they are indeed buggy. Under those circumstances I don't think it's a good idea to expose a new setting to the user.
Has anyone actually read the handful of relevant procs/functions responsible for the sizing?
For example-- if you choose "12" in Pd's font size dialog, the actual pixel size for the font displayed on the tk canvas could be -11, -12, -13, etc. Are the discrepancies in your screenshots due to different actual pixel sizes, or did you normalize everything to the same actual pixel font size?
-Jonathan
Mensaje telepatico asistido por maquinas.
@ Jonathan.
Please download this patch:
http://puredata.info/Members/lucarda/software/pd-test-metrics.zip/at_downloa...
do changes to the .tcl
https://github.com/pure-data/pure-data/wiki/Crossplatform-font-metrics-&...
and do your tests. To have it clearer.
For Purr Data change the name on the ggee folder that comes with the patch.
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 20, 2017 5:56 PM To: pd-list@lists.iem.at; Jonathan Wilkes Subject: Re: [PD] (wip) Preferences file.
Well the modifided tcl AFAWCT gives uniform patch rendering on all OS with the same font.
Also this tweek is compatible with Purr-Data.
It came from a long discussion we had with Alex, he was mad cuz his help-patches done on OSX were bad on linux & windows.
We concluded that:
Each OS was using a different font: dejavu:linux, monaco:macOS, courier:windows.
So we started testing all on DejaVU and we still got his help-patches bad.
Then we use extended metrics and “All solved”.
Obscure why vanilla:monaco:osx fits for vanilla:dejavu:linux:mod.tcl
But anyway this tcl mod renders perfectly patches that were done with extended, or with Purr-Data.
GOP needs testing, but surely vanilla will behave as if it was extended.
Only changes are : @ pd-gui.tcl line 127 you will find the Pd vanilla font metrics
The actual real pixel dimensions of the font are none of our business and irrelevant cuz patches render the same or really close on all OS.
Mensaje telepatico asistido por maquinas.
Well the modifided tcl AFAWCT gives uniform patch rendering on all OS with the same font.
Ok, if that's the case then I would suggest not to add a user-facing font-metrics option. If a Vanilla user wants larger fonts than the fontspec provides for, they can just increase the zoom level. -Jonathan
On 02/20/2017 07:26 PM, Jonathan Wilkes via Pd-list wrote:
Ok, if that's the case then I would suggest not to add a user-facing font-metrics option.
+1
i'd also like to add, that we should not (ever) add an option with the sole purpose of working around bugs. if you consider the slightly different font sizes a bug (and i gather you do), then we should find a solution to the bug itself (rather than provide an easy way to make everything worse). if you only consider them an annoyance, you might want to investigate in creating a gui-plugin that fixes the problem. (it seems that currently, Pd-gui signals the font metrics back to Pd-core, which will (among other things) trigger Pd-core to load it's libraries. it might be worth entangling *that*)
fgamdsr IOhannes
I don't think of it as a bug but as an enhancement.
If it is really easy to switch between those 2 font metrics, which one will be the default?
The one that is not compatible with Purr Data and Extended?
I personally can perfectly live without that option.
Salutti,
Lucarda.
Mensaje telepatico asistido por maquinas.
From: Pd-list pd-list-bounces@lists.iem.at on behalf of zmoelnig@iem.at zmoelnig@iem.at Sent: Monday, February 20, 2017 7:21 PM To: pd-list@lists.iem.at Subject: Re: [PD] (wip) Preferences file.
On 02/20/2017 07:26 PM, Jonathan Wilkes via Pd-list wrote:
Ok, if that's the case then I would suggest not to add a user-facing font-metrics option.
+1
i'd also like to add, that we should not (ever) add an option with the sole purpose of working around bugs. if you consider the slightly different font sizes a bug (and i gather you do), then we should find a solution to the bug itself (rather than provide an easy way to make everything worse). if you only consider them an annoyance, you might want to investigate in creating a gui-plugin that fixes the problem. (it seems that currently, Pd-gui signals the font metrics back to Pd-core, which will (among other things) trigger Pd-core to load it's libraries. it might be worth entangling *that*)
fgamdsr IOhannes
On 02/20/2017 08:57 PM, Lucas Cordiviola wrote:
I don't think of it as a bug but as an enhancement.
then you should implement it as a gui-plugin. (that's the purpose of gui-plugins: enhance the gui, without adding more code to the core that somebody has to maintain).
gfmadsr IOhannes
I'd like to focus on a central point of this discussion.
Seems like Lucas is just hoping to add a new fonts metric settings to Pd. Ok, doing that may raise many complicated issues, like changing a lot of stuff so you can set it one way or the other... And he can go ahead and make a plug in for that... but maybe we could also just talk about if we can change the font metrics for good, hard code it to that, so it aligns to the way Pd Extended and Purr Data work.
Changing the metrics from Vanilla to extended's/purr data's doesn't compromise the patch as the other way around dows, I already pointed this out.
It'll look different, sure, but it's not like vanilla's look is so sacred, I mean, we still don't have the same fonts for every platform... we already have issues within the distribution itself, where a patch from Mac OS overlaps in linux/windows... all sorts of things, I don't see this as a sacred cow going to the slaughter!
On the other hand, opening extended patches in the vanilla metrics does compromise the visual experience a lot, creating all sorts of overlaps.
if sticking to one is the way to go, for sake of simplicity and maintaining that code (a good point), makes a lot sense that vanilla sticks to the metrics and looks of extended and purr data...
I only see advantages, cause the way it is right now, just drives these forks apart...
And I, for one, am not willing to work on different documentation and patches for vanilla and purr data, cause it'd be too crazy... I'll stick to one, and I choose the old extended and new purr data way, as they're convenient to me.
cheers
2017-02-20 18:33 GMT-03:00 IOhannes m zmölnig zmoelnig@iem.at:
On 02/20/2017 08:57 PM, Lucas Cordiviola wrote:
I don't think of it as a bug but as an enhancement.
then you should implement it as a gui-plugin. (that's the purpose of gui-plugins: enhance the gui, without adding more code to the core that somebody has to maintain).
gfmadsr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list
+0.8
I mostly agree with Alex, especially on that extended metrics look bad on vanilla & not the other way round.
There's lots of extended help patches around.
Should I try:
Vanilla old style gui-plugin?
: )
Mensaje telepatico asistido por maquinas.
From: Pd-list pd-list-bounces@lists.iem.at on behalf of Alexandre Torres Porres porres@gmail.com Sent: Tuesday, February 21, 2017 1:54 AM To: pd-list@lists.iem.at Subject: Re: [PD] (wip) Preferences file.
I'd like to focus on a central point of this discussion.
Seems like Lucas is just hoping to add a new fonts metric settings to Pd. Ok, doing that may raise many complicated issues, like changing a lot of stuff so you can set it one way or the other... And he can go ahead and make a plug in for that... but maybe we could also just talk about if we can change the font metrics for good, hard code it to that, so it aligns to the way Pd Extended and Purr Data work.
Changing the metrics from Vanilla to extended's/purr data's doesn't compromise the patch as the other way around dows, I already pointed this out.
It'll look different, sure, but it's not like vanilla's look is so sacred, I mean, we still don't have the same fonts for every platform... we already have issues within the distribution itself, where a patch from Mac OS overlaps in linux/windows... all sorts of things, I don't see this as a sacred cow going to the slaughter!
On the other hand, opening extended patches in the vanilla metrics does compromise the visual experience a lot, creating all sorts of overlaps.
if sticking to one is the way to go, for sake of simplicity and maintaining that code (a good point), makes a lot sense that vanilla sticks to the metrics and looks of extended and purr data...
I only see advantages, cause the way it is right now, just drives these forks apart...
And I, for one, am not willing to work on different documentation and patches for vanilla and purr data, cause it'd be too crazy... I'll stick to one, and I choose the old extended and new purr data way, as they're convenient to me.
cheers
2017-02-20 18:33 GMT-03:00 IOhannes m zmölnig <zmoelnig@iem.atmailto:zmoelnig@iem.at>: On 02/20/2017 08:57 PM, Lucas Cordiviola wrote:
I don't think of it as a bug but as an enhancement.
then you should implement it as a gui-plugin. (that's the purpose of gui-plugins: enhance the gui, without adding more code to the core that somebody has to maintain).
gfmadsr IOhannes
Pd-list@lists.iem.atmailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Ok, if that's the case then I would suggest not to add a user-facing font-metrics option.
+1
i'd also like to add, that we should not (ever) add an option with the
sole purpose of working around bugs.
Is it a bug?
if you consider the slightly different font sizes a bug (and i gather
you do), then we should find a solution to the bug itself (rather than provide an easy way to make everything worse).
Yes.
if you only consider them an annoyance, you might want to investigate in
creating a gui-plugin that fixes the problem.
We have a problem.
(it seems that currently, Pd-gui signals the font metrics back to
Pd-core, which will (among other things) trigger Pd-core to load it's libraries. it might be worth entangling *that*)
Yes, I cant override or change the variable “font_metrics” set @ line 127 from “pd-gui.tcl” using a gui-plugin.
Is it posible?
I still think that shipping dejavu and hard-code Pd-extended metrics is full of goodness.
Salutti, Lucarda
fgamdsr IOhannes
Mensaje telepatico asistido por maquinas.
Ok, seems we have yet another thread to keep discussing a same topic that I kinda started. Anyway, if the focus of the debate has changed indeed, I suggest changing the thread name and adding (was: "xxxx" <= old thread subject), in this case: (was: (wip) Preferences file).
So, I did bring this up, how patches look differently in vanilla according to the operating system, and how they look different from extended / purr data (which, on their own, look consistent in all platforms and also look like each other!).
Changing the font metrics from Vanilla to extended's/purr data's doesn't compromise the patch as the other way around does. Cause opening extended patches in the vanilla's metrics does compromise the visual experience a lot, creating all sorts of overlaps... I already pointed this out in the previous threads.
So, keeping it objective and not to repeat myself too much, I consider this an issue, an undesired behaviour, a bug, whatever, and I hope we could fix it. Any opposition? What is the best way to do this?
cheers
2017-02-21 19:05 GMT-03:00 Lucas Cordiviola lucarda27@hotmail.com:
Ok, if that's the case then I would suggest not to add a user-facing
font-metrics option.
+1
i'd also like to add, that we should not (ever) add an option with the
sole purpose of working around bugs.
Is it a bug?
if you consider the slightly different font sizes a bug (and i gather
you do), then we should find a solution to the bug itself (rather than provide an easy way to make everything worse).
Yes.
if you only consider them an annoyance, you might want to investigate in
creating a gui-plugin that fixes the problem.
We have a problem.
(it seems that currently, Pd-gui signals the font metrics back to
Pd-core, which will (among other things) trigger Pd-core to load it's libraries. it might be worth entangling *that*)
Yes, I cant override or change the variable “font_metrics” set @ line 127 from “pd-gui.tcl” using a gui-plugin.
Is it posible?
I still think that shipping dejavu and hard-code Pd-extended metrics is full of goodness.
Salutti, Lucarda
fgamdsr IOhannes
Mensaje telepatico asistido por maquinas.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list
On Die, 2017-02-21 at 19:33 -0300, Alexandre Torres Porres wrote:
Ok, seems we have yet another thread to keep discussing a same topic that I kinda started. Anyway, if the focus of the debate has changed indeed, I suggest changing the thread name and adding (was: "xxxx" <= old thread subject), in this case: (was: (wip) Preferences file).
So, I did bring this up, how patches look differently in vanilla according to the operating system, and how they look different from extended / purr data (which, on their own, look consistent in all platforms and also look like each other!).
Changing the font metrics from Vanilla to extended's/purr data's doesn't compromise the patch as the other way around does. Cause opening extended patches in the vanilla's metrics does compromise the visual experience a lot, creating all sorts of overlaps... I already pointed this out in the previous threads.
So, keeping it objective and not to repeat myself too much, I consider this an issue, an undesired behaviour, a bug, whatever, and I hope we could fix it. Any opposition? What is the best way to do this?
This is my view on the matter:
The primary goal is to make Pd(-vanilla)'s appearance consistent across platforms. Part of that is that box sizes don't change when switching platforms. As a side effect of this fix, patches also don't change appearance when switching between Pd flavors (Do we still need to care about Pd-extended, since it's been phased out?).
From what I gathered from the "Pd Metrics on Xubuntu 16 04 02 LTS" thread, the following steps are required to achieve that goal:
* Adjustments of the font metrics. It seems we can just take the ones from Pd-extended.
* Use the same font on all platforms. Pd apparently looks for "DejaVu Sans Mono" first, so that is the one we should make available everywhere.
On Linux, it's the task of Pd's package maintainers that DejaVu is installed when Pd is to be installed. If I'm not mistaken, DejaVu is installed per default on all Debian derivatives, so we do not have to care about them. On Windows, the font is missing and the Pd installer could be adapted to install the font along with Pd. On macOS, I don't know what the required steps would be.
I propose that before we submit any fixes to Miller we are absolutely certain that the adapted font metrics are correct in that the resulting box sizes are consistent for all available font sizes (8, 10, 12, 16, 24, 36). And when testing this, we make sure that Pd uses "DejaVu Sans Mono". Only then we submit any fix.
If we find good font metrics, I'll submit a fix to the NSIS installer script, so that installing DejaVu is part of the Pd installation process on Windows. Yet, I'm not sure whether it is enough to simply drop the font files into %windir%\Fonts or whether the font needs to be registered somewhere.
Roman
On 2017-02-22 09:05, Roman Haefeli wrote:
If we find good font metrics, I'll submit a fix to the NSIS installer script, so that installing DejaVu is part of the Pd installation process on Windows. Yet, I'm not sure whether it is enough to simply drop the font files into %windir%\Fonts or whether the font needs to be registered somewhere.
http://nsis.sourceforge.net/Register_Fonts
fgmasdr IOhannes
On Mit, 2017-02-22 at 11:56 +0100, IOhannes m zmoelnig wrote:
On 2017-02-22 09:05, Roman Haefeli wrote:
If we find good font metrics, I'll submit a fix to the NSIS installer script, so that installing DejaVu is part of the Pd installation process on Windows. Yet, I'm not sure whether it is enough to simply drop the font files into %windir%\Fonts or whether the font needs to be registered somewhere.
Thanks. Looks more complicated than I expected it to be, however probably still easy enough. You'll hear from me.
Roman
On 2017-02-22 13:26, Roman Haefeli wrote:
On Mit, 2017-02-22 at 11:56 +0100, IOhannes m zmoelnig wrote:
On 2017-02-22 09:05, Roman Haefeli wrote:
If we find good font metrics, I'll submit a fix to the NSIS installer script, so that installing DejaVu is part of the Pd installation process on Windows. Yet, I'm not sure whether it is enough to simply drop the font files into %windir%\Fonts or whether the font needs to be registered somewhere.
Thanks. Looks more complicated than I expected it to be, however probably still easy enough. You'll hear from me.
afaik the relevant scripts are included with NSIS(?).
at least, that's how i remember it from using the 'nsis' Debian package about 10 years. things ought to have improved since then.
fvmasd IOhannes
From what I gathered from the "Pd Metrics on Xubuntu 16 04 02 LTS"
thread, the following steps are required to achieve that goal:
Adjustments of the font metrics. It seems we can just take the ones
from Pd-extended.
+1
Use the same font on all platforms. Pd apparently looks for "DejaVu
Sans Mono" first, so that is the one we should make available
everywhere.
+1
Salutti, Lucarda.
Mensaje telepatico asistido por maquinas.
From: Pd-list pd-list-bounces@lists.iem.at on behalf of Roman Haefeli reduzent@gmail.com Sent: Wednesday, February 22, 2017 8:05 AM To: pd-list@lists.iem.at Subject: Re: [PD] Cross-platform uniform GUI rendering of patches.
On Die, 2017-02-21 at 19:33 -0300, Alexandre Torres Porres wrote:
Ok, seems we have yet another thread to keep discussing a same topic that I kinda started. Anyway, if the focus of the debate has changed indeed, I suggest changing the thread name and adding (was: "xxxx" <= old thread subject), in this case: (was: (wip) Preferences file).
So, I did bring this up, how patches look differently in vanilla according to the operating system, and how they look different from extended / purr data (which, on their own, look consistent in all platforms and also look like each other!).
Changing the font metrics from Vanilla to extended's/purr data's doesn't compromise the patch as the other way around does. Cause opening extended patches in the vanilla's metrics does compromise the visual experience a lot, creating all sorts of overlaps... I already pointed this out in the previous threads.
So, keeping it objective and not to repeat myself too much, I consider this an issue, an undesired behaviour, a bug, whatever, and I hope we could fix it. Any opposition? What is the best way to do this?
This is my view on the matter:
The primary goal is to make Pd(-vanilla)'s appearance consistent across platforms. Part of that is that box sizes don't change when switching platforms. As a side effect of this fix, patches also don't change appearance when switching between Pd flavors (Do we still need to care about Pd-extended, since it's been phased out?).
From what I gathered from the "Pd Metrics on Xubuntu 16 04 02 LTS"
thread, the following steps are required to achieve that goal:
Adjustments of the font metrics. It seems we can just take the ones from Pd-extended.
Use the same font on all platforms. Pd apparently looks for "DejaVu Sans Mono" first, so that is the one we should make available everywhere.
On Linux, it's the task of Pd's package maintainers that DejaVu is installed when Pd is to be installed. If I'm not mistaken, DejaVu is installed per default on all Debian derivatives, so we do not have to care about them. On Windows, the font is missing and the Pd installer could be adapted to install the font along with Pd. On macOS, I don't know what the required steps would be.
I propose that before we submit any fixes to Miller we are absolutely certain that the adapted font metrics are correct in that the resulting box sizes are consistent for all available font sizes (8, 10, 12, 16, 24, 36). And when testing this, we make sure that Pd uses "DejaVu Sans Mono". Only then we submit any fix.
If we find good font metrics, I'll submit a fix to the NSIS installer script, so that installing DejaVu is part of the Pd installation process on Windows. Yet, I'm not sure whether it is enough to simply drop the font files into %windir%\Fonts or whether the font needs to be registered somewhere.
Roman
2017-02-22 5:05 GMT-03:00 Roman Haefeli reduzent@gmail.com:
Do we still need to care about Pd-extended, since it's been phased out?.
It's not a special case, its "sucessor" (Pd-l2ork/Purr Data) is here and is compatible to it. We can forget about extended, but it still counts if we're considering the newcomer. In this sense, it is not being or has been phased out, it's moving on...
On the other hand, I haven't adopted Purr Data yet... and I still use Extended (0.42-5 by the way), where I have over 350 patches that I use for teaching which are compatible to this version... not to mention all of the documentation made for its libraries, so, yeah, you get my point, Extended patches are still around, a similar option is taking its place and behaves the same, so, yeah, I say we worry about it.
cheers
-
Alexandre Torres Porres -
IOhannes m zmoelnig -
IOhannes m zmölnig
-
Jonathan Wilkes -
Lucas Cordiviola -
Roman Haefeli -
zmoelnig＠iem.at