October 2010 - Dillo-dev - lists.mailman3.com

Dillo config in LTIB

by jcid＠dillo.org

Hi, On Mon, Oct 11, 2010 at 08:12:09PM -0700, Vic wrote: > Hi, > > I installed Dillo in LTIB and while the splash page went up, > clicking links reported a dns error. I checked out dillorc and > saw no setting related to dns. Dillo uses getaddrinfo(). It depends on the OS. > Trying a link to localhost also > gave I/O errors. This is strange... > My trace as follows: > > Nav_open_url: new url='http://www.dillo.org/' > DNS error: TRY_AGAIN > Dns_server [0]: www.dillo.org is (nil) Does "ping www.dillo.org" resolve? > Using localhost: > > Nav_open_url: new url='http://localhost:88' > Dns_server [0]: localhost is 127.0.0.1 > Connecting to 127.0.0.1 > ** WARNING **: IO_write, closing with pending data not sent > ** WARNING **: "GET / HTTP/1.1\x0D > Connection: close\x0D > Accept-Charset: utf-8,*;q=0.8\x0D > Accept-Encoding: gzip\x0D > Host: localhost:88\x0D > Referer: http://localhost:88/\x0D > User-Agent: Dillo/2.1\x0D > \x0D > " > > Thanks for any help. It looks like something external closed the connection. Firewall? -- Cheers Jorge.-

Oct. 12, 2010

Dillo config in LTIB

by vic＠smartqsys.com

Hi, I installed Dillo in LTIB and while the splash page went up, clicking links reported a dns error. I checked out dillorc and saw no setting related to dns. Trying a link to localhost also gave I/O errors. My trace as follows: Nav_open_url: new url='http://www.dillo.org/' DNS error: TRY_AGAIN Dns_server [0]: www.dillo.org is (nil) Using localhost: Nav_open_url: new url='http://localhost:88' Dns_server [0]: localhost is 127.0.0.1 Connecting to 127.0.0.1 ** WARNING **: IO_write, closing with pending data not sent ** WARNING **: "GET / HTTP/1.1\x0D Connection: close\x0D Accept-Charset: utf-8,*;q=0.8\x0D Accept-Encoding: gzip\x0D Host: localhost:88\x0D Referer: http://localhost:88/\x0D User-Agent: Dillo/2.1\x0D \x0D " Thanks for any help. Vic

Oct. 12, 2010

Pending tasks

by Johannes.Hofmann＠gmx.de

On Mon, Oct 11, 2010 at 01:33:17PM -0300, Jorge Arellano Cid wrote: > Hi, > > With regard to: > > > 1 provide a dillo css compatibility table (and keep it up to date) > > 2 optimizing line-breaks - i.e. break at '-' but don't > > break e.g. <b>D</b>illo (after the 'D'). > > 3 support for  > > 4 support for text-indent > > 5 support font-variant > > 6 support more vertical-align options > > 7 make thickness of lines for underline and line-through > > depending on the font size and weight > > 8 support more border-style options (dotted, dashed ...) > > 9 support border-collapse (table related) > > 5 and 7 are in testing phase (in the repo). > AFAIK, 2,3,4,6,8 and 9 are open, with some work done for 6 by > corvid. > > After the big table rendering work long ago, I'm studying the > tables code again. > > Please notice that the doxygen dw documentation on table > algorithms (the math formulas part) is not up-to-date. It's done > in a different way since the big patch. > > My idea is to refresh my memory on this part of the code, and > then to try to devise a way to implement 8 and 9. At the same > time, working on this part will help for 6. > > Most probably we'll have to try to tackle these complex > problems coordinating our effort/knowledge. I'll be in better > shape to help with this after working for a while on tables. > > @Johannes, @corvid, please state what are your plans for work > on these remaining parts (if there's one already). I'm still working on CSS for the <html>-element (the issue reported by Jeremy). As my original patch had issues with pages that have multiple <head> elements, I decided to make some major changes to the StyleEngine-API. It looks ok now, but I need to do some more tests. Cheers, Johannes

Oct. 11, 2010

Pending tasks

by jcid＠dillo.org

