- Dillo-dev - lists.mailman3.com

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

Work on TABLES

by jcid＠dillo.org

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.

Jan. 19, 2008

Working on TABLES

by jcid＠dillo.org

Hi there, As you may remember, I dared to awake the sleeping dragon of table apportion algorithms. Frankly, I don't yet know whether it was a good idea after all, but I have hope. It is impresive how complex the geometric combination of cases grows; hopefully some code will be uploaded before Jan 20. In the meanwhile, does anyone want to give a try to imagemaps? Or maybe to implement tabs? This is much simpler than it looks. Basically we can add the tab widgets and to switch the navigation stack and rendered page upon click. As dillo is quick to render this has the advantage of low memory consumption because we don't need to have all the rendered pages in memory! And it opens the possibility of multiple windows with TABS using low resources. -- Cheers Jorge.-

Jan. 16, 2008

patch: progressive images

by jcid＠dillo.org

Hi, On Mon, Jan 14, 2008 at 06:06:03PM +0000, place wrote: > (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. Great! Committed. > - Considered looking into animated gifs, but then my good sense prevailed :) :-) -- Cheers Jorge.-

Jan. 16, 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 appreciatted. ;) Why google sucks, part n: UTF-8 queries work from the dialog, and I can click page 2, page 3, etc., but it turns out that if I use their search input, they _insist_ upon sending <input type=hidden name=ie value="ISO-8859-1"> unless I change the user-agent string. So what if my accept-charset is utf-8 (even tried removing iso-8859-1)? Doesn't matter. It must think it knows what dillo can do, but it is tragically mistaken. Maybe the proper solution is to allow hidden inputs to be "unhidden" as text inputs. Probably wouldn't be the only place where it would be useful...

Jan. 15, 2008

patch: progressive images

by place＠gobigwest.com

Johannes wrote: > This is cool! I haven't looked at the details, but it works > and is stable here. That's excellent news :) :)

Jan. 15, 2008

patch: progressive images

by Johannes.Hofmann＠gmx.de

