- Dillo-dev - lists.mailman3.com

[bug]: ignored CSS attributes on html element

by Johannes.Hofmann＠gmx.de

On Tue, Sep 14, 2010 at 07:26:53PM +0100, Jeremy Henty wrote: > On Mon, Sep 13, 2010 at 03:54:22PM -0400, Benjamin Johnson wrote: > > On Mon, 13 Sep 2010 15:42:17 -0400, Johannes Hofmann > > <Johannes.Hofmann(a)gmx.de> wrote: > > > > >Hm, I've never seen the "text" property in CSS, can you point me to > > >the place where it is documented? > > >Also in http://www.penny-arcade.com/2010/9/10/ I can't find the > > >string "text:" neither in the source nor in the stylesheet - am I > > >missing something? > > > > I'm guessing it's just a typo for "color". > > Yes, you're right. I'm bewildered as to how I could have messed that > up. But anyway, dillo ignores the "color" attribute on the html > element (as easily seen by changing "text" to "color" in the example I > gave and then experimenting with changing between "html" and "body"). > So, how to fix this? Please test attached patch. It is a bit more involved than I had hoped, but it seems necessary after looking at the spec. Regards, Johannes

Sept. 17, 2010

[bug]: ignored CSS attributes on html element

by Johannes.Hofmann＠gmx.de

