jit.textfile and jit.gl.text3d


    Apr 27 2006 | 9:15 pm
    not sure if a forum post went thru or not...but this is a response to an old thread... I'm finally getting to look at jit.textfile -> jit.gl.text3d. Works pretty well, but I have some issues. The r/c/l justify works, but only if the "filler" characters are "0". On my XP machine, at least, it renders ASCII "0" as a rectangle. So instead of printing something like in my jit.window:
    hello i am typing text
    i get:
    hello_ _ _ _ _ _ i am typing text
    (just pretend the underscores are rectangles :) ) So, clever fellow that I pretend to be, I chromakeyed the jit.textfile output with a 1x1 matrix "filled" with "32" for blank space. This gets rid of the rectangles, and looks fine for left justified text, but for center and right, the spaces mess up the alignment. Here is a clear patch to illustrate the problem. Is there a workaround? It seems that jit.gl.text3d treats 0 as a special character for the purposes of alginments, as every other ascii character messes up the aligns:

    • Apr 27 2006 | 9:54 pm
    • Apr 27 2006 | 10:15 pm
      hmmm...a good alternative to chromakeying out the 0s in favor of 32s, but it still has the same center and right alignment problems....
      p
    • Apr 27 2006 | 10:35 pm
      havent noticed that. mybe find the num of trailing 0's and add same number at the start of line. with (a to clever for me) use of jit.str.regexp. will this work?
    • Apr 28 2006 | 7:55 am
      On Apr 28, 2006, at 12:15 AM, pnyboer wrote:
      > > hmmm...a good alternative to chromakeying out the 0s in favor of > 32s, but it still has the same center and right alignment problems....
      I might recommend using a strategy which sends each line serially to jit.gl.text3d @automatic 0 if you want to avoid such issues.
      -Joshua
    • Apr 28 2006 | 3:45 pm
      after trying on a mac, i see that it doesn't render ascii 0....but it doesn't seem to do center or right align correctly (OSX.39)....see patch at end of mail....
      > I might recommend using a strategy which sends each line serially to > jit.gl.text3d @automatic 0 if you want to avoid such issues.
      hmmm....wouldn't this sort of defeat the advantage of having all the text in a single matrix? It seems that such a strategy would require me to cook up some sort of leading scheme, which sounds like a somewhat awful task that would probably never come out right due to varying font metrics and scales. Or is there something trickier I'm missing?
      I guess a feature request for jit.gl.text3d would be a flag to defeat rendering of ascii character 0. "ascii0 0" could be a nice message to send to overcome this problem :) highly specific, but it would make the textfile->text3d all so convenient....
      p.