On Mon, Jan 14, 2008 at 06:06:03PM +0000, place wrote: > (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. This is cool! I haven't looked at the details, but it works and is stable here. Johannes > > > > - Considered looking into animated gifs, but then my good sense prevailed :) > > diff -pur dw2/dw/fltkimgbuf.cc dw2-cur/dw/fltkimgbuf.cc > --- dw2/dw/fltkimgbuf.cc 2007-11-12 15:27:13.000000000 +0000 > +++ dw2-cur/dw/fltkimgbuf.cc 2008-01-13 06:06:44.000000000 +0000 > @@ -191,6 +191,16 @@ void FltkImgbuf::copyRow (int row, const > } > } > > +void FltkImgbuf::newScan () > +{ > + if (isRoot()) { > + for (Iterator<FltkImgbuf> it = scaledBuffers->iterator(); it.hasNext(); ) { > + FltkImgbuf *sb = it.getNext (); > + sb->copiedRows->clear(); > + } > + } > +} > + > core::Imgbuf* FltkImgbuf::getScaledBuf (int width, int height) > { > if (root) > diff -pur dw2/dw/fltkimgbuf.hh dw2-cur/dw/fltkimgbuf.hh > --- dw2/dw/fltkimgbuf.hh 2007-10-06 22:03:01.000000000 +0000 > +++ dw2-cur/dw/fltkimgbuf.hh 2008-01-12 20:39:27.000000000 +0000 > @@ -42,6 +42,7 @@ public: > > void setCMap (int *colors, int num_colors); > inline void scaleRow (int row, const core::byte *data); > + void newScan (); > void copyRow (int row, const core::byte *data); > core::Imgbuf* getScaledBuf (int width, int height); > void getRowArea (int row, dw::core::Rectangle *area); > diff -pur dw2/dw/imgbuf.hh dw2-cur/dw/imgbuf.hh > --- dw2/dw/imgbuf.hh 2007-10-06 22:03:01.000000000 +0000 > +++ dw2-cur/dw/imgbuf.hh 2008-01-12 20:38:03.000000000 +0000 > @@ -167,6 +167,7 @@ public: > > virtual void setCMap (int *colors, int num_colors) = 0; > virtual void copyRow (int row, const byte *data) = 0; > + virtual void newScan () = 0; > > /* > * Methods called from dw::Image > diff -pur dillo2/src/bitvec.c dillo2-cur/src/bitvec.c > --- dillo2/src/bitvec.c 2007-10-06 22:36:34.000000000 +0000 > +++ dillo2-cur/src/bitvec.c 2008-01-14 00:40:48.000000000 +0000 > @@ -30,6 +30,14 @@ bitvec_t *a_Bitvec_new(int num_bits) > } > > /* > + * Clear a bitvec > + */ > +void a_Bitvec_clear(bitvec_t *bvec) > +{ > + memset(bvec->vec, 0, sizeof(uchar_t) * bvec->len/BVEC_SIZE + 1); > +} > + > +/* > * Free a bitvec > */ > void a_Bitvec_free(bitvec_t *bvec) > diff -pur dillo2/src/bitvec.h dillo2-cur/src/bitvec.h > --- dillo2/src/bitvec.h 2007-10-06 22:36:34.000000000 +0000 > +++ dillo2-cur/src/bitvec.h 2008-01-14 00:40:48.000000000 +0000 > @@ -21,6 +21,7 @@ bitvec_t *a_Bitvec_new(int bits); > void a_Bitvec_free(bitvec_t *bvec); > int a_Bitvec_get_bit(bitvec_t *bvec, int pos); > void a_Bitvec_set_bit(bitvec_t *bvec, int pos); > +void a_Bitvec_clear(bitvec_t *bvec); > > /* > #define a_Bitvec_get_bit(bvec,pos) \ > diff -pur dillo2/src/dicache.c dillo2-cur/src/dicache.c > --- dillo2/src/dicache.c 2007-11-07 05:03:53.000000000 +0000 > +++ dillo2-cur/src/dicache.c 2008-01-14 02:26:26.000000000 +0000 > @@ -84,6 +84,7 @@ static DICacheEntry *Dicache_entry_new(v > entry->RefCount = 1; > entry->TotalSize = 0; > entry->Y = 0; > + entry->ScanNumber = 0; > entry->BitVec = NULL; > entry->State = DIC_Empty; > entry->version = 0; > @@ -263,7 +264,7 @@ void a_Dicache_callback(int Op, CacheCli > > dReturn_if_fail ( DicEntry != NULL ); > > - /* when the data stream is not an image 'v_imgbuf' keeps NULL */ > + /* when the data stream is not an image 'v_imgbuf' remains NULL */ > if (Op == CA_Send && DicEntry->v_imgbuf) { > if (Image->height == 0 && DicEntry->State >= DIC_SetParms) { > /* Set parms */ > @@ -273,11 +274,25 @@ void a_Dicache_callback(int Op, CacheCli > DicEntry->type); > } > if (DicEntry->State == DIC_Write) { > - for (i = 0; i < DicEntry->height; ++i) > - if (a_Bitvec_get_bit(DicEntry->BitVec, (int)i) && > - !a_Bitvec_get_bit(Image->BitVec, (int)i) ) > - a_Image_write(Image, DicEntry->v_imgbuf, > - DicEntry->linebuf, i, FALSE); > + if (DicEntry->ScanNumber == Image->ScanNumber) { > + for (i = 0; i < DicEntry->height; ++i) > + if (a_Bitvec_get_bit(DicEntry->BitVec, (int)i) && > + !a_Bitvec_get_bit(Image->BitVec, (int)i) ) > + a_Image_write(Image, DicEntry->v_imgbuf, > + DicEntry->linebuf, i, FALSE); > + } else { > + for (i = 0; i < DicEntry->height; ++i) { > + if (a_Bitvec_get_bit(DicEntry->BitVec, (int)i) || > + !a_Bitvec_get_bit(Image->BitVec, (int)i) || > + DicEntry->ScanNumber > Image->ScanNumber + 1) { > + a_Image_write(Image, DicEntry->v_imgbuf, > + DicEntry->linebuf, i, FALSE); > + } > + if (!a_Bitvec_get_bit(DicEntry->BitVec, (int)i)) > + a_Bitvec_clear_bit(Image->BitVec, (int)i); > + } > + Image->ScanNumber = DicEntry->ScanNumber; > + } > } > } else if (Op == CA_Close || Op == CA_Abort) { > a_Image_close(Web->Image); > @@ -353,6 +368,22 @@ void a_Dicache_set_cmap(DilloUrl *url, i > } > > /* > + * Reset for a new scan from a multiple-scan image. > + */ > +void a_Dicache_new_scan(DilloImage *image, const DilloUrl *url, int version) > +{ > + DICacheEntry *DicEntry; > + > + dReturn_if_fail ( url != NULL ); > + DicEntry = Dicache_get_entry_version(url, version); > + dReturn_if_fail ( DicEntry != NULL ); > + > + a_Bitvec_clear(DicEntry->BitVec); > + DicEntry->ScanNumber++; > + a_Image_new_scan(image, DicEntry->v_imgbuf); > +} > + > +/* > * Implement the write method > * (Write a scan line into the Dicache entry) > * buf: row buffer > diff -pur dillo2/src/dicache.h dillo2-cur/src/dicache.h > --- dillo2/src/dicache.h 2007-10-06 22:36:34.000000000 +0000 > +++ dillo2-cur/src/dicache.h 2008-01-14 00:40:48.000000000 +0000 > @@ -31,6 +31,7 @@ struct _DICacheEntry { > void *v_imgbuf; /* Void pointer to an Imgbuf object */ > size_t TotalSize; /* Amount of memory the image takes up */ > int Y; /* Current decoding row */ > + uint_t ScanNumber; /* Current decoding scan */ > bitvec_t *BitVec; /* Bit vector for decoded rows */ > DicEntryState State; /* Current status for this entry */ > int RefCount; /* Reference Counter */ > @@ -53,6 +54,7 @@ void a_Dicache_set_parms(DilloUrl *url, > void a_Dicache_set_cmap(DilloUrl *url, int version, DilloImage *Image, > const uchar_t *cmap, uint_t num_colors, > int num_colors_max, int bg_index); > +void a_Dicache_new_scan(DilloImage *image, const DilloUrl *url, int version); > void a_Dicache_write(DilloImage *Image, DilloUrl *url, int version, > const uchar_t *buf, int x, uint_t Y); > void a_Dicache_close(DilloUrl *url, int version, CacheClient_t *Client); > diff -pur dillo2/src/image.cc dillo2-cur/src/image.cc > --- dillo2/src/image.cc 2007-11-07 05:03:53.000000000 +0000 > +++ dillo2-cur/src/image.cc 2008-01-14 00:40:48.000000000 +0000 > @@ -55,6 +55,7 @@ DilloImage *a_Image_new(int width, > Image->in_type = DILLO_IMG_TYPE_NOTSET; > Image->bg_color = bg_color; > Image->ProcessedBytes = 0; > + Image->ScanNumber = 0; > Image->BitVec = NULL; > Image->State = IMG_Empty; > > @@ -155,6 +156,16 @@ void a_Image_set_cmap(DilloImage *Image, > } > > /* > + * Begin a new scan for a multiple-scan image > + */ > +void a_Image_new_scan(DilloImage *Image, void *v_imgbuf) > +{ > + a_Bitvec_clear(Image->BitVec); > + Image->ScanNumber++; > + ((Imgbuf*)v_imgbuf)->newScan(); > +} > + > +/* > * Implement the write method > */ > void a_Image_write(DilloImage *Image, void *v_imgbuf, > diff -pur dillo2/src/image.hh dillo2-cur/src/image.hh > --- dillo2/src/image.hh 2007-12-24 06:17:25.000000000 +0000 > +++ dillo2-cur/src/image.hh 2008-01-14 00:40:48.000000000 +0000 > @@ -44,6 +44,7 @@ struct _DilloImage { > > int ProcessedBytes; /* Amount of bytes already decoded */ > bitvec_t *BitVec; /* Bit vector for decoded rows */ > + uint_t ScanNumber; /* Current decoding scan */ > ImageState State; /* Processing status */ > > int RefCount; /* Reference counter */ > @@ -62,6 +63,7 @@ void a_Image_set_parms(DilloImage *Image > int version, uint_t width, uint_t height, > DilloImgType type); > void a_Image_set_cmap(DilloImage *Image, const uchar_t *cmap); > +void a_Image_new_scan(DilloImage *image, void *v_imgbuf); > void a_Image_write(DilloImage *Image, void *v_imgbuf, > const uchar_t *buf, uint_t y, int decode); > void a_Image_close(DilloImage *Image); > diff -pur dillo2/src/jpeg.c dillo2-cur/src/jpeg.c > --- dillo2/src/jpeg.c 2007-11-07 05:03:53.000000000 +0000 > +++ dillo2-cur/src/jpeg.c 2008-01-14 02:29:32.000000000 +0000 > @@ -42,7 +42,9 @@ > typedef enum { > DILLO_JPEG_INIT, > DILLO_JPEG_STARTING, > - DILLO_JPEG_READING, > + DILLO_JPEG_READ_BEGIN_SCAN, > + DILLO_JPEG_READ_IN_SCAN, > + DILLO_JPEG_READ_END_SCAN, > DILLO_JPEG_DONE, > DILLO_JPEG_ERROR > } DilloJpegState; > @@ -139,10 +141,7 @@ void *a_Jpeg_image(const char *Type, voi > static void Jpeg_close(DilloJpeg *jpeg, CacheClient_t *Client) > { > a_Dicache_close(jpeg->url, jpeg->version, Client); > - > - if (jpeg->state != DILLO_JPEG_DONE) { > - jpeg_destroy_decompress(&(jpeg->cinfo)); > - } > + jpeg_destroy_decompress(&(jpeg->cinfo)); > dFree(jpeg); > } > > @@ -288,6 +287,15 @@ static void Jpeg_write(DilloJpeg *jpeg, > else > DEBUG_MSG(5, "jpeg: can't handle %d component images\n", > jpeg->cinfo.num_components); > + > + /* > + * TODO: The multiple-scan jpeg code is valuable at download time > + * when an image arrives slowly, but should not be used to redisplay > + * cached images. > + */ > + if (jpeg_has_multiple_scans(&jpeg->cinfo)) > + jpeg->cinfo.buffered_image = TRUE; > + > a_Dicache_set_parms(jpeg->url, jpeg->version, jpeg->Image, > (uint_t)jpeg->cinfo.image_width, > (uint_t)jpeg->cinfo.image_height, > @@ -301,34 +309,94 @@ static void Jpeg_write(DilloJpeg *jpeg, > /* decompression step 5 (see libjpeg.doc) */ > if (jpeg_start_decompress(&(jpeg->cinfo))) { > jpeg->y = 0; > - jpeg->state = DILLO_JPEG_READING; > + jpeg->state = jpeg_has_multiple_scans(&jpeg->cinfo) ? > + DILLO_JPEG_READ_BEGIN_SCAN : DILLO_JPEG_READ_IN_SCAN; > + } > + } > + > + /* > + * A progressive jpeg contains multiple scans that can be used to display > + * an increasingly sharp image as it is being received. The reading of each > + * scan must be surrounded by jpeg_start_output()/jpeg_finish_output(). > + */ > + > + if (jpeg->state == DILLO_JPEG_READ_END_SCAN) { > + if (jpeg_finish_output(&jpeg->cinfo)) { > + if (jpeg_input_complete(&jpeg->cinfo)) { > + jpeg->state = DILLO_JPEG_DONE; > + } else { > + jpeg->state = DILLO_JPEG_READ_BEGIN_SCAN; > + } > } > } > - if (jpeg->state == DILLO_JPEG_READING) { > + > + if (jpeg->state == DILLO_JPEG_READ_BEGIN_SCAN) { > + if (jpeg_start_output(&jpeg->cinfo, jpeg->cinfo.input_scan_number)) { > + a_Dicache_new_scan(jpeg->Image, jpeg->url, jpeg->version); > + jpeg->state = DILLO_JPEG_READ_IN_SCAN; > + } > + } > + > + if (jpeg->state == DILLO_JPEG_READ_IN_SCAN) { > linebuf = dMalloc(jpeg->cinfo.image_width * > jpeg->cinfo.num_components); > array[0] = linebuf; > - while (jpeg->y < jpeg->cinfo.image_height) { > + > + while (1) { > num_read = jpeg_read_scanlines(&(jpeg->cinfo), array, 1); > - if (num_read == 0) > + if (num_read == 0) { > + /* out of input */ > break; > + } > a_Dicache_write(jpeg->Image, jpeg->url, jpeg->version, > linebuf, 0, jpeg->y); > > jpeg->y++; > - } > - if (jpeg->y == jpeg->cinfo.image_height) { > - DEBUG_MSG(5, "height achieved\n"); > > - jpeg_destroy_decompress(&(jpeg->cinfo)); > - jpeg->state = DILLO_JPEG_DONE; > + if (jpeg->y == jpeg->cinfo.image_height) { > + /* end of scan */ > + if (!jpeg_has_multiple_scans(&jpeg->cinfo)) { > + jpeg->state = DILLO_JPEG_DONE; > + break; > + } else { > + jpeg->y = 0; > + if (jpeg_input_complete(&jpeg->cinfo)) { > + if (jpeg->cinfo.input_scan_number == > + jpeg->cinfo.output_scan_number) { > + jpeg->state = DILLO_JPEG_DONE; > + break; > + } else { > + /* one final loop through the scanlines */ > + jpeg_finish_output(&jpeg->cinfo); > + jpeg_start_output(&jpeg->cinfo, > + jpeg->cinfo.input_scan_number); > + continue; > + } > + } > + jpeg->state = DILLO_JPEG_READ_END_SCAN; > + if (!jpeg_finish_output(&jpeg->cinfo)) { > + /* out of input */ > + break; > + } else { > + if (jpeg_input_complete(&jpeg->cinfo)) { > + jpeg->state = DILLO_JPEG_DONE; > + break; > + } else { > + jpeg->state = DILLO_JPEG_READ_BEGIN_SCAN; > + } > + } > + if (!jpeg_start_output(&jpeg->cinfo, > + jpeg->cinfo.input_scan_number)) { > + /* out of input */ > + break; > + } > + a_Dicache_new_scan(jpeg->Image, jpeg->url, jpeg->version); > + jpeg->state = DILLO_JPEG_READ_IN_SCAN; > + } > + } > } > dFree(linebuf); > } > - if (jpeg->state == DILLO_JPEG_ERROR) { > - jpeg_destroy_decompress(&(jpeg->cinfo)); > - jpeg->state = DILLO_JPEG_DONE; > - } > } > > #endif /* ENABLE_JPEG */ > diff -pur dillo2/src/png.c dillo2-cur/src/png.c > --- dillo2/src/png.c 2007-10-06 22:36:34.000000000 +0000 > +++ dillo2-cur/src/png.c 2008-01-14 01:36:51.000000000 +0000 > @@ -79,6 +79,7 @@ struct _DilloPng { > uchar_t **row_pointers; /* pntr to row starts */ > jmp_buf jmpbuf; /* png error processing */ > int error; /* error flag */ > + png_uint_32 previous_row; > int rowbytes; /* No. bytes in image row */ > short passes; > short channels; /* No. image channels */ > @@ -230,6 +231,11 @@ static void > > png_progressive_combine_row(png_ptr, png->row_pointers[row_num], new_row); > > + if (row_num < png->previous_row) { > + a_Dicache_new_scan(png->Image, png->url, png->version); > + } > + png->previous_row = row_num; > + > switch (png->channels) { > case 3: > a_Dicache_write(png->Image, png->url, png->version, > @@ -419,6 +425,7 @@ static DilloPng *Png_new(DilloImage *Ima > png->linebuf = NULL; > png->image_data = NULL; > png->row_pointers = NULL; > + png->previous_row = 0; > > return png; > } > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Jan. 15, 2008

Various minor patches

by Johannes.Hofmann＠gmx.de

On Tue, Jan 15, 2008 at 12:34:12AM +0100, Thomas-Martin Seck wrote: > * Jorge Arellano Cid (jcid(a)dillo.org) > > > On Sun, Jan 13, 2008 at 05:07:04PM +0100, Thomas-Martin Seck wrote: > > > I'd like to know in what sense it looks "promising" to you. > > It can deal with UTF8 now :) But wait, I just noticed that > the window title is not decoded correctly if it contains special > characters, cf <http://www.heise.de/newsticker/meldung/101768> (notice > the "?" in "B?rse"). This is a known problem that only happens with window managers that use the WM_ICON_NAME instead of the _NET_WM_ICON_NAME property. I think this is a fltk bug (try the editor from the fltk/test directory and "save as" with a filename that contains special chars). I had sent a mail to the fltk list, but there seemed to be no consensus about my proposed fix. Johannes > > No seriously, I like to have a fast, graphical, no-frills browser that > allows me to read "non-active" UTF8 content since more and more content > generation systems use it instead of plain ISO8859-1. What I like to see > is frames support and CSS and if this is in the works I will happily > waiting for it to mature -- and I am sure it will, now that a small > but determined community seems to be (re-)forming. > > What I do not really crave for is scripting or support for active > content like Flash or Jave; if all else fails, I can use Opera or FF for > "demanding" sites. > > Unfortunately, I cannot help much with developing the core browser but > offer to maintain the FreeBSD "port" of dillo2 once you consider to > release it and try help with FreeBSD specific build or packaging issues. > Well, as long as it does not break things for others, of course :) > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Jan. 15, 2008

Various minor patches

by tmseck-lists＠netcologne.de

* Jorge Arellano Cid (jcid(a)dillo.org) > On Sun, Jan 13, 2008 at 05:07:04PM +0100, Thomas-Martin Seck wrote: > I'd like to know in what sense it looks "promising" to you. It can deal with UTF8 now :) But wait, I just noticed that the window title is not decoded correctly if it contains special characters, cf <http://www.heise.de/newsticker/meldung/101768> (notice the "?" in "B?rse"). No seriously, I like to have a fast, graphical, no-frills browser that allows me to read "non-active" UTF8 content since more and more content generation systems use it instead of plain ISO8859-1. What I like to see is frames support and CSS and if this is in the works I will happily waiting for it to mature -- and I am sure it will, now that a small but determined community seems to be (re-)forming. What I do not really crave for is scripting or support for active content like Flash or Jave; if all else fails, I can use Opera or FF for "demanding" sites. Unfortunately, I cannot help much with developing the core browser but offer to maintain the FreeBSD "port" of dillo2 once you consider to release it and try help with FreeBSD specific build or packaging issues. Well, as long as it does not break things for others, of course :)

Jan. 15, 2008

Various minor patches

by tmseck-lists＠netcologne.de

* Jorge Arellano Cid (jcid(a)dillo.org) > 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. > > OK with the idea but the patch "as is" breaks it for Linux. Please > send a new one. 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.

Jan. 15, 2008

Various minor patches

by jcid＠dillo.org

Hi, 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. We too! ;) > 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. OK with the idea but the patch "as is" breaks it for Linux. Please send a new one. > > 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. Committed. > 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. Committed, with Johannes' suggestion. > Otherwise dillo-fltk looks really promising -- keep up the good work! I'd like to know in what sense it looks "promising" to you. -- Cheers Jorge.-

