On Sat, Oct 01, 2011 at 03:17:09PM -0300, Jorge Arellano Cid wrote:
On Sat, Oct 01, 2011 at 04:45:52PM +0000, corvid wrote:
Jorge wrote:
On Sat, Oct 01, 2011 at 11:03:18AM -0300, Jorge Arellano Cid wrote:
On Fri, Sep 30, 2011 at 08:54:39AM +0200, Johannes Hofmann wrote:
On Wed, Sep 28, 2011 at 05:49:10PM -0300, Jorge Arellano Cid wrote:
[...] Please explain the non-deterministical behaviour at google.
If I search for e.g. dillo on google, the first line (the link) of a result entry is sometimes broken into two lines, sometimes not.
Thanks for the explanation.
After some time reviewing it and guessing, I succeeded to isolate a small testcase which I'm reviewing now.
Sorry, it was not a reliable testcase... :-P
I haven't looked into this, but do you suppose it could have to do with the part in html.cc that goes
if (isspace(buf[buf_index])) { /* whitespace: group all available whitespace */ while (++buf_index < bufsize && isspace(buf[buf_index])) ; Html_process_space(html, buf + token_start, buf_index - token_start); token_start = buf_index; } ...
that is, sends off whatever it's accumulated at the end of a packet?
Not sure, but I don't think so.
Without the whitespace patch, dillo also doesn't seem to get right the available horizontal space for the link [1].
To me it looks related to the way ParMin propagates upwards in a textblock, but I'm just starting to look into it.
Yes, I also think it's related to that. Textblock::getExtremesImpl() starts from wrapRef and uses the precomputed line->maxWordMin, line->maxParMax, line->parMin, and line->parMax. From there it does compute the stuff on it's own. So if the computation of line->maxWordMin, line->maxParMax, line->parMin, and line->parMax in wordWrap() doesn't agree with what Textblock::getExtremesImpl() does afterwards, the result becomes unreliable. Cheers, Johannes