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

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

Re: project list for sponsoring test period

by jcid＠dillo.org

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. > > OTOH, yes, I see dillo would be in better shape test-wise if we > > could include an [automated] test framework in the tarball. This > > wasn't done because it takes some time and needs manpower we > > didn't have. > > At "Henning's company" we are also thinking about automated tests > for dillo. > My current idea is to create a new view, that writes text that can > easily be compared with expected results. That would be more flexible > than to compare bitmaps of rendered output, which might give to many > false positves. > If this works out we can think about integrating the framework into > dillo mainline, but currently it's just an idea. I have some automated tests too (e.g. URL resolver), but rendering is a different beast. That's my thoughts. -- Cheers Jorge.-

Oct. 6, 2010

A Dillo-Win32 update

by obeythepenguin＠gmail.com

On 10/4/10, Johannes Hofmann <Johannes.Hofmann(a)gmx.de> wrote: > On Sat, Oct 02, 2010 at 06:00:54PM -0400, Benjamin Johnson wrote: >> I don't think basic functionality like local file browsing and HTTPS >> is unnecessary "load in every dillo code". If there's any situation >> where it's undesired, perhaps the code could be #ifdef'd out and a >> new autoconf option added (--disable-local-files, etc.) > > We already agreed quite some time ago on dillo-dev, that HTTPS > support could be integrated into the main dillo binary if that would > help to create proper HTTPS support. > For the current highly experimental HTTPS stuff DPI seems the right > place. Fair enough -- but local file browsing? Does that seriously bloat the browser so much it has to be implemented as an external service? That's something I'd expect *any* browser (or similar program) to have built-in. >> As far as sharing bookmarks, cookies, etc. between browser >> processes: most major browsers (IE, Firefox, Opera, probably Chrome) >> allow one browser process running, and if a second is started, it >> signals the first to take some action (create a new window, for >> instance). That would still require some amount of IPC, but it's >> less complicated than DPI, and certainly less wasteful since you >> don't have multiple instances loading the same UI, static libraries, >> etc. > > Notifying an already open browser instance instead of creating a new > process is just a workaround needed because of the long startup > times of today's browsers. I can see I'm not likely to win this one, so I suppose I'll drop it. At any rate, I did just think of a possible way to (re)implement DPI, using a dsock-like wrapper that hooks into the Windows messaging system. I *think* fltk can expose a window's internal handle, which is the main thing you'd need. Anyway, I'll get back to you once I've done a bit more research, and in the mean time, I'll try to split up that patch. I can think of worse ways to kill three hours... :-) Cheers, ~Benjamin

Oct. 4, 2010

A Dillo-Win32 update

by Johannes.Hofmann＠gmx.de

On Sat, Oct 02, 2010 at 06:00:54PM -0400, Benjamin Johnson wrote: > On Sat, 02 Oct 2010 17:31:07 -0400, Diego . > <darkspirit5000(a)gmail.com> wrote: > > >Your solution only works for downloads. Your downloader can be made a > >DPI and you can chose wich to use. Actually downloads do not stop if > >dillo close. > > I'm well aware how DPI is implemented, and that downloads continue > when Dillo is exited. My solution is intended in part as a > temporary measure, since I need downloads to function regardless of > whether DPI is available or not. I do have concerns, however, with > both the specific implementation and general (perceived) necessity > of DPI. > > >If the problems are dup2 and sockets dpid can be change to work on > >windows. > >Dillo always ask the dpi that serves a service before conect to it. > >dpid run the DPI so can send dillo the right fd, socket, file or do > >other thing. > > I've been working on that, but with very limited success. dup2 and > sockets are the most immediate problem, but there are larger > problems beyond that (for example, packaging Dillo/DPI). > > >dpid avoid to load in every dillo code to handle DPIs or external > >programs that will use only one and avoid the synchronize thing. > > I don't think basic functionality like local file browsing and HTTPS > is unnecessary "load in every dillo code". If there's any situation > where it's undesired, perhaps the code could be #ifdef'd out and a > new autoconf option added (--disable-local-files, etc.) We already agreed quite some time ago on dillo-dev, that HTTPS support could be integrated into the main dillo binary if that would help to create proper HTTPS support. For the current highly experimental HTTPS stuff DPI seems the right place. > > As far as sharing bookmarks, cookies, etc. between browser > processes: most major browsers (IE, Firefox, Opera, probably Chrome) > allow one browser process running, and if a second is started, it > signals the first to take some action (create a new window, for > instance). That would still require some amount of IPC, but it's > less complicated than DPI, and certainly less wasteful since you > don't have multiple instances loading the same UI, static libraries, > etc. Notifying an already open browser instance instead of creating a new process is just a workaround needed because of the long startup times of today's browsers. Cheers, Johannes