Jan. 14, 2008

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

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

by place＠gobigwest.com

Dug out my old patch and ripped out the meta tag stuff, the charset-setting dialog, etc. This much should be unobjectionable. 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... Note that View Source will not show files as converted because the conversion is up in html.cc and View Source uses the cache.

Jan. 10, 2008

Report on fltk-2.0.x-r5990

by place＠gobigwest.com

Jeremy 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? *giving it a try* Nothing bad has happened so far, anyway...

Jan. 10, 2008

Report on fltk-2.0.x-r5990

by onepoint＠starurchin.org

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. FYI my system is Linux 2.6.23.12-0 , glibc 2.3.4 , gcc 3.4.3 . Jeremy Henty

Jan. 9, 2008

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

by place＠gobigwest.com

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

Jan. 8, 2008

Re: Feature request

by Beartooth＠swva.net

On Tue, 08 Jan 2008 10:36:38 -0300, Jorge Arellano Cid wrote: [...] > Anyway, if you don't mind someone may get your filenames, you > can use the patch. Or compile a special dillo to hook to the MUA, and > friends, and take care to read the URL before launching it! :-) Thanks! I'm afraid patches, compilation, and all that are way beyond me. I'm on this list at all only because it's the only one on Gmane. I guess I'll just hope a version of the patch makes it into 1.0 Strength to all your arms! -- Beartooth Staffwright, PhD, Neo-Redneck Linux Convert Fedora 8; Alpine 0.99999, Pan 0.132; Privoxy 3.0.6; Dillo 0.8.6, Galeon 2.0.3, Epiphany 2.20, Opera 9.24, Firefox 2.0 Remember I know precious little of what I am talking about.

