- Dillo-dev - lists.mailman3.com

Various minor patches

by jcid＠dillo.org

On Wed, Jan 30, 2008 at 04:37:09PM +0100, Johannes Hofmann wrote: > On Wed, Jan 30, 2008 at 03:21:41PM +0100, Christian Kellermann wrote: > > * Jorge Arellano Cid <jcid(a)dillo.org> [080130 15:06]: > > > On Wed, Jan 30, 2008 at 10:51:19AM -0300, Jorge Arellano Cid wrote: > > > > On Sun, Jan 27, 2008 at 05:10:19PM +0100, Christian Kellermann wrote: > > > > > * Johannes Hofmann <Johannes.Hofmann(a)gmx.de> [080125 20:21]: > > > > > > On Mon, Jan 21, 2008 at 04:03:47PM +0100, Christian Kellermann wrote: > > > > > > > > On Sun, Jan 13, 2008 at 05:07:04PM +0100, Thomas-Martin Seck wrote: > > > > > > > > > 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. > > > > > > > > > > > > > > > > Very nice! The same problem exists on DragonFly... > > > > > > > > > > > > > > This breaks configure for me (OpenBSD/386 -stable). seems the test does not use the LDFLAGS=-L/usr/local/lib... My knowledge (and motivation) to fiddle with this autoconf hell is limited, so I'd kindly hand the ball over to someone else. > > > > > > > > > > > > What exactly is breaking? Can you provide config.log? > > > > > > > > > > > > Here on DragonFly linking was failing with unresolved symbols, > > > > > > but it turned out that the problem was caused by a libiconv > > > > > > package that was no longer needed. The iconv stuff is now handled > > > > > > in libc on DragonFly... > > > > > > > > > > I have attached the log. Seems like the function signature differs > > > > > on OpenBSD a bit. The testcase modified as such that it includes > > > > > <iconv.h> and calling iconv_open("",""); works for me when doint > > > > > it manually. > > > > > > > > > > I don't know what happens here... > > > > > > > > > > Kind regards, > > > > > > > > Does it fail with current CVS? > > > > > > Sorry, from the log it's clear it doesn't. > > > > > > This page seems to have good info: > > > > > > http://synflood.at/blog/index.php?/plugin/tag/bsd > > > > > > (my understanding of German is barely for survival. ;). > > > > > > > Yes it does describe my problem, but how do we fix this in a portable way? > > Not sure, it describes the same problem. > > I think the problem is that libiconv only exports > libiconv_open() and the corresponding iconv.h header file defines > iconv_open to libiconv_open. > Unfortunately the test program generated by autoconf does not > include iconv.h. OK, I modified configure.in in CVS. This approach may work. Beware I don't have how to test this patch, so you will probably have to try and tweak. -- Cheers Jorge.-

Jan. 30, 2008

[PATCH]: improved ROWSPAN handling

by place＠gobigwest.com

Jeremy wrote: > I need to look at the handling of ROWSPAN="0" attributes. Are these > even legal? I didn't change html.cc to allow it, but it's legal: "rowspan = number [p.50] [CN] [p.49] This attribute specifies the number of rows spanned by the current cell. The default value of this attribute is one ("1"). The value zero ("0") means that the cell spans all rows from the current row to the last row of the table section (THEAD, TBODY, or TFOOT) in which the cell is defined."

Jan. 30, 2008

[PATCH]: improved ROWSPAN handling

by onepoint＠starurchin.org

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

Jan. 30, 2008

Various minor patches

by Johannes.Hofmann＠gmx.de

