- Dillo-dev - lists.mailman3.com

weird font

by Johannes.Hofmann＠gmx.de

On Wed, Nov 11, 2009 at 12:35:49PM -0300, Jorge Arellano Cid wrote: > On Tue, Nov 10, 2009 at 11:06:30PM +0100, Johannes Hofmann wrote: > > Hi Jorge, > > > > On Tue, Nov 10, 2009 at 06:46:45PM -0300, Jorge Arellano Cid wrote: > > > Hi, > > > > > > On some sites I get weird fonts. Today I got to isolate the > > > problem. See attached file. Here it displays like this: > > > > > > http://www.dillo.org/test/xmp2.png > > > > > > The embedded CSS says: > > > > > > pre { font-family: MS Courier New, Courier, monospace; } > > > > > > If I remove "MS Courier New", it works OK. > > > Any clues? > > > > There are multiple issues with font selection: > > > > * The CSS parser only returns the part until the first blank > > ('MS' in this case). > > * StyleEngine currently does not handle comma separated font name > > lists (see \todo comment). > > * ::fltk::font(name, fa); in fltkplatform.cc does not offer a way to > > determine whether a font with that name actually exists on the > > system. Instead if no exact match can be found, it guesses a > > replacement font. This makes it impossible for dillo to choose the > > right one from a given list. > > > > In your specific case, fltk gets the string 'MS' and on your system > > it seems to find some funny font that has a similar name. > > Thanks for the detailed explanation. I just committed a fix for the first two issues. This should also fix your problem. It still does not test all font names in the list as I don't know how to do that with fltk2, but it's a step in the right direction. Cheers, Johannes

Nov. 15, 2009

Q: why do we defer loading linked stylesheets?

by corvid＠lavabit.com

Johannes wrote: > On Sat, Nov 14, 2009 at 10:16:07AM +0000, Jeremy Henty wrote: > > On Fri, Nov 13, 2009 at 08:05:05AM +0000, corvid wrote: > > > Jeremy wrote: > > > > Why do we defer loading the CSS stylesheets named in <link> > > > > elements until the <head> element is closed? In html.cc, > > > > Html_tag_close_head() has the comment "charset is already set, > > > > load remote stylesheets now", but I don't understand the > > > > significance of the charset. > > > > > > > > [...] > > > > > > It looks like it dates to > > > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2009-February/005870.html > > > > Yuk! So what should we do if the <head> includes a <style> element > > that @imports a style sheet? Defer loading that stylesheet until the > > end of the <head>? Maybe defer parsing the entire <style> element? > > Shouldn't we treat all the style information in the same way? It > > seems to me that currently we don't. (Mind you, I'm not familiar with > > these charset and reepush issues so I'm probably missing something.) > > I don't remember all the details, but the basic idea is to defer the > repush (not the loading), so we repush - and as a consequence > redraw - the page just once. > So in your example with an @import directive in the <style> element > body, we would parse it if it is readily available in the cache. But > if not, we continue rendering without it. Then, once <head> is > closed and all requested style sheets are in cache, we repush the > page and restart parsing from start. > There is still a chance that during that repush we find a new > style sheet to be loaded due to a @import in one of the style sheets > we had not examined yet. That seems to be an inherent problem of the > @import thing in general. Speaking of repush, I see that there's another bug about auth and segfaults in the bug tracker. (At least the Tim crash had to do with repush, as I recall.)

Nov. 14, 2009

Q: why do we defer loading linked stylesheets?

by Johannes.Hofmann＠gmx.de

