- Dillo-dev - lists.mailman3.com

a couple of patches: referer and image_off

by place＠gobigwest.com

Jorge wrote: > >From the updated dillorc2: > > # Set the HTTP Referer information (WARNING: affects privacy) > * # We use the same URI, not the refering page (to avoid cross-site tracking). > # none : No referer at all (full privacy). > # host : Default value. Send same URI's hostname (no sensible info is sent). > # path : same URI is sent (NO PRIVACY). > http_referer=host What do you mean by "NO PRIVACY"?

Feb. 1, 2008

Various minor patches

by jcid＠dillo.org

On Thu, Jan 31, 2008 at 03:35:56PM +0100, Christian Kellermann wrote: > * Jorge Arellano Cid <jcid(a)dillo.org> [080131 13:25]: > > > > 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. > > > > Did the new test in configure.in work? > Nope it did not. > > > You wrote: > > > In a way yes. because my solution was to add -liconv to my LDFLAGS. > > and > > > 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 assume you set LDFLAGS=-L/usr/local/lib... > > > > but this is expected to be done by the test at configure.in:96. > > The test can fail though! Would you mind posting the output of: > > > > cpp -v > > > > in your system. > > $ cpp -v > Reading specs from /usr/libexec/../lib/gcc-lib/i386-unknown-openbsd4.2/3.3.5/specs > Configured with: > Thread model: single > gcc version 3.3.5 (propolice) > /usr/libexec/../lib/gcc-lib/i386-unknown-openbsd4.2/3.3.5/cc1 -E -traditional-cpp -quiet -nostdinc -v -I/usr/include -iprefix /usr/libexec/../lib/gcc-lib/i386-unknown-openbsd4.2/3.3.5/ -D__GNUC__ - > #include "..." search starts here: > #include <...> search starts here: > /usr/include > End of search list. > > Hope this helps, OK, then configure.in:96 should be adding /usr/local/lib to LDFLAGS. If I understood correctly, the missing part is "-liconv" in LIBS. The CVS has new code for this. Please test, tweak and report back. Making a blind patch with auto*tools is not easy. -- Cheers Jorge.-

Jan. 31, 2008

a couple of patches: referer and image_off

by jcid＠dillo.org

Hi there, - Added a text placeholder: "[IMG]" for img_off mode. - Added a http_referer preference. See details in dillorc2. This couple plays well together. When in img_off mode, non loaded images will show "[IMG]" (or original alt text), and the partial referer helps with getting images from sites that don't allow external sources. >From the updated dillorc2: # Set the HTTP Referer information (WARNING: affects privacy) * # We use the same URI, not the refering page (to avoid cross-site tracking). # none : No referer at all (full privacy). # host : Default value. Send same URI's hostname (no sensible info is sent). # path : same URI is sent (NO PRIVACY). http_referer=host Note: please read the "*"-marked line twice. ;) -- Cheers Jorge.-

Jan. 31, 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 Actually, on second thoughts I'm not so happy with this patch. It resolves all the slack in the row boundaries by pushing them up as far as possible. Let me see if I can get it to spread things out better. Jeremy Henty

Jan. 31, 2008

Various minor patches

by Christian.Kellermann＠nefkom.net

* Jorge Arellano Cid <jcid(a)dillo.org> [080131 13:25]: > > > 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. > > Did the new test in configure.in work? Nope it did not. > You wrote: > > In a way yes. because my solution was to add -liconv to my LDFLAGS. > and > > 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 assume you set LDFLAGS=-L/usr/local/lib... > > but this is expected to be done by the test at configure.in:96. > The test can fail though! Would you mind posting the output of: > > cpp -v > > in your system. $ cpp -v Reading specs from /usr/libexec/../lib/gcc-lib/i386-unknown-openbsd4.2/3.3.5/specs Configured with: Thread model: single gcc version 3.3.5 (propolice) /usr/libexec/../lib/gcc-lib/i386-unknown-openbsd4.2/3.3.5/cc1 -E -traditional-cpp -quiet -nostdinc -v -I/usr/include -iprefix /usr/libexec/../lib/gcc-lib/i386-unknown-openbsd4.2/3.3.5/ -D__GNUC__ - #include "..." search starts here: #include <...> search starts here: /usr/include End of search list. Hope this helps, Christian -- You may use my gpg key for replies: pub 1024D/47F79788 2005/02/02 Christian Kellermann (C-Keen)

Jan. 31, 2008

[PATCH]: escape illegal characters instead of stripping them

by onepoint＠starurchin.org

On Thu, Jan 31, 2008 at 10:30:37AM -0300, Jorge Arellano Cid wrote: > On Sun, Jan 27, 2008 at 07:15:28PM +0000, Jeremy Henty wrote: > > > > This patch makes Dillo escape all illegal URL characters instead > > of stripping them. > > Committed an improved version. Yes, that *is* neater. I'll remember that! Jeremy Henty

Jan. 31, 2008

Re: patch: image input as submit input

by jcid＠dillo.org

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

Jan. 31, 2008

[PATCH]: escape illegal characters instead of stripping them

by jcid＠dillo.org

On Sun, Jan 27, 2008 at 07:15:28PM +0000, Jeremy Henty wrote: > > 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. Committed an improved version. -- Cheers Jorge.-

Jan. 31, 2008

Various minor patches

by jcid＠dillo.org

On Wed, Jan 30, 2008 at 03:40:52PM +0100, Christian Kellermann wrote: > * 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. Did the new test in configure.in work? I assume not because of the silence. You wrote: > In a way yes. because my solution was to add -liconv to my LDFLAGS. and > 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 assume you set LDFLAGS=-L/usr/local/lib... but this is expected to be done by the test at configure.in:96. The test can fail though! Would you mind posting the output of: cpp -v in your system. -- Cheers Jorge.-

Jan. 31, 2008

an experiment in widget coloring (with code)

by place＠gobigwest.com

Jorge wrote: > I like the idea, even the look of coloured widgets, but some people may > prefer the old look. > > Would you implement this as a dillorc2 preference? e.g. > > # When set to yes, form elements follow the color style of the page. > widget_colors=YES All right.

Jan. 31, 2008

a highlighting colors proposal (with code)

by place＠gobigwest.com

Jorge wrote: > On Tue, Jan 29, 2008 at 04:31:15AM +0000, place wrote: > > (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. > > The idea for this problem (and others) is to have a small button, > like the img-on/off, with a toolbox icon. When clicked the page is > rendered using the force_my_colors style. > > The idea is to eventually be able to specify a CSS stylesheet > that defines what "my_colors" is. And the button applies it on the > rendered page. > > After developing the table apportion patch, it became somehow clear > to me that the next big step to undertake is to start parsing some CSS. > If we add a very simple parser and hook a few elements, then it can > grow incrementally. > > This is not as hard as it looks because we presented a working prototype > of this at FOSDEM 2005 with Sebastian. The parser should be no problem (as > I know the html parser well), but for the CSS-dw2 hooks we'd need to ask > Sebastian (and hope for some free time on his part) or to dig > in the old prototype code and try to figure it out. > > I'd much prefer Sebastian to advice us because he has the CSS model > and dw2 design in his head, and can save us from a boat load of trouble. > > > Note: with regard to this patch. Would you mind implement the > toolbox-button/force-my-colors approach? > > Note2: if this kind of highlight is regarded as better than the > former, I have no problems to commit. These are independent ideas. I started trying to formulate questions because it made sense to do things that fit with how it would eventually work with CSS -- and I don't really know too clearly how things are supposed to work with CSS -- but... well, if your Devious Maintainer Plan was to get me to say "Oh, let's not worry about forcing colors for now, and try to get some css going," then you have succeeded.

Jan. 31, 2008

New table layout rocks!

by jcid＠dillo.org

On Wed, Jan 30, 2008 at 09:24:57PM +0100, Johannes Hofmann wrote: > 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: > > > On Tue, Jan 29, 2008 at 02:39:17PM +0100, Diego . wrote: > > > > > > > After this effort maybe the "Rewrite of tables code" item on Plans > > > > page ( http://www.dillo.org/Plans.html) can change from > > > > yellow(prototype at least) to green (recently finished) > > > > > > Sadly this may a little too hasty. 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? > > > > AFAIS, the main bottleneck in dillo2 still is too many redraw requests. > > Yes, that's probabely true. > > However, I currently don't see any low hanging fruit in this area. > dillo1 also redraws all the time. It is just not visible because it > draws to some offscreen area first and then copies the result to the > screen. And what's more important, drawing was cheaper without > antialiased fonts... My feeling is exactly. One cheap way to avoid redraws is to throttle them at let say 3 seconds, and to force one when the parsing is done with the full page (close time). Another, cleaner approach, may be to avoid unnecessary redraw requests from the textblock and table widgets (or other source). I haven't investigated this in detail, but for instance, Textblock::wordWrap always sets "mustQueueResize = true". If the Textblock knows that the just added contents are out of the displayed area, and that it didn't grow wider/thiner, we may avoid the request until it is displayed, or page ends, whatever comes first. Disclaimer: these are just ideas, no proof of concept yet. -- Cheers Jorge.-

Jan. 30, 2008

an experiment in widget coloring (with code)

by jcid＠dillo.org

On Fri, Jan 25, 2008 at 10:06:58PM +0000, place wrote: > With my color settings, my buttons were light grey with unreadable > white labels. Well, that's no good. > > And standard gui widget colors scream > "I'm using a Windows Office Productivity Suite!" to me. :-) > So here is something to play with. I currently have the widgets using > background color and the labels/text either black or white. I like the idea, even the look of coloured widgets, but some people may prefer the old look. Would you implement this as a dillorc2 preference? e.g. # When set to yes, form elements follow the color style of the page. widget_colors=YES > fltk_black to make black work right Will be committed after writing this email. > widget_colors.dillo to set backgroundColor in Style. > widget_colors.dw where you set the widget colors. Will expect your answer. -- Cheers Jorge.-

Jan. 30, 2008

a highlighting colors proposal (with code)

by jcid＠dillo.org

Hi, On Tue, Jan 29, 2008 at 04:31:15AM +0000, place wrote: > (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. The idea for this problem (and others) is to have a small button, like the img-on/off, with a toolbox icon. When clicked the page is rendered using the force_my_colors style. The idea is to eventually be able to specify a CSS stylesheet that defines what "my_colors" is. And the button applies it on the rendered page. After developing the table apportion patch, it became somehow clear to me that the next big step to undertake is to start parsing some CSS. If we add a very simple parser and hook a few elements, then it can grow incrementally. This is not as hard as it looks because we presented a working prototype of this at FOSDEM 2005 with Sebastian. The parser should be no problem (as I know the html parser well), but for the CSS-dw2 hooks we'd need to ask Sebastian (and hope for some free time on his part) or to dig in the old prototype code and try to figure it out. I'd much prefer Sebastian to advice us because he has the CSS model and dw2 design in his head, and can save us from a boat load of trouble. Note: with regard to this patch. Would you mind implement the toolbox-button/force-my-colors approach? Note2: if this kind of highlight is regarded as better than the former, I have no problems to commit. These are independent ideas. -- Cheers Jorge.-

Jan. 30, 2008

New table layout rocks!

by Johannes.Hofmann＠gmx.de

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: > > On Tue, Jan 29, 2008 at 02:39:17PM +0100, Diego . wrote: > > > > > After this effort maybe the "Rewrite of tables code" item on Plans > > > page ( http://www.dillo.org/Plans.html) can change from > > > yellow(prototype at least) to green (recently finished) > > > > Sadly this may a little too hasty. 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? > > AFAIS, the main bottleneck in dillo2 still is too many redraw requests. Yes, that's probabely true. However, I currently don't see any low hanging fruit in this area. dillo1 also redraws all the time. It is just not visible because it draws to some offscreen area first and then copies the result to the screen. And what's more important, drawing was cheaper without antialiased fonts... Johannes > > With regard to table rendering the code is mainly O(n), > so "badly degraded" would be a bug. > > Now, the code isn't yet optimized so there's plenty of space for > improving (in the O(n) realm). > > Please send the test cases and their detected problems. > > -- > Cheers > Jorge.- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Jan. 30, 2008

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

Various minor patches

by jcid＠dillo.org

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? -- Cheers Jorge.-

Jan. 30, 2008

patch: colspan=0

by jcid＠dillo.org

On Wed, Jan 30, 2008 at 02:34:28AM +0000, place wrote: > (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." Committed. -- Cheers Jorge.-

Jan. 30, 2008

[PATCH]: cleanup: comment out DEBUG_MSG in dw2/dw/widget.cc

by jcid＠dillo.org

On Tue, Jan 29, 2008 at 12:43:05PM +0000, Jeremy Henty wrote: > > 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. Committed. -- Cheers Jorge.-

Jan. 30, 2008

New table layout rocks!

by jcid＠dillo.org

On Tue, Jan 29, 2008 at 03:50:58PM +0000, Jeremy Henty wrote: > On Tue, Jan 29, 2008 at 02:39:17PM +0100, Diego . wrote: > > > After this effort maybe the "Rewrite of tables code" item on Plans > > page ( http://www.dillo.org/Plans.html) can change from > > yellow(prototype at least) to green (recently finished) > > Sadly this may a little too hasty. 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? AFAIS, the main bottleneck in dillo2 still is too many redraw requests. With regard to table rendering the code is mainly O(n), so "badly degraded" would be a bug. Now, the code isn't yet optimized so there's plenty of space for improving (in the O(n) realm). Please send the test cases and their detected problems. -- Cheers Jorge.-

Jan. 30, 2008

New table layout rocks!

by jcid＠dillo.org

On Fri, Jan 25, 2008 at 08:09:14PM +0100, Johannes Hofmann wrote: > 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. Good to know! :) -- Cheers Jorge.-

Jan. 30, 2008

New table layout rocks!

by jcid＠dillo.org

Hi, 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! I'm happy to hear it has endured testing. Good. -- Cheers Jorge.-

Jan. 30, 2008

patch: colspan=0

by place＠gobigwest.com

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

Jan. 30, 2008

New table layout rocks!

by onepoint＠starurchin.org

On Tue, Jan 29, 2008 at 02:39:17PM +0100, Diego . wrote: > After this effort maybe the "Rewrite of tables code" item on Plans > page ( http://www.dillo.org/Plans.html) can change from > yellow(prototype at least) to green (recently finished) Sadly this may a little too hasty. I am currently investigating bugs in the handling of ROWSPAN. Also, my impression is that performance has badly degraded for tables with many rows. Jeremy Henty

Jan. 29, 2008

New table layout rocks!

by darkspirit5000＠gmail.com

After this effort maybe the "Rewrite of tables code" item on Plans page ( http://www.dillo.org/Plans.html) can change from yellow(prototype at least) to green (recently finished) :) Diego. PD: I can not get scrollbar in that page. 2008/1/26, Jeremy Henty <onepoint(a)starurchin.org>: > > On Fri, Jan 25, 2008 at 08:09:14PM +0100, Johannes Hofmann wrote: > > > > Yes, Jorge did a great job. I've not yet found any regressions and > > on some pages it's better than dillo1 was. > > Another improvement I forgot to mention: I had several links where > huge areas of whitespace appeared inside the page. These now render > sensibly. The new code seems to be much better at allocating space > between the rows and columns. > > Regards, > > Jeremy Henty > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >

Jan. 29, 2008

[PATCH]: cleanup: comment out DEBUG_MSG in dw2/dw/widget.cc

by onepoint＠starurchin.org

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

Jan. 29, 2008

a highlighting colors proposal (with code)

by place＠gobigwest.com

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

Jan. 29, 2008

[PATCH]: escape illegal characters instead of stripping them

by onepoint＠starurchin.org

Oops, I broke the indentation! Here's the same patch, but with corrected whitespace. Jeremy Henty

Jan. 28, 2008

[PATCH]: escape illegal characters instead of stripping them

by onepoint＠starurchin.org

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

Jan. 27, 2008

Q: "Yes, enough memory!", really?

by onepoint＠starurchin.org

On Sun, Jan 27, 2008 at 06:17:21PM +0100, Johannes Hofmann wrote: > Hi, > > On Sun, Jan 27, 2008 at 05:11:30PM +0000, Jeremy Henty wrote: > > > > 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? > > Yeah, looks scary! But this code path is only reached if there is at > least one illegal character, so at least one char will be skipped > and then there is enough room for the \0. OK, I get it! Thanks. I thought I must be missing something since otherwise Dillo would have segfaulted everytime it created a URL, which obviously does not happen. Regards, Jeremy Henty

Jan. 27, 2008

Q: "Yes, enough memory!", really?

by Johannes.Hofmann＠gmx.de

Hi, On Sun, Jan 27, 2008 at 05:11:30PM +0000, Jeremy Henty wrote: > > 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? Yeah, looks scary! But this code path is only reached if there is at least one illegal character, so at least one char will be skipped and then there is enough room for the \0. Regards, 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. 27, 2008

Q: "Yes, enough memory!", really?

by onepoint＠starurchin.org

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

Jan. 27, 2008

Various minor patches

by Christian.Kellermann＠nefkom.net

Skipped content of type multipart/mixed

Jan. 27, 2008

New table layout rocks!

by onepoint＠starurchin.org

On Fri, Jan 25, 2008 at 08:09:14PM +0100, Johannes Hofmann wrote: > > Yes, Jorge did a great job. I've not yet found any regressions and > on some pages it's better than dillo1 was. Another improvement I forgot to mention: I had several links where huge areas of whitespace appeared inside the page. These now render sensibly. The new code seems to be much better at allocating space between the rows and columns. Regards, Jeremy Henty

Jan. 26, 2008

an experiment in widget coloring (with code)

by place＠gobigwest.com

With my color settings, my buttons were light grey with unreadable white labels. Well, that's no good. And standard gui widget colors scream "I'm using a Windows Office Productivity Suite!" to me. So here is something to play with. I currently have the widgets using background color and the labels/text either black or white. fltk_black to make black work right widget_colors.dillo to set backgroundColor in Style. widget_colors.dw where you set the widget colors.

Jan. 25, 2008

Various minor patches

by Johannes.Hofmann＠gmx.de

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... Regards, Johannes > > 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. 25, 2008

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