CEGUI (Crazy Eddie's GUI) Forums

hi all , it's my first question topic.
^^ cegui is very cool and i like it very much.

those days i have a problem about the function
[bMultiLineEditbox::formatText

if the key ' '(space)is the first word , there must be a new line like the effect '\n' and the codes i fond is
"
// get cp / char count of next token
size_t nextTokenSize = getNextTokenLength(paraText, lineIndex + lineLen);

// get pixel width of the token
float tokenExtent = fnt->getTextExtent(paraText.substr(lineIndex + lineLen, nextTokenSize));
"

so my question is why we use the wrap TextUtils::DefaultWrapDelimiters(" \n\t\r") to split the text?

thank for your time[/b]

Hi,

haihuojiming wrote:so my question is why we use the wrap TextUtils::DefaultWrapDelimiters(" \n\t\r") to split the text?

As opposed to?

I think my original intention might have been to extend the system to allow user configuration of the delimiters used for this, and other things. I guess it's something that just never got done (I don't recall it having come up as a question before).

CE.

Glad to see your reply, CE

eg. i put the text " i-should-be-the-first-line" to MultiLineEditbox(there is a space word value befor "i should") ,
int the MultiLineEditbox::formatText function

size_t nextTokenSize = getNextTokenLength(paraText, lineIndex + lineLen);
float tokenExtent = fnt->getTextExtent(paraText.substr(lineIndex + lineLen, nextTokenSize));
will be return 1 and the " " pixel width, then the lineLen = 1 , so when the other words "i-should-be-the-first-line" 's pixel width is widther than the MultiLineEditbox 's width
if ((lineExtent + tokenExtent) > areaWidth)
{
// Was this the first token?
if (lineLen == 0)
{
// get point at which to break the token
lineLen = fnt->getCharAtPixel(paraText.substr(lineIndex, nextTokenSize), areaWidth);
}

// text wraps, exit loop early with line info up until wrap point
break;
}
those codes work, and a new line will be create, so the result is

______________
|.........................| <----- empty line("...." means the space symbol)
| i-should-be-the|
| -first-line...........|
|_____________|

i think the use of delimiters may be have this problem.

is it?

sorry for my bad express, and thanks again for your help.

Ah, I think I understand now.

Basically the issue is: If you have a line that consists of long "word" (meaning a string of chars with none of the delimiters) with a space at the start of the line, it wraps creating a blank line at the start - which is not what you really want to see.

I would call this a bug in the system, actually I'll have a look into it and determine the course of action to take. I do not think there is a workaround without editing the CEGUI source.

CE.

the feeling of report the bug to help cegui project is cool,
and

because i use cegui to a project, i'll reprot bugs i find .

That seems to be the default behavior for a multi-line editbox without horizontal scrolling. For example, click 'post reply' and test it out in the message box. The behavior makes perfect sense because when this happens in the middle of a paragraph you want this behavior: the word should automatically 'break' to the next line if it cannot fit on the current line. The best way to accomplish this is to break at the previous space. This is standard behavior.

Judging by the example you provided, it seems what you want is non-standard behavior; ie, instead of 'word-wrapping' you want 'letter-wrapping'. In this case, just call mleb->setWordWrapping(false).

One thing I discovered when I was testing this yesterday was that if you have some normal wrapped text, and it occurs that the last word before a wrap fits exactly within the wrap area, the space that follows is put at the start of the following line, if that line then consists of a long string of characters it will again wrap at the space, giving you a blank line in the middle of a sentence - this, at least, is not correct behaviour and so I created a mantis ticket. While I have not fixed it yet, the same fix will actually address both cases.

IMO, the first case is debatable as to whether it's an issue, and I do see how in come cases it's undesirable. The second case is IMO definitely an issue and I cant see any circumstance where it would be deemed acceptable (it's quite hard to get it to do it, the text has to fit just right!)...





CE

Actually CE, that scenario also makes sense and is standard behavior for multiline editboxes without horizontal scrolling. Again, you can test both situations by pressing the 'post reply' button here on the forum and use the letter x for testing inside the message box.

The reason this happens is because a space symbolizes the separation of a word. If you are using a control with 'word-wrapping' enabled, the only way to wrap adjacent words is by wrapping at the point where those words are separated. How exactly would you 'fix' the situation? You cannot just 'remove' the space and move the line up, because that character is essential to the sentence structure. If you just get rid of the space and move the line up, you are essentially combining those words.

Also, from a technical standpoint if you do this you will have to keep track of every occurance! What happens when the control is resized? What if the user wants to select->copy that text? Now you have to deal with managing/inserting/removing these spaces depending on all kinds of circumstances.



In regards to the original issue, if you look at his example he is obviously using incorrect grammar. The solution is simple, don't start a paragraph with a space! In regards to the second issue, either increase the controls width, insert a hyphen into the second word (word-wra), or just deal with it!

p.s. yes, I am a bit eccentric...

edit: actually you probably wouldn't need to manage anything, as you would probably just determine that when rendering the letters but your still breaking the sentence structure (a newline is not equivilent to a space!) and is non-standard behavior! ^_^

Jamarr wrote:yes, I am a bit eccentric...

Yah, me too - just a little bit though, honest!

In order to please everybody, I might add the new behaviour as an option

My fix would be either to skip the space at rendering as you mentioned, or keep any leading space at the start of the line.

No firm decision has been made yet since we've been tied up releasing 0.6.2 - which is now done \o/

CE.

I think i know why the WrapWords are used to wrap the string.
It's the result i really want to know because i think there must be a correct reason for using the wrapwords omt the textformat function.
thanks.

I use the Chinese in MultiLineEditbox and our language need no blank word between words. so it's puzzle for me .

it's also the reason that i don't edit the codes ablot this issue i thinked.

thank both and at last i can do sometion about it.

add a property. ^^

haihuojiming wrote:I use the Chinese in MultiLineEditbox and our language need no blank word between words. so it's puzzle for me .

Then, for correct word-wrapping, the system needs to know every Chinese word, or is there some trick to see where one can wrap text in Chinese ?

Pompei2 wrote:Then, for correct word-wrapping, the system needs to know every Chinese word, or is there some trick to see where one can wrap text in Chinese ?

in our text, the words are arounded one by one, blank is not nessery for two words, it's defference from English, for example:

"我喜欢游戏" means
i like game

so, the string will be wrapped just when no space of the widget be used for the follow words,
-----
+-----+
|我喜| <---- “喜欢” means like , but they can be put in two lines
|欢游|
|戏 |
+-----+

^^ so, system just wrap the Chinese words by no wrapword like ' ' '\t' ,ect

CrazyEddie wrote:or keep any leading space at the start of the line.

So basically, you'd take the length of the word + the previous space (if there is one) and if that length is greater than the controls width use letter-wrapping instead of word-wrapping? Something like this:



standard (current) behavior:


While it doesn't follow normal (textarea in ie, at least) behavior, it does look better.

haihuojiming wrote:

Pompei2 wrote:Then, for correct word-wrapping, the system needs to know every Chinese word, or is there some trick to see where one can wrap text in Chinese ?

in our text, the words are arounded one by one, blank is not nessery for two words, it's defference from English, for example:

"我喜欢游戏" means
i like game

so, the string will be wrapped just when no space of the widget be used for the follow words,
-----
+-----+
|我喜| <---- “喜欢” means like , but they can be put in two lines
|欢游|
|戏 |
+-----+

^^ so, system just wrap the Chinese words by no wrapword like ' ' '\t' ,ect

Again, if you don't need word wrapping why not just turn it off? You can do this programatically by calling setWordWrapping(false) or setting the wordwrap property to false in the looknfeel or layout xml file.

@Jamarr: Yeah, point taken That first example is pretty bad.

This has turned out to be quite an interesting discussion, especially in relation to the Chinese.

I still think some kind of option to switch to an alternate behaviour is the way to go.

@ haihuojiming: So getting back to the original issue, for Chinese the correct solution would be to effectively ignore any leading space on a line (meaning it's not drawn, and not considered for wrapping), and the remaining characters are drawn and wrapped at any location as needed?

CE.