- Dillo-dev - lists.mailman3.com

a policy for dillorc vs. style.css conflicts?

by corvid＠lavabit.com

Johannes wrote: > [paste] > > > On Fr, 13 Feb 2009 20:33, corvid wrote: > > > > > > > There is also a problem with the lately introduced font_min_size > > > > > > > while having set font-size for * in style.css. > > > > > > > > > > > > I just gave it a try and it seemed to be working for me. > > > > > > What is it doing wrong? > > > > > > > > > > I have set these values in dillorc: > > > > > font_min_size=10 > > > > > font_max_size=12 > > > > > > > > > > For font_max_size, I used the attached patch. > > > > > > > > > > My style.css looks like this: > > > > > > > > > > * { > > > > > font-family: ProFont !important; > > > > > font-size: 9pt; > > > > > } > > > > > > > > > > body { > > > > > background-color: white !important; > > > > > } > > > > > > > > > > Now every font size is supposed to be between 10pt and 12pt (the > > > > > font-size: 9pt should be overwritten by font_min_size). But if I now > > > > > visit heise.de, there is text which is even smaller than 9pt. I have > > > > > selected the specific range in this screenshot: > > > > > http://img5.imageshack.us/img5/1082/200902131918591280x800sok3.png > > > > > > > > > > Any ideas on how to fix this? > > > > > > > > Ah, I believe font_min_size is in pixels. > > > > > > > > > > That is possible, but setting font_min_size and font_max_size > > > to a higher value (e.g. 50 and 100) does not fix this issue. > > > When having disabled the style.css, the font sizes are the same as > > > before. > > I think this is some sort of weirdness with either ProFont, fltk or > both in combination. > I can't get ProFont working at all. It only shows 1px high lines. > Can you confirm that the font_min_size works properly with > non-bitmap fonts? > Regarding font_max_size I wasn't sure whether we want another option > or should just set a reasonable fixed upper limit. > But now that someone even made a patch for font_max_size it seems a > good idea to have an option... When I quickly tried font_min_size of 30 and nothing about fonts in my style.css, I saw regular-sized fonts as well. (I'd never even heard of ProFont.)

Feb. 15, 2009

My valgrind logs, for all to see.

by Johannes.Hofmann＠gmx.de

On Sun, Feb 15, 2009 at 02:14:53AM +0000, Jeremy Henty wrote: > On Sat, Feb 14, 2009 at 07:04:21PM -0300, Jorge Arellano Cid wrote: > > On Sat, Feb 14, 2009 at 09:33:27PM +0000, Jeremy Henty wrote: > > > Would having a single page with anchors for each link be enough, > > > or do you want separate pages for each one? > > > > A single page seems easier. > > Actually, I've gone for a summary page with links to a separate page > for each error. I've put some information from the stack traces into > the link texts. I think it works rather well, eg. you can clearly see > that most of the errors are coming from CSS handling (and some of > those leaks are not as small as I thought). Please comment. > > http://starurchin.org/dillo/valgrind.html I just committed two fixes for CSS related leaks. Not sure if that's all. Regards, Johannes

Feb. 15, 2009

a policy for dillorc vs. style.css conflicts?

by Johannes.Hofmann＠gmx.de