On Tue, Sep 14, 2010 at 03:27:25PM -0400, Benjamin Johnson wrote: > On Tue, 14 Sep 2010 14:54:19 -0400, Johannes Hofmann > <Johannes.Hofmann(a)gmx.de> wrote: > > >It took me a while to find out, but the reason is rather simple: > > > >The <html> is opened before the style is loaded (it's in <head> > >after all). So at the time we call startElement() for <html>, we > >don't have the style information. > > > >I didn't find anything in the CSS reference how to handle this case, > >but major browsers seem to allow CSS for the html-element. > > > >We could somehow delay the startElement() call for <html> until > ><head> is parsed completely, but I have to look for a way to make > >this hack not too ugly... Suggestions welcome :-) > > > >Cheers, > >Johannes > > Maybe treat it, for CSS purposes, like a second <body> tag? i.e. > rather than delay startElement(), map CSS attributes assigned to > "html" to some pseudo-element parsed just before <body>. > > That might be a really stupid idea, but it makes sense to me since > that's how <html> usually behaves, CSS-wise. For example, on my own > sites I use something like > > html { > background: #202020; > color: #202020; > } > > body { > background: white; > width: 6in; > margin: 2em auto 2em auto; > padding: 1em 4em 1em 4em; > border: 2px solid black; > } > > to display the body as a white box against a black background. Ok it is defined here: http://www.w3.org/TR/CSS2/colors.html They say "we recommend that authors specify the background for the BODY element rather than the HTML element", but I guess we still have to support it for <html> as well. Johannes

Sept. 17, 2010

[patch]: do not require Html_process_word()s argument to be null-terminated

by Johannes.Hofmann＠gmx.de

On Wed, Sep 15, 2010 at 09:24:58PM +0100, Jeremy Henty wrote: > > Johannes Hofmann wrote: > > > I don't have a solution yet, but I envision something, where e.g. > > Html_write_raw() or DilloHtml::write() works with a const buf and > > buflen (no null-termination required), but non-terminated buffers > > don't leak into lower-layer functions (like Html_process_space(), or > > Html_process_word()). > > In that case, whenever a "high-layer" function like Html_write_raw() > calls a lower-layer function it will have to either poke in a null > byte (as Html_write_raw() does now) or copy a segment of its buffer > into a new null-terminated buffer. If you want the original buffer to > be const then it can't poke in a null, so it will have to copy. > Unless there's a third way, but I can't see one. As I said, I don't have any good idea either. So maybe what we currently have is a good compromise - I don't know. Also I won't invest much time as there are is no real need to change things. > > Would you consider all the Html_tag_open_*() functions to be > lower-layer too? If so then it would be natural (as I understand your > suggestion) for them to lose their length arguments. Is that right? > And presumably Html_get_{attr,attr2}() also? The more I think about > this the more functions in html.cc I think it might affect. Maybe we > could clone a new repository to experiment with? I would leave them as they are but feel free to experiment. Having a cloned repo for experimenting is always a good idea. I have a clone for every non-trivial thing I do. Regards, Johannes

Sept. 17, 2010

[patch]: do not require Html_process_word()s argument to be null-terminated

by onepoint＠starurchin.org

Johannes Hofmann wrote: > I don't have a solution yet, but I envision something, where e.g. > Html_write_raw() or DilloHtml::write() works with a const buf and > buflen (no null-termination required), but non-terminated buffers > don't leak into lower-layer functions (like Html_process_space(), or > Html_process_word()). In that case, whenever a "high-layer" function like Html_write_raw() calls a lower-layer function it will have to either poke in a null byte (as Html_write_raw() does now) or copy a segment of its buffer into a new null-terminated buffer. If you want the original buffer to be const then it can't poke in a null, so it will have to copy. Unless there's a third way, but I can't see one. Would you consider all the Html_tag_open_*() functions to be lower-layer too? If so then it would be natural (as I understand your suggestion) for them to lose their length arguments. Is that right? And presumably Html_get_{attr,attr2}() also? The more I think about this the more functions in html.cc I think it might affect. Maybe we could clone a new repository to experiment with? Regards, Jeremy Henty

Sept. 15, 2010

[patch]: do not require Html_process_word()s argument to be null-terminated

by Johannes.Hofmann＠gmx.de

On Wed, Sep 15, 2010 at 07:45:06AM +0100, Jeremy Henty wrote: > > Just to clarify, I wasn't expecting any speed-up from this, it was > just a cleanup patch. I accept the point about the dangers of fragile > APIs in general, but I don't find it very compelling in this > particular case. Html_process_word() is called from only one place, > and it's caller has to hack its around the entirely unnecessary > requirement that the argument be null-terminated. I don't see that > any API is damaged just by cleaning up this particular function call. First I have to say that I agree with Jorge. Working with non NULL-terminated buffers is extremly ugly and error prone. The reason is that when using length based variants of the standard string routines (e.g. strncmp() ...) you always have to recompute the length relative to your current position in the buffer. With null-terminated strings no matter where you are in the string it will still be properly terminated. On the other hand I'd also like to see Html_write_raw() to work on a const-buffer and even drop the requirement that it's buf parameter needs to be null-terminated (which is not addressed in your patch atm). The reason is that currently we pass a buflen and _also_ require buf to be null-terminated. That's rather confusing. I don't have a solution yet, but I envision something, where e.g. Html_write_raw() or DilloHtml::write() works with a const buf and buflen (no null-termination required), but non-terminated buffers don't leak into lower-layer functions (like Html_process_space(), or Html_process_word()). Also, as there is no pressing need we should be extremely careful and think twice before changing things. Regards, Johannes

Sept. 15, 2010

[patch]: do not require Html_process_word()s argument to be null-terminated

by onepoint＠starurchin.org

Just to clarify, I wasn't expecting any speed-up from this, it was just a cleanup patch. I accept the point about the dangers of fragile APIs in general, but I don't find it very compelling in this particular case. Html_process_word() is called from only one place, and it's caller has to hack its around the entirely unnecessary requirement that the argument be null-terminated. I don't see that any API is damaged just by cleaning up this particular function call. Regards, Jeremy Henty

Sept. 15, 2010

Segmentation fault on startup

by jameslovejoy＠tiscali.co.uk

I can confirm that dillo runs successfully with fltk compiled with --disable-xft Thanks! On 14 Sep 2010, at 07:01, James Lovejoy <jameslovejoy(a)tiscali.co.uk> wrote: > Mostly I'm just doing this for educational purposes and I'll just sort of learn as I go along. From what you have told me I can pretty much say that the target system does not have fontconfig on it (I don't ever remember installing it). I will 1. Install it 2. Try fltk without xft. > > On 13 Sep 2010, at 21:23, "Benjamin Johnson" <obeythepenguin(a)gmail.com> wrote: > >> On Mon, 13 Sep 2010 15:49:39 -0400, James Lovejoy <jameslovejoy(a)tiscali.co.uk> wrote: >> >>> Where should fonts.confirm be and how can I make sure fontconfig is installed. >> >> Not meaning this personally, but are you *sure* you're experienced enough to roll your own distro? I used to do that kind of work myself, and two things you really need to know are (1) what every package on the system does, at least in very general terms; and (2) how to work with the base system's tools (package management, etc.) >> >> I believe fonts.conf is in /etc/fonts.d/ or /etc/fontconfig/ or some similar location; you should be able to find it using >> find /etc -name fonts.conf >> >> As far as checking if fontconfig is installed, see if you have /usr/bin/fc-cache or /usr/lib/libfontconfig* on your system. The easiest way to check for a package in general is to use your system's package management tools, but unfortunately I'm not that familiar with dkpg -- I've always used Slackware-based systems myself. >> >> ~Benjamin >> >> _______________________________________________ >> Dillo-dev mailing list >> Dillo-dev(a)dillo.org >> http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Sept. 14, 2010

[bug]: ignored CSS attributes on html element

by obeythepenguin＠gmail.com

On Tue, 14 Sep 2010 14:54:19 -0400, Johannes Hofmann <Johannes.Hofmann(a)gmx.de> wrote: > It took me a while to find out, but the reason is rather simple: > > The <html> is opened before the style is loaded (it's in <head> > after all). So at the time we call startElement() for <html>, we > don't have the style information. > > I didn't find anything in the CSS reference how to handle this case, > but major browsers seem to allow CSS for the html-element. > > We could somehow delay the startElement() call for <html> until > <head> is parsed completely, but I have to look for a way to make > this hack not too ugly... Suggestions welcome :-) > > Cheers, > Johannes Maybe treat it, for CSS purposes, like a second <body> tag? i.e. rather than delay startElement(), map CSS attributes assigned to "html" to some pseudo-element parsed just before <body>. That might be a really stupid idea, but it makes sense to me since that's how <html> usually behaves, CSS-wise. For example, on my own sites I use something like html { background: #202020; color: #202020; } body { background: white; width: 6in; margin: 2em auto 2em auto; padding: 1em 4em 1em 4em; border: 2px solid black; } to display the body as a white box against a black background. ~Benjamin

Sept. 14, 2010

[bug]: ignored CSS attributes on html element

by Johannes.Hofmann＠gmx.de

On Tue, Sep 14, 2010 at 07:26:53PM +0100, Jeremy Henty wrote: > On Mon, Sep 13, 2010 at 03:54:22PM -0400, Benjamin Johnson wrote: > > On Mon, 13 Sep 2010 15:42:17 -0400, Johannes Hofmann > > <Johannes.Hofmann(a)gmx.de> wrote: > > > > >Hm, I've never seen the "text" property in CSS, can you point me to > > >the place where it is documented? > > >Also in http://www.penny-arcade.com/2010/9/10/ I can't find the > > >string "text:" neither in the source nor in the stylesheet - am I > > >missing something? > > > > I'm guessing it's just a typo for "color". > > Yes, you're right. I'm bewildered as to how I could have messed that > up. But anyway, dillo ignores the "color" attribute on the html > element (as easily seen by changing "text" to "color" in the example I > gave and then experimenting with changing between "html" and "body"). > So, how to fix this? It took me a while to find out, but the reason is rather simple: The <html> is opened before the style is loaded (it's in <head> after all). So at the time we call startElement() for <html>, we don't have the style information. I didn't find anything in the CSS reference how to handle this case, but major browsers seem to allow CSS for the html-element. We could somehow delay the startElement() call for <html> until <head> is parsed completely, but I have to look for a way to make this hack not too ugly... Suggestions welcome :-) Cheers, Johannes > > Regards, > > Jeremy Henty > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Sept. 14, 2010

[bug]: ignored CSS attributes on html element

by onepoint＠starurchin.org

On Mon, Sep 13, 2010 at 03:54:22PM -0400, Benjamin Johnson wrote: > On Mon, 13 Sep 2010 15:42:17 -0400, Johannes Hofmann > <Johannes.Hofmann(a)gmx.de> wrote: > > >Hm, I've never seen the "text" property in CSS, can you point me to > >the place where it is documented? > >Also in http://www.penny-arcade.com/2010/9/10/ I can't find the > >string "text:" neither in the source nor in the stylesheet - am I > >missing something? > > I'm guessing it's just a typo for "color". Yes, you're right. I'm bewildered as to how I could have messed that up. But anyway, dillo ignores the "color" attribute on the html element (as easily seen by changing "text" to "color" in the example I gave and then experimenting with changing between "html" and "body"). So, how to fix this? Regards, Jeremy Henty

Sept. 14, 2010

Segmentation fault on startup

by jameslovejoy＠tiscali.co.uk

Mostly I'm just doing this for educational purposes and I'll just sort of learn as I go along. From what you have told me I can pretty much say that the target system does not have fontconfig on it (I don't ever remember installing it). I will 1. Install it 2. Try fltk without xft. On 13 Sep 2010, at 21:23, "Benjamin Johnson" <obeythepenguin(a)gmail.com> wrote: > On Mon, 13 Sep 2010 15:49:39 -0400, James Lovejoy <jameslovejoy(a)tiscali.co.uk> wrote: > >> Where should fonts.confirm be and how can I make sure fontconfig is installed. > > Not meaning this personally, but are you *sure* you're experienced enough to roll your own distro? I used to do that kind of work myself, and two things you really need to know are (1) what every package on the system does, at least in very general terms; and (2) how to work with the base system's tools (package management, etc.) > > I believe fonts.conf is in /etc/fonts.d/ or /etc/fontconfig/ or some similar location; you should be able to find it using > find /etc -name fonts.conf > > As far as checking if fontconfig is installed, see if you have /usr/bin/fc-cache or /usr/lib/libfontconfig* on your system. The easiest way to check for a package in general is to use your system's package management tools, but unfortunately I'm not that familiar with dkpg -- I've always used Slackware-based systems myself. > > ~Benjamin > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Sept. 14, 2010

Segmentation fault on startup

by obeythepenguin＠gmail.com

On Mon, 13 Sep 2010 15:49:39 -0400, James Lovejoy <jameslovejoy(a)tiscali.co.uk> wrote: > Where should fonts.confirm be and how can I make sure fontconfig is > installed. Not meaning this personally, but are you *sure* you're experienced enough to roll your own distro? I used to do that kind of work myself, and two things you really need to know are (1) what every package on the system does, at least in very general terms; and (2) how to work with the base system's tools (package management, etc.) I believe fonts.conf is in /etc/fonts.d/ or /etc/fontconfig/ or some similar location; you should be able to find it using find /etc -name fonts.conf As far as checking if fontconfig is installed, see if you have /usr/bin/fc-cache or /usr/lib/libfontconfig* on your system. The easiest way to check for a package in general is to use your system's package management tools, but unfortunately I'm not that familiar with dkpg -- I've always used Slackware-based systems myself. ~Benjamin

Sept. 13, 2010

Segmentation fault on startup

by jameslovejoy＠tiscali.co.uk

Where should fonts.confirm be and how can I make sure fontconfig is installed. On 13 Sep 2010, at 20:34, "corvid" <corvid(a)lavabit.com> wrote: > James wrote: >> If you check my prior email I have included an updated backtrace. On further examination of the source it looks to me like fltk is trying to hardcode my fonts?!? > > To the best of my knowledge, fltk::HELVETICA, COURIER, TIMES, etc., actually > meant Helvetica, Courier, Times, etc., with the old font system, > but with xft, they just mean sans, mono, serif, etc. > > And then in the fontconfig files, sans and friends are set > to some specific font (e.g., looking quickly in mine, it seems that > fonts.conf makes sans an alias for sans-serif, and then conf.d is full > of files that specify that, for the sans-serif family, here are a bunch > of specific font families in order of preference...). > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Sept. 13, 2010

[bug]: ignored CSS attributes on html element

by obeythepenguin＠gmail.com

On Mon, 13 Sep 2010 15:42:17 -0400, Johannes Hofmann <Johannes.Hofmann(a)gmx.de> wrote: > Hi, > Hm, I've never seen the "text" property in CSS, can you point me to > the place where it is documented? > Also in http://www.penny-arcade.com/2010/9/10/ I can't find the > string "text:" neither in the source nor in the stylesheet - am I > missing something? > > Regards, > Johannes I'm guessing it's just a typo for "color". ~Benjamin

Sept. 13, 2010

[bug]: ignored CSS attributes on html element

by Johannes.Hofmann＠gmx.de

Hi, On Sun, Sep 12, 2010 at 10:26:29PM +0100, Jeremy Henty wrote: > > Penny Arcade is illegible in Dillo[1]. The problem is that its CSS > sets the text attribute on the html element and Dillo ignores this, so > we get black text on blue instead of white text on blue. > > Here is a demo: > > <html> > <head> > <style type="text/css">html{text:#F00;}</style> > </head> > <body> > Blah, blah, blah > </body> > </html> > > The text is plain black, but if you change html to body in the CSS > then the text is red as it should be. > > Thoughts on how to fix this? It's not obvious to me whether this is a > one-liner patch or something more radical is needed. Hm, I've never seen the "text" property in CSS, can you point me to the place where it is documented? Also in http://www.penny-arcade.com/2010/9/10/ I can't find the string "text:" neither in the source nor in the stylesheet - am I missing something? Regards, Johannes

Sept. 13, 2010

Segmentation fault on startup

by corvid＠lavabit.com

James wrote: > If you check my prior email I have included an updated backtrace. On further examination of the source it looks to me like fltk is trying to hardcode my fonts?!? To the best of my knowledge, fltk::HELVETICA, COURIER, TIMES, etc., actually meant Helvetica, Courier, Times, etc., with the old font system, but with xft, they just mean sans, mono, serif, etc. And then in the fontconfig files, sans and friends are set to some specific font (e.g., looking quickly in mine, it seems that fonts.conf makes sans an alias for sans-serif, and then conf.d is full of files that specify that, for the sans-serif family, here are a bunch of specific font families in order of preference...).

Sept. 13, 2010

Segmentation fault on startup

by obeythepenguin＠gmail.com

On Mon, 13 Sep 2010 13:18:51 -0400, James Lovejoy <jameslovejoy(a)tiscali.co.uk> wrote: > I'm not sure what xft really does. And I wouldn't say they are > antialiased because at font size 12 they look very jagged. Xft = Freetype = font rasterization engine. Basically it gives your program support for things like anti-aliasing and TrueType fonts. Try building FLTK2 with ./configure --disable-xft and see what it does. ~Benjamin

Sept. 13, 2010

Segmentation fault on startup

by jameslovejoy＠tiscali.co.uk

If you check my prior email I have included an updated backtrace. On further examination of the source it looks to me like fltk is trying to hardcode my fonts?!? On 13 Sep 2010, at 19:44, "corvid" <corvid(a)lavabit.com> wrote: > James wrote: >> I'm not sure what xft really does. And I wouldn't say they are antialiased because at font size 12 they look very jagged. > > I don't know in any detail myself, but if jagged characters don't bother > you, maybe you'll be happy with xft disabled in fltk. > > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Sept. 13, 2010

Segmentation fault on startup

by jameslovejoy＠tiscali.co.uk

With -g backtrace shows: #0 0x080ba0f4 in fltk::setfont(font=0x08172a18, size=12) at x11/Font_xft.cxx:318 #1 0x080f0e9a in fltk::Widget::measure_label(int&, int&) const () #2 0x08051126 in UI::make_filemenu_button (this=0x813de58) at ui.cc:531 #3 0x08052691 in UI::make_panel (this=0x813de58, ww=780) at ui.cc:626 #4 0x08052e48 in UI (this=0x813de58, x=0, y=0, ww=780, wh=580, label=0x81110c4 "Dillo", cur_ui=0x0) at ui.cc:724 #5 0x08054fbb in a_UIcmd_browser_window_new (ww=780, wh=580, xid=0, vbw=0x0) at uicmd.cc:433 #6 0x0804f753 in main (argc=1, argv=0xbffffd34) at dillo.cc:334 On 13 Sep 2010, at 18:18, James Lovejoy <jameslovejoy(a)tiscali.co.uk> wrote: > I'm not sure what xft really does. And I wouldn't say they are antialiased because at font size 12 they look very jagged. > > On 13 Sep 2010, at 17:12, "corvid" <corvid(a)lavabit.com> wrote: > >> James wrote: >>> In that case I must have fontconfig because in the text editor there are several fonts and font sizes I can pick from. >> >> Is other software showing antialiased fonts? >> You said that this was a minimalist distribution, so I don't know whether >> fltk with xft configured is important to you... >> >> >> _______________________________________________ >> Dillo-dev mailing list >> Dillo-dev(a)dillo.org >> http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Sept. 13, 2010

Segmentation fault on startup

by corvid＠lavabit.com

James wrote: > I'm not sure what xft really does. And I wouldn't say they are antialiased because at font size 12 they look very jagged. I don't know in any detail myself, but if jagged characters don't bother you, maybe you'll be happy with xft disabled in fltk.

Sept. 13, 2010

Segmentation fault on startup

by jameslovejoy＠tiscali.co.uk

I'm not sure what xft really does. And I wouldn't say they are antialiased because at font size 12 they look very jagged. On 13 Sep 2010, at 17:12, "corvid" <corvid(a)lavabit.com> wrote: > James wrote: >> In that case I must have fontconfig because in the text editor there are several fonts and font sizes I can pick from. > > Is other software showing antialiased fonts? > You said that this was a minimalist distribution, so I don't know whether > fltk with xft configured is important to you... > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Sept. 13, 2010

Segmentation fault on startup

by corvid＠lavabit.com

James wrote: > In that case I must have fontconfig because in the text editor there are several fonts and font sizes I can pick from. Is other software showing antialiased fonts? You said that this was a minimalist distribution, so I don't know whether fltk with xft configured is important to you...

Sept. 13, 2010

Segmentation fault on startup

by jameslovejoy＠tiscali.co.uk

In that case I must have fontconfig because in the text editor there are several fonts and font sizes I can pick from. On 13 Sep 2010, at 12:52, "Benjamin Johnson" <obeythepenguin(a)gmail.com> wrote: > On Mon, 13 Sep 2010 02:06:52 -0400, James Lovejoy <jameslovejoy(a)tiscali.co.uk> wrote: > >> Ok, I'll compile with -g this afternoon after school. I don't have fontconfig on the target system. Is it required? >> >> James > > If you don't have fontconfig installed, I'm frankly surprised you can get X to start at all. Yes, I'd say it's required. > > ~Benjamin > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Sept. 13, 2010

Segmentation fault on startup

by obeythepenguin＠gmail.com

On Mon, 13 Sep 2010 02:06:52 -0400, James Lovejoy <jameslovejoy(a)tiscali.co.uk> wrote: > Ok, I'll compile with -g this afternoon after school. I don't have > fontconfig on the target system. Is it required? > > James If you don't have fontconfig installed, I'm frankly surprised you can get X to start at all. Yes, I'd say it's required. ~Benjamin

Sept. 13, 2010

Segmentation fault on startup

by jameslovejoy＠tiscali.co.uk

Ok, I'll compile with -g this afternoon after school. I don't have fontconfig on the target system. Is it required? James On 13 Sep 2010, at 00:54, "corvid" <corvid(a)lavabit.com> wrote: > James wrote: >> Changing all fonts to lucida gets rid of the warnings but it still segfaults. > > If you compile fltk with -g, does the backtrace reveal anything interesting? > > I don't immediately know that it would matter in this case since I didn't > notice any relevant hardcoding in fltk, but just in case...do you know > whether fontconfig is set up properly so that "sans" points to a font that > you have? > >> Sent from my iPod > > Is there a way to disable that advertisement? > > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Sept. 13, 2010

RFC: Rules for distro-friendly packages

by weigelt＠metux.de

Hi folks, I've collected several rules that upstreams should follow to make distro maintainer's life easier. Feel free to comment on this. http://www.metux.de/index.php/de/component/content/article/57.html cu -- ---------------------------------------------------------------------- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weigelt(a)metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 ---------------------------------------------------------------------- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme ----------------------------------------------------------------------

Sept. 13, 2010

Segmentation fault on startup

by corvid＠lavabit.com

James wrote: > Changing all fonts to lucida gets rid of the warnings but it still segfaults. If you compile fltk with -g, does the backtrace reveal anything interesting? I don't immediately know that it would matter in this case since I didn't notice any relevant hardcoding in fltk, but just in case...do you know whether fontconfig is set up properly so that "sans" points to a font that you have? > Sent from my iPod Is there a way to disable that advertisement?

Sept. 13, 2010

[bug]: ignored CSS attributes on html element

by onepoint＠starurchin.org

Penny Arcade is illegible in Dillo[1]. The problem is that its CSS sets the text attribute on the html element and Dillo ignores this, so we get black text on blue instead of white text on blue. Here is a demo: <html> <head> <style type="text/css">html{text:#F00;}</style> </head> <body> Blah, blah, blah </body> </html> The text is plain black, but if you change html to body in the CSS then the text is red as it should be. Thoughts on how to fix this? It's not obvious to me whether this is a one-liner patch or something more radical is needed. Regards, Jeremy Henty [1] see http://www.penny-arcade.com/2010/9/10/

Sept. 12, 2010

Segmentation fault on startup

by jameslovejoy＠tiscali.co.uk

Changing all fonts to lucida gets rid of the warnings but it still segfaults. Sent from my iPod On 12 Sep 2010, at 17:17, "corvid" <corvid(a)lavabit.com> wrote: > James wrote: >> I managed to get a backtrace from GDB: >> >> #0 0x080ba0f4 in fltk::setfont(fltk::font*, float) () >> #1 0x080f0e9a in fltk::Widget::measure_label(int&, int&) const () >> #2 0x08051126 in UI::make_filemenu_button (this=0x813de58) at ui.cc:531 >> #3 0x08052691 in UI::make_panel (this=0x813de58, ww=780) at ui.cc:626 >> #4 0x08052e48 in UI (this=0x813de58, x=0, y=0, ww=780, wh=580, >> label=0x81110c4 "Dillo", cur_ui=0x0) at ui.cc:724 >> #5 0x08054fbb in a_UIcmd_browser_window_new (ww=780, wh=580, xid=0, >> vbw=0x0) >> at uicmd.cc:433 >> #6 0x0804f753 in main (argc=1, argv=0xbffffd34) at dillo.cc:334 > > If you edit dillorc to specify fonts that you have, does it work? > > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Sept. 12, 2010

[patch]: do not require Html_process_word()s argument to be null-terminated

by jcid＠dillo.org

On Sun, Sep 12, 2010 at 01:14:11PM +0100, Jeremy Henty wrote: > > This is almost a trivial cleanup, but I'd be more comfortable if > someone else checked I have not missed anything. (I have been using > it locally for a week or two with no problems so far.) > > Html_process_word() requires its argument to be null-terminated. This > forces Html_write_raw() (the only caller of Html_process_word()) to > write a null character before calling Html_process_word() and restore > the original character afterwards. > > It turns out to be easy to change Html_process_word() to not need the > null-terminator. This eliminates the hack in Html_write_raw() and > lets us make several function arguments "const char *" instead of > "char *". > > It's a little tricky to see that the patch is correct. It works > because none of the functions that Html_process_word() calls require a > null-terminator, and the return value of a_Html_parse_entities() *is* > null-terminated. > > Have I missed anything? If not, I'll push it. A few years ago, parts of the parser were coded not to need null-terminators (for speed's sake). It got really hard to maintain and every time a change was necessary, the whole function-call stack needed a review. Simple semantically good loking patches introduced bugs because library functions couldn't be used there too. One day I decided to use standard null-terminated strings and everything got easier. Not to mention there was no noticeable speed penalty. IOW, I learnt this the hard way! ;) FWIW, profiling has surprised me a few times: once I wrote a minimal perfect hash for matching HTML elements and the added complexity didn't payoff against a simple binary search. -1 -- Cheers Jorge.-

Sept. 12, 2010

Segmentation fault on startup

by jcid＠dillo.org

On Sun, Sep 12, 2010 at 02:39:17PM +0100, James Lovejoy wrote: > Hi, > > I managed to get a backtrace from GDB: > > #0 0x080ba0f4 in fltk::setfont(fltk::font*, float) () > #1 0x080f0e9a in fltk::Widget::measure_label(int&, int&) const () > #2 0x08051126 in UI::make_filemenu_button (this=0x813de58) at ui.cc:531 > #3 0x08052691 in UI::make_panel (this=0x813de58, ww=780) at ui.cc:626 > #4 0x08052e48 in UI (this=0x813de58, x=0, y=0, ww=780, wh=580, > label=0x81110c4 "Dillo", cur_ui=0x0) at ui.cc:724 > #5 0x08054fbb in a_UIcmd_browser_window_new (ww=780, wh=580, > xid=0, vbw=0x0) > at uicmd.cc:433 > #6 0x0804f753 in main (argc=1, argv=0xbffffd34) at dillo.cc:334 It shows the problem is in FLTK's font handling, as in the suggested thread. Please take a look in dillorc, fonts section, to find some hints on how to diagnose. My guess is the target system doesn't have the requested fonts installed, FLTK panics -> segfault. -- Cheers Jorge.-

Sept. 12, 2010

Segmentation fault on startup

by corvid＠lavabit.com

James wrote: > I managed to get a backtrace from GDB: > > #0 0x080ba0f4 in fltk::setfont(fltk::font*, float) () > #1 0x080f0e9a in fltk::Widget::measure_label(int&, int&) const () > #2 0x08051126 in UI::make_filemenu_button (this=0x813de58) at ui.cc:531 > #3 0x08052691 in UI::make_panel (this=0x813de58, ww=780) at ui.cc:626 > #4 0x08052e48 in UI (this=0x813de58, x=0, y=0, ww=780, wh=580, > label=0x81110c4 "Dillo", cur_ui=0x0) at ui.cc:724 > #5 0x08054fbb in a_UIcmd_browser_window_new (ww=780, wh=580, xid=0, > vbw=0x0) > at uicmd.cc:433 > #6 0x0804f753 in main (argc=1, argv=0xbffffd34) at dillo.cc:334 If you edit dillorc to specify fonts that you have, does it work?

Sept. 12, 2010

Segmentation fault on startup

by jameslovejoy＠tiscali.co.uk

Hi, I managed to get a backtrace from GDB: #0 0x080ba0f4 in fltk::setfont(fltk::font*, float) () #1 0x080f0e9a in fltk::Widget::measure_label(int&, int&) const () #2 0x08051126 in UI::make_filemenu_button (this=0x813de58) at ui.cc:531 #3 0x08052691 in UI::make_panel (this=0x813de58, ww=780) at ui.cc:626 #4 0x08052e48 in UI (this=0x813de58, x=0, y=0, ww=780, wh=580, label=0x81110c4 "Dillo", cur_ui=0x0) at ui.cc:724 #5 0x08054fbb in a_UIcmd_browser_window_new (ww=780, wh=580, xid=0, vbw=0x0) at uicmd.cc:433 #6 0x0804f753 in main (argc=1, argv=0xbffffd34) at dillo.cc:334 James ----- Original Message ----- From: "Jorge Arellano Cid" <jcid(a)dillo.org> To: "Dillo mailing list" <dillo-dev(a)dillo.org> Sent: Saturday, September 11, 2010 10:21 PM Subject: Re: [Dillo-dev] Segmentation fault on startup > On Sat, Sep 11, 2010 at 09:51:32PM +0100, James Lovejoy wrote: >> Hi, >> >> Fltk was compiled already with xft support. > > OK, but are the fonts installed? > > -- > Cheers > Jorge.- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Sept. 12, 2010

[patch]: do not require Html_process_word()s argument to be null-terminated

by onepoint＠starurchin.org

This is almost a trivial cleanup, but I'd be more comfortable if someone else checked I have not missed anything. (I have been using it locally for a week or two with no problems so far.) Html_process_word() requires its argument to be null-terminated. This forces Html_write_raw() (the only caller of Html_process_word()) to write a null character before calling Html_process_word() and restore the original character afterwards. It turns out to be easy to change Html_process_word() to not need the null-terminator. This eliminates the hack in Html_write_raw() and lets us make several function arguments "const char *" instead of "char *". It's a little tricky to see that the patch is correct. It works because none of the functions that Html_process_word() calls require a null-terminator, and the return value of a_Html_parse_entities() *is* null-terminated. Have I missed anything? If not, I'll push it. Regards, Jeremy Henty

Sept. 12, 2010

Segmentation fault on startup

by jcid＠dillo.org

On Sat, Sep 11, 2010 at 09:51:32PM +0100, James Lovejoy wrote: > Hi, > > Fltk was compiled already with xft support. OK, but are the fonts installed? -- Cheers Jorge.-

Sept. 11, 2010

Segmentation fault on startup

by jcid＠dillo.org

On Sat, Sep 11, 2010 at 08:38:16PM +0100, James Lovejoy wrote: > Hi, > > I'm creating a new distro that is supposed to be fast and light. I thought about Firefox but it all stacks up after you install gtk as well. So your slogan "fast and light" seemed sound the ticket. > > I compiled it on my ubuntu 10.04 system and it works on there. Copied it to the new distro and here is the output when I type "dillo" at the prompt: > > dillo: /lib/libjpeg.so.8: no version information available (required by dillo) > paths: Cannot open file '/root/.dillo/dillorc' > paths: Using /usr/local/etc/dillo/dillorc > paths: Cannot open file '/root/.dillo/keysrc' > paths: Using /usr/local/etc/dillo/keysrc > dillo_dns_init: Here we go! (threaded) > Disabling cookies. > ** WARNING **: preferred sans-serif font "DejaVu Sans" not found. > ** WARNING **: preferred serif font "DejaVu Serif" not found. > ** WARNING **: preferred monospace font "DejaVu mono" not found. > ** WARNING **: preferred cursive font "DejaVu Sans" not found. > ** WARNING **: preferred fantasy font "DejaVu Sans" not found. > Segmentation fault > > I can't get a backtrace from GDB because it's supposed to be a mega minimal > system. It works fine on the development system. It looks like an FLTK font handling problem. This thread may help: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2010-June/007523.html -- Cheers Jorge.-

Sept. 11, 2010

Segmentation fault on startup

by jameslovejoy＠tiscali.co.uk

Hi, I'm creating a new distro that is supposed to be fast and light. I thought about Firefox but it all stacks up after you install gtk as well. So your slogan "fast and light" seemed sound the ticket. I compiled it on my ubuntu 10.04 system and it works on there. Copied it to the new distro and here is the output when I type "dillo" at the prompt: dillo: /lib/libjpeg.so.8: no version information available (required by dillo) paths: Cannot open file '/root/.dillo/dillorc' paths: Using /usr/local/etc/dillo/dillorc paths: Cannot open file '/root/.dillo/keysrc' paths: Using /usr/local/etc/dillo/keysrc dillo_dns_init: Here we go! (threaded) Disabling cookies. ** WARNING **: preferred sans-serif font "DejaVu Sans" not found. ** WARNING **: preferred serif font "DejaVu Serif" not found. ** WARNING **: preferred monospace font "DejaVu mono" not found. ** WARNING **: preferred cursive font "DejaVu Sans" not found. ** WARNING **: preferred fantasy font "DejaVu Sans" not found. Segmentation fault I can't get a backtrace from GDB because it's supposed to be a mega minimal system. It works fine on the development system. Regards, James

Sept. 11, 2010

Commit bit: WAS Re: [Dillo-dev] [patch]: html.cc: re-indent Html_tag_open_q() for consistency

by onepoint＠starurchin.org

Johannes Hofmann wrote: > BTW, don't you have a commit bit (or how is it called with DVCS's)? Not at the moment. I have considered asking but it's been a long while since I have felt comfortable making a serious long-term commitment to working on dillo. I'm very happy to contribute as and when I can but I wouldn't want anyone expecting me to be active, say, in six month's time. Also, I don't feel I know what the long-term plan for dillo is, in terms of priorities and directions. My impression (perhaps wrongly) is that the discussion happens elsewhere (although it does surface on this list every now and then). So I wouldn't feel comfortable doing non-trivial stuff without the other dev's review. But maybe that's over-cautious. If everyone's time would be more effectively used if I had a commit bit then I'm happy to have one. I feel a bit one-of-a-kind in the Dillo world. Is there anyone else in the class of "not a core dev but a long-time contributor"? Regards, Jeremy Henty

Sept. 7, 2010

[patch]: html.cc: re-indent Html_tag_open_q() for consistency

by Johannes.Hofmann＠gmx.de

On Mon, Sep 06, 2010 at 09:31:22PM +0100, Jeremy Henty wrote: > > The wise say you shouldn't sweat the small stuff, but when one > function in a file is indented by 4 spaces and all the rest are > indented by 3, well... Committed! BTW, don't you have a commit bit (or how is it called with DVCS's)? Cheers, Johannes

Sept. 6, 2010

[patch]: html.cc: re-indent Html_tag_open_q() for consistency

by onepoint＠starurchin.org

The wise say you shouldn't sweat the small stuff, but when one function in a file is indented by 4 spaces and all the rest are indented by 3, well... Regards, Jeremy Henty

Sept. 6, 2010

[bug]: <pre> element respects color but not background-color

by Johannes.Hofmann＠gmx.de

On Mon, Sep 06, 2010 at 07:18:52AM +0100, Jeremy Henty wrote: > > Johannes Hofmann wrote: > > > Correct. All Html_tag_open_*() functions that don't add a widget > > (e.g. a textblock or an image) must call > > html->styleEngine->inheritBackgroundColor() to make background-color > > work. Unfortunately this is just a hack that doesn't solve all > > problems. E.g. <pre style="border: 1px solid black">foo</pre> will > > still not work. For now, I would just add inheritBackgroundColor() > > where necessary. > > OK, patch attached. Please review carefully - I am not familiar with > the Dillo CSS implementation so this is really a request for comments. > (Although it does fix the page that first highlighted the problem.) Thanks! I commited a slightly modified version. Cheers, Johannes

Sept. 6, 2010

[bug]: <pre> element respects color but not background-color

by onepoint＠starurchin.org

Johannes Hofmann wrote: > Correct. All Html_tag_open_*() functions that don't add a widget > (e.g. a textblock or an image) must call > html->styleEngine->inheritBackgroundColor() to make background-color > work. Unfortunately this is just a hack that doesn't solve all > problems. E.g. <pre style="border: 1px solid black">foo</pre> will > still not work. For now, I would just add inheritBackgroundColor() > where necessary. OK, patch attached. Please review carefully - I am not familiar with the Dillo CSS implementation so this is really a request for comments. (Although it does fix the page that first highlighted the problem.) And thanks for the explanation of the CSS workings! Regards, Jeremy Henty

Sept. 6, 2010

[patch]: consistent screaming quotes

by Johannes.Hofmann＠gmx.de

On Sun, Sep 05, 2010 at 09:53:05AM +0100, Jeremy Henty wrote: > > A small cleanup. I noticed the ugly unbalanced quotes in the '>>> > a_Nav_repush <<<<' message so I did a quick grep and fixed all similar > messages to have the same formatting. Committed! Cheers, Johannes

Sept. 5, 2010

[bug]: <pre> element respects color but not background-color

by Johannes.Hofmann＠gmx.de

Hi Jeremy, On Sun, Sep 05, 2010 at 12:52:02PM +0100, Jeremy Henty wrote: > > The problem is that Html_tag_open_pre() does not call > html->styleEngine->inheritBackgroundColor() before calling > HT2TB(html)->addParbreak(). But several other Html_tag_open_*() > functions have the same problem, eg. Html_tag_open_{dt,dl}(). Should > we fix them one by one or is there a better way? Correct. All Html_tag_open_*() functions that don't add a widget (e.g. a textblock or an image) must call html->styleEngine->inheritBackgroundColor() to make background-color work. Unfortunately this is just a hack that doesn't solve all problems. E.g. <pre style="border: 1px solid black">foo</pre> will still not work. For now, I would just add inheritBackgroundColor() where necessary. > > Also, I wonder if more of the Html_tag_open_*() functions should call > html->styleEngine->setNonCssHints(), but I don't understand the CSS > engine well enough to be sure. setNonCssHints() in contrast is not a hack :-) It is used to pass style information from (deprecated) non-CSS HTML attributes like bgColor, align and so on to StyleEngine. This style information from HTML attributes has to be handled specially as described in http://www.w3.org/TR/CSS2/cascade.html#preshint So for all HTML-attributes that we want to support and that change the style there should be a corresponding setNonCssHints() call. Regards, Johannes

Sept. 5, 2010

[bug]: <pre> element respects color but not background-color

by onepoint＠starurchin.org

The problem is that Html_tag_open_pre() does not call html->styleEngine->inheritBackgroundColor() before calling HT2TB(html)->addParbreak(). But several other Html_tag_open_*() functions have the same problem, eg. Html_tag_open_{dt,dl}(). Should we fix them one by one or is there a better way? Also, I wonder if more of the Html_tag_open_*() functions should call html->styleEngine->setNonCssHints(), but I don't understand the CSS engine well enough to be sure. Regards, Jeremy Henty

Sept. 5, 2010

[bug]: <pre> element respects color but not background-color

by onepoint＠starurchin.org

<html> <head> <style type="text/css"> pre { background-color:#222; color:#fff; } </style> </head> <body> <pre>Blah, blah, blah</pre> </body> </html> Dillo renders the above as white text on the default background, which is almost illegible. Firefox renders it white on black, as intended. If you apply the style to the body element instead of the pre element then Dillo renders it correctly. The pre element respects the color style parameter but not the background-color. This bug is visible at http://jeffkreeftmeijer.com/2010/the-mighty-reflog-and-the-amazing-bisect/ Regards, Jeremy Henty

Sept. 5, 2010

[patch]: consistent screaming quotes

by onepoint＠starurchin.org

A small cleanup. I noticed the ugly unbalanced quotes in the '>>> a_Nav_repush <<<<' message so I did a quick grep and fixed all similar messages to have the same formatting. (I am still thinking about the "parse missing attribute close quotes like Firefox" patch, but it's taking me a little while to get familiar with html.cc again.) Regards, Jeremy Henty

Sept. 5, 2010

Fwd: your dillo win32 build ....

by obeythepenguin＠gmail.com

Received this earlier today, and figured I should share with the people who deserve real credit :-) ~Benjamin ------- Forwarded message ------- From: "a.r. ramakrishnan" <srizbf(a)gmail.com> To: obeythepenguin(a)gmail.com Cc: Subject: your dillo win32 build .... Date: Fri, 03 Sep 2010 12:40:54 -0400 Hello Benjamin jhonson, congrats for your attempt on dillo for windows. i have tested your 20100902 binary. your building dillo for win9x is exceptional. and it is working under windows98. there are some layout problems in webpages. but barring that you have given the fast browser for normal use . thank you once again expecting many more from you 3rdsep2010 -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Sept. 4, 2010

Another (native) Dillo-Win32 patch

by obeythepenguin＠gmail.com

All right, I have it running on Windows 95! Screenshots: http://dillo-win32.sourceforge.net/screenshots/dillo-win95.png http://dillo-win32.sourceforge.net/screenshots/dillo-wikipedia-win95.png It's still a little glitchy (FLTK issues, not Dillo per se), but now Dillo can truly run on any Windows system, for all practical purposes. [Of course, if you can prove people still use Win3.11...] Here's the latest patch: http://dillo-win32.sourceforge.net/files/dillo-r1698-win32-20100902.diff I've also got a full installer up on the SourceForge page, if anyone has a Windows machine and wants to take it for a spin. I've been using it quite a bit myself the last few days, including three straight hours the other night. As long as you don't need DPI, it's quite usable. Speaking of which... there's going to be a few complications, mainly because on Windows, file and socket handles are NOT interchangable. DPI seems to rely heavily on dup2(), for which there's no direct Windows equivalent. I've written up a full description of the problem here: http://dillo-win32.sourceforge.net/dpi.html This is where I'm going to need your expert advice. Jorge, if you have the time, I'd especially like to hear your opinion -- I know you're quite busy, and not a personal fan of the Windows platform, but I feel a well-executed port would ultimately help the project far more than it would hurt anything. Thanks again & cheers, ~Benjamin

Sept. 3, 2010

[Patch] Work around lazy loading images

by obeythepenguin＠gmail.com

Another patch, this time not Win32-related. This works around the annoying "lazy loading" technique, which sets src to a placeholder image then uses JavaScript to fetch the real images after the pages load. Here's the diff: http://pastebin.com/wyP32Ukj (sorry it's not hg diff; I don't have access from school) I know Dillo aims to strictly follow standards, but I don't think it's a standards violation per se, so much as a trick too clever for its own good. I personally feel this helps the democratization of information access more than it hurts standards compliance, since otherwise the information might not be available until/unless Dillo implements JavaScript support. You may, of course, disagree... Cheers, ~Benjamin

Sept. 1, 2010