- Dillo-dev - lists.mailman3.com

Various minor patches
by tmseck-lists＠netcologne.de Jan. 31, 2008

Jan. 31, 2008

All, I am very glad to see that dillo-fltk has now gained some momentum. While looking at it on FreeBSD (6.2) I came across some minor problems, patches for which are attached: 1) detect_libiconv.diff src/decode.c uses iconv_open but - at least on FreeBSD - libiconv is not in the default linker path, making the build abort. Add a simple test to configure.in to check for libiconv's presence and usability and a substitution for ICONV_LIBS to src/Makefile.am. 2) src-colors.h.diff I needed to include <stdint.h> or <inttypes.h> in order to have int32_t properly defined. I decided to wrap this include in a hopefully portable and correct way by instrumenting config.h. 3) src-dns.c.diff On current FreeBSD releases, netdb.h does no longer define EAI_NODATA, it had been marked as obsoleted there and #if 0'ed out since Oct 2003. It therefore cannot be checked for on a current FreeBSD release, so test whether we are either compiling on something other that FreeBSD or if it's a 4.x or older FreeBSD release. Other BSDs might have similar issues in this regard. Otherwise dillo-fltk looks really promising -- keep up the good work! Best regards, -- Thomas-Martin Seck current dillo and FLTK port maintainer on FreeBSD

4 22

[PATCH]: improved ROWSPAN handling
by onepoint＠starurchin.org Jan. 31, 2008

Jan. 31, 2008

Here's a page demonstrating some problems Dillo has when all the cells in a table have ROWSPAN > 1 . http://starurchin.org/dillo/bugs/table_rowspan.html The cause of these issues is that Dillo has (excuse me) a rather clumsy way of calculating the row heights once it has assigned column widths and calculated the cell heights. It first calculates row heights based on the cells with ROWSPAN = 1 , and then adds extra height to rows to accommodate cells with ROWSPAN > 1 . This algorithm gives poor results when no cells have ROWSPAN = 1 . It can add unnecessary vertical space (see example on the page). Worse, if there is no vertical padding in the table as well as no cells with ROWSPAN = 1 , the table has zero height after the first pass. The second pass can't cope with this (because it would be dividing by 0) so it does nothing, so the table still has no height when the layout is finished. This messes up the redisplaying of the contents and can create "dead" text that can't be selected or clicked. This patch fixes all these problems by rewriting the algorithm that calculates row heights. Nothing else in the layout code is changed. The new code scans all the cells once, top-down, and keeps track of the minimum height we must insert between the top of the table and the bottom of the cell. Once each cell is dealt with, the height assigned to its top will not change (because we work top-down) and the height assigned to its bottom can only increase, so by the end all cells have at least as much vertical height as they need. Then another pass tours the height constraints and writes the correct values into the cumHeights vector. Advantages of this patch: * Fixes the bugs noted above. * Assigns the minimal possible vertical height to the table (given the column widths that have already been assigned). * Treats all cells the same no matter what their ROWSPAN, so there are no special cases when no cells have ROWSPAN = 1 . * Doesn't do any division, so there are no special cases when the available padding is 0 . If this change is merged I'll submit a cleanup patch that removes the now-unused apportionRowSpan() method. This was a purely internal change, so I didn't need to update any docs. (Phew!) I need to look at the handling of ROWSPAN="0" attributes. Are these even legal? Regards, Jeremy Henty

2 2

[PATCH]: escape illegal characters instead of stripping them
by onepoint＠starurchin.org Jan. 31, 2008

Jan. 31, 2008

HREF attributes often contain unescaped spaces, even though this is illegal. This is unfortunate because Dillo deletes illegal URL characters, which breaks the link. See, eg. http://www.labreporter.com/Films.html This patch makes Dillo escape all illegal URL characters instead of stripping them. Regards, Jeremy Henty

2 3

Re: patch: image input as submit input
by jcid＠dillo.org Jan. 31, 2008

Jan. 31, 2008

On Wed, Jan 30, 2008 at 07:43:26PM +0000, place wrote: > In which I display my oh-so-impressive ability to, uhhh, uncomment code... :-) > It mostly just allows one to discover that there are lots > of paypal buttons out there. Half-committed. i.e. I left the outer spam_safe if, as an incentive to implement the real image input widget! ;-) -- Cheers Jorge.-

1 0

a highlighting colors proposal (with code)
by place＠gobigwest.com Jan. 31, 2008

Jan. 31, 2008