On Sun, Feb 15, 2009 at 07:16:55PM +0000, corvid wrote: > Jorge wrote: > > On Sun, Feb 15, 2009 at 05:07:28PM +0000, corvid wrote: > > > Johannes wrote: > > > > On Sat, Feb 14, 2009 at 04:07:15PM +0000, corvid wrote: > > > > > Johannes wrote: > > > > > > On Sun, Feb 01, 2009 at 07:20:33PM +0000, corvid wrote: > > > > > > > I was just looking at some of the prefs that I > > > > > > > don't think are doing anything right now, e.g., > > > > > > > link_color, force_my_colors... > > > > > > > I could stuff them into buildUserStyle(), but > > > > > > > I don't know which should prevail in case of > > > > > > > conflicts. > > > > > > > > > > > > > > I can't remember whether I've already mentioned that > > > > > > > I've been wondering whether it might be reasonable to > > > > > > > rip a bunch of color stuff out of dillorc and expect > > > > > > > a dillo user to be able to deal with a well-commented > > > > > > > sample style.css instead. > > > > > > > > > > > > Good point. I always favor simplicity so I think we should have just > > > > > > one way to modify the style. Having two (style.css and preferences) > > > > > > just adds confusion. We need to document this properly as you > > > > > > said. > > > > > > > > > > If I have a style.css containing: > > > > > > > > > > * {font-size: 30px} > > > > > > > > > > and a page containing: > > > > > > > > > > regular regular large > > > > > > > > > > Can it be interpreted as "make everything big"? > > > > > > > > Sorry, I think I don't fully understand the question. > > > > > > > > * {font-size: 30px !important} > > > > > > > > would set a fixed font size of 30px. The itself doesn't alter > > > > it. What am I missing? > > > > > > If I do this, it doesn't use 30px until the first tag it sees. > > > > BTW, there's BUG#892 (prefs' bg_color is not working). > > Speaking of which, the submitter tells me that font_min_size > doesn't work sometimes. Pasted in: > > > > On Fr, 13 Feb 2009 20:33, corvid wrote: > > > > > > There is also a problem with the lately introduced font_min_size > > > > > > while having set font-size for * in style.css. > > > > > > > > > > I just gave it a try and it seemed to be working for me. > > > > > What is it doing wrong? > > > > > > > > I have set these values in dillorc: > > > > font_min_size=10 > > > > font_max_size=12 > > > > > > > > For font_max_size, I used the attached patch. > > > > > > > > My style.css looks like this: > > > > > > > > * { > > > > font-family: ProFont !important; > > > > font-size: 9pt; > > > > } > > > > > > > > body { > > > > background-color: white !important; > > > > } > > > > > > > > Now every font size is supposed to be between 10pt and 12pt (the > > > > font-size: 9pt should be overwritten by font_min_size). But if I now > > > > visit heise.de, there is text which is even smaller than 9pt. I have > > > > selected the specific range in this screenshot: > > > > http://img5.imageshack.us/img5/1082/200902131918591280x800sok3.png > > > > > > > > Any ideas on how to fix this? > > > > > > Ah, I believe font_min_size is in pixels. > > > > > > > That is possible, but setting font_min_size and font_max_size > > to a higher value (e.g. 50 and 100) does not fix this issue. > > When having disabled the style.css, the font sizes are the same as > > before. I think this is some sort of weirdness with either ProFont, fltk or both in combination. I can't get ProFont working at all. It only shows 1px high lines. Can you confirm that the font_min_size works properly with non-bitmap fonts? Regarding font_max_size I wasn't sure whether we want another option or should just set a reasonable fixed upper limit. But now that someone even made a patch for font_max_size it seems a good idea to have an option... Cheers, Johannes

Feb. 15, 2009

a policy for dillorc vs. style.css conflicts?

by corvid＠lavabit.com

