basiljs gets points!

[ffd8]

• 4 new point based functions: createOutlines(), addPoints(), points(), pointsInPaths()
• w/ initial research by @kajetansom on point getting and interpolating, extended to handle live type, multi-line type, pageitems, etc.
• createOutlines() built upon outline pseudocode from @fabianmoronzirfas on issue Convert text to path  #100

Some sample code for the new functions:

  // create text and outline it
  textSize(100);
  var tf = createOutlines(text("basil.js", 50, 50, width, height));
  
  // add # of points between points of outline
  addPoints(tf, 5);
  
  // get all points as 1D array
  var pts = points(tf);
  
  // get all points in separate paths as 2D array
  var ptsPaths = pointsInPaths(tf);
  
  
  // redraw 1D array from points()
  tf.remove();
  noFill();
  beginShape();
  for (var i = 0; i < pts.length; i++) {
      vertex(pts[i].x, pts[i].y);
  }
  endShape();
  
  
  // redraw 2D array from pointsInPaths()
  //tf.remove();
  noFill();
  translate(0, 150);
  for (var j = 0; j < ptsPaths.length; j++) {
    beginShape(CLOSE);
    for (var i = 0; i < ptsPaths[j].length; i++) {
        vertex(ptsPaths[j][i].x, ptsPaths[j][i].y);
    }
    endShape();
  }


  // redraw wildstyle
  noFill();
  translate(0, 150);
  var offset = 15;
  for (var j = 0; j < ptsPaths.length; j++) {
    beginShape(CLOSE);
    for (var i = 0; i < ptsPaths[j].length-offset; i++) {
        vertex(ptsPaths[j][i+offset].x, ptsPaths[j][i+offset].y);
        vertex(ptsPaths[j][i].x, ptsPaths[j][i].y);
    }
    endShape();
  }

[ff6347]

Nice. I'm a bit behind on my reviews lately. Maybe @trych finds some time soonisher then me.

[trych]

Sweet! Can't make any promises, but will try to have a look at it soon!

[trych]

Ok, here we go. Sorry, quite a lot of points, but it would be great to get this right, I really like the new functions! :)

General

• There was a lot of auto-formatting (removal/adding of indenting) happening in math.js. Easiest would be to go back to original file, add the new function and resave with auto-formatting turned off , then do another PR.
• parameter names are missing in the inline documentation; syntax is supposed to be @param {Type} parameterName Description.
• new functions need to be added to changelog.txt :)

createOutlines

• I think setting the second parameter to false to actually not delete the original is pretty confusing. I would instead simply relabel the setting parameter to keepOriginal, so the user could optionally set a true flag to keep the original

• The second parameter still needs to be listed in the documentation

• Converting a multiline text frame does currently not return an array, but a group instead. It should return the actual array of Polygons as described

• we should generally avoid try catch statements whenever possible. In this case I would check if the passed object actually has a createOutlines() method (if(item.hasOwnProperty('createOutlines')))

• some special cases that give unpredictable results

  • creating outlines of a text frame linked to other textframes deletes all following text frames (not previous ones though). Possible solution: simply always convert the last text frame of a chain
  • if converting a story or a word with overset text, InDesign will throw an error, but gives the user the basil error that they used the wrong argument, we should check if the passed word ends in overset text

addPoints

• awesome function!
• again, we should try to avoid try/catch; maybe check if object contains polygons first, if so cycle through them, if not, check if it has paths and cycle through them
• my guess is, this function does not really work for all page items, so I would change the docs accordingly and only allow rectangles, ovals, graphic lines, polygons, paths (am I missing any) and then do an initial check, if any of these were passed
• amount is off by one, I think? If i do addPoints(item, 5) it actually adds only 4 points to each segment

points, pointsInPaths

• didn't have to much time to test these, but again the same as above (copy/paste):
• again, we should try to avoid try/catch; maybe check if object contains polygons first, if so cycle through them, if not, check if it has paths and cycle through them
• my guess is, this function does not really work for all page items, so I would change the docs accordingly and only allow rectangles, ovals, graphic lines, polygons, paths (am I missing any) and then do an initial check, if any of these were passed

optional extras, nice to have

• some simple example scripts with fancy results :)

[trych]

Needs some changes, see my comments above.

[ff6347]

Did you see these conflicts? for math.js?
Did you rebuild the basil.js file?

[ffd8]

Thanks @trych for all the comments above. Indeed, did something weird in Sublimetext and it formatted the whole math.js doc, so I'll re-do it. Git-noob.. do I need to cancel this pull, or can I simply modify it?

Re: Try/Catch, what is the problem with them? While I should also include the native InDesign error message, I found it better to offer some advice when the error occurred.. in testing, if somehow the wrong item was passed in one of those steps, sometime Indesign just said 'nope' – rather than articulating what was wrong.. that's where our catch and error message can help. What's a suggested alternative?

[trych]

Try/Catch, what is the problem with them?

It's just not very clean coding and a bit like "let the user do their stuff and see what happens" instead of planning it carefully and do proper checking of inputs. And as it stands right now (without the native InDesign error message) it is even more confusing, because I might get a error message like Be sure to use:\n Story | TextFrame | Paragraph | Line | Word | Character" after passing a word, so that's confusing. Mixing this with a native error message is also not good, because then you might have different local languages mixed in one error message.

Instead I would – as it is done in most basil functions currently – carefully check by code for each condition that needs to be fulfilled to use the function. That means first check, if the correct type of object was passed. If not give a helpful basil error. This error should avoid most further errors right away. Then, if necessary, check if the object has a path (or whatever your function needs). If not, give a helpful basil message. And so on.

Right now there are quite a few ways to "break" the functions and get caught in the try/catch statement. If there is proper check of the inputs, that could be avoided. Does that explanation help? If not, let me know, I might find some time to put together an example for one of the functions.

do I need to cancel this pull, or can I simply modify it?

I think the cleanest would be to actually cancel this PR and prepare a new one, else all these formatting changes back and forth would end up in the git history. Would that be okay for you?

Edit: Also, since I merged the bounds() PR in the meantime, there is now a merge conflict. So if you would do a new PR, you could (beforehand) merge the develop branch to be up-to-date and to avoid this conflict as well.

[ffd8]

Closed! Replaced by a much better set of functions in #352 – integrating the helpful suggestions above. Tested it against so many scenarios.. should be quite safe now... and no try/catch!