- Dillo-dev - lists.mailman3.com

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

small-caps

by jcid＠dillo.org

On Fri, Oct 08, 2010 at 12:27:21PM +0000, corvid wrote: > Johannes wrote: > > On Thu, Oct 07, 2010 at 01:13:18PM -0400, Jorge Arellano Cid wrote: > > > Hi, > > > > > > Just committed a patch for CSS' small-caps, > > > http://www.dillo.org/css_compat/tests/font-variant.html > > > > I don't think the letterSpacing value needs to be scaled down in the > > small-caps case. > > corvid, what do you think? > > If letter-spacing were originally specified in pixels or centimeters > or something, then it definitely wouldn't. If it were given in ems, > I'm not sure. > *does the usual "let's see what firefox does"* > It appears that firefox doesn't modify letter-spacing. I tried with ems and FF doesn't touch letter-spacing. Committed a patch to mimic this behaviour. -- Cheers Jorge.-

Oct. 8, 2010

small-caps

by corvid＠lavabit.com

Johannes wrote: > On Thu, Oct 07, 2010 at 01:13:18PM -0400, Jorge Arellano Cid wrote: > > Hi, > > > > Just committed a patch for CSS' small-caps, > > http://www.dillo.org/css_compat/tests/font-variant.html > > I don't think the letterSpacing value needs to be scaled down in the > small-caps case. > corvid, what do you think? If letter-spacing were originally specified in pixels or centimeters or something, then it definitely wouldn't. If it were given in ems, I'm not sure. *does the usual "let's see what firefox does"* It appears that firefox doesn't modify letter-spacing.

Oct. 8, 2010

small-caps

by Johannes.Hofmann＠gmx.de

On Thu, Oct 07, 2010 at 01:13:18PM -0400, Jorge Arellano Cid wrote: > Hi, > > Just committed a patch for CSS' small-caps, > http://www.dillo.org/css_compat/tests/font-variant.html I don't think the letterSpacing value needs to be scaled down in the small-caps case. corvid, what do you think? Cheers, Johannes

Oct. 8, 2010