- Dillo-dev - lists.mailman3.com

New table layout rocks!

by Johannes.Hofmann＠gmx.de

On Fri, Jan 25, 2008 at 07:10:05PM +0000, Jeremy Henty wrote: > > I've been collecting web pages that Dillo misrendered: truncated > images, overlapping text, pages clipped at the right, etc. I'm really > pleased to announce that the latest Dillo handles them all. This is a > major improvement! I'm assuming this is the new table layout code at > work. Yes, Jorge did a great job. I've not yet found any regressions and on some pages it's better than dillo1 was. Johannes > > Regards, > > Jeremy Henty > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Jan. 25, 2008

New table layout rocks!

by onepoint＠starurchin.org

I've been collecting web pages that Dillo misrendered: truncated images, overlapping text, pages clipped at the right, etc. I'm really pleased to announce that the latest Dillo handles them all. This is a major improvement! I'm assuming this is the new table layout code at work. Regards, Jeremy Henty

Jan. 25, 2008

Various minor patches

by Christian.Kellermann＠nefkom.net

> 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. I am using autoconf-2.61 and automake-1.9. Kind regards, Christian -- You may use my gpg key for replies: pub 1024D/47F79788 2005/02/02 Christian Kellermann (C-Keen)

Jan. 21, 2008

Work on TABLES

by jcid＠dillo.org

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.-

Jan. 19, 2008

Re: patch: image.cc typo one-liner

by place＠gobigwest.com

I wrote: > Ah, the ancient programming principle that > The one who touched it last owns it. It dawned on me that I just touched textblock.cc. Oh no! *runs screaming*

Jan. 19, 2008

Various minor patches

by jcid＠dillo.org

On Sat, Jan 19, 2008 at 05:23:50PM +0100, Thomas-Martin Seck wrote: > * Thomas-Martin Seck (tmseck-lists(a)netcologne.de) > > > Sorry, I had hoped that the autotools could deal with this somehow and > > since I only use FreeBSD I could only get to the "works for me" state. > > What does break on Linux? The intent is to check for libiconv.h in the > > default include path and for iconv_open in libiconv, assuming that > > libiconv can be located without adding -L/path/to/libiconv to LDFLAGS > > explicitly. > > OK, I learned that glibc(?) nowadays includes iconv functionality. I > updated the patch so that it checks for iconv_open in libc first and, > failing this, in libiconv next. It still works on FreeBSD 6.2, could you > please test whether this is the correct approach for Linux et al? It works here, committed! Comments welcome. -- Cheers Jorge.-

Jan. 19, 2008

Re: patch: image.cc typo one-liner

by place＠gobigwest.com

Jorge wrote: > Now that you're images, would you mind giving a look to these anomalies? Ah, the ancient programming principle that The one who touched it last owns it. I have met with this before :) And a sobering thought, now, glancing at the changelog... > > http://www.dillo.org/test/img/ > > 1.- n1 renders a right column with old background (over dialup). I couldn't tell what this one was supposed to be doing wrong. > 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! ;) I don't really know what is going on with allocation and requisition and all of this drawing business, but I did find that after - requisition->width += getStyle()->boxDiffHeight (); + requisition->width += getStyle()->boxDiffWidth (); in my Image::sizeRequestImpl -- which didn't seem to change anything, but sure _sounds_ sensible, and diff -pur dw2/dw/textblock.cc dw2-cur/dw/textblock.cc --- dw2/dw/textblock.cc 2007-12-20 20:02:20.000000000 +0000 +++ dw2-cur/dw/textblock.cc 2008-01-19 18:31:26.000000000 +0000 @@ -339,12 +339,12 @@ void Textblock::sizeAllocateImpl (core:: childAllocation.y = lineYOffsetCanvasAllocation (line, allocation) + (line->ascent - word->size.ascent) - - word->content.widget->getStyle()->margin.top; +; // - word->content.widget->getStyle()->margin.top; childAllocation.width = word->size.width; childAllocation.ascent = word->size.ascent - + word->content.widget->getStyle()->margin.top; +; // + word->content.widget->getStyle()->margin.top; childAllocation.descent = word->size.descent - + word->content.widget->getStyle()->margin.bottom; +; // + word->content.widget->getStyle()->margin.bottom; word->content.widget->sizeAllocate (&childAllocation); break; the problem went away for those cases, at least. But as for whether it's supposed to be like this or the margins should be included and something else is supposed to be subtracting them somewhere, I have no idea. I was led in this direction by finding that allocation.y was -95 somewhere in image.cc with n3, which just sounded wrong.

Jan. 19, 2008

Work on TABLES

by Johannes.Hofmann＠gmx.de

Hi Jorge, works great so far! Your patch makes www.wetter-online.de work again. It did work in dillo1, but didn't in dillo2 until now. It still renders a bit different than in firefox, but it is already better than in dillo1. I will continue testing. Enjoy your free time, Johannes On Sat, Jan 19, 2008 at 11:13:22AM -0300, Jorge Arellano Cid wrote: > Hi there, > > Good news! > > It looks like awakening the dragon wasn't a bad idea after all! > > It took a lot of time and debugging, but now after lots of tests, > it seems much better than what we had before. > > This is not a simple patch, but an algorithms change + bug fixes. > Beware that the html documentation is not up-to-date yet though; > I prefer to let you test the new code with lots of other cases and > to send feedback or bugfixes to the list before adopting the new code. > > I uploaded a subset of the used test cases to: > > http://www.dillo.org/test/tables > > You can start with per1.html, per2.html per3.html & per4.html. > > Please note that the test is not just rendering the page, but resizing > its tables from MIN to MAX. It's interesting to compare what we had before, > dillo1 and Firefox (Ill cases follow Firefox's example). > > So the bottom line is: Test, test, test!!! & send feedback. > > I'll be back near Jan 30; after enjoying my deserved rest period. ;-) > > -- > Cheers > Jorge.- > > PS: If you want to debug, uncomment table.cc:21 > and define dillo_dbg_rendering to 1 in html.cc:64. > PS2: I left an exit assert testing d_a and d_w >= 0. If this triggers, > please send the URL. > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Jan. 19, 2008

Various minor patches

by tmseck-lists＠netcologne.de

* Thomas-Martin Seck (tmseck-lists(a)netcologne.de) > Sorry, I had hoped that the autotools could deal with this somehow and > since I only use FreeBSD I could only get to the "works for me" state. > What does break on Linux? The intent is to check for libiconv.h in the > default include path and for iconv_open in libiconv, assuming that > libiconv can be located without adding -L/path/to/libiconv to LDFLAGS > explicitly. OK, I learned that glibc(?) nowadays includes iconv functionality. I updated the patch so that it checks for iconv_open in libc first and, failing this, in libiconv next. It still works on FreeBSD 6.2, could you please test whether this is the correct approach for Linux et al?

Jan. 19, 2008

Re: patch: image.cc typo one-liner

by jcid＠dillo.org

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.-

Jan. 19, 2008