- Dillo-dev - lists.mailman3.com

patch: progressive images

by place＠gobigwest.com

(the ones that start out blurry and grow sharper) - Added code for progressive display of, well, progressive jpegs because I was tired of waiting for full download before display. jpeglib uses the word "scan" for each loop through the scanlines of the image, so I did the same. I'm not sure it's a terribly descriptive term, though, at least to me (not a graphics person). Couldn't think of a better word. - Turned out scaled ones didn't work. (And, incidentally, that was frustrating because it took some time to realize that the breaking ones were scaled ever so slightly.) Added some bit clearing to imgbuf code on the dw side so that scaled buffers would continue to copy from root buffers. - Turned out that if there was more than one copy on a page, only the first copy worked. (dillo uses image decoders on the first one and pulls the scanlines out of Dicache for the rest.) More bit clearing and a scan number to help a_Dicache_callback with its copying. - Discovered that interlaced pngs use progressive display, and that they hadn't been working for scaled or for multiple on a page. - Considered looking into animated gifs, but then my good sense prevailed :)

Jan. 14, 2008

Various minor patches

by tmseck-lists＠netcologne.de

* Johannes Hofmann (Johannes.Hofmann(a)gmx.de) > On Sun, Jan 13, 2008 at 05:07:04PM +0100, Thomas-Martin Seck wrote: > > > > 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. > > EAI_NODATA still exists on DragonFly. But if it's obsolete we should > generally avoid to use it. Or to be on the safe side do something > like: > > #ifdef EAI_NODATA > ... > #endif Frankly, I do not know why certain constants were obsoleted over the years (in FreeBSD) -- it might be because some RFC/draft says so or ISC/Nominum decided to do so in their implementation which FreeBSD seems to track rather closely. DragonFly probably never felt the need to update this after importing the 4.something userland back in the day? One could make EAI_NODATA equal EAI_NONAME in this case, this is the way it was done in FreeBSD for a few months until 01/2004: <http://www.freebsd.org/cgi/cvsweb.cgi/src/include/netdb.h?rev=1.30;content-…>. This is probably a better approach than the hard coded OS #ifdef I came up with first if one wants to catch this case at all.

Jan. 13, 2008

Various minor patches

by Johannes.Hofmann＠gmx.de

