one question, how does canvas and other fonts for labels work in cross platforms?
why not use that for comment... for now, all cyclone/comment is can be thought of just being a fancy label perhaps...
I did use it a lot in my new help files that I'm working on, but only cause it'd be too much work to use canvas and labels, as it'd imply a canvas for each word as it doesn't take spaces (is only a symbol)
I was even thinking of ditching it when, it stopped working on vanilla 0.47
- yeah, that's another thing, a fix needs to be made to vanilla for old
versions of comment (0.2 and below to work) - but then I realized it could be really useful. I was also hoping to add properties windows to make it more convenient.
anyway, the question is, why labels and stuff simply work?
cheers
2016-11-28 21:45 GMT-02:00 Jonathan Wilkes jancsika@yahoo.com:
Another reason for putting it off is that I still haven't figured out a sane approach to handling arbitrary fonts in a diagram where everything is absolutely positioned. In fact I only have a minimally-workable approach to handling a single, mono- spaced font across platforms. For example, there was a change somewhere in the Gnu/Linux font-stack (relatively) recently that renders fonts (or at least DejaVu Sans Mono) noticeably wider than before. So Windows, OSX, and old Gnu/Linux would render a particular line of text sized at "12px" within less than a single pixel of each other. The new Gnu/Linux font stack (seen in Ubuntu 16.04 and some recent Arch) rendered the same text about 7 pixels wider.
Worse, the newer Gnu/Linux font stack quantizes the "px" sizes such that the next smallest size is noticeably smaller. So in Ubuntu 16.04 I have to compromise by keeping the object box the same size and having some extra padding at the end-- otherwise users of that OS could end up tightly spacing their object chains in ways that cause overlaps on the other platforms.
So... I'd like to get a handle on that mess first, then handling arbitrary font families-- as in cyclone/comment-- will hopefully be easier and less prone to bugs.
well, it seems some of the issues are exactly what we're facing now...
I think those issues are impossible to solve for displaying arbitrary fonts in a diagram like a Pd patch, and especially for arbitrary fonts in multi-line text. The user simply won't be able to predict whether or not there will be collisions on someone else's platform (or even if those fonts aren't available, which fonts will get chosen).
I'm all for porting cyclone/comment for the sake of Max compatibility. But I'd strongly advise against using cyclone/comment in any patch that's supposed to be used cross-platform (aside from its own help patch, of course).
-Jonathan
cheers
Hi, I see Purr Data has this feature where it accepts spaces in lables such as in canvases... this is awesome, and mostly why I use cyclone/comment
I can see we could depart from how you can lable stuff in Purr Data to make a new working cross platform version of cyclone/comment that is still backwards compatible.
cheers
2016-11-29 2:28 GMT-02:00 Alexandre Torres Porres porres@gmail.com:
one question, how does canvas and other fonts for labels work in cross platforms?
why not use that for comment... for now, all cyclone/comment is can be thought of just being a fancy label perhaps...
I did use it a lot in my new help files that I'm working on, but only cause it'd be too much work to use canvas and labels, as it'd imply a canvas for each word as it doesn't take spaces (is only a symbol)
I was even thinking of ditching it when, it stopped working on vanilla 0.47 - yeah, that's another thing, a fix needs to be made to vanilla for old versions of comment (0.2 and below to work) - but then I realized it could be really useful. I was also hoping to add properties windows to make it more convenient.
anyway, the question is, why labels and stuff simply work?
cheers
2016-11-28 21:45 GMT-02:00 Jonathan Wilkes jancsika@yahoo.com:
Another reason for putting it off is that I still haven't figured out a sane approach to handling arbitrary fonts in a diagram where everything is absolutely positioned. In fact I only have a minimally-workable approach to handling a single, mono- spaced font across platforms. For example, there was a change somewhere in the Gnu/Linux font-stack (relatively) recently that renders fonts (or at least DejaVu Sans Mono) noticeably wider than before. So Windows, OSX, and old Gnu/Linux would render a particular line of text sized at "12px" within less than a single pixel of each other. The new Gnu/Linux font stack (seen in Ubuntu 16.04 and some recent Arch) rendered the same text about 7 pixels wider.
Worse, the newer Gnu/Linux font stack quantizes the "px" sizes such that the next smallest size is noticeably smaller. So in Ubuntu 16.04 I have to compromise by keeping the object box the same size and having some extra padding at the end-- otherwise users of that OS could end up tightly spacing their object chains in ways that cause overlaps on the other platforms.
So... I'd like to get a handle on that mess first, then handling arbitrary font families-- as in cyclone/comment-- will hopefully be easier and less prone to bugs.
well, it seems some of the issues are exactly what we're facing now...
I think those issues are impossible to solve for displaying arbitrary fonts in a diagram like a Pd patch, and especially for arbitrary fonts in multi-line text. The user simply won't be able to predict whether or not there will be collisions on someone else's platform (or even if those fonts aren't available, which fonts will get chosen).
I'm all for porting cyclone/comment for the sake of Max compatibility. But I'd strongly advise against using cyclone/comment in any patch that's supposed to be used cross-platform (aside from its own help patch, of course).
-Jonathan
cheers
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list
This has been around for some time in pd-l2ork and by extension in Purr-Data, but as Liam recently pointed out on the l2ork-dev list, it can also break patches on vanilla where spaces (including escaped ones) in the .pd file get misinterpreted by the vanilla parser. Liam suggested changing those to ASCII 255 which is some other sort of a space... Something to be investigated further down the road. Of course, an alternative would be that vanilla ports the same space parsing method from pd-l2ork/purr-data.
Best,
Ico
On 12/2/2016 1:10 PM, Alexandre Torres Porres wrote:
Hi, I see Purr Data has this feature where it accepts spaces in lables such as in canvases... this is awesome, and mostly why I use cyclone/comment
I can see we could depart from how you can lable stuff in Purr Data to make a new working cross platform version of cyclone/comment that is still backwards compatible.
cheers
2016-11-29 2:28 GMT-02:00 Alexandre Torres Porres <porres@gmail.com mailto:porres@gmail.com>:
one question, how does canvas and other fonts for labels work in cross platforms? why not use that for comment... for now, all cyclone/comment is can be thought of just being a fancy label perhaps... I did use it a lot in my new help files that I'm working on, but only cause it'd be too much work to use canvas and labels, as it'd imply a canvas for each word as it doesn't take spaces (is only a symbol) I was even thinking of ditching it when, it stopped working on vanilla 0.47 - yeah, that's another thing, a fix needs to be made to vanilla for old versions of comment (0.2 and below to work) - but then I realized it could be really useful. I was also hoping to add properties windows to make it more convenient. anyway, the question is, why labels and stuff simply work? cheers 2016-11-28 21:45 GMT-02:00 Jonathan Wilkes <jancsika@yahoo.com <mailto:jancsika@yahoo.com>>: Another reason for putting it off is that I still haven't figured out a sane approach to handling arbitrary fonts in a diagram where everything is absolutely positioned. In fact I only have a minimally-workable approach to handling a single, mono- spaced font across platforms. For example, there was a change somewhere in the Gnu/Linux font-stack (relatively) recently that renders fonts (or at least DejaVu Sans Mono) noticeably wider than before. So Windows, OSX, and old Gnu/Linux would render a particular line of text sized at "12px" within less than a single pixel of each other. The new Gnu/Linux font stack (seen in Ubuntu 16.04 and some recent Arch) rendered the same text about 7 pixels wider. Worse, the newer Gnu/Linux font stack quantizes the "px" sizes such that the next smallest size is noticeably smaller. So in Ubuntu 16.04 I have to compromise by keeping the object box the same size and having some extra padding at the end-- otherwise users of that OS could end up tightly spacing their object chains in ways that cause overlaps on the other platforms. So... I'd like to get a handle on that mess first, then handling arbitrary font families-- as in cyclone/comment-- will hopefully be easier and less prone to bugs. > well, it seems some of the issues are exactly what we're facing now... I think those issues are impossible to solve for displaying arbitrary fonts in a diagram like a Pd patch, and especially for arbitrary fonts in multi-line text. The user simply won't be able to predict whether or not there will be collisions on someone else's platform (or even if those fonts aren't available, which fonts will get chosen). I'm all for porting cyclone/comment for the sake of Max compatibility. But I'd strongly advise against using cyclone/comment in any patch that's supposed to be used cross-platform (aside from its own help patch, of course). -Jonathan > cheers _______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list <https://lists.puredata.info/listinfo/pd-list>
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
but how about getting that functionality as an external.
One thing is opening a vanilla GUI with spaces in the lable and trying to open that in Vanilla, another would be to have it an external GUI object with such functionality (such as cyclone/comment) and load it anywhere.
I'm not really aware of the existing issues in cyclone/comment, and we haven't touched it yet, but they do not behave well in cross platforms.
My insight was that maybe we could use the code from purr-data, but as I write this now, I realize how purr-data has this completely different GUI front end, that's completely different to what's in Pd, so I may have been way off...
2016-12-02 22:41 GMT-02:00 Ivica Ico Bukvic ico@vt.edu:
This has been around for some time in pd-l2ork and by extension in Purr-Data, but as Liam recently pointed out on the l2ork-dev list, it can also break patches on vanilla where spaces (including escaped ones) in the .pd file get misinterpreted by the vanilla parser. Liam suggested changing those to ASCII 255 which is some other sort of a space... Something to be investigated further down the road. Of course, an alternative would be that vanilla ports the same space parsing method from pd-l2ork/purr-data.
Best,
Ico
On 12/2/2016 1:10 PM, Alexandre Torres Porres wrote:
Hi, I see Purr Data has this feature where it accepts spaces in lables such as in canvases... this is awesome, and mostly why I use cyclone/comment
I can see we could depart from how you can lable stuff in Purr Data to make a new working cross platform version of cyclone/comment that is still backwards compatible.
cheers
2016-11-29 2:28 GMT-02:00 Alexandre Torres Porres porres@gmail.com:
one question, how does canvas and other fonts for labels work in cross platforms?
why not use that for comment... for now, all cyclone/comment is can be thought of just being a fancy label perhaps...
I did use it a lot in my new help files that I'm working on, but only cause it'd be too much work to use canvas and labels, as it'd imply a canvas for each word as it doesn't take spaces (is only a symbol)
I was even thinking of ditching it when, it stopped working on vanilla 0.47 - yeah, that's another thing, a fix needs to be made to vanilla for old versions of comment (0.2 and below to work) - but then I realized it could be really useful. I was also hoping to add properties windows to make it more convenient.
anyway, the question is, why labels and stuff simply work?
cheers
2016-11-28 21:45 GMT-02:00 Jonathan Wilkes jancsika@yahoo.com:
Another reason for putting it off is that I still haven't figured out a sane approach to handling arbitrary fonts in a diagram where everything is absolutely positioned. In fact I only have a minimally-workable approach to handling a single, mono- spaced font across platforms. For example, there was a change somewhere in the Gnu/Linux font-stack (relatively) recently that renders fonts (or at least DejaVu Sans Mono) noticeably wider than before. So Windows, OSX, and old Gnu/Linux would render a particular line of text sized at "12px" within less than a single pixel of each other. The new Gnu/Linux font stack (seen in Ubuntu 16.04 and some recent Arch) rendered the same text about 7 pixels wider.
Worse, the newer Gnu/Linux font stack quantizes the "px" sizes such that the next smallest size is noticeably smaller. So in Ubuntu 16.04 I have to compromise by keeping the object box the same size and having some extra padding at the end-- otherwise users of that OS could end up tightly spacing their object chains in ways that cause overlaps on the other platforms.
So... I'd like to get a handle on that mess first, then handling arbitrary font families-- as in cyclone/comment-- will hopefully be easier and less prone to bugs.
well, it seems some of the issues are exactly what we're facing now...
I think those issues are impossible to solve for displaying arbitrary fonts in a diagram like a Pd patch, and especially for arbitrary fonts in multi-line text. The user simply won't be able to predict whether or not there will be collisions on someone else's platform (or even if those fonts aren't available, which fonts will get chosen).
I'm all for porting cyclone/comment for the sake of Max compatibility. But I'd strongly advise against using cyclone/comment in any patch that's supposed to be used cross-platform (aside from its own help patch, of course).
-Jonathan
cheers
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/li stinfo/pd-list
_______________________________________________Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list
well, another thing is getting cyclone/comment to work in Purr-data, which it isn't yet, and needed to be ported. So maybe at least we could fix that and sort it out by departing from this label structure into a new cyclone/comment external for Purr-data, that seems like something that makes sense
2016-12-02 23:06 GMT-02:00 Alexandre Torres Porres porres@gmail.com:
but how about getting that functionality as an external.
One thing is opening a vanilla GUI with spaces in the lable and trying to open that in Vanilla, another would be to have it an external GUI object with such functionality (such as cyclone/comment) and load it anywhere.
I'm not really aware of the existing issues in cyclone/comment, and we haven't touched it yet, but they do not behave well in cross platforms.
My insight was that maybe we could use the code from purr-data, but as I write this now, I realize how purr-data has this completely different GUI front end, that's completely different to what's in Pd, so I may have been way off...
2016-12-02 22:41 GMT-02:00 Ivica Ico Bukvic ico@vt.edu:
This has been around for some time in pd-l2ork and by extension in Purr-Data, but as Liam recently pointed out on the l2ork-dev list, it can also break patches on vanilla where spaces (including escaped ones) in the .pd file get misinterpreted by the vanilla parser. Liam suggested changing those to ASCII 255 which is some other sort of a space... Something to be investigated further down the road. Of course, an alternative would be that vanilla ports the same space parsing method from pd-l2ork/purr-data.
Best,
Ico
On 12/2/2016 1:10 PM, Alexandre Torres Porres wrote:
Hi, I see Purr Data has this feature where it accepts spaces in lables such as in canvases... this is awesome, and mostly why I use cyclone/comment
I can see we could depart from how you can lable stuff in Purr Data to make a new working cross platform version of cyclone/comment that is still backwards compatible.
cheers
2016-11-29 2:28 GMT-02:00 Alexandre Torres Porres porres@gmail.com:
one question, how does canvas and other fonts for labels work in cross platforms?
why not use that for comment... for now, all cyclone/comment is can be thought of just being a fancy label perhaps...
I did use it a lot in my new help files that I'm working on, but only cause it'd be too much work to use canvas and labels, as it'd imply a canvas for each word as it doesn't take spaces (is only a symbol)
I was even thinking of ditching it when, it stopped working on vanilla 0.47 - yeah, that's another thing, a fix needs to be made to vanilla for old versions of comment (0.2 and below to work) - but then I realized it could be really useful. I was also hoping to add properties windows to make it more convenient.
anyway, the question is, why labels and stuff simply work?
cheers
2016-11-28 21:45 GMT-02:00 Jonathan Wilkes jancsika@yahoo.com:
Another reason for putting it off is that I still haven't figured out a sane approach to handling arbitrary fonts in a diagram where everything is absolutely positioned. In fact I only have a minimally-workable approach to handling a single, mono- spaced font across platforms. For example, there was a change somewhere in the Gnu/Linux font-stack (relatively) recently that renders fonts (or at least DejaVu Sans Mono) noticeably wider than before. So Windows, OSX, and old Gnu/Linux would render a particular line of text sized at "12px" within less than a single pixel of each other. The new Gnu/Linux font stack (seen in Ubuntu 16.04 and some recent Arch) rendered the same text about 7 pixels wider.
Worse, the newer Gnu/Linux font stack quantizes the "px" sizes such that the next smallest size is noticeably smaller. So in Ubuntu 16.04 I have to compromise by keeping the object box the same size and having some extra padding at the end-- otherwise users of that OS could end up tightly spacing their object chains in ways that cause overlaps on the other platforms.
So... I'd like to get a handle on that mess first, then handling arbitrary font families-- as in cyclone/comment-- will hopefully be easier and less prone to bugs.
well, it seems some of the issues are exactly what we're facing now...
I think those issues are impossible to solve for displaying arbitrary fonts in a diagram like a Pd patch, and especially for arbitrary fonts in multi-line text. The user simply won't be able to predict whether or not there will be collisions on someone else's platform (or even if those fonts aren't available, which fonts will get chosen).
I'm all for porting cyclone/comment for the sake of Max compatibility. But I'd strongly advise against using cyclone/comment in any patch that's supposed to be used cross-platform (aside from its own help patch, of course).
-Jonathan
cheers
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/li stinfo/pd-list
_______________________________________________Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/li stinfo/pd-list
Why not just use the built-in <ctrl-5> comment?
From: Alexandre Torres Porres <porres@gmail.com>
To: Jonathan Wilkes jancsika@yahoo.com Cc: Pd-List pd-list@lists.iem.at Sent: Friday, December 2, 2016 1:10 PM Subject: Re: [PD] cyclone comment and cross platform (was Re: Purr Data rc1)
Hi, I see Purr Data has this feature where it accepts spaces in lables such as in canvases... this is awesome, and mostly why I use cyclone/comment I can see we could depart from how you can lable stuff in Purr Data to make a new working cross platform version of cyclone/comment that is still backwards compatible. cheers 2016-11-29 2:28 GMT-02:00 Alexandre Torres Porres porres@gmail.com:
one question, how does canvas and other fonts for labels work in cross platforms? why not use that for comment... for now, all cyclone/comment is can be thought of just being a fancy label perhaps... I did use it a lot in my new help files that I'm working on, but only cause it'd be too much work to use canvas and labels, as it'd imply a canvas for each word as it doesn't take spaces (is only a symbol) I was even thinking of ditching it when, it stopped working on vanilla 0.47 - yeah, that's another thing, a fix needs to be made to vanilla for old versions of comment (0.2 and below to work) - but then I realized it could be really useful. I was also hoping to add properties windows to make it more convenient. anyway, the question is, why labels and stuff simply work? cheers
2016-11-28 21:45 GMT-02:00 Jonathan Wilkes jancsika@yahoo.com:
Another reason for putting it off is that I still haven't figured out a sane approach to handling arbitrary fonts in a diagram where everything is absolutely positioned. In fact I only have a minimally-workable approach to handling a single, mono- spaced font across platforms. For example, there was a change somewhere in the Gnu/Linux font-stack (relatively) recently that renders fonts (or at least DejaVu Sans Mono) noticeably wider than before. So Windows, OSX, and old Gnu/Linux would render a particular line of text sized at "12px" within less than a single pixel of each other. The new Gnu/Linux font stack (seen in Ubuntu 16.04 and some recent Arch) rendered the same text about 7 pixels wider. Worse, the newer Gnu/Linux font stack quantizes the "px" sizes such that the next smallest size is noticeably smaller. So in Ubuntu 16.04 I have to compromise by keeping the object box the same size and having some extra padding at the end-- otherwise users of that OS could end up tightly spacing their object chains in ways that cause overlaps on the other platforms. So... I'd like to get a handle on that mess first, then handling arbitrary font families-- as in cyclone/comment-- will hopefully be easier and less prone to bugs.
well, it seems some of the issues are exactly what we're facing now...
I think those issues are impossible to solve for displaying arbitrary fonts in a diagram like a Pd patch, and especially for arbitrary fonts in multi-line text. The user simply won't be able to predict whether or not there will be collisions on someone else's platform (or even if those fonts aren't available, which fonts will get chosen).
I'm all for porting cyclone/comment for the sake of Max compatibility. But I'd strongly advise against using cyclone/comment in any patch that's supposed to be used cross-platform (aside from its own help patch, of course).
-Jonathan
cheers
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list
Spaces work in labels in L2Ork because they are escaped with a backslash. But this is creating an incompatibility with Vanilla, which then can't read the object's properties.
If you want a way to get larger, nicer text into a PD file than allowed with the ctrl+5 comment, the best way might be to use ASCII 255, the non breaking space (" "), which looks like a space but is read like a regular character. It's a bit of a pain to copy it between every word, but it works nicely across platforms once it's in place. A faster option for editing might be to let Vanilla replace spaces with underscores and then edit them in the .pd file with a text editor.
From: Pd-list pd-list-bounces@lists.iem.at on behalf of Jonathan Wilkes via Pd-list pd-list@lists.iem.at Sent: 04 December 2016 01:27 To: Alexandre Torres Porres Cc: Pd-List Subject: Re: [PD] cyclone comment and cross platform (was Re: Purr Data rc1)
Why not just use the built-in <ctrl-5> comment?
From: Alexandre Torres Porres porres@gmail.com To: Jonathan Wilkes jancsika@yahoo.com Cc: Pd-List pd-list@lists.iem.at Sent: Friday, December 2, 2016 1:10 PM Subject: Re: [PD] cyclone comment and cross platform (was Re: Purr Data rc1)
Hi, I see Purr Data has this feature where it accepts spaces in lables such as in canvases... this is awesome, and mostly why I use cyclone/comment
I can see we could depart from how you can lable stuff in Purr Data to make a new working cross platform version of cyclone/comment that is still backwards compatible.
cheers
2016-11-29 2:28 GMT-02:00 Alexandre Torres Porres <porres@gmail.commailto:porres@gmail.com>: one question, how does canvas and other fonts for labels work in cross platforms?
why not use that for comment... for now, all cyclone/comment is can be thought of just being a fancy label perhaps...
I did use it a lot in my new help files that I'm working on, but only cause it'd be too much work to use canvas and labels, as it'd imply a canvas for each word as it doesn't take spaces (is only a symbol)
I was even thinking of ditching it when, it stopped working on vanilla 0.47 - yeah, that's another thing, a fix needs to be made to vanilla for old versions of comment (0.2 and below to work) - but then I realized it could be really useful. I was also hoping to add properties windows to make it more convenient.
anyway, the question is, why labels and stuff simply work?
cheers
2016-11-28 21:45 GMT-02:00 Jonathan Wilkes <jancsika@yahoo.commailto:jancsika@yahoo.com>:
Another reason for putting it off is that I still haven't figured out a sane approach to handling arbitrary fonts in a diagram where everything is absolutely positioned. In fact I only have a minimally-workable approach to handling a single, mono- spaced font across platforms. For example, there was a change somewhere in the Gnu/Linux font-stack (relatively) recently that renders fonts (or at least DejaVu Sans Mono) noticeably wider than before. So Windows, OSX, and old Gnu/Linux would render a particular line of text sized at "12px" within less than a single pixel of each other. The new Gnu/Linux font stack (seen in Ubuntu 16.04 and some recent Arch) rendered the same text about 7 pixels wider.
Worse, the newer Gnu/Linux font stack quantizes the "px" sizes such that the next smallest size is noticeably smaller. So in Ubuntu 16.04 I have to compromise by keeping the object box the same size and having some extra padding at the end-- otherwise users of that OS could end up tightly spacing their object chains in ways that cause overlaps on the other platforms.
So... I'd like to get a handle on that mess first, then handling arbitrary font families-- as in cyclone/comment-- will hopefully be easier and less prone to bugs.
well, it seems some of the issues are exactly what we're facing now...
I think those issues are impossible to solve for displaying arbitrary fonts in a diagram like a Pd patch, and especially for arbitrary fonts in multi-line text. The user simply won't be able to predict whether or not there will be collisions on someone else's platform (or even if those fonts aren't available, which fonts will get chosen).
I'm all for porting cyclone/comment for the sake of Max compatibility. But I'd strongly advise against using cyclone/comment in any patch that's supposed to be used cross-platform (aside from its own help patch, of course).
-Jonathan
cheers
Pd-list@lists.iem.atmailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-listhttps://lists.puredata.info/listinfo/pd-list
Another thing that pd-l2ork's comment does that makes it theoretically incompatible with vanilla, it recognizes line breaks and saves them. It uses ASCII 11 to save it into the .pd file which is vertical tab that is by and large unused. While vanilla shows line breaks when creating an object, cutting and pasting it, or saving, closing, and reopening the file shows that they don't get saved. As a result a lot of patches sidestep this by using multiple comments, which is hard to maintain, particularly when it comes to writing documentation.
Both improvements pd-l2ork uses could be easily ported back to vanilla as I cannot think of a scenario where it could potentially cause a breakage in backwards compatibility.
Best,
Ico
On 12/3/2016 9:10 PM, Liam Goodacre wrote:
Spaces work in labels in L2Ork because they are escaped with a backslash. But this is creating an incompatibility with Vanilla, which then can't read the object's properties.
If you want a way to get larger, nicer text into a PD file than allowed with the ctrl+5 comment, the best way might be to use ASCII 255, the non breaking space (" "), which looks like a space but is read like a regular character. It's a bit of a pain to copy it between every word, but it works nicely across platforms once it's in place. A faster option for editing might be to let Vanilla replace spaces with underscores and then edit them in the .pd file with a text editor.
*From:* Pd-list pd-list-bounces@lists.iem.at on behalf of Jonathan Wilkes via Pd-list pd-list@lists.iem.at *Sent:* 04 December 2016 01:27 *To:* Alexandre Torres Porres *Cc:* Pd-List *Subject:* Re: [PD] cyclone comment and cross platform (was Re: Purr Data rc1) Why not just use the built-in <ctrl-5> comment?
*From:* Alexandre Torres Porres porres@gmail.com *To:* Jonathan Wilkes jancsika@yahoo.com *Cc:* Pd-List pd-list@lists.iem.at *Sent:* Friday, December 2, 2016 1:10 PM *Subject:* Re: [PD] cyclone comment and cross platform (was Re: Purr Data rc1)
Hi, I see Purr Data has this feature where it accepts spaces in lables such as in canvases... this is awesome, and mostly why I use cyclone/comment
I can see we could depart from how you can lable stuff in Purr Data to make a new working cross platform version of cyclone/comment that is still backwards compatible.
cheers
2016-11-29 2:28 GMT-02:00 Alexandre Torres Porres <porres@gmail.com mailto:porres@gmail.com>:
one question, how does canvas and other fonts for labels work in cross platforms? why not use that for comment... for now, all cyclone/comment is can be thought of just being a fancy label perhaps... I did use it a lot in my new help files that I'm working on, but only cause it'd be too much work to use canvas and labels, as it'd imply a canvas for each word as it doesn't take spaces (is only a symbol) I was even thinking of ditching it when, it stopped working on vanilla 0.47 - yeah, that's another thing, a fix needs to be made to vanilla for old versions of comment (0.2 and below to work) - but then I realized it could be really useful. I was also hoping to add properties windows to make it more convenient. anyway, the question is, why labels and stuff simply work? cheers 2016-11-28 21:45 GMT-02:00 Jonathan Wilkes <jancsika@yahoo.com <mailto:jancsika@yahoo.com>>: Another reason for putting it off is that I still haven't figured out a sane approach to handling arbitrary fonts in a diagram where everything is absolutely positioned. In fact I only have a minimally-workable approach to handling a single, mono- spaced font across platforms. For example, there was a change somewhere in the Gnu/Linux font-stack (relatively) recently that renders fonts (or at least DejaVu Sans Mono) noticeably wider than before. So Windows, OSX, and old Gnu/Linux would render a particular line of text sized at "12px" within less than a single pixel of each other. The new Gnu/Linux font stack (seen in Ubuntu 16.04 and some recent Arch) rendered the same text about 7 pixels wider. Worse, the newer Gnu/Linux font stack quantizes the "px" sizes such that the next smallest size is noticeably smaller. So in Ubuntu 16.04 I have to compromise by keeping the object box the same size and having some extra padding at the end-- otherwise users of that OS could end up tightly spacing their object chains in ways that cause overlaps on the other platforms. So... I'd like to get a handle on that mess first, then handling arbitrary font families-- as in cyclone/comment-- will hopefully be easier and less prone to bugs. > well, it seems some of the issues are exactly what we're facing now... I think those issues are impossible to solve for displaying arbitrary fonts in a diagram like a Pd patch, and especially for arbitrary fonts in multi-line text. The user simply won't be able to predict whether or not there will be collisions on someone else's platform (or even if those fonts aren't available, which fonts will get chosen). I'm all for porting cyclone/comment for the sake of Max compatibility. But I'd strongly advise against using cyclone/comment in any patch that's supposed to be used cross-platform (aside from its own help patch, of course). -Jonathan > cheers ______________________________ _________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list <https://lists.puredata.info/listinfo/pd-list>
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Another thing that pd-l2ork's comment does that makes it theoretically incompatible with vanilla, it recognizes line breaks and saves them. It uses ASCII 11 to save it into the .pd file which is vertical tab that is by and large unused. While vanilla shows line breaks when creating an object, cutting and pasting it, or saving, closing, and reopening the file shows that they don't get saved. As a result a lot of patches sidestep this by using multiple comments, which is hard to maintain, particularly when it comes to writing documentation.
Both improvements pd-l2ork uses could be easily ported back to vanilla as I cannot think of a scenario where it could potentially cause a breakage in backwards compatibility.
What about people parsing Pd files in Pd? If they're searching for symbol "foo", are they going to have to deal with the edge case of symbol "foo\v"?
Best, Ico
On 12/3/2016 9:10 PM, Liam Goodacre wrote:
#yiv8549058902 #yiv8549058902 -- P {margin-top:0;margin-bottom:0;}#yiv8549058902 Spaces work in labels in L2Ork because they are escaped with a backslash. But this is creating an incompatibility with Vanilla, which then can't read the object's properties.
If you want a way to get larger, nicer text into a PD file than allowed with the ctrl+5 comment, the best way might be to use ASCII 255, the non breaking space (" "), which looks like a space but is read like a regular character. It's a bit of a pain to copy it between every word, but it works nicely across platforms once it's in place. A faster option for editing might be to let Vanilla replace spaces with underscores and then edit them in the .pd file with a text editor.
From: Pd-list pd-list-bounces@lists.iem.at on behalf of Jonathan Wilkes via Pd-list pd-list@lists.iem.at Sent: 04 December 2016 01:27 To: Alexandre Torres Porres Cc: Pd-List Subject: Re: [PD] cyclone comment and cross platform (was Re: Purr Data rc1) Why not just use the built-in <ctrl-5> comment?
From: Alexandre Torres Porres <porres@gmail.com>
To: Jonathan Wilkes jancsika@yahoo.com Cc: Pd-List pd-list@lists.iem.at Sent: Friday, December 2, 2016 1:10 PM Subject: Re: [PD] cyclone comment and cross platform (was Re: Purr Data rc1)
Hi, I see Purr Data has this feature where it accepts spaces in lables such as in canvases... this is awesome, and mostly why I use cyclone/comment
I can see we could depart from how you can lable stuff in Purr Data to make a new working cross platform version of cyclone/comment that is still backwards compatible.
cheers
2016-11-29 2:28 GMT-02:00 Alexandre Torres Porres porres@gmail.com:
one question, how does canvas and other fonts for labels work in cross platforms?
why not use that for comment... for now, all cyclone/comment is can be thought of just being a fancy label perhaps...
I did use it a lot in my new help files that I'm working on, but only cause it'd be too much work to use canvas and labels, as it'd imply a canvas for each word as it doesn't take spaces (is only a symbol)
I was even thinking of ditching it when, it stopped working on vanilla 0.47 - yeah, that's another thing, a fix needs to be made to vanilla for old versions of comment (0.2 and below to work) - but then I realized it could be really useful. I was also hoping to add properties windows to make it more convenient.
anyway, the question is, why labels and stuff simply work?
cheers
2016-11-28 21:45 GMT-02:00 Jonathan Wilkes jancsika@yahoo.com:
Another reason for putting it off is that I still haven't figured out a sane approach
to handling arbitrary fonts in a diagram where everything is absolutely positioned.
In fact I only have a minimally-workable approach to handling a single, mono-
spaced font across platforms. For example, there was a change somewhere in
the Gnu/Linux font-stack (relatively) recently that renders fonts (or at least
DejaVu Sans Mono) noticeably wider than before. So Windows, OSX, and
old Gnu/Linux would render a particular line of text sized at "12px" within less
than a single pixel of each other. The new Gnu/Linux font stack (seen in Ubuntu
16.04 and some recent Arch) rendered the same text about 7 pixels wider.
Worse, the newer Gnu/Linux font stack quantizes the "px" sizes such that the
next smallest size is noticeably smaller. So in Ubuntu 16.04 I have to compromise
by keeping the object box the same size and having some extra padding at the
end-- otherwise users of that OS could end up tightly spacing their object chains
in ways that cause overlaps on the other platforms.
So... I'd like to get a handle on that mess first, then handling arbitrary font
families-- as in cyclone/comment-- will hopefully be easier and less prone
to bugs.
well, it seems some of the issues are exactly what we're facing now...
I think those issues are impossible to solve for displaying arbitrary fonts in a diagram like a Pd patch, and especially for arbitrary fonts in multi-line text. The user simply won't be able to predict whether or not there will be collisions on someone else's platform (or even if those fonts aren't available, which fonts will get chosen).
I'm all for porting cyclone/comment for the sake of Max compatibility. But I'd strongly advise against using cyclone/comment in any patch that's supposed to be used cross-platform (aside from its own help patch, of course).
-Jonathan
cheers
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 12/04/2016 07:13 PM, Jonathan Wilkes via Pd-list wrote:
If they're searching for symbol "foo", are they going to have to deal with the edge case of symbol "foo\v"?
hmm, how does "foo" not match "foo\v"?
grdsa IOhannes
From: IOhannes m zmölnig <zmoelnig@iem.at>
To: pd-list@lists.iem.at Sent: Sunday, December 4, 2016 1:48 PM Subject: Re: [PD] cyclone comment and cross platform (was Re: Purr Data rc1)
On 12/04/2016 07:13 PM, Jonathan Wilkes via Pd-list wrote:
If they're searching for symbol "foo", are they going to have to deal with the edge case of symbol "foo\v"?
hmm, how does "foo" not match "foo\v"?
[11(|[makefilename %c]|[symbol foo$1(|[select foo]|[bng] -Jonathan
grdsa IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 12/04/2016 07:57 PM, Jonathan Wilkes via Pd-list wrote:
[11(|[makefilename %c]|[symbol foo$1(|[select foo]|[bng]
ah, i misread your question - i was thinking of regexes (parsing the file outside of Pd)
Pd itself doesn't provide any ways to *search* for a string; the best you can get is to iteratively match atoms which fails in this case.
gfmrdsa IOhannes
This only pertains to comments and as such should not make any difference elsewhere (unless you want to live-code something by hacking comments :-). Also, Pd-L2Ork inherited from extended search in patch option that offers match full or a subset of a string which should cover all the cases.
On 12/4/2016 1:57 PM, Jonathan Wilkes via Pd-list wrote:
*From:* IOhannes m zmölnig zmoelnig@iem.at *To:* pd-list@lists.iem.at *Sent:* Sunday, December 4, 2016 1:48 PM *Subject:* Re: [PD] cyclone comment and cross platform (was Re: Purr Data rc1)
On 12/04/2016 07:13 PM, Jonathan Wilkes via Pd-list wrote:
If they're searching for symbol "foo", are they going to have to
deal with the edge case of symbol "foo\v"?
hmm, how does "foo" not match "foo\v"?
[11( | [makefilename %c] | [symbol foo$1( | [select foo] | [bng]
-Jonathan
grdsa IOhannes
Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
What about people parsing Pd files in Pd? If they're searching for symbol "foo", are they going to have to deal with the edge case of symbol "foo\v"?
Ivica,Just to give an example-- suppose someone is using a patch to store configuration data for their project. They type the config data as comments in the patch, much like [pd META]. Then they parse their patch from within Pd, using [textfile], or [text] or whatever.
Now, if they decide to insert some newlines into the comments to make their config prettier, as far as I understand this ends up appending an invisible '\v' character to the last atom of each line. So the next time they read their config they will get corrupted data that's hard to debug because the character doing the corruption is non-printable. That's the only direct downside I can see. But as a design pattern it's problematic-- there are other places in Pd where a dev tried to use an "obscure" character as a placeholder for something else. That approach usually ends up creating more bugs. -Jonathan
The character is not invisible. In an editor it manifests with an endline plus an indentation in the following line which actually visually helps parse things out inside a plaintext file like .pd.
I think the example you mentioned, while possible, is contrived because if a user is reading a config, they are likely already inside Pd with the intention of using such a config to configure their patch state. If this is the case, and the config is stored inside a patch in a form of a comment, then this is a non-issue because all \v chars are replaced with \n at runtime which IIRC regexp and similar methodologies can recognize as a separation between args.
Now, the only reason I can imagine someone parsing a pd file without actually loading it would be your pd META example for tooltips which is a one-off example that can be easily addressed in a number of ways. Other examples seem to me like academic exercises--why would you store config inside a comments inside a pd patch, just to parse a comment which would require you to circumnavigate all the other syntax inside the file when you could do the same in a plaintext file or a coll object, or better yet, use preset_hub/node system?
Best,
Ico
On 12/4/2016 2:38 PM, Jonathan Wilkes wrote:
What about people parsing Pd files in Pd? If they're searching for
symbol "foo", are they going to have to deal with the edge case of symbol "foo\v"?
Ivica, Just to give an example-- suppose someone is using a patch to store configuration data for their project. They type the config data as comments in the patch, much like [pd META]. Then they parse their patch from within Pd, using [textfile], or [text] or whatever.
Now, if they decide to insert some newlines into the comments to make their config prettier, as far as I understand this ends up appending an invisible '\v' character to the last atom of each line. So the next time they read their config they will get corrupted data that's hard to debug because the character doing the corruption is non-printable.
That's the only direct downside I can see. But as a design pattern it's problematic-- there are other places in Pd where a dev tried to use an "obscure" character as a placeholder for something else. That approach usually ends up creating more bugs.
-Jonathan
The character is not invisible. In an editor it manifests with an endline plus an indentation in the following line which actually visually helps parse things out inside a plaintext file like .pd.
I think the example you mentioned, while possible, is contrived because if a user is reading a config, they are likely already inside Pd with the intention of using such a config to configure their patch state. If this is the case, and the config is stored inside a patch in a form of a comment, then this is a non-issue because all \v chars are replaced with \n at runtime which IIRC regexp and similar methodologies can recognize as a separation between args. Now, the only reason I can imagine someone parsing a pd file without actually loading it would be your pd META example for tooltips which is a one-off example that can be easily addressed in a number of ways. Other examples seem to me like academic exercises--why would you store config inside a comments inside a pd patch, just to parse a comment which would require you to circumnavigate all the other syntax inside the file when you could do the same in a plaintext file or a coll object, or better yet, use preset_hub/node system? I agree that '\v' is a small inconsistency, but it's an inconsistency nonetheless. I worry about it getting used a model more than anything else. This mostly comes after seeing the warnings in core Pd, and noticing that the same class of warnings is replicated throughout nearly all of the external libraries.
-Jonathan
Best, Ico
On 12/4/2016 2:38 PM, Jonathan Wilkes wrote:
> What about people parsing Pd files in Pd? If they're searching for symbol "foo", are they going to have to deal with the edge case of symbol "foo\v"?
Ivica, Just to give an example-- suppose someone is using a patch to store configuration data for their project. They type the config data as comments in the
patch, much like [pd META]. Then they parse their patch from within Pd, using [textfile], or [text] or whatever.
Now, if they decide to insert some newlines into the comments to make their config prettier, as far as I understand this ends up appending an invisible '\v' character to the last atom of each line. So the next time they read their config they will get corrupted data that's hard to debug because the character doing the corruption is non-printable. That's the only direct downside I can see. But as a design pattern it's problematic-- there are other places in Pd where a dev tried to use an "obscure" character as a placeholder for something else. That approach usually ends up creating more bugs. -Jonathan
On 12/04/2016 03:10 AM, Liam Goodacre wrote:
Spaces work in labels in L2Ork because they are escaped with a backslash. But this is creating an incompatibility with Vanilla, which then can't read the object's properties.
are you sure? my impression is, that Pd can parse any labels with backslash-escaped spaces just fine (see attached patch with a canvas with a label with spaces, which works nicely on my Pd-0.47-1 as packaged in Debian).
the only problem occurs when you try to save such patches.
mgfdsar IOhannes
2016-12-03 23:27 GMT-02:00 Jonathan Wilkes jancsika@yahoo.com:
Why not just use the built-in <ctrl-5> comment?
So, why use cyclone/comment instead of pd’s comment?
It does offer advantages as it is, such as setting a different font type, different font size and colors. It is still not updated to the latest version of Max 4, let alone up to Max 7, so it can be improved by including other functionalities, such as background color. We didn’t touch it yet and I was hoping to at least include a properties window as it’d be the sensible thing to do with it.
I’ve been finding it very useful, and I can see advantages to have it in vanilla even if you could use labels with spaces in there, such as not having any canvas background or being able to break the text into different lines.
Why keep distributing cyclone/comment in cyclone? Well, cause it was there before…
Now, we have some issues with it.
In the cyclone development end, we find it is not behaving well in cross platforms, we need to fix this! We haven’t really tried it yet… and we’re not sure where to look.
In the Purr Data end, it is not yet ported, and it is the only object in cyclone that doesn’t load yet.
So, my idea would be to maybe start a new cyclone/comment for Purr Data, having it’s ability to use spaces in GUI’s labels as a starting point. Somewhere in this process, it’d be good to come up with also a working external, that doesn’t look weird in Linux, for the cyclone package release.
cheers
-
Alexandre Torres Porres -
IOhannes m zmölnig -
Ivica Ico Bukvic -
Jonathan Wilkes -
Liam Goodacre