Jan. 8, 2008

Re: Feature request

by jcid＠dillo.org

Hi, On Fri, Jan 04, 2008 at 06:03:31PM +0000, Beartooth wrote: > On Thu, 03 Jan 2008 21:30:32 +0000, Jeremy Henty wrote: > > > On Thu, Jan 03, 2008 at 04:29:39PM +0000, Beartooth wrote: > > > >> With other browsers, if I copy a URL that begins with www > >> (i.e., no http://), I will get to the site; with some, I don't even > >> need the www -- I can type simply "loc.gov" for instance, to be > >> taken to the Library of Congress. > > > > Doesn't Dillo already do this? If I create a new Dillo window, type > > imdb.com into the URL field and hit <Enter>, Dillo takes me to > > http://imdb.com . The same works for starurchin.org (my personal > > domain) and loc.gov too. These also work if I copy and paste the URL > > instead of typing it. > > > > Can you give a specific example where Dillo does not work as you would > > like? Which version are you using? > > > I mis-spoke. Instead of "copy," I meant "click on." I > have my newsreader and my mailers (even the remote one) set so > that if I click on a URL in a message, they launch Dillo. > > If a message contains, for instance, "www.loc.gov," > Dillo will launch and will show that in the URL field; but it > won't open the site. > > I'm running 0.8.6 under Fedora 8. You can try the patch below, but beware that it opens a security hole because if a file is not found it will ask the filename with the HTTP protocol. Now AFAIS this is not a huge risk because the queries are going to different machines, and the local DNS will only get the first segment of the filename. Now, if an evil DNS tells you that the "server" exists and sends you a prepared IP, the server on that IP will get all the information. Anyway, if you don't mind someone may get your filenames, you can use the patch. Or compile a special dillo to hook to the MUA, and friends, and take care to read the URL before launching it! :-) diff -pru dillo2/src/html.cc dillo2-cur/src/html.cc --- dillo2/src/html.cc 2008-01-08 09:07:18.000000000 -0300 +++ dillo2-cur/src/html.cc 2008-01-08 10:22:08.000000000 -0300 @@ -3000,7 +3000,13 @@ static void Html_tag_open_a(DilloHtml *h url = Html_url_new(html, attrbuf, NULL, 0, 0, 0, 0); dReturn_if_fail ( url != NULL ); - + if (strcmp(URL_SCHEME(url), "file") == 0 && + access(URL_PATH(url), F_OK) != 0) { + char *http_try = dStrconcat("http://", attrbuf, NULL); + a_Url_free(url); + url = Html_url_new(html, http_try, NULL, 0, 0, 0, 0); + dFree(http_try); + } old_style = S_TOP(html)->style; style_attrs = *old_style; -- Cheers Jorge.-

Jan. 8, 2008

patch: circles and discs

by jcid＠dillo.org

On Sun, Jan 06, 2008 at 05:17:23PM +0000, place wrote: > I almost regret this because I liked the little squares best. > Committed. Yes, :-) Maybe defaulting to a shaded, or less dark disk, could be better. (i.e. if color == BLACK, style == plain -> draw slicker disk). -- Cheers Jorge.-