On Sat, Nov 14, 2009 at 10:16:07AM +0000, Jeremy Henty wrote: > On Fri, Nov 13, 2009 at 08:05:05AM +0000, corvid wrote: > > Jeremy wrote: > > > Why do we defer loading the CSS stylesheets named in <link> > > > elements until the <head> element is closed? In html.cc, > > > Html_tag_close_head() has the comment "charset is already set, > > > load remote stylesheets now", but I don't understand the > > > significance of the charset. > > > > > > [...] > > > > It looks like it dates to > > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2009-February/005870.html > > Yuk! So what should we do if the <head> includes a <style> element > that @imports a style sheet? Defer loading that stylesheet until the > end of the <head>? Maybe defer parsing the entire <style> element? > Shouldn't we treat all the style information in the same way? It > seems to me that currently we don't. (Mind you, I'm not familiar with > these charset and reepush issues so I'm probably missing something.) I don't remember all the details, but the basic idea is to defer the repush (not the loading), so we repush - and as a consequence redraw - the page just once. So in your example with an @import directive in the <style> element body, we would parse it if it is readily available in the cache. But if not, we continue rendering without it. Then, once <head> is closed and all requested style sheets are in cache, we repush the page and restart parsing from start. There is still a chance that during that repush we find a new style sheet to be loaded due to a @import in one of the style sheets we had not examined yet. That seems to be an inherent problem of the @import thing in general. Cheers, Johannes

Nov. 14, 2009

Q: why do we defer loading linked stylesheets?

by onepoint＠starurchin.org

On Fri, Nov 13, 2009 at 08:05:05AM +0000, corvid wrote: > Jeremy wrote: > > Why do we defer loading the CSS stylesheets named in <link> > > elements until the <head> element is closed? In html.cc, > > Html_tag_close_head() has the comment "charset is already set, > > load remote stylesheets now", but I don't understand the > > significance of the charset. > > > > [...] > > It looks like it dates to > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2009-February/005870.html Yuk! So what should we do if the <head> includes a <style> element that @imports a style sheet? Defer loading that stylesheet until the end of the <head>? Maybe defer parsing the entire <style> element? Shouldn't we treat all the style information in the same way? It seems to me that currently we don't. (Mind you, I'm not familiar with these charset and reepush issues so I'm probably missing something.) Regards, Jeremy Henty

Nov. 14, 2009

Q: why do we defer loading linked stylesheets?

by corvid＠lavabit.com

Jeremy wrote: > Why do we defer loading the CSS stylesheets named in <link> elements > until the <head> element is closed? In html.cc, Html_tag_close_head() > has the comment "charset is already set, load remote stylesheets now", > but I don't understand the significance of the charset. > > I am asking because I'd like to patch Dillo to add @import-ed > stylesheets to the browser window popup menu, just as it already does > for <link>-ed stylesheets. At the moment this causes all sorts of > code branches (is the @import in a <link>-ed file or an embedded > <style>, if the latter, is it in the <head> or not). It would be much > simpler to just immediately load every style file at the same time as > it is added to html->ccsUrls , but that would change the behaviour to > load <link>-ed styles immediately instead of at the end of the <head> > element. Would that break anything? It looks like it dates to http://lists.auriga.wearlab.de/pipermail/dillo-dev/2009-February/005870.html

Nov. 13, 2009

Q: why do we defer loading linked stylesheets?

by onepoint＠starurchin.org

Why do we defer loading the CSS stylesheets named in <link> elements until the <head> element is closed? In html.cc, Html_tag_close_head() has the comment "charset is already set, load remote stylesheets now", but I don't understand the significance of the charset. I am asking because I'd like to patch Dillo to add @import-ed stylesheets to the browser window popup menu, just as it already does for <link>-ed stylesheets. At the moment this causes all sorts of code branches (is the @import in a <link>-ed file or an embedded <style>, if the latter, is it in the <head> or not). It would be much simpler to just immediately load every style file at the same time as it is added to html->ccsUrls , but that would change the behaviour to load <link>-ed styles immediately instead of at the end of the <head> element. Would that break anything? Regards, Jeremy Henty

Nov. 13, 2009

EAGAIN loop in IO_read

by jcid＠dillo.org

On Thu, Nov 12, 2009 at 09:01:03PM +0900, furaisanjin wrote: > This misleads, so I clarify. > > 2009/11/12 furaisanjin <furaisanjin(a)gmail.com>: > > > I have no idea but the problem did happen in one hour but now it's > > very difficult to make it happen. > > I haven't seen it since I applied the patch. Thanks, it's good to hear that! ;) -- Cheers Jorge.-

