I like that the issue with maptext overflowing was fixed and it now wraps correctly, but I am still left with a dilemma when trying to create an on-screen chat box. Unless I use a monospace font, there is no way for me to tell if a message overflowed onto another line, and therefore if I want to display X amount of lines to the user (In this case, 17), it will bug up when trying to do so because it overflowed to another line and I can't tell.
I'm making this request simply because I would like some way to be able to tell if a line of text (I have them all separated with <br> tags) goes onto a second or even third line in accordance with the font used and the maptext_width.
I'm not sure how possible it is, but it would be very helpful.
ID:1450772
Dec 22 2013, 10:20 am
|
|||||||
| |||||||
In response to FIREking
|
|
I was just using simple Times New Roman 9pt. I'm not super experienced with fonts and stuff so I don't really have any experience with this to be able to give a good, fortified suggestion. I'm hoping someone like yourself with experience can come up with something.
I do like the "scroll up" ability, quite a bit. So long as it could work when using <text align='top'>, it should provide a workable system to create a chatbox with. |
This is what I use for the time being.
client/var/tmp/Lines = list() It's not perfect but it handles maptext-overlapping across multiple lines sort of well. It doesn't identify < br >/line breaks though (yet). My system uses a list (Lines) of text entries, if one entry is too long the display portion does some-extra leg work. Sort of forgot about < br > tags, but one would just have to figure out a way to count how many were in the given "line" and add that number to
lines -= round(lentext(v)/max_character_width)+1//this checks how long a single text entry over the max width
Update: Butchered FA's split text proc to make this: proc/CountStrings(haystack, needle)
lines -= round(lentext(v)/max_character_width)+1+CountStrings(v,"<br>")
I'm half asleep and molesting split-text that way just kind of pop'ed in my head, there's probably cleaner alternatives my insomniac brain didn't see. |
Yeah, it's be nice if we could get some way of telling how long (in pixels) map_text is.
At the moment, the only way of doing this is using some kind of list to keep track of the length of each character used, then looping through each character in the string you're using and adding up the length of it. Then you'd need to find the closest space to the point you want the string to cut off and split it in two. |
At the moment, the only way of doing this is using some kind of list to keep track of the length of each character used. There's another way, but it involves browsers. Basically you pop the text into a hidden div via javascript through the browser with a limited width, and check the height of the div after the contents have updated. Though, of course, this is somewhat inelegant. |
I've been running the chat text through DMIFonts getlines() proc, after setting up a DMIFont the style and size of my maptext, then breaking that up into a list with Forum_Accounts split proc to count the lines, and displaying sections of the chat text list on demand.
|
Maybe we should be given the equivalent to the output control with maptext, which would automatically "scroll up" to handle the overflow...
I personally like the idea of having the ability to just strictly use monospace fonts with a graphical font system (instead of developers hacking together screen object systems controlled by the server). Its very annoying that we still don't have something as basic as this. One of the first things you learn to program when making a game with opengl is how to make the client draw text on the screen using little textured quads that have bitmaps of letters on them. I don't understand why the seeker client doesn't have this functionality.
Assuming you really love TTF fonts for some reason (even though you can't predict how they will look on different machines, and you can't measure them at all), I would say you need to think of a clever way to handle the overflow. Without that suggestion, I don't see this feature request having any momentum.