Hi, With regard to: > 1 provide a dillo css compatibility table (and keep it up to date) > 2 optimizing line-breaks - i.e. break at '-' but don't > break e.g. <b>D</b>illo (after the 'D'). > 3 support for  > 4 support for text-indent > 5 support font-variant > 6 support more vertical-align options > 7 make thickness of lines for underline and line-through > depending on the font size and weight > 8 support more border-style options (dotted, dashed ...) > 9 support border-collapse (table related) 5 and 7 are in testing phase (in the repo). AFAIK, 2,3,4,6,8 and 9 are open, with some work done for 6 by corvid. After the big table rendering work long ago, I'm studying the tables code again. Please notice that the doxygen dw documentation on table algorithms (the math formulas part) is not up-to-date. It's done in a different way since the big patch. My idea is to refresh my memory on this part of the code, and then to try to devise a way to implement 8 and 9. At the same time, working on this part will help for 6. Most probably we'll have to try to tackle these complex problems coordinating our effort/knowledge. I'll be in better shape to help with this after working for a while on tables. @Johannes, @corvid, please state what are your plans for work on these remaining parts (if there's one already). -- Cheers Jorge.-

Oct. 11, 2010

Re: project list for sponsoring test period

by Johannes.Hofmann＠gmx.de

On Mon, Oct 11, 2010 at 12:54:37PM +0200, Johannes Hofmann wrote: > > Andreas installed mercurial in dillo.org - thanks Andreas! > I have setup a repository for css_compat. So the tests are version > controlled now. Here is how it works: > > Create a clone on your local workstation: > hg clone ssh://dillo.org/css_compat . Argh, that should have been: hg clone ssh://dillo.org//sfhome/groups/dillo/htdocs/css_compat > > Edit, hack, test, etc... > hg add foo.html > hg commit > > To publish the changes: > hg push > > This should update the CSS tests on the website. In the beginning > please verify that permissions are ok. It should work > automatically, but well - you know... > > Cheers, > Johannes > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Oct. 11, 2010

Re: project list for sponsoring test period

by Johannes.Hofmann＠gmx.de

On Wed, Oct 06, 2010 at 02:56:32PM -0400, Jorge Arellano Cid wrote: > On Mon, Oct 04, 2010 at 02:16:57PM +0200, Johannes Hofmann wrote: > > On Mon, Oct 04, 2010 at 07:59:45AM -0400, Jorge Arellano Cid wrote: > > > On Sun, Oct 03, 2010 at 09:16:30PM +0200, Johannes Hofmann wrote: > > > > [...] > > > > BTW, what do you think about adding the css_compat/ directory to the > > > > repo (under doc)? That would give us version control and it would > > > > document our progress. > > > > > > Having the test cases visible as HTML from the site is very > > > helpful IMHO. Unfortunately I don't yet know of a way of browsing > > > raw files from hg web interfaces (it may be doable). > > > > For my own website I have > > > > [hooks] > > changegroup = hg up > > > > in the .hgrc. So everytime I push to it, the files are updated. > > We could do the same for the CSS tests. > > Yes, it seems fair enough. > > FWIW, so long we've had the HTML test suite, and the personal > test pages each one of us develops. As you explained, the problem > is how to automate HTML rendering tests. I hesitate to include an > html test-page collection in the tarball because it would grow > bigger and bigger and nobody would apply to test each one > everytime a relevant change is made! :) > > I like the CSS checklist we have because it is sorted by > property and provides test-cases we can reference by URL, and it > lives outside the tarball so its size can grow independently. > > A fast way to check the tests is to provide an image with the > correct rendering in the test page (maybe with an explanation > too). It takes more time to prepare though, and each time you > update the page you have to also update the screenshot. Quite a > burden. > > I don't have a good solution yet. These days I've been working > with Gecko and Dillo. Having the test page showed in both > provides for a "dynamic screenshot" from Gecko. This avoids the > burden of updating the image, with the advantage of showing how > Gecko renders unespecified parts of the SPEC. > > An HTML test-page, with written explanations of what to check > for, and two browsers is the fastest/simplest solution I see so > far. (It also has the advantage of almost anyone being able to do > the test). > > If we have it online (i.e. with http URLs), better, and if we > had some version control it may be what we need. > > > > > > > > Besides that I don't see the benefits of having css_compat/ > > > under version control, and our progress is more or less in the hg > > > log, but I see it can be more tightly coupled with the test case > > > if the extended comment makes a reference to it for instance. > > > Please explain me a bit because it may be I don't see the gains > > > because of lack of knowledge on my side! > > > > Basically I like to do almost everything under version control. Just > > yesterday I almost overwrote your vertical-align.html with my own > > version! > > Also just pushing my changes to dillo.org would be faster than > > copying the files manually. > > Do you have root on dillo.org? If so, you could install mercurial > > and I will set up a repo for the CSS tests. > > We can decide later whether we want to integrate it into the main > > dillo repo or not. > > Not me, but you can ask Andreas Kemnade. > He's our savvy sysadmin. Andreas installed mercurial in dillo.org - thanks Andreas! I have setup a repository for css_compat. So the tests are version controlled now. Here is how it works: Create a clone on your local workstation: hg clone ssh://dillo.org/css_compat . Edit, hack, test, etc... hg add foo.html hg commit To publish the changes: hg push This should update the CSS tests on the website. In the beginning please verify that permissions are ok. It should work automatically, but well - you know... Cheers, Johannes

