[PD] cyclone comment and cross platform (was Re: Purr Data rc1)

Sun Dec 4 19:13:22 CET 2016

> 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 at lists.iem.at> on behalf of Jonathan Wilkes via Pd-list <pd-list at 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 at gmail.com>
 To: Jonathan Wilkes <jancsika at yahoo.com> 
 Cc: Pd-List <pd-list at 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 at 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 at 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 at lists.iem.at mailing list
 UNSUBSCRIBE and account-management ->  https://lists.puredata.info/ listinfo/pd-list

 _______________________________________________
Pd-list at lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list

_______________________________________________
Pd-list at lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20161204/f7254528/attachment-0001.html>