Peter Nyboer

not sure if a forum post went thru or not...but this is a response to 

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 

(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 

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:

(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:

jit-textfile-and-jit-gl-text3d

hmmm...a good alternative to chromakeying out the 0s in favor of 32s, but it still has the same center and right alignment problems....

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?

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?


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.

>
> 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.

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 

> 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....

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....

jit.textfile and jit.gl.text3d