Jorge wrote: > On Sun, Feb 15, 2009 at 05:07:28PM +0000, corvid wrote: > > Johannes wrote: > > > On Sat, Feb 14, 2009 at 04:07:15PM +0000, corvid wrote: > > > > Johannes wrote: > > > > > On Sun, Feb 01, 2009 at 07:20:33PM +0000, corvid wrote: > > > > > > I was just looking at some of the prefs that I > > > > > > don't think are doing anything right now, e.g., > > > > > > link_color, force_my_colors... > > > > > > I could stuff them into buildUserStyle(), but > > > > > > I don't know which should prevail in case of > > > > > > conflicts. > > > > > > > > > > > > I can't remember whether I've already mentioned that > > > > > > I've been wondering whether it might be reasonable to > > > > > > rip a bunch of color stuff out of dillorc and expect > > > > > > a dillo user to be able to deal with a well-commented > > > > > > sample style.css instead. > > > > > > > > > > Good point. I always favor simplicity so I think we should have just > > > > > one way to modify the style. Having two (style.css and preferences) > > > > > just adds confusion. We need to document this properly as you > > > > > said. > > > > > > > > If I have a style.css containing: > > > > > > > > * {font-size: 30px} > > > > > > > > and a page containing: > > > > > > > > regular regular large > > > > > > > > Can it be interpreted as "make everything big"? > > > > > > Sorry, I think I don't fully understand the question. > > > > > > * {font-size: 30px !important} > > > > > > would set a fixed font size of 30px. The itself doesn't alter > > > it. What am I missing? > > > > If I do this, it doesn't use 30px until the first tag it sees. > > BTW, there's BUG#892 (prefs' bg_color is not working). Speaking of which, the submitter tells me that font_min_size doesn't work sometimes. Pasted in: > On Fr, 13 Feb 2009 20:33, corvid wrote: > > > > > There is also a problem with the lately introduced font_min_size > > > > > while having set font-size for * in style.css. > > > > > > > > I just gave it a try and it seemed to be working for me. > > > > What is it doing wrong? > > > > > > I have set these values in dillorc: > > > font_min_size=10 > > > font_max_size=12 > > > > > > For font_max_size, I used the attached patch. > > > > > > My style.css looks like this: > > > > > > * { > > > font-family: ProFont !important; > > > font-size: 9pt; > > > } > > > > > > body { > > > background-color: white !important; > > > } > > > > > > Now every font size is supposed to be between 10pt and 12pt (the > > > font-size: 9pt should be overwritten by font_min_size). But if I now > > > visit heise.de, there is text which is even smaller than 9pt. I have > > > selected the specific range in this screenshot: > > > http://img5.imageshack.us/img5/1082/200902131918591280x800sok3.png > > > > > > Any ideas on how to fix this? > > > > Ah, I believe font_min_size is in pixels. > > > > That is possible, but setting font_min_size and font_max_size > to a higher value (e.g. 50 and 100) does not fix this issue. > When having disabled the style.css, the font sizes are the same as > before.

Feb. 15, 2009

a policy for dillorc vs. style.css conflicts?

by Johannes.Hofmann＠gmx.de

On Sun, Feb 15, 2009 at 03:57:46PM -0300, Jorge Arellano Cid wrote: > On Sun, Feb 15, 2009 at 05:07:28PM +0000, corvid wrote: > > Johannes wrote: > > > On Sat, Feb 14, 2009 at 04:07:15PM +0000, corvid wrote: > > > > Johannes wrote: > > > > > On Sun, Feb 01, 2009 at 07:20:33PM +0000, corvid wrote: > > > > > > I was just looking at some of the prefs that I > > > > > > don't think are doing anything right now, e.g., > > > > > > link_color, force_my_colors... > > > > > > I could stuff them into buildUserStyle(), but > > > > > > I don't know which should prevail in case of > > > > > > conflicts. > > > > > > > > > > > > I can't remember whether I've already mentioned that > > > > > > I've been wondering whether it might be reasonable to > > > > > > rip a bunch of color stuff out of dillorc and expect > > > > > > a dillo user to be able to deal with a well-commented > > > > > > sample style.css instead. > > > > > > > > > > Good point. I always favor simplicity so I think we should have just > > > > > one way to modify the style. Having two (style.css and preferences) > > > > > just adds confusion. We need to document this properly as you > > > > > said. > > > > > > > > If I have a style.css containing: > > > > > > > > * {font-size: 30px} > > > > > > > > and a page containing: > > > > > > > > regular regular large > > > > > > > > Can it be interpreted as "make everything big"? > > > > > > Sorry, I think I don't fully understand the question. > > > > > > * {font-size: 30px !important} > > > > > > would set a fixed font size of 30px. The itself doesn't alter > > > it. What am I missing? > > > > If I do this, it doesn't use 30px until the first tag it sees. > > BTW, there's BUG#892 (prefs' bg_color is not working). Jorge, what do you think about this? Can we go the style.css way and remove all dillorc options for stuff that can also be done with style.css? Cheers, Johannes