Nov. 12, 2009

EAGAIN loop in IO_read

by furaisanjin＠gmail.com

This misleads, so I clarify. 2009/11/12 furaisanjin <furaisanjin(a)gmail.com>: > I have no idea but the problem did happen in one hour but now it's > very difficult to make it happen. I haven't seen it since I applied the patch. Regards, furaisanjin

Nov. 12, 2009

EAGAIN loop in IO_read

by furaisanjin＠gmail.com

2009/11/12 Jorge Arellano Cid <jcid(a)dillo.org>: > On Thu, Nov 12, 2009 at 07:54:25AM +0900, furaisanjin wrote: >> Hi. >> >> My problem also seems to be fixed because it's very harder to >> reproduce the problem now. > > ?Is still possible to trigger the problem (but very hard)? I have no idea but the problem did happen in one hour but now it's very difficult to make it happen. >> By the way, I'm a bit wondering this code >> and I suppose something like this. >> >> --- dillo/src/IO/dpi.c ?2009-11-11 05:51:28.000000000 +0900 >> +++ dillo-test/src/IO/dpi.c ? ? 2009-11-11 22:05:42.000000000 +0900 >> @@ -793,12 +793,15 @@ char *a_Dpi_send_blocking_cmd(const char >> >> ? ? if ((sock_fd = Dpi_connect_socket(server_name, TRUE)) == -1) { >> ? ? ? ?MSG_ERR("[a_Dpi_send_blocking_cmd] Can't connect to server.\n"); >> - ? } else if (Dpi_blocking_write(sock_fd, cmd, strlen(cmd)) == -1) { >> - ? ? ?MSG_ERR("[a_Dpi_send_blocking_cmd] Can't send message.\n"); >> - ? } if ((ret = Dpi_blocking_read(sock_fd)) == NULL) { >> - ? ? ?MSG_ERR("[a_Dpi_send_blocking_cmd] Can't read message.\n"); >> + ? } else { >> + ? ? if (Dpi_blocking_write(sock_fd, cmd, strlen(cmd)) == -1) { >> + ? ? ? MSG_ERR("[a_Dpi_send_blocking_cmd] Can't send message.\n"); >> + ? ? } >> + ? ? if ((ret = Dpi_blocking_read(sock_fd)) == NULL) { >> + ? ? ? MSG_ERR("[a_Dpi_send_blocking_cmd] Can't read message.\n"); >> + ? ? } >> + ? ? Dpi_close_fd(sock_fd); >> ? ? } >> - ? Dpi_close_fd(sock_fd); > > ?Dpi_close_fd() checks fd != -1 so AFAIS it's OK. I meant Dpi_blocking_read as well. Regards, furaisanjin

Nov. 12, 2009

modify bookmarks (Re: [Dillo-dev] EAGAIN loop in IO_read)

by corvid＠lavabit.com

Jorge wrote: > On Thu, Nov 12, 2009 at 12:08:33AM +0000, corvid wrote: > > Jorge wrote: > > > BTW, I chasing a very weird bug here. I can't modify a bookmark > > > unless I comment closing a stream on an unrelated file! > > > > > > This is: > > > > > > @@ -417,8 +417,10 @@ static int Dpi_read_comm_keys(int *port) > > > SharedKey[i] = 0; > > > ret = 1; > > > } > > > - if (In) > > > - fclose(In); > > > > > > > > > Then it works! :-P > > > > > > @all: The question is, is this happening only in my system or do you > > > see the problem as well. In other words: can you modify a bookmark? > > > > I don't normally use bookmarks, but if I try it, I click submit, get > > Nav_open_url: new url='dpi:/bm/modify?operation=modify&submit=submit.&s0=on&url1=on' > > Nav_open_url: new url='dpi:/bm/modify' > > > > and...nothing else seems to happen. > > Exactly as here... > > and if you apply the above patch? Yup, I get a new page for updating the title.

Nov. 12, 2009