text function limitations?

@RonJeffries it seems to me one of those low-priority bugs that just hangs around forever. I’m idly curious if rendering to an image context and then drawing that as a sprite would solve the problem in, like, 4 easy steps.

might. try it?

@RonJeffries Were you referring to my code above about the rectangle at the side of the screen. If so, I added the following changes to the above code. It now use the edges as limits.

    self.x=math.max(5,x)
    self.y=math.max(5,y)  
    self.width=math.min(width,WIDTH-self.x-5)
    self.height=math.min(height,HEIGHT-self.y-5) 

If anyone is looking for other print/text issues, the following code prints the string of zeroes to the print window. 390768 works, but 390769 doesn’t show anything.
It prints 13,956 lines.

function setup()
    str=string.rep("0",390768)
    print(str)
end

@RonJeffries try this project.

If you tap the Boolean for rendering text to a buffer first, it’ll do that.

Right now for me there’s no visible difference, because at least on my iPhone this project isn’t currently causing the vanishing-text problem, which I know for a fact it used to because @dave1707 pointed that out the first time I posted it.

@UberGoober If I slide the rectH parameter, the text disappears if I do the Boolean switch or not.

@dave1707 huh you’re right.

I didn’t catch that because it’s not just about the text extending past the screen, which is what I tested for, and which works fine at most sizes.

For some reason this is about certain specific heights. I don’t get it.

As far as I’m concerned, there’s limitations to Codea. It can’t do everything the way everyone wants. If Codea doesn’t do something, I write code to compensate, that’s life. Sure, @Simeon can adjust things, but there will always be something else.

I’m here to request what I think would be of value. If I wanted to put up with bad stuff, I’d code in C# :smiley:. Simeon gets to decide, but I believe it is part of our job as experienced users to suggest ideas of potential value.

@dave1707 your pragmatic attitude makes sense to me a lot of time, but I think there are edge cases where you might possibly be going overboard, such as questioning the necessity of keeping Codea from violating the universal standard for where the cursor goes after you paste something, for one, and this, for another.

Consistency in rendering text at any size and any location no matter what the coordinates is imho also a universal standard—it’s table stakes for any graphics renderer really.

Codea flubbing it obviously isn’t a death blow, mainly because it doesn’t come up very often, but it does come up now and then, and when it does, it’s a bad look.

@RonJeffries @UberGoober I’m not saying that Codea shouldn’t be fixed. I’m just saying that it has its limitations and we’re going to run into them as we write code. So someone can either stop writing code and wait until the problems are fixed, or they’re going to have to modify their code to work around it. Once the fixes are made, they can always go back and modify the original code or leave it. Right now there are limitations as to how text is displayed on the screen. So someone can either wait or code around it until, if or when it’s fixed. The text limitation has been around for a very long time. Will it be changed soon, I don’t know. But I’ll write code to avoid it. Will my code work, yes. Will it still work when the fix is made, probably.

I’m not sure I am understanding the point here. I’m sure we all write code including whatever workarounds we need to get things to work. But it seems you were objecting to my request that text not fail at screen edge but instead display as much as fits. Were you not objecting? If not … then I don’t understand.

Thanks!

@RonJeffries We must not be talking about the same thing. You posted this right after my post of a program above.

If I draw a rectangle at the side of the screen, I get half a rectangle. I suggest that text should clip at the screen edge, not just vanish altogether.

So I made changes to my code to clip the text if the rectangle exceeded the edge of the screen. So we’re you referring to my program or something else.

i’m referring to the same thing. i can of course work around it. what i don’t understand is that you seem to be taking issue with the idea that it would be more consistent and better, if it clipped.

I’m can’t quite follow the entire discussion but I’ll throw in my two cents.
In my opinion the text should absolutely just clip by default. From my own experience with it, the current behaviour just seems like a bug. A limitation yes, but one imposed by the presence of the bug itself.

I can understand it’s unlikely to be fixed and I can work around it but it’s still a bug and the limitation should not realistically exist. There’s not even a clear cut point as far as I can tell as to when the bug manifests.

@RonJeffries In the case of my code, I didn’t see the text clipping as a problem. The user chooses the x,y,w,h values for splitString to create the text/rect area. If the edge of the text box ended up passed the edge of the screen and got clipped, they would alter the values to keep it on the screen. I figured that was just a user problem. But anyways I fixed it so the edge limits the size unless they’re too close to an edge. I normally don’t code for everything that can go wrong, not even for myself. If I write it and it breaks for something, I usually fix it.

PS. My other posts were about the text disappearing if it was too long to display on the screen. That’s been a problem for a long time and the only fix is to code for it.

as you were, or at least as i was. i think there may be an easy way to do this. will report back.

[original post deleted] I think I got on a bit of a high horse that I’d prefer to climb down from. Carry on!

@dave nice detective work, it seems like. That explains why this bug crops up on my iPad when the text is nowhere near the size of the screen.

Here’s an example that I probably posted the first time I wrote about the text disappearing. Change the sliders for tww (textWrapWidth) and fs (fontSize) to vary the text on the screen. In the upper right corner I display the text width and text height. Anytime the width or height exceeds 1024, the text disappears.

viewer.mode=STANDARD

function setup()
    parameter.integer("tww",100,1100,500)
    parameter.integer("fs",10,100,20)
    fill(255)
    textMode(CORNER)
    str=string.rep("0",500)
end

function draw()
    background(0)
    fontSize(fs)
    textWrapWidth(tww)
    w,h=textSize(str)
    text(str,0,0)
    pushStyle()
    textWrapWidth(1000)
    fontSize(17)
    fill(224, 199, 174)
    rect(WIDTH-220,HEIGHT-80,200,50)
    fill(0)
    text("string width   "..w,WIDTH-200,HEIGHT-50)
    text("string height  "..h,WIDTH-200,HEIGHT-80)
    popStyle()
end

Here’s the explanation for the disappearing text on the screen. I thought it was based on the screen width or height, but it’s not. I knew about this a long time ago, but I just remembered how it works now. I’ll see if I can find my original post from long ago. But here’s the explanation in the meantime.

There’s a command textSize() that returns the 2 values width and height of a string. So w,h=textSize(string) will give the w,h values of a string that’s being displayed using the text command. Different fonts and fontSize will change the values of w and h. The only constant for the text command no matter what the font or fontSize is, is 1024. If the width of the text being displayed is 1024 or less, it will show on the screen. If the width is greater than 1024, it will disappear. So you can determine if a text command will or won’t show on the screen. It doesn’t matter if you’re in portrait or landscape orientation, 1024 is the limit.

PS. Here’s one link where I explain this and refer to an earlier post. Scroll to the bottom.

https://codea.io/talk/discussion/8682/scrolling-text-box