Jan. 8, 2008

patch: http warnings

by jcid＠dillo.org

On Sun, Jan 06, 2008 at 05:39:31PM +0000, place wrote: > HTTP/1.1 has warning headers to tell you things like > "110 Response is stale" or "214 Transformation applied". > > There should probably be some mechanism to actually notify > the user properly -- nobody's ever going to notice an > MSG_HTTP string. > > As was the case with the "100 Continue"s some time ago, I > am not encountering genuine ones to test against. I just > tested by letting it treat date headers as warnings... > Committed. -- Cheers Jorge.-

Jan. 8, 2008

select crash

by jcid＠dillo.org

On Tue, Jan 08, 2008 at 09:37:58AM +0000, Jeremy Henty wrote: > > Jorge, please commit place's patch. I tried other fixes but I think > that this is the correct and most simple way to do it. Committed. -- Cheers Jorge.-

Jan. 8, 2008

Re: patch: crash when .dillo/ is absent (cookierc)

by jcid＠dillo.org

On Tue, Jan 08, 2008 at 06:26:07AM +0000, place wrote: > Poking around on mobileread.com and I saw where the guy who put dillo > on the iliad mentioned that the fltk dillo segfaults when there's no > .dillo dir. Well, we can't have _that_ happening. > > Plus, if somebody's on a crippled system, they might desperately > need info from the web to get themselves out of whatever they just > accidentally did to their computer... > Committed! -- Cheers Jorge.-