On Wed, Jan 30, 2008 at 03:21:41PM +0100, Christian Kellermann wrote: > * Jorge Arellano Cid <jcid(a)dillo.org> [080130 15:06]: > > On Wed, Jan 30, 2008 at 10:51:19AM -0300, Jorge Arellano Cid wrote: > > > On Sun, Jan 27, 2008 at 05:10:19PM +0100, Christian Kellermann wrote: > > > > * Johannes Hofmann <Johannes.Hofmann(a)gmx.de> [080125 20:21]: > > > > > On Mon, Jan 21, 2008 at 04:03:47PM +0100, Christian Kellermann wrote: > > > > > > > On Sun, Jan 13, 2008 at 05:07:04PM +0100, Thomas-Martin Seck wrote: > > > > > > > > 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. > > > > > > > > > > > > > > Very nice! The same problem exists on DragonFly... > > > > > > > > > > > > This breaks configure for me (OpenBSD/386 -stable). seems the test does not use the LDFLAGS=-L/usr/local/lib... My knowledge (and motivation) to fiddle with this autoconf hell is limited, so I'd kindly hand the ball over to someone else. > > > > > > > > > > What exactly is breaking? Can you provide config.log? > > > > > > > > > > Here on DragonFly linking was failing with unresolved symbols, > > > > > but it turned out that the problem was caused by a libiconv > > > > > package that was no longer needed. The iconv stuff is now handled > > > > > in libc on DragonFly... > > > > > > > > I have attached the log. Seems like the function signature differs > > > > on OpenBSD a bit. The testcase modified as such that it includes > > > > <iconv.h> and calling iconv_open("",""); works for me when doint > > > > it manually. > > > > > > > > I don't know what happens here... > > > > > > > > Kind regards, > > > > > > Does it fail with current CVS? > > > > Sorry, from the log it's clear it doesn't. > > > > This page seems to have good info: > > > > http://synflood.at/blog/index.php?/plugin/tag/bsd > > > > (my understanding of German is barely for survival. ;). > > > > Yes it does describe my problem, but how do we fix this in a portable way? Not sure, it describes the same problem. I think the problem is that libiconv only exports libiconv_open() and the corresponding iconv.h header file defines iconv_open to libiconv_open. Unfortunately the test program generated by autoconf does not include iconv.h. Johannes > > -- > You may use my gpg key for replies: > pub 1024D/47F79788 2005/02/02 Christian Kellermann (C-Keen) > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Jan. 30, 2008

New table layout rocks!

by onepoint＠starurchin.org

On Wed, Jan 30, 2008 at 10:29:48AM -0300, Jorge Arellano Cid wrote: > On Tue, Jan 29, 2008 at 03:50:58PM +0000, Jeremy Henty wrote: > > I am currently investigating bugs in the handling of ROWSPAN. > > Also, my impression is that performance has badly degraded for > > tables with many rows. > > Degraded since previous dillo2 or dillo1 version? Since dillo2 a few months ago. I have a script that scrapes a lot of RSS feeds and builds a two-column HTML table with small cells but a *lot* of rows. Looking at that page with Dillo, if I drag the window around it thrashes the CPU. Also, dragging a selection is *extremely* slow: it takes 0.5-1 second to highlight/unhighlight *each* cell. I'm pretty sure (though I have not yet made sure) that this poor rendering performance appeared quite recently. > Please send the test cases and their detected problems. I'll submit tests and fixes for the ROWSPAN bug in a new thread, then look at rendering performance. Regards, Jeremy Henty

Jan. 30, 2008

Various minor patches

by Christian.Kellermann＠nefkom.net

* Jorge Arellano Cid <jcid(a)dillo.org> [080130 15:36]: > On Wed, Jan 30, 2008 at 03:21:41PM +0100, Christian Kellermann wrote: > > * Jorge Arellano Cid <jcid(a)dillo.org> [080130 15:06]: > > > On Wed, Jan 30, 2008 at 10:51:19AM -0300, Jorge Arellano Cid wrote: > > > > On Sun, Jan 27, 2008 at 05:10:19PM +0100, Christian Kellermann wrote: > > > > > * Johannes Hofmann <Johannes.Hofmann(a)gmx.de> [080125 20:21]: > > > > > > On Mon, Jan 21, 2008 at 04:03:47PM +0100, Christian Kellermann wrote: > > > > > > > > On Sun, Jan 13, 2008 at 05:07:04PM +0100, Thomas-Martin Seck wrote: > > > > > > > > > 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. > > > > > > > > > > > > > > > > Very nice! The same problem exists on DragonFly... > > > > > > > > > > > > > > This breaks configure for me (OpenBSD/386 -stable). seems the test does not use the LDFLAGS=-L/usr/local/lib... My knowledge (and motivation) to fiddle with this autoconf hell is limited, so I'd kindly hand the ball over to someone else. > > > > > > > > > > > > What exactly is breaking? Can you provide config.log? > > > > > > > > > > > > Here on DragonFly linking was failing with unresolved symbols, > > > > > > but it turned out that the problem was caused by a libiconv > > > > > > package that was no longer needed. The iconv stuff is now handled > > > > > > in libc on DragonFly... > > > > > > > > > > I have attached the log. Seems like the function signature differs > > > > > on OpenBSD a bit. The testcase modified as such that it includes > > > > > <iconv.h> and calling iconv_open("",""); works for me when doint > > > > > it manually. > > > > > > > > > > I don't know what happens here... > > > > > > > > > > Kind regards, > > > > > > > > Does it fail with current CVS? > > > > > > Sorry, from the log it's clear it doesn't. > > > > > > This page seems to have good info: > > > > > > http://synflood.at/blog/index.php?/plugin/tag/bsd > > > > > > (my understanding of German is barely for survival. ;). > > > > > > > Yes it does describe my problem, but how do we fix this in a portable way? > > > Before this patch, we had no test for iconv. Did it work for you then? > In a way yes. because my solution was to add -liconv to my LDFLAGS. Thanks for looking at this -- You may use my gpg key for replies: pub 1024D/47F79788 2005/02/02 Christian Kellermann (C-Keen)