(Maybe this one deserves to be called a patch. It seems pretty clearly to be an improvement to me, at least...) If a page has, e.g., black text on a black background, it is nice to be able to highlight it to read it. So this changes the behavior from highlighted background is inverted background and highlighted text is inverted text to highlighted background is inverted background and highlighted text is normal background. And that is a good improvement in most cases, but then bg_color=#808080 inverts to 7f7f7f. So I changed SHADING_INVERSE so that it's really more of a SHADING_CONTRAST (I left the name alone because you might have chosen to apply my recent widget coloring code, which had SHADING_INVERSE in it somewhere, and it's nice to have patches compile cleanly.) The one negative point I've seen is in something like: <html><head></head><body bgcolor=#808080 text=#808080 link=blue> words words <s>strike</s> <u>underline</u> <a href=link>link</a> words. </body></html> The highlighted text will show no distinction between the underlined text and the link. It didn't seem important enough to bother with at the moment...

2 2

patch: colspan=0
by place＠gobigwest.com Jan. 30, 2008

Jan. 30, 2008

(Since Jeremy brought up the topic of spanning...) table.cc can handle colspan=0, so this just makes html.cc accept it as valid. from the spec: "The value zero ("0") means that the cell spans all columns from the current column to the last column of the column group (COLGROUP) in which the cell is defined." <table border=2> <tr> <td>A</td><td colspan=h>colspan=h</td></tr> <tr> <td>A</td><td colspan=-2>colspan=-2</td></tr> <tr> <td>A</td><td colspan=0>colspan=0</td></tr> <tr> <td>A</td><td colspan=1>colspan=1</td></tr> <tr> <td>A</td><td colspan=2>colspan=2</td></tr> <tr> <td>B</td><td>C</td><td>D</td><td>E</td><td>F</td></tr> </table>

2 1

[PATCH]: cleanup: comment out DEBUG_MSG in dw2/dw/widget.cc
by onepoint＠starurchin.org Jan. 30, 2008

Jan. 30, 2008

This patch comments out all uses of DEBUG_MSG in widget.cc . The justification is: * Consistency: all other uses of DEBUG_MSG in the DW source are already commented out. * The arguments to DEBUG_MSG use the GTK API, so they would fail to compile if they were ever used. Regards, Jeremy Henty

2 1

Q: "Yes, enough memory!", really?
by onepoint＠starurchin.org Jan. 27, 2008

Jan. 27, 2008

I'm worried about dillo2/src/url.c, line 361: p = str1 = dNew(char, strlen(url_str)); /* Yes, enough memory! */ The code after this line copies url_str to str1 , skipping illegal characters. It seems to me it should allocate one more character for the terminating null character. Does the comment "enough memory" mean that I am missing something, or is it talking about some other issue? Regards, Jeremy Henty

2 2

Work on TABLES
by jcid＠dillo.org Jan. 19, 2008

Jan. 19, 2008

On Sat, Jan 19, 2008 at 07:19:13PM +0000, place wrote: > table.cc is intimidating stuff. > > It works so far, so I don't have much to report, "It works so far" is great news for me, and certainly if it keeps stable better. Good feedback is welcomed! > but I just needed to say > that when I saw per.bak.html, I thought it was going to be something derived > from some article on http://en.wikipedia.org/wiki/Per_Bak instead of being > about, you know, percentages. Percentages is definitely less cool than frozen insulators... -- Cheers Jorge.-

1 0

Re: patch: image.cc typo one-liner
by jcid＠dillo.org Jan. 19, 2008

Jan. 19, 2008

Hi, On Sat, Jan 19, 2008 at 02:47:43AM +0000, place wrote: > It caused stripes along the sides of images with vspace and hspace. > > The line numbers of the patch are off because my image.cc is somewhat > hacked up, but who cares for a one-liner... > > diff -pur dw2/dw/image.cc dw2-cur/dw/image.cc > --- dw2/dw/image.cc 2007-12-24 06:17:14.000000000 +0000 > +++ dw2-cur/dw/image.cc 2008-01-19 02:18:15.000000000 +0000 > @@ -263,7 +263,7 @@ void Image::drawRow (int row) > > buffer->getRowArea (row, &area); > if (area.width && area.height) > - queueDrawArea (area.x + getStyle()->boxOffsetY (), > + queueDrawArea (area.x + getStyle()->boxOffsetX (), > area.y + getStyle()->boxOffsetY (), > area.width, area.height); > } Committed. Now that you're images, would you mind giving a look to these anomalies? http://www.dillo.org/test/img/ 1.- n1 renders a right column with old background (over dialup). 2.- n2 makes space inside the link, not outside, and renders different image size the first time (e.g. when from local harddisk); after back and forward size changes. 3.- n3 is obviously wrong! ;) -- Cheers Jorge.-

2 2