Oct. 11, 2010

small-caps

by jcid＠dillo.org

On Fri, Oct 08, 2010 at 08:45:21PM +0200, Johannes Hofmann wrote: > On Fri, Oct 08, 2010 at 01:20:16PM -0400, Jorge Arellano Cid wrote: > > On Thu, Oct 07, 2010 at 07:08:31PM +0000, corvid wrote: > > > Jorge wrote: > > > > I had to use mbrtowc() because for some reason utf8decode() > > > > didn't work for me. > > > > > > > > I tried: > > > > > > > > diff -r 686a69055264 dw/fltkviewbase.cc > > > > --- a/dw/fltkviewbase.cc Thu Oct 07 12:09:37 2010 -0400 > > > > +++ b/dw/fltkviewbase.cc Thu Oct 07 12:46:26 2010 -0400 > > > > @@ -27,6 +27,7 @@ > > > > #include <fltk/events.h> > > > > #include <fltk/Cursor.h> > > > > #include <fltk/run.h> > > > > +#include <fltk/utf.h> > > > > > > > > #include <stdio.h> > > > > #include <wchar.h> > > > > @@ -505,7 +506,7 @@ void FltkWidgetView::drawText (core::sty > > > > memset (&st2, '\0', sizeof (mbstate_t)); > > > > for (curr = 0; next < len; curr = next) { > > > > next = theLayout->nextGlyph(text, curr); > > > > - cb = (int)mbrtowc(&wc, text + curr, next - curr, &st1); > > > > + wc = utf8decode(text + curr, text + next - 1, &cb); > > > > if ((wcu = towupper(wc)) == wc) { > > > > /* already uppercase, just draw the character */ > > > > setfont(ff->font, ff->size); > > > > > > > > > > > > @corvid: do you see why? > > > > > > I think the 'end' is supposed to point to the byte past the end. > > > (If so, that would mean that I have a bug that happens to have no effect > > > where html.cc checks for ideographic chars.) > > > > Yes it works with 'end' pointing to 'next' ;) > > > > BTW, misc.c also uses the utf8decode(). > > > > I hesitate on whether to call utf8{de,en}code() directly from > > fltkviewbase.cc and fltkplatform.cc, or to add an API to the > > platform.hh, and implement it in layout.cc as nextGlyph(). The > > first one looks simpler. > > It's ok to call it directly. fltkviewbase.cc is > fltk-dependent anyway. > But we can't call the fltk-based utf8 methods directly from files > in dw/ that don't have the fltk prefix. Done! -- Cheers Jorge.-

Oct. 9, 2010

small-caps

by Johannes.Hofmann＠gmx.de

On Fri, Oct 08, 2010 at 01:20:16PM -0400, Jorge Arellano Cid wrote: > On Thu, Oct 07, 2010 at 07:08:31PM +0000, corvid wrote: > > Jorge wrote: > > > I had to use mbrtowc() because for some reason utf8decode() > > > didn't work for me. > > > > > > I tried: > > > > > > diff -r 686a69055264 dw/fltkviewbase.cc > > > --- a/dw/fltkviewbase.cc Thu Oct 07 12:09:37 2010 -0400 > > > +++ b/dw/fltkviewbase.cc Thu Oct 07 12:46:26 2010 -0400 > > > @@ -27,6 +27,7 @@ > > > #include <fltk/events.h> > > > #include <fltk/Cursor.h> > > > #include <fltk/run.h> > > > +#include <fltk/utf.h> > > > > > > #include <stdio.h> > > > #include <wchar.h> > > > @@ -505,7 +506,7 @@ void FltkWidgetView::drawText (core::sty > > > memset (&st2, '\0', sizeof (mbstate_t)); > > > for (curr = 0; next < len; curr = next) { > > > next = theLayout->nextGlyph(text, curr); > > > - cb = (int)mbrtowc(&wc, text + curr, next - curr, &st1); > > > + wc = utf8decode(text + curr, text + next - 1, &cb); > > > if ((wcu = towupper(wc)) == wc) { > > > /* already uppercase, just draw the character */ > > > setfont(ff->font, ff->size); > > > > > > > > > @corvid: do you see why? > > > > I think the 'end' is supposed to point to the byte past the end. > > (If so, that would mean that I have a bug that happens to have no effect > > where html.cc checks for ideographic chars.) > > Yes it works with 'end' pointing to 'next' ;) > > BTW, misc.c also uses the utf8decode(). > > I hesitate on whether to call utf8{de,en}code() directly from > fltkviewbase.cc and fltkplatform.cc, or to add an API to the > platform.hh, and implement it in layout.cc as nextGlyph(). The > first one looks simpler. It's ok to call it directly. fltkviewbase.cc is fltk-dependent anyway. But we can't call the fltk-based utf8 methods directly from files in dw/ that don't have the fltk prefix. Cheers, Johannes

