a policy for dillorc vs. style.css conflicts?
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.
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. Johannes
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 <span>large</span> Can it be interpreted as "make everything big"? I was also thinking that we would need to get the color and size from StyleEngine for plain and root png/gif backgrounds...
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 <span>large</span>
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 <span> itself doesn't alter it. What am I missing?
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>)? Alternatively we could move plain handling into a dpi together with the source view ... Cheers, Johannes
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 <span>large</span>
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 <span> 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 ...
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 <span>large</span>
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 <span> 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 <span>large</span>" 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@dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
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 <span>large</span>
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 <span> 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.-
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 <span>large</span>
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 <span> 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
On Sun, Feb 15, 2009 at 07:54:15PM +0100, Hofmann Johannes wrote:
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 <span>large</span>
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 <span> 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?
I'm very happy with the latest patches on font size, it's very important: http://www.useit.com/alertbox/designmistakes.html Reading that page is assuring. We're providing the necessary controls for people expressing their need for them! WRT your question, yes, it'd be good to go the CSS way, but also to keep it simple for a non-CSS-savvy user to set. This is, maybe font_{min_size, max_size, factor} are well placed in dillorc. For text background and color, linkcolor, visited linkcolor they seem to belong in CSS. Now, if we're to put them in CSS, we must provide well-commented sample stylesheets, and also give some directions in the FAQ. It should be simple for the user to know how to set his own stylesheet options without previous CSS knowledge, and also how to disable the remote CSS when a page doesn't look good. It'd be great to specify, for instance, a "reading" stylesheet (for low contrast and highcontrast) from our website and to let the user tweak it. Then when he gets to a long page that he wants to read (not just skim), he could disable remote CSS and use the one he prefers. A few days ago I got to read the above link and relized the actual relevance of this issue. -- Cheers Jorge.-
On Mon, Feb 16, 2009 at 09:48:23AM -0300, Jorge Arellano Cid wrote:
On Sun, Feb 15, 2009 at 07:54:15PM +0100, Hofmann Johannes wrote:
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 <span>large</span>
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 <span> 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?
I'm very happy with the latest patches on font size, it's very important:
http://www.useit.com/alertbox/designmistakes.html
Reading that page is assuring. We're providing the necessary controls for people expressing their need for them!
WRT your question, yes, it'd be good to go the CSS way, but also to keep it simple for a non-CSS-savvy user to set. This is, maybe font_{min_size, max_size, factor} are well placed in dillorc. For text background and color, linkcolor, visited linkcolor they seem to belong in CSS.
Exactly. font_{min_size, max_size, factor} can't be expressed in CSS, so they must stay in dillorc. Whatever can be expressed in CSS should be done in style.css.
Now, if we're to put them in CSS, we must provide well-commented sample stylesheets, and also give some directions in the FAQ. It should be simple for the user to know how to set his own stylesheet options without previous CSS knowledge, and also how to disable the remote CSS when a page doesn't look good.
It'd be great to specify, for instance, a "reading" stylesheet (for low contrast and highcontrast) from our website and to let the user tweak it. Then when he gets to a long page that he wants to read (not just skim), he could disable remote CSS and use the one he prefers.
As you say, it's mostly a question of documentation. Cheers, Johannes
A few days ago I got to read the above link and relized the actual relevance of this issue.
-- Cheers Jorge.-
_______________________________________________ Dillo-dev mailing list Dillo-dev@dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
Jorge wrote:
Now, if we're to put them in CSS, we must provide well-commented sample stylesheets, and also give some directions in the FAQ. It should be simple for the user to know how to set his own stylesheet options without previous CSS knowledge, and also how to disable the remote CSS when a page doesn't look good.
It'd be great to specify, for instance, a "reading" stylesheet (for low contrast and highcontrast) from our website and to let the user tweak it. Then when he gets to a long page that he wants to read (not just skim), he could disable remote CSS and use the one he prefers.
Some days ago, I started trying to put together a sample style sheet (attached). I got as far as putting in the things that I would find valuable to know, but I _have_ been exposed to CSS a bit in recent months, so it was hard to see how much would have to be spelled out to an intelligent layman and how much would be obvious from context and insulting to spell out. So I...I got stuck. (Strays from topic a bit: The world is filled with things aimed toward experts and filled with things aimed toward ignorant people who can be kept ignorant and separated from their money, but the intelligent layman does not have his needs met.)
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 <span>large</span>
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 <span> 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.
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 <span>large</span>
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 <span> 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
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.)
On Sun, Feb 15, 2009 at 09:13:50PM +0000, corvid wrote:
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.)
Ah now I see. The check only happened when the font-size was _changed_ Please try attached patch. Cheers, Johannes
Johannes wrote:
On Sun, Feb 15, 2009 at 09:13:50PM +0000, corvid wrote:
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.)
Ah now I see. The check only happened when the font-size was _changed_ Please try attached patch.
It appears to work for me.
On Sun, Feb 15, 2009 at 11:15:34PM +0000, corvid wrote:
Johannes wrote:
On Sun, Feb 15, 2009 at 09:13:50PM +0000, corvid wrote:
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.)
Ah now I see. The check only happened when the font-size was _changed_ Please try attached patch.
It appears to work for me.
Committed. Thanks, Johannes
participants (3)
-
corvid＠lavabit.com -
jcid＠dillo.org -
Johannes.Hofmann＠gmx.de