Jan. 8, 2008

select crash

by onepoint＠starurchin.org

Jorge, please commit place's patch. I tried other fixes but I think that this is the correct and most simple way to do it. Regards, Jeremy Henty

Jan. 8, 2008

select crash

by place＠gobigwest.com

dillo crashed on a form where an option didn't have a value (clicked on the Go button at the bottom of http://www.syllable-hardware.info/hardware.php?list.1 ) A glance at the spec suggested that what I wanted in that case was the contents of the tag. So... Trying the change below at least makes it not crash, but I don't know the code, so I'm not calling this a patch. diff -pur dillo2/src/html.cc dillo2-cur/src/html.cc --- dillo2/src/html.cc 2008-01-02 20:20:31.000000000 +0000 +++ dillo2-cur/src/html.cc 2008-01-08 01:30:08.000000000 +0000 @@ -3808,7 +3808,8 @@ static void Html_submit_form2(DilloHtml if (sel_res->isSelected(i)) { DilloHtmlOption *option = input->select->options->get (i); - Html_append_input(DataStr, input->name, option->value); + char *val = option->value ? option->value : option->content; + Html_append_input(DataStr, input->name, val); } } break;

Jan. 8, 2008

patch: http warnings

by place＠gobigwest.com

HTTP/1.1 has warning headers to tell you things like "110 Response is stale" or "214 Transformation applied". There should probably be some mechanism to actually notify the user properly -- nobody's ever going to notice an MSG_HTTP string. As was the case with the "100 Continue"s some time ago, I am not encountering genuine ones to test against. I just tested by letting it treat date headers as warnings...

