- Dillo-dev - lists.mailman3.com

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

small-caps

by corvid＠lavabit.com

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

Oct. 7, 2010

small-caps

by jcid＠dillo.org

Hi, Just committed a patch for CSS' small-caps, http://www.dillo.org/css_compat/tests/font-variant.html 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? -- Cheers Jorge.-

Oct. 7, 2010