> 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-boun...@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 <por...@gmail.com>
To: Jonathan Wilkes <jancs...@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 <por...@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 <jancs...@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
_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