Feb. 15, 2009

a policy for dillorc vs. style.css conflicts?

by jcid＠dillo.org

On Sun, Feb 15, 2009 at 05:07:28PM +0000, corvid wrote: > Johannes wrote: > > On Sat, Feb 14, 2009 at 04:07:15PM +0000, corvid wrote: > > > Johannes wrote: > > > > On Sun, Feb 01, 2009 at 07:20:33PM +0000, corvid wrote: > > > > > I was just looking at some of the prefs that I > > > > > don't think are doing anything right now, e.g., > > > > > link_color, force_my_colors... > > > > > I could stuff them into buildUserStyle(), but > > > > > I don't know which should prevail in case of > > > > > conflicts. > > > > > > > > > > I can't remember whether I've already mentioned that > > > > > I've been wondering whether it might be reasonable to > > > > > rip a bunch of color stuff out of dillorc and expect > > > > > a dillo user to be able to deal with a well-commented > > > > > sample style.css instead. > > > > > > > > Good point. I always favor simplicity so I think we should have just > > > > one way to modify the style. Having two (style.css and preferences) > > > > just adds confusion. We need to document this properly as you > > > > said. > > > > > > If I have a style.css containing: > > > > > > * {font-size: 30px} > > > > > > and a page containing: > > > > > > regular regular large > > > > > > Can it be interpreted as "make everything big"? > > > > Sorry, I think I don't fully understand the question. > > > > * {font-size: 30px !important} > > > > would set a fixed font size of 30px. The itself doesn't alter > > it. What am I missing? > > If I do this, it doesn't use 30px until the first tag it sees. BTW, there's BUG#892 (prefs' bg_color is not working). -- Cheers Jorge.-

Feb. 15, 2009

My valgrind logs, for all to see.

by Johannes.Hofmann＠gmx.de

On Sun, Feb 15, 2009 at 02:14:53AM +0000, Jeremy Henty wrote: > On Sat, Feb 14, 2009 at 07:04:21PM -0300, Jorge Arellano Cid wrote: > > On Sat, Feb 14, 2009 at 09:33:27PM +0000, Jeremy Henty wrote: > > > Would having a single page with anchors for each link be enough, > > > or do you want separate pages for each one? > > > > A single page seems easier. > > Actually, I've gone for a summary page with links to a separate page > for each error. I've put some information from the stack traces into > the link texts. I think it works rather well, eg. you can clearly see > that most of the errors are coming from CSS handling (and some of > those leaks are not as small as I thought). Please comment. > > http://starurchin.org/dillo/valgrind.html Thanks for testing! Unfortunately I don't have valgrind running here. Do the dates on the page mean that the CSS related leaks mostly started with dillo sources from after 2009-02-12? Regards, Johannes

Feb. 15, 2009

a policy for dillorc vs. style.css conflicts?

by Johannes.Hofmann＠gmx.de