Jan. 30, 2008

Various minor patches

by jcid＠dillo.org

On Wed, Jan 30, 2008 at 03:21:41PM +0100, Christian Kellermann wrote: > * Jorge Arellano Cid <jcid(a)dillo.org> [080130 15:06]: > > On Wed, Jan 30, 2008 at 10:51:19AM -0300, Jorge Arellano Cid wrote: > > > On Sun, Jan 27, 2008 at 05:10:19PM +0100, Christian Kellermann wrote: > > > > * Johannes Hofmann <Johannes.Hofmann(a)gmx.de> [080125 20:21]: > > > > > On Mon, Jan 21, 2008 at 04:03:47PM +0100, Christian Kellermann wrote: > > > > > > > On Sun, Jan 13, 2008 at 05:07:04PM +0100, Thomas-Martin Seck wrote: > > > > > > > > 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. > > > > > > > > > > > > > > Very nice! The same problem exists on DragonFly... > > > > > > > > > > > > This breaks configure for me (OpenBSD/386 -stable). seems the test does not use the LDFLAGS=-L/usr/local/lib... My knowledge (and motivation) to fiddle with this autoconf hell is limited, so I'd kindly hand the ball over to someone else. > > > > > > > > > > What exactly is breaking? Can you provide config.log? > > > > > > > > > > Here on DragonFly linking was failing with unresolved symbols, > > > > > but it turned out that the problem was caused by a libiconv > > > > > package that was no longer needed. The iconv stuff is now handled > > > > > in libc on DragonFly... > > > > > > > > I have attached the log. Seems like the function signature differs > > > > on OpenBSD a bit. The testcase modified as such that it includes > > > > <iconv.h> and calling iconv_open("",""); works for me when doint > > > > it manually. > > > > > > > > I don't know what happens here... > > > > > > > > Kind regards, > > > > > > Does it fail with current CVS? > > > > Sorry, from the log it's clear it doesn't. > > > > This page seems to have good info: > > > > http://synflood.at/blog/index.php?/plugin/tag/bsd > > > > (my understanding of German is barely for survival. ;). > > > > Yes it does describe my problem, but how do we fix this in a portable way? Before this patch, we had no test for iconv. Did it work for you then? -- Cheers Jorge.-

Jan. 30, 2008

Various minor patches

by Christian.Kellermann＠nefkom.net

* Jorge Arellano Cid <jcid(a)dillo.org> [080130 15:06]: > On Wed, Jan 30, 2008 at 10:51:19AM -0300, Jorge Arellano Cid wrote: > > On Sun, Jan 27, 2008 at 05:10:19PM +0100, Christian Kellermann wrote: > > > * Johannes Hofmann <Johannes.Hofmann(a)gmx.de> [080125 20:21]: > > > > On Mon, Jan 21, 2008 at 04:03:47PM +0100, Christian Kellermann wrote: > > > > > > On Sun, Jan 13, 2008 at 05:07:04PM +0100, Thomas-Martin Seck wrote: > > > > > > > 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. > > > > > > > > > > > > Very nice! The same problem exists on DragonFly... > > > > > > > > > > This breaks configure for me (OpenBSD/386 -stable). seems the test does not use the LDFLAGS=-L/usr/local/lib... My knowledge (and motivation) to fiddle with this autoconf hell is limited, so I'd kindly hand the ball over to someone else. > > > > > > > > What exactly is breaking? Can you provide config.log? > > > > > > > > Here on DragonFly linking was failing with unresolved symbols, > > > > but it turned out that the problem was caused by a libiconv > > > > package that was no longer needed. The iconv stuff is now handled > > > > in libc on DragonFly... > > > > > > I have attached the log. Seems like the function signature differs > > > on OpenBSD a bit. The testcase modified as such that it includes > > > <iconv.h> and calling iconv_open("",""); works for me when doint > > > it manually. > > > > > > I don't know what happens here... > > > > > > Kind regards, > > > > Does it fail with current CVS? > > Sorry, from the log it's clear it doesn't. > > This page seems to have good info: > > http://synflood.at/blog/index.php?/plugin/tag/bsd > > (my understanding of German is barely for survival. ;). > Yes it does describe my problem, but how do we fix this in a portable way? -- You may use my gpg key for replies: pub 1024D/47F79788 2005/02/02 Christian Kellermann (C-Keen)