Oct. 8, 2010

small-caps

by corvid＠lavabit.com

Jorge wrote: > On Thu, Oct 07, 2010 at 07:08:31PM +0000, corvid wrote: > > Jorge wrote: > > > I had to use mbrtowc() because for some reason utf8decode() > > > didn't work for me. > > > > > > I tried: > > > > > > diff -r 686a69055264 dw/fltkviewbase.cc > > > --- a/dw/fltkviewbase.cc Thu Oct 07 12:09:37 2010 -0400 > > > +++ b/dw/fltkviewbase.cc Thu Oct 07 12:46:26 2010 -0400 > > > @@ -27,6 +27,7 @@ > > > #include <fltk/events.h> > > > #include <fltk/Cursor.h> > > > #include <fltk/run.h> > > > +#include <fltk/utf.h> > > > > > > #include <stdio.h> > > > #include <wchar.h> > > > @@ -505,7 +506,7 @@ void FltkWidgetView::drawText (core::sty > > > memset (&st2, '\0', sizeof (mbstate_t)); > > > for (curr = 0; next < len; curr = next) { > > > next = theLayout->nextGlyph(text, curr); > > > - cb = (int)mbrtowc(&wc, text + curr, next - curr, &st1); > > > + wc = utf8decode(text + curr, text + next - 1, &cb); > > > if ((wcu = towupper(wc)) == wc) { > > > /* already uppercase, just draw the character */ > > > setfont(ff->font, ff->size); > > > > > > > > > @corvid: do you see why? > > > > I think the 'end' is supposed to point to the byte past the end. > > (If so, that would mean that I have a bug that happens to have no effect > > where html.cc checks for ideographic chars.) > > Yes it works with 'end' pointing to 'next' ;) > > BTW, misc.c also uses the utf8decode(). > > I hesitate on whether to call utf8{de,en}code() directly from > fltkviewbase.cc and fltkplatform.cc, or to add an API to the > platform.hh, and implement it in layout.cc as nextGlyph(). The > first one looks simpler. > > Definitely what I like about using utf8{de,en}code() is that > there's no need to alter the locale (LC_CTYPE). If it's only used in fltk*, I think I'd call it directly.

Oct. 8, 2010

small-caps

by jcid＠dillo.org

On Thu, Oct 07, 2010 at 07:08:31PM +0000, corvid wrote: > Jorge wrote: > > I had to use mbrtowc() because for some reason utf8decode() > > didn't work for me. > > > > I tried: > > > > diff -r 686a69055264 dw/fltkviewbase.cc > > --- a/dw/fltkviewbase.cc Thu Oct 07 12:09:37 2010 -0400 > > +++ b/dw/fltkviewbase.cc Thu Oct 07 12:46:26 2010 -0400 > > @@ -27,6 +27,7 @@ > > #include <fltk/events.h> > > #include <fltk/Cursor.h> > > #include <fltk/run.h> > > +#include <fltk/utf.h> > > > > #include <stdio.h> > > #include <wchar.h> > > @@ -505,7 +506,7 @@ void FltkWidgetView::drawText (core::sty > > memset (&st2, '\0', sizeof (mbstate_t)); > > for (curr = 0; next < len; curr = next) { > > next = theLayout->nextGlyph(text, curr); > > - cb = (int)mbrtowc(&wc, text + curr, next - curr, &st1); > > + wc = utf8decode(text + curr, text + next - 1, &cb); > > if ((wcu = towupper(wc)) == wc) { > > /* already uppercase, just draw the character */ > > setfont(ff->font, ff->size); > > > > > > @corvid: do you see why? > > I think the 'end' is supposed to point to the byte past the end. > (If so, that would mean that I have a bug that happens to have no effect > where html.cc checks for ideographic chars.) Yes it works with 'end' pointing to 'next' ;) BTW, misc.c also uses the utf8decode(). I hesitate on whether to call utf8{de,en}code() directly from fltkviewbase.cc and fltkplatform.cc, or to add an API to the platform.hh, and implement it in layout.cc as nextGlyph(). The first one looks simpler. Definitely what I like about using utf8{de,en}code() is that there's no need to alter the locale (LC_CTYPE). -- Cheers Jorge.-

Oct. 8, 2010