On Sun, Feb 15, 2009 at 05:07:28PM +0000, corvid wrote: > Johannes wrote: > > On Sat, Feb 14, 2009 at 04:07:15PM +0000, corvid wrote: > > > Johannes wrote: > > > > On Sun, Feb 01, 2009 at 07:20:33PM +0000, corvid wrote: > > > > > I was just looking at some of the prefs that I > > > > > don't think are doing anything right now, e.g., > > > > > link_color, force_my_colors... > > > > > I could stuff them into buildUserStyle(), but > > > > > I don't know which should prevail in case of > > > > > conflicts. > > > > > > > > > > I can't remember whether I've already mentioned that > > > > > I've been wondering whether it might be reasonable to > > > > > rip a bunch of color stuff out of dillorc and expect > > > > > a dillo user to be able to deal with a well-commented > > > > > sample style.css instead. > > > > > > > > Good point. I always favor simplicity so I think we should have just > > > > one way to modify the style. Having two (style.css and preferences) > > > > just adds confusion. We need to document this properly as you > > > > said. > > > > > > If I have a style.css containing: > > > > > > * {font-size: 30px} > > > > > > and a page containing: > > > > > > regular regular large > > > > > > Can it be interpreted as "make everything big"? > > > > Sorry, I think I don't fully understand the question. > > > > * {font-size: 30px !important} > > > > would set a fixed font size of 30px. The itself doesn't alter > > it. What am I missing? > > If I do this, it doesn't use 30px until the first tag it sees. Ah ok, so "regular regular large" is the whole page without <html><body>... In that case I would have thought that html.cc generates fake <html> and <body> elements - which seems not to be the case currently. Opinions? > > > > > I was also thinking that we would need to get the color and > > > size from StyleEngine for plain and root png/gif backgrounds... > > > > Not sure about plain. Which color should StyleEngine choose? Or do > > you mean we should simulate a dummy DocTree for plain (e.g. > > <html><body><pre> ... </pre></body></html>)? > > I don't know what is most appropriate, but it would be good for a user > still to be able to control it somehow. I agree, maybe plain should really call StyleEngine::startElement() for <html>, <body>, <pre> and then use StyleEngine::style() to get the backgroundColor and color? Maybe even the font? > > > Alternatively we could move plain handling into a dpi together with > > the source view ... > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Feb. 15, 2009

a policy for dillorc vs. style.css conflicts?

by corvid＠lavabit.com

Johannes wrote: > On Sat, Feb 14, 2009 at 04:07:15PM +0000, corvid wrote: > > Johannes wrote: > > > On Sun, Feb 01, 2009 at 07:20:33PM +0000, corvid wrote: > > > > I was just looking at some of the prefs that I > > > > don't think are doing anything right now, e.g., > > > > link_color, force_my_colors... > > > > I could stuff them into buildUserStyle(), but > > > > I don't know which should prevail in case of > > > > conflicts. > > > > > > > > I can't remember whether I've already mentioned that > > > > I've been wondering whether it might be reasonable to > > > > rip a bunch of color stuff out of dillorc and expect > > > > a dillo user to be able to deal with a well-commented > > > > sample style.css instead. > > > > > > Good point. I always favor simplicity so I think we should have just > > > one way to modify the style. Having two (style.css and preferences) > > > just adds confusion. We need to document this properly as you > > > said. > > > > If I have a style.css containing: > > > > * {font-size: 30px} > > > > and a page containing: > > > > regular regular large > > > > Can it be interpreted as "make everything big"? > > Sorry, I think I don't fully understand the question. > > * {font-size: 30px !important} > > would set a fixed font size of 30px. The itself doesn't alter > it. What am I missing? If I do this, it doesn't use 30px until the first tag it sees. > > I was also thinking that we would need to get the color and > > size from StyleEngine for plain and root png/gif backgrounds... > > Not sure about plain. Which color should StyleEngine choose? Or do > you mean we should simulate a dummy DocTree for plain (e.g. > <html><body><pre> ... </pre></body></html>)? I don't know what is most appropriate, but it would be good for a user still to be able to control it somehow. > Alternatively we could move plain handling into a dpi together with > the source view ...

Feb. 15, 2009

[patch] Search Previous

by corvid＠lavabit.com

Johannes wrote: > I didn't touch the caseSens==true case, because I wasn't sure > whether we want to retain the possibility to search for e.g. \t or > \n in plain text or not. I just wanted to mention that DilloPlain::write() calls a_Misc_expand_tabs().

Feb. 15, 2009