Jan. 30, 2008

Various minor patches

by Christian.Kellermann＠nefkom.net

* Jorge Arellano Cid <jcid(a)dillo.org> [080130 14:51]: > On Sun, Jan 27, 2008 at 05:10:19PM +0100, Christian Kellermann wrote: > > * Johannes Hofmann <Johannes.Hofmann(a)gmx.de> [080125 20:21]: > > > On Mon, Jan 21, 2008 at 04:03:47PM +0100, Christian Kellermann wrote: > > > > > On Sun, Jan 13, 2008 at 05:07:04PM +0100, Thomas-Martin Seck wrote: > > > > > > 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. > > > > > > > > > > Very nice! The same problem exists on DragonFly... > > > > > > > > This breaks configure for me (OpenBSD/386 -stable). seems the test does not use the LDFLAGS=-L/usr/local/lib... My knowledge (and motivation) to fiddle with this autoconf hell is limited, so I'd kindly hand the ball over to someone else. > > > > > > What exactly is breaking? Can you provide config.log? > > > > > > Here on DragonFly linking was failing with unresolved symbols, > > > but it turned out that the problem was caused by a libiconv > > > package that was no longer needed. The iconv stuff is now handled > > > in libc on DragonFly... > > > > I have attached the log. Seems like the function signature differs > > on OpenBSD a bit. The testcase modified as such that it includes > > <iconv.h> and calling iconv_open("",""); works for me when doint > > it manually. > > > > I don't know what happens here... > > > > Kind regards, > > Does it fail with current CVS? I just tried the recent cvs it is still failing... -- You may use my gpg key for replies: pub 1024D/47F79788 2005/02/02 Christian Kellermann (C-Keen)

Jan. 30, 2008

Various minor patches

by jcid＠dillo.org

On Wed, Jan 30, 2008 at 10:51:19AM -0300, Jorge Arellano Cid wrote: > On Sun, Jan 27, 2008 at 05:10:19PM +0100, Christian Kellermann wrote: > > * Johannes Hofmann <Johannes.Hofmann(a)gmx.de> [080125 20:21]: > > > On Mon, Jan 21, 2008 at 04:03:47PM +0100, Christian Kellermann wrote: > > > > > On Sun, Jan 13, 2008 at 05:07:04PM +0100, Thomas-Martin Seck wrote: > > > > > > 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. > > > > > > > > > > Very nice! The same problem exists on DragonFly... > > > > > > > > This breaks configure for me (OpenBSD/386 -stable). seems the test does not use the LDFLAGS=-L/usr/local/lib... My knowledge (and motivation) to fiddle with this autoconf hell is limited, so I'd kindly hand the ball over to someone else. > > > > > > What exactly is breaking? Can you provide config.log? > > > > > > Here on DragonFly linking was failing with unresolved symbols, > > > but it turned out that the problem was caused by a libiconv > > > package that was no longer needed. The iconv stuff is now handled > > > in libc on DragonFly... > > > > I have attached the log. Seems like the function signature differs > > on OpenBSD a bit. The testcase modified as such that it includes > > <iconv.h> and calling iconv_open("",""); works for me when doint > > it manually. > > > > I don't know what happens here... > > > > Kind regards, > > Does it fail with current CVS? Sorry, from the log it's clear it doesn't. This page seems to have good info: http://synflood.at/blog/index.php?/plugin/tag/bsd (my understanding of German is barely for survival. ;). -- Cheers Jorge.-

Jan. 30, 2008