On Fri, May 20, 2016, Sebastian Geerken wrote:
Hi Jorge,
On Fr, Mai 20, 2016, Jorge Arellano Cid wrote:
The attached tetscase is a slight variation of the previous one.
Comparing rendering behaviour with Firefox here shows some interesting facts/bugs/design-decisions:
1.- FF links the olive div's width to viewport width only. Dillo links it to viewport and its own child width.
Dillo has a rather (over-)simple definition as what do draw with the background color. I regard this as a low-priority issue, which can be solved after the next release.
2.- When splitting the first sentence (in olive div), by narrowing the viewport, text in the teal div is also split! 3.- After 2.-, when widening the viewport, text in olive widens, but text in teal not! (reload, does the trick).
I'll write more on this later.
I've looked a bit at this, and it seems to look like another case I was working on, so it may be best to fix the latter, and hopefully the former is fixed, too. I'll describe my analysis so far, which may give you a better understanding of the code. The test case is attached. Notice that there is a float within a float, with no sizes explicitly defined. Dillo (and also FF) will use the maximal width as size, as long as it fits into the available width (which is the case here). It should look like (and looks like in FF): abcdefghijkl float mnopqrstuvwx It actually is drawn by dillo like this: float abcdefghijkl mnopqrstuvwx There are two problems: 1. Why is the word "abcdefghijkl" in the second line? 2. Why is the float positioned too far right? Let's examine problem 1. I'm using RTFL (<http://home.gna.org/rtfl/>; use the latest version from SVN, not the release, and make sure you have the graphviz library installed). To enable the RTFL messages, run the dillo configure script with "--enable-rtfl". Run: $ src/dillo n33180d.html | rtfl-objview -OM -a "*" -A draw (I'm also adding "-v 'emacsclient -n %n %p'", and you may use the script rtfl-filter-out-classes.) The relevant textblock is the lower right one (some guessing, and examine the attributes). Go to the attribute "lines/0/firstWord", select the last (which is the relevant) assignment and press Ctrl+A. This way, we can focus on what has happened before the first line is eventually created. Then examine "words/0/badnessAndPenalty" (again last entry); you'll see "... vs. -31" here, which means that when calculating the badness (used for line breaking), an ideal width of -31 was assumed, which is obviously an icorrect value. The "stack trace" function (Ctrl+T) leads to "accumulateWordData", in which "calcLineBreak" is used to calculate this value. Press Ctrl+A again to hide everything behind the last command within "calcLineBreak" ("leave"). What values go into the return value? - lineBreakWidth = 194, which looks plausible. (You can examine this further: this is calculates by "getAvailWidth", which actually returns the maximal width.) - leftInnerPadding = 0 (ok) - leftBorder = 0 (ok) - rightBorder = 225, which is obviously too large. "rightBorder" goes back to the attribute "newLineRightBorder", which is set in "calcBorders". If you look at the messages here, you'll notice that the result of "getGeneratorRest" is -194, which is too small (it should be 0 here). Further examination shows: - getGeneratorWidth (this widget) = 194: ok - getGeneratorWidth (container) = 0: too small Examining the latter shows than the width of the child (194) is not yet regarded here. I'm not yet sure how to fix this best; most probably a size recalculation should be queued under certain circumstances. Sebastian