Jan. 6, 2008

patch: circles and discs

by place＠gobigwest.com

I almost regret this because I liked the little squares best.

Jan. 6, 2008

Re: Feature request

by place＠gobigwest.com

> I mis-spoke. Instead of "copy," I meant "click on." I > have my newsreader and my mailers (even the remote one) set so > that if I click on a URL in a message, they launch Dillo. > > If a message contains, for instance, "www.loc.gov," > Dillo will launch and will show that in the URL field; but it > won't open the site. > > I'm running 0.8.6 under Fedora 8. I actually think dillo is too quick to regard things as http urls. When I type "dillo [filename]" and mistype the filename, I don't like the fact that it asks dns to resolve it. In principle, it can be a security issue telling the outside world my filenames.

Jan. 4, 2008

Re: Feature request

by Beartooth＠swva.net

On Thu, 03 Jan 2008 21:30:32 +0000, Jeremy Henty wrote: > On Thu, Jan 03, 2008 at 04:29:39PM +0000, Beartooth wrote: > >> With other browsers, if I copy a URL that begins with www >> (i.e., no http://), I will get to the site; with some, I don't even >> need the www -- I can type simply "loc.gov" for instance, to be >> taken to the Library of Congress. > > Doesn't Dillo already do this? If I create a new Dillo window, type > imdb.com into the URL field and hit <Enter>, Dillo takes me to > http://imdb.com . The same works for starurchin.org (my personal > domain) and loc.gov too. These also work if I copy and paste the URL > instead of typing it. > > Can you give a specific example where Dillo does not work as you would > like? Which version are you using? I mis-spoke. Instead of "copy," I meant "click on." I have my newsreader and my mailers (even the remote one) set so that if I click on a URL in a message, they launch Dillo. If a message contains, for instance, "www.loc.gov," Dillo will launch and will show that in the URL field; but it won't open the site. I'm running 0.8.6 under Fedora 8. -- Beartooth Staffwright, PhD, Neo-Redneck Linux Convert Fedora 8; Alpine 0.99999, Pan 0.132; Privoxy 3.0.6; Dillo 0.8.6, Galeon 2.0.3, Epiphany 2.20, Opera 9.24, Firefox 2.0 Remember I know precious little of what I am talking about.

Jan. 4, 2008

Feature request

by onepoint＠starurchin.org

On Thu, Jan 03, 2008 at 04:29:39PM +0000, Beartooth wrote: > With other browsers, if I copy a URL that begins with www > (i.e., no http://), I will get to the site; with some, I don't even > need the www -- I can type simply "loc.gov" for instance, to be > taken to the Library of Congress. Doesn't Dillo already do this? If I create a new Dillo window, type imdb.com into the URL field and hit <Enter>, Dillo takes me to http://imdb.com . The same works for starurchin.org (my personal domain) and loc.gov too. These also work if I copy and paste the URL instead of typing it. Can you give a specific example where Dillo does not work as you would like? Which version are you using? Regards, Jeremy Henty

Jan. 3, 2008

Feature request

by Beartooth＠swva.net

With other browsers, if I copy a URL that begins with www (i.e., no http://), I will get to the site; with some, I don't even need the www -- I can type simply "loc.gov" for instance, to be taken to the Library of Congress. This is a great help, not only with sites whose address one knows by heart, but also with email, in which people omit the front part(s) of sites routinely. It would be an especially welcome feature for those of us who keep Dillo set as our default browser. I have no idea how those other browsers do it, nor why Dillo does not. Is there a reason? -- Beartooth Staffwright, PhD, Neo-Redneck Linux Convert Fedora 8; Alpine 0.99999, Pan 0.132; Privoxy 3.0.6; Dillo 0.8.6, Galeon 2.0.3, Epiphany 2.20, Opera 9.24, Firefox 2.0 Remember I know precious little of what I am talking about.

Jan. 3, 2008

patch: beveled border (was: Re: [Dillo-dev] patch: color shading)

by jcid＠dillo.org

Hi, On Thu, Jan 03, 2008 at 05:05:41AM +0000, place wrote: > Jorge wrote: > > BTW, would you mind looking at this case? > > > > <table border=90> > > <tr> <td>1 2 3 4 > > <td>5 6 7 8 9 10 > > <td>A > > <tr> <td colspan="2" bgcolor=teal>cs=2 > > <td>B > > </table> > > > > It may use a bevel like firefox. > > Attached. > > I took the liberty of changing Points to int[2]s to allow me to use > fltk::addvertices() instead of fltk::addvertex(). Probably succumbing > to premature optimization here... It looks quite OK to me. Committed. -- Cheers Jorge.-

Jan. 3, 2008

patch: beveled border (was: Re: [Dillo-dev] patch: color shading)

by place＠gobigwest.com

Jorge wrote: > BTW, would you mind looking at this case? > > <table border=90> > <tr> <td>1 2 3 4 > <td>5 6 7 8 9 10 > <td>A > <tr> <td colspan="2" bgcolor=teal>cs=2 > <td>B > </table> > > It may use a bevel like firefox. Attached. I took the liberty of changing Points to int[2]s to allow me to use fltk::addvertices() instead of fltk::addvertex(). Probably succumbing to premature optimization here...

Jan. 3, 2008

patch: color shading

by place＠gobigwest.com

Jorge wrote: > BTW, would you mind looking at this case? > > <table border=90> > <tr> <td>1 2 3 4 > <td>5 6 7 8 9 10 > <td>A > <tr> <td colspan="2" bgcolor=teal>cs=2 > <td>B > </table> > > It may use a bevel like firefox. I'll at least take a look. The code for drawing borders seems a bit opaque at first glance, but it might not be too bad... > Have you kept on working on the code to support charset decoding when > specified in the HEAD section? No.

Jan. 2, 2008

[patch] segfault when closing window while it is loading

by jcid＠dillo.org

On Wed, Jan 02, 2008 at 06:53:20PM +0100, Johannes Hofmann wrote: > > It looks OK, but I can't make mine crash... > > Do you have an example URL? > > Here it crashes with any remote URL, that takes long enough to load > so I can close the child window while it is still loading. > I'm using BSD, perhaps it does not happen on Linux? Committed! (Finally it segfaulted for me with: http://chlamydia.fs.ei.tum.de/pub/DragonFly/packages/stable/DragonFly-1.10.… ) -- Cheers Jorge.-

Jan. 2, 2008

[patch] segfault when closing window while it is loading

by Johannes.Hofmann＠gmx.de

On Wed, Jan 02, 2008 at 12:25:08PM -0300, Jorge Arellano Cid wrote: > On Tue, Jan 01, 2008 at 12:44:55PM +0100, Johannes Hofmann wrote: > > Happy new year! > > 8-) > > > Below is a small patch to fix a crash that happens when I open > > a new window (e.g. with the middle mouse button) and close it > > immediately while it is still loading the page. > > > > Johannes > > > > --- a/src/uicmd.cc Mon Dec 31 22:49:02 2007 +0100 > > +++ b/src/uicmd.cc Tue Jan 01 12:38:14 2008 +0100 > > @@ -125,6 +125,7 @@ void a_UIcmd_close_bw(void *vbw) > > Layout *layout = (Layout*)bw->render_layout; > > > > MSG("a_UIcmd_close_bw\n"); > > + a_Bw_stop_clients(bw, BW_Root + BW_Img + Bw_Force); > > ui->destroy(); > > delete(layout); > > a_Bw_free(bw); > > It looks OK, but I can't make mine crash... > Do you have an example URL? Here it crashes with any remote URL, that takes long enough to load so I can close the child window while it is still loading. I'm using BSD, perhaps it does not happen on Linux? Cheers, Johannes > > -- > Cheers > Jorge.- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Jan. 2, 2008

[patch] segfault when closing window while it is loading

by place＠gobigwest.com

Jorge wrote: > On Tue, Jan 01, 2008 at 12:44:55PM +0100, Johannes Hofmann wrote: > > Below is a small patch to fix a crash that happens when I open > > a new window (e.g. with the middle mouse button) and close it > > immediately while it is still loading the page. > It looks OK, but I can't make mine crash... > Do you have an example URL? I used to get this with any http url, but the patch fixes it for them. With file urls, there's something else that still breaks when the layout is being deleted. The interesting part of the backtrace for that goes: #4 0x40345f00 in abort () from /lib/libc.so.6 #5 0x0809928c in misc::assertNotReached () at misc.hh:67 #6 0x080a87cd in object::Object::equals (this=0x8356b00, other=0x8356b00) at object.cc:49 #7 0x080a526a in container::untyped::List::remove0 (this=0x827a678, element=0x8356b00, compare=true, doNotDeleteAtAll=false) at container.cc:254 #8 0x08084b7b in container::untyped::List::remove (this=0x827a678, element=0x8356b00) at ../lout/container.hh:169 #9 0x08084b9f in container::typed::List<dw::fltk::FltkPlatform::IdleFunc>::remove (this=0x827b260, element=0x8356b00) at ../lout/container.hh:376 #10 0x080823ec in dw::fltk::FltkPlatform::removeIdle (this=0x827ac08, idleId=4) at fltkplatform.cc:303 #11 0x0809af40 in ~Layout (this=0x827b660) at layout.cc:114 #12 0x08054937 in a_UIcmd_close_bw (vbw=0x827b210) at uicmd.cc:129

Jan. 2, 2008

Re: Colspan and table percentages

by jcid＠dillo.org

Hi, On Mon, Dec 24, 2007 at 06:56:26AM +0000, place wrote: > I've noticed that sometimes people will make a table with two columns > for the purpose of indenting their text, specifying only the > width of the first column as some percentage. > > When they do this, dillo squishes everything to the right. > > Tiny example: > > <html><head><title></title></head><body> > <table width=500 border=3> > <tr> > <td width="50%">Is explicitly 50%</td> > <td>should be 50%</td> > </tr> > </table> > </body></html> This has uncovered a whole family of bugs! After experimenting with new algorithms and a different way to compute tables, it works in most of my tests. Making it work in all of them may need major changes also. This is a very complex area so I'm taking my time to try to fix it. -- Cheers Jorge.-

Jan. 2, 2008