Version: 0.8.4 (using KDE 3.2.3, Mandrake Linux Cooker i586 - Cooker) Compiler: gcc version 3.4.1 (Mandrakelinux 10.1 3.4.1-4mdk) OS: Linux (i686) release 2.6.8.1-12mdk If some becomes annoying and copies and pastes the word lots of time so that it doesn't have any spaces, the word doesn't wrap at the edge of the screen. It would be really helpfull if it did please.
It would be extremely difficult to implement this with the current rendering system (KHTML) - perhaps impossible, since said word wrapping would have to be dynamic (as in, if it wraps, then you make your window larger, the wrapping adjusts). KHTML, as per the HTML spec, can not be made to word-break on a box boundry. Even if you set a box to a fixed width, if the text does not have any valid word-breaking characters, then it can not be broken. Instead, the HTML will render outside the box, scrolled (if "overflow" == "scroll") or, not be rendered at all if the "overflow" property is set to "none" on the box. The only way around this would be to actually use JavaScript to reflow the contents of the chat window by inserting linefeeds (!!!), both when the message is appended and when the widget is resized.
On Friday 10 December 2004 21:59, Jason Keirstead wrote: > The only way around this would be to actually use JavaScript to reflow the > contents of the chat window by inserting linefeeds (!!!), both when the > message is appended and when the widget is resized. Or we can insert those funky soft hyphenation characters (‧?) into the HTML in long words. But I'm not sure KHTML deals with them properly.
this is kinda of a wrong bug ... because kopete doesnt need word wrapping ..... the whole kde needs word wrapping !! kmail needs word wrapping , konqueror needs word wrapping , kopete needs word wrapping!
Whoa. Why isn't there one to begin with then?? Ok, so implementing it would be hard. But, word wrap is important, cause one long link means you will be scrolling to read every line of text. So, how about implementing a feature where if a single word has more than 50chars, break it every 50. eg: http://www.thisisaverylonglinkdontyouthink?.com/~t ( <----- 50 letters/numbers hisismeusingthisdomain/thisismyfolder/thisismyfile ( <----- 50 letters/numbers .php 50 can change to what you want, and the link would still link to what its supposed to. Please try to find a way. On 11 Dec 2004 12:20:51 -0000, Iori Yagami <yagami@netcabo.pt> wrote: > ------- You are receiving this mail because: ------- > You reported the bug, or are watching the reporter. > > http://bugs.kde.org/show_bug.cgi?id=94702 > > ------- Additional Comments From yagami netcabo pt 2004-12-11 13:20 ------- > this is kinda of a wrong bug ... because kopete doesnt need word wrapping ..... > > the whole kde needs word wrapping !! > > kmail needs word wrapping , konqueror needs word wrapping , kopete needs word wrapping! >
Em Sábado, 11 de Dezembro de 2004 20:12, o k776 escreveu: > So, how about > implementing a feature where if a single word has more than 50chars, > break it every 50. eg: no ... how about implementing a feature where a single word gets wrapped if its bigger than the text frame ?
ok, as long as it wraps in the end, I dont care how its done. On 11 Dec 2004 20:34:18 -0000, Iori Yagami <yagami@netcabo.pt> wrote: > ------- You are receiving this mail because: ------- > You reported the bug, or are watching the reporter. > > http://bugs.kde.org/show_bug.cgi?id=94702 > > ------- Additional Comments From yagami netcabo pt 2004-12-11 21:34 ------- > Em S
I think you guys misunderstand... wrapping words that way is against the HTML specification, this is why KHTML doesn't do it, because it would be very, very wrong. If KHTML provided some non-compliant way of turning on word-wrapping in the API, Kopete could use it. But right now it can't.
On Saturday 11 December 2004 23:59, Jason Keirstead wrote: > I think you guys misunderstand... wrapping words that way is > against the HTML specification That's actually total rubbish. HTML viewers are permitted to automatically generate hyphenation points, for instance. The HTML spec doesn't dictate layout on this level. And also, it's totally irrelevant what the HTML spec says. All that matters is what KHTML can render, since we're using it as a message rendering widget, not as a HTML viewer. As I see it, we have a few options (maybe someone else can think of more): 1) make KHTML do automatic word-wrapping. 2) implement it ourselves using soft hyphens (see http://www.w3.org/TR/REC-html40/struct/text.html#hyphenation, but note that KHTML isn't currently one of "Those browsers that interpret soft hyphens" as far as I'm aware). 3) implement it ourselves using the non-standard <wbr> tag (supported by recent IE and Firefox at least -- but not by KHTML at the moment). 4) implement it ourselves using zero-width space characters (​ -- currently misrendered by KHTML as far as I can tell). 5) implement it ourselves using <br/> or similar to put in artificial breaks every n characters -- this would suck. 6) ignore it. 7) stop using KHTML (note that using, say, a QLabel would probably result in the chat window being forced to the width of long URLs -- this too would suck).
> That's actually total rubbish. HTML viewers are permitted to automatically > generate hyphenation points, for instance. The HTML spec doesn't dictate > layout on this level. Yes it does. It is actually in the CSS spec though. See the section on the white-space property (http://www.w3.org/TR/CSS21/text.html#q8) : None of the possible white-space values allow the UA to insert hyphenation points. This behaviour can be easily verified by creating a fixed width box and putting a really long word in it. For example: <div style="background-color:red;width:25px"> ThisIsAReallyLongWordWithNoAvailableBreakPoints </div> Depending on the box's overflow property (feel free to expierment!), the text will either: a) Render outside the box b) Render to the box's edge, then not render c) Force a scrollbar in the box itself. This is the behaviour of *all* CSS 2.0 compliant browsers with *any* box. If you don't believe me try it yourself. Breaking this spec would break pages, and that is certainly not something KHTML should or would do. > As I see it, we have a few options (maybe someone else can think of more): > 1) make KHTML do automatic word-wrapping. This could be done, but *only* if it was a thing available to the KTHML API, not automatic. > 5) implement it ourselves using <br/> or similar to put in artificial > breaks every n characters -- this would suck. This wouldn't work. A <br/> is a forced break and is always broken. Lines with <br/>s in them would look very weird if you resized the window. Also, the root problem with numbers 1-4 is you don't know where to insert the hyphenation characters, since you don't know the width of the box. Only KHTML knows that. With soft hyphens it doesn't matter, but like you said, KHTML doesn't support then in any form yet.
On Sunday 12 December 2004 13:15, Jason Keirstead wrote: > > That's actually total rubbish. HTML viewers are permitted to > > automatically generate hyphenation points, for instance. The HTML spec > > doesn't dictate layout on this level. > > Yes it does. It is actually in the CSS spec though. > > See the section on the white-space property > (http://www.w3.org/TR/CSS21/text.html#q8) : > > None of the possible white-space values allow the UA to insert hyphenation > points. Nor do they forbid it, or even mention hyphenation. The section before the one you referenced (which covers where line breaks may occur) says, in "white-space: normal" mode, to "break lines as necessary to fill line boxes". Please provide a reference which actually backs up your claims. > This behaviour can be easily verified by creating a fixed width box and > putting a really long word in it. Pointless. That verifies an implementation, not the standard. > This is the behaviour of *all* CSS 2.0 compliant browsers with *any* box. Why is that relevant to what the standard allows? > > 5) implement it ourselves using <br/> or similar to put in artificial > > breaks every n characters -- this would suck. > > This wouldn't work. A <br/> is a forced break and is always broken. Lines > with <br/>s in them would look very weird if you resized the window. You don't say. Of course the line would always be broken. I only mentioned this for completeness, because it's kinda what k776 was suggesting (maybe ey actually had in mind using spaces not <br/> but the principle is the same). This is clearly not the right solution. > Also, the root problem with numbers 1-4 is you don't know where to insert > the hyphenation characters, since you don't know the width of the box. You don't understand how hyphenation works. Hyphenation points are chosen where it makes sense in the words (which is language-dependent). For a URL, placing them after /, ? and & is a reasonable choice. The width of the box is irrelevant.
On December 12, 2004 09:59 am, Richard Smith wrote: > Nor do they forbid it, or even mention hyphenation. The section before the > one you referenced (which covers where line breaks may occur) says, in > "white-space: normal" mode, to "break lines as necessary to fill line > boxes". Please provide a reference which actually backs up your claims. Yes, break lines as necessary. But lines can only be broken on valid word breaking boundries. These are white spaces and soft hyphens. Even normal hyphens will not break a word. Also, in the HTML 4 spec, they specify: "In Western scripts, for example, text should only be wrapped at white space." You can't just break a word wherever you see fit, simply because it is long, it could alter the whole meaning of the paragraph. It is common sense. > Pointless. That verifies an implementation, not the standard. You can verify it with every implimentation - even the W3C reference browser > You don't understand how hyphenation works. Hyphenation points are chosen > where it makes sense in the words (which is language-dependent). For a URL, > placing them after /, ? and & is a reasonable choice. The width of the box > is irrelevant. If KHTML could insert a soft hyphenation point at those characters in a URL, then that would be great. Unfortunately it would not fix this bug since long words that are not URLs would still cause overflows. Like when people type things like: hahahahhahahahhahahahhahahahhahahahhahahahhahahahhahahahhahahahhahahahhahahahhahahah .... or other nonsense.
a -khtml-wrap css property or something like this could be introduced
Jason, Richard, and Olivier. The main reason I want a word wrap is for the: * links * other long pointless words See, I do a lot of talking to teachers and stuff via Kopete. And most of the time they give links to resources, and if they are long, that means it will create a horizontal scroll bar. And I would like to see the whole link without having to scroll so as Richard says "If KHTML could insert a soft hyphenation point at those characters in a URL, then that would be great." As for pointless words like hahahahahahahahahahahahahahahahaha, how about a tool that checks is it repeats continously, and if it does, stop at n letter/numbers but putting (........) at the end. On 12 Dec 2004 19:12:51 -0000, Olivier Goffart <ogoffart@tiscalinet.be> wrote: > ------- You are receiving this mail because: ------- > You reported the bug, or are watching the reporter. > > http://bugs.kde.org/show_bug.cgi?id=94702 > > > ------- Additional Comments From ogoffart tiscalinet be 2004-12-12 20:12 ------- > a -khtml-wrap css property or something like this could be introduced >
This bug doesn't belong to us, and is very minor i think.