Oct. 4, 2010

A Dillo-Win32 update

by obeythepenguin＠gmail.com

On Sun, 03 Oct 2010 16:22:27 -0400, Johannes Hofmann <Johannes.Hofmann(a)gmx.de> wrote: > I doubt that libcurl would be an option, but as I said, feel free to > experiment. > > Cheers, > Johannes The idea would be to provide libcurl as an *alternative to* Dillo's implementation, not a replacement for it. Cheers, ~Benjamin

Oct. 3, 2010

A Dillo-Win32 update

by Johannes.Hofmann＠gmx.de

On Sun, Oct 03, 2010 at 03:13:51PM -0400, Benjamin Johnson wrote: > On Sun, 03 Oct 2010 14:36:14 -0400, Johannes Hofmann > <Johannes.Hofmann(a)gmx.de> wrote: > > >Do you plan to get the windows port into dillo mainline, or do you > >want to maintain it as a patch? > > Getting it into Dillo mainline was always my intention. I do plan > to maintain the SourceForge site for binary releases and other > Windows-specific components, similar to GIMP for Windows. > > >If you plan to get it in, I would suggest to focus on getting in > >what you have before doing other stuff. > > I'm just trying to look ahead, that's all. > > In a nutshell, I'm faced with some difficult technical hurdles, and > somewhat a conflict of interests. On the one hand, I personally am > not fond of DPI, and (as you've seen) question its necessity, > particularly for such basic functionality as non-HTTP protocol > support. On the other, my goal is (and has always been) to get my > code into Dillo mainline, since I have neither the interest nor > resources to maintain a full-blown fork. > > >That would mean: > > > >* splitting up your patch into smaller chunks, > > each with a description of what it does and why it's needed. > > It should be obvious for each patch that it does what you > > described and only that. > > I tried to do that already. The problem is that this is a very > complicated patch, and all the individual "subpatches" are highly > interdependent on one another. In order to effectively split the > patch, I would essentially have to re-code each change manually, > which I currently lack the time to do. That's fine, but I fear nobody else will do the work for you. > > >* Avoid any changes to the code base that are not necessary for the > > windows port (e.g. the include path changes in src/table.cc, or > > the fix for the race mentioned in html.cc - if you think there is a > > bug, this should be discussed on the list independent from the win > > port. The same for the change in decode.c). > > I have not made a single change that is not necessary for the > Windows port. The include path changes are necessary because MinGW > does not accept them as written (relative to the top-level source > directory). Regarding the race condition, that already *has* been > discussed on the list, and the fix was specifically necessary for > the Windows port: > > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2010-August/007652.html I have missed that. But I still fail to see why we should need to wait until there is no more connection open - that could take ages. > > >* This iowatch kludge is nasty - as you also state in the > > comment. This must be fixed in some other way. Did you do some > > research on the fltk lists about this? Is this solved in fltk-1.3? > > Yes, I did do research on the fltk lists -- that's how I discovered > its necessity. To wit: > > http://www.mail-archive.com/fltk-bugs@easysw.com/msg01341.html > > Unfortunately, WSAAsyncSelect() doesn't appear to be the only > problem. I patched the fltk source to disable USE_ASYNC_SELECT, to > no avail. That's when I decided to implement the timeout kludge, in > the interest of having *something* working, which I considered > better than having nothing at all. The bug is marked as resolved for fltk-1.3. I'd suggest to write a test program to check whether it works as you expect in fltk-1.3. > > I dislike the timeout kludge as well, since it's slow and extremely > unstable, but as of yet have not found a workable alternative > considering the current implementation. I haven't been able to dig > further into fltk itself, due to lack of time and familiarity with > the codebase (though I intend to someday, as there are some other > things in there that need work, like popup menus on Windows 95). > > By the way, this is one reason I was interested in an alternate > implementation using libcurl -- it would be much simpler than trying > to implement low-level, cross-platform I/O ourselves. I doubt that libcurl would be an option, but as I said, feel free to experiment. Cheers, Johannes

Oct. 3, 2010