Hello, On Sun, Jan 13, 2008 at 05:07:04PM +0100, Thomas-Martin Seck wrote: > 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. Very nice! The same problem exists on DragonFly... > > 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. EAI_NODATA still exists on DragonFly. But if it's obsolete we should generally avoid to use it. Or to be on the safe side do something like: #ifdef EAI_NODATA ... #endif Regards, Johannes > > Otherwise dillo-fltk looks really promising -- keep up the good work! > > Best regards, > -- > Thomas-Martin Seck > current dillo and FLTK port maintainer on FreeBSD Content-Description: detect_libiconv.diff > --- dillo2/configure.in Fri Oct 19 17:39:27 2007 > +++ dillo2-cur/configure.in Sun Jan 13 15:46:18 2008 > @@ -300,6 +300,18 @@ > AC_DEFINE([ENABLE_SSL], [], [Enable SSL support]) > fi > > +dnl ---------------------- > +dnl Test for libiconv > +dnl ---------------------- > +AC_CHECK_HEADER(iconv.h, iconv_ok=yes, iconv_ok=no) > +if test "x$iconv_ok" = "xyes"; then > + AC_CHECK_LIB(iconv, iconv_open, iconv_ok=yes, iconv_ok=no) > +fi > +if test "x$iconv_ok" = "xyes"; then > + LIBICONV_LIBS="-liconv" > +else > + AC_ERROR(libiconv must be installed!) > +fi > > dnl ---------------------- > dnl Test for POSIX threads > @@ -465,6 +477,7 @@ > AC_SUBST(LIBFLTK_CXXFLAGS) > AC_SUBST(LIBFLTK_CFLAGS) > AC_SUBST(LIBFLTK_LIBS) > +AC_SUBST(LIBICONV_LIBS) > AC_SUBST(datadir) > AC_SUBST(src doc) > > --- dillo2/src/Makefile.am Tue Nov 13 14:56:43 2007 > +++ dillo2-cur/src/Makefile.am Sun Jan 13 15:04:17 2008 > @@ -14,7 +14,7 @@ > ../../dw-testbed/dw/libDw-fltk.a \ > ../../dw-testbed/dw/libDw-core.a \ > ../../dw-testbed/lout/liblout.a \ > - @LIBJPEG_LIBS@ @LIBPNG_LIBS@ @LIBFLTK_LIBS@ @LIBZ_LIBS@ > + @LIBJPEG_LIBS@ @LIBPNG_LIBS@ @LIBFLTK_LIBS@ @LIBZ_LIBS@ @LIBICONV_LIBS@ > > dillo_fltk_SOURCES = \ > dillo.cc \ Content-Description: src-colors.h.diff > --- dillo2/src/colors.h Sun Oct 7 00:36:34 2007 > +++ dillo2-cur/src/colors.h Sun Jan 13 15:49:28 2008 > @@ -1,6 +1,15 @@ > #ifndef __COLORS_H__ > #define __COLORS_H__ > > +#include "config.h" > +#ifdef HAVE_INTTYPES_H > +#include <inttypes.h> > +#else > +#ifdef HAVE_STDINT_H > +#include <stdint.h> > +#endif > +#endif > + > #ifdef __cplusplus > extern "C" { > #endif /* __cplusplus */ Content-Description: src-dns.c.diff > --- dillo2/src/dns.c Mon Nov 5 21:25:16 2007 > +++ dillo2-cur/src/dns.c Sun Jan 13 16:48:07 2008 > @@ -289,8 +289,12 @@ static void *Dns_server(void *data) > MSG("DNS error: HOST_NOT_FOUND\n"); > else if (error == EAI_AGAIN) > MSG("DNS error: TRY_AGAIN\n"); > + /* The EAI_NODATA definition is marked as obsoleted in FreeBSD's netdb.h > + * and is #if 0'ed in releases starting with 5.2: */ > +#if !defined __FreeBSD__ || __FreeBSD__ <= 4 > else if (error == EAI_NODATA) > MSG("DNS error: NO_ADDRESS\n"); > +#endif > else if (h_errno == EAI_FAIL) > MSG("DNS error: NO_RECOVERY\n"); > } else { > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Jan. 13, 2008

Various minor patches

by tmseck-lists＠netcologne.de

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

Jan. 13, 2008

patch: the http header Content-Type half of charset conversion

by place＠gobigwest.com

Jorge wrote: > How did you make the search? I managed to get a few windows-125[2-3] > but nothing else. URLs, or a dummies guide to searching is appreciated. ;) I wonder whether "???????" came through. I was careful to send the msg as UTF-8, but I neglected to check the copy that came back via the list to see whether anything munged it up along the way. The third hit on the first page via google gives me a koi8-r page for a charset patch to 0.6.6. http://www.google.com/search?q=dillo+%D0%B1%D1%80%D0%B0%D1%83%D0%B7%D0%B5%D… I just stumbled upon the fact that google itself is a decent source. www.google.cn is GB2312 (google, working to crush dissent and make information disappear. Big money is the only morality, after all.) www.google.gr is ISO-8859-7, www.google.lt is windows-1257 Took me a while this time to find any Hebrew. pc.co.il is windows-1255. Displayed left-to-right, but it's a start. > Actually, to me, it looks like the cache is a good place to make the > conversion (instead of html). That way text, html and view source would > work in a similar way: I think you're right. When I started it, I had the idea that cache was going to be "pure" and not know about what it was sending to clients, but, yeah, it does need to know. > Maybe the most important part now is to try to get HTML's meta charset > working, and only after that to choose where to place the code. Putting aside my earlier concerns about javascript since it's not like javascript support is imminent, let's see... http says it's charset A. cache.c translates A->utf8. meta says it's charset B. html.cc translates utf8->A followed by B->utf8, except that won't work because the utf8 that html.cc received is probably full of UFFFD characters and things. badly-written pages displaying text and making buttons and tooltips and so on by the time the meta tag is reached.

Jan. 13, 2008

Report on fltk-2.0.x-r5990

by jcid＠dillo.org

On Wed, Jan 09, 2008 at 08:15:40AM +0000, Jeremy Henty wrote: > > I have been running Dillo on top of the latest daily snapshot > (fltk-2.0.x-r5990) and seen no problems. Has anyone else tried this? > Maybe we should update the recommended FLTK snapshot? > > NB: fltk-2.0.x-r5990 is not binary compatible with the current > recommended snapshot, so if you upgrade you have to rebuild Dillo (and > any other FLTK2 applications) or you will get memory corruption. Yes, diff -pru fltk-2.0.x-r5975 fltk-2.0.x-r5990 |grep -v ^Only|less shows only a few lines changed. Unless I overlooked another change it looks safe to upgrade. -- Cheers Jorge.-

Jan. 13, 2008

patch: the http header Content-Type half of charset conversion

by jcid＠dillo.org

On Thu, Jan 10, 2008 at 06:00:12PM +0000, place wrote: > Dug out my old patch and ripped out the meta tag stuff, the > charset-setting dialog, etc. > This much should be unobjectionable. OK, committed. I added support for surrounding whitespace in Html_get_charset(), and added a call to dStr_fit(Local_Buf). > Had good fun searching for things like dillo ?????????????? and seeing > how many sites using windows-1251 or koi8-r worked now with this > much of the code. Maybe half. Greek and Hebrew were somewhat less > than half. And my fonts don't have enough coverage to make it fun > trying Asian sites. Of course it doesn't matter much when everybody > who participates here is a native speaker of some latin-1 language... How did you make the search? I managed to get a few windows-125[2-3] but nothing else. URLs, or a dummies guide to searching is appreciatted. ;) > Note that View Source will not show files as converted because the > conversion is up in html.cc and View Source uses the cache. Actually, to me, it looks like the cache is a good place to make the conversion (instead of html). That way text, html and view source would work in a similar way: file ---- \ .-> text '-> / Cache ---> html .-> (w/decoding) \ / '-> View Source web ---- .-> verbatim from source / Save \ '-> utf-8 (removing meta charset if present) For saving, a preference may be set (or a dialog popped up). Maybe the most important part now is to try to get HTML's meta charset working, and only after that to choose where to place the code. -- Cheers Jorge.-

Jan. 13, 2008

patch: multiple-line http headers (and a free bonus Content-Type msg change)

by place＠gobigwest.com

Jorge wrote: > In what regards to us as a project, we try to comply with the > advice in good RFCs, ignore the bloat and artificial barriers, > and to try to implement an eclectic subset of it. Oh, okay. I'd been under the impression that dillo leaned very strongly toward spec-following. But "don't follow a stupid rule if it's extra work" sounds eminently reasonable.

Jan. 12, 2008

patch: multiple-line http headers (and a free bonus Content-Type msg change)

by jcid＠dillo.org

Hi, On Tue, Jan 08, 2008 at 08:01:50PM +0000, place wrote: > Finally got around to it. > > Since it's another one of those things > I am probably never going to encounter > in the outside world, I tested by sticking > whitespace into headers sent by file.c. OK, committed with some minor comments. > PS I see that this guy has a rant about how > the headers can attain an arbitrary degree > of horribleness if you really want to go by > the letter of the rfc: > http://www.and.org/texts/server-http Welcome to the RFC world! :-) Sometimes RFCs provide good advice, others, they constitute an antology example of what Porter called "rising the entry barriers". If a certain market has a low-cost entrance for potential competitors, the existing ones may arrange for an artificial obstacle to rise the entry barriers. e.g. SW companies may get a few employees inside an RFC committee to get sure the protocol gets overly complex so it takes a huge effort to comply. I do consider HTTP-1.1 and the SGML spec of HTML (which not even the bigger browsers do comply with), as excellent examples of this. *Sigh*, every now and then I reflect how much easier it would be if clean-room, vested-interest-free RFCs were produced. Some RFCs are very helpful though (as the one for URL/URIs and resolving algorithms). This is very good news because it demonstrates that good, simple and clean RFCs can be produced in the real world. In what regards to us as a project, we try to comply with the advice in good RFCs, ignore the bloat and artificial barriers, and to try to implement an eclectic subset of it. -- Cheers Jorge.- PS: A good article on how to destroy a protocol was given by Raph Levien here: http://www.levien.com/free/decommoditizing.html

Jan. 12, 2008

Re: patch: FltkViewBase::getClippingView source-copying error

by jcid＠dillo.org

On Tue, Jan 08, 2008 at 04:32:50PM +0000, place wrote: > I finally found out why alt tags had been so very flaky for me all along. Good, it was also biting me from a long time! Committed. -- Cheers Jorge.-

Jan. 12, 2008