- Dillo-dev - lists.mailman3.com

Problem with fonts.

by corvid＠lavabit.com

Rajesh wrote: > I have loaded Dillo Browser on to my ARM based embedded platform. > Presently, I am facing a problem with fonts. The messages that I get > while the browser comes up are > --------------------------------------------------------------- > bad font: > variable > ** WARNING **: preferred sans-serif font "helvetica Sans" not > found. > ** WARNING **: preferred serif font "helvetica Serif" not > found. > ** WARNING **: preferred monospace font "helvetica Sans Mono" not > found. > ** WARNING **: preferred cursive font "helvetica Sans" not > found. > ** WARNING **: preferred fantasy font "helvetica Sans" not > found. > ------------------------------------------------------------------ > > Also, the size of the text that appears on Dillo (On the ARM based > system) appears very small. > However, the same page if I open with Dillo running on a Linux PC, will > show bigger fonts. So, my questions are: > > 1. How do I get rid of the "bad font" error message on my ARM-based > system ? I have used LTIB as the unix based development platform. > > 2. How to overcome the font size problem ? Playing around with max/min > font_size and scale_factor in dillorc did not help. What fonts do you have? If you don't have scalable fonts, maybe you'll want to --disable-xft in fltk configuration. In any case, if you have helvetica, for instance, you'd just want to say font_sans_serif="helvetica". (Fltk's src/x11/Font_xlfd.cxx suggests that helvetica is relatively safe for sans, courier for monospaced, and times for serif.)

April 8, 2010

Problem with fonts.

by rmarathe＠i-rode.com

Hello, I have loaded Dillo Browser on to my ARM based embedded platform. Presently, I am facing a problem with fonts. The messages that I get while the browser comes up are --------------------------------------------------------------- bad font: variable ** WARNING **: preferred sans-serif font "helvetica Sans" not found. ** WARNING **: preferred serif font "helvetica Serif" not found. ** WARNING **: preferred monospace font "helvetica Sans Mono" not found. ** WARNING **: preferred cursive font "helvetica Sans" not found. ** WARNING **: preferred fantasy font "helvetica Sans" not found. ------------------------------------------------------------------ Also, the size of the text that appears on Dillo (On the ARM based system) appears very small. However, the same page if I open with Dillo running on a Linux PC, will show bigger fonts. So, my questions are: 1. How do I get rid of the "bad font" error message on my ARM-based system ? I have used LTIB as the unix based development platform. 2. How to overcome the font size problem ? Playing around with max/min font_size and scale_factor in dillorc did not help. regards, Rajesh Marathe.

April 8, 2010

web bug save?

by Johannes.Hofmann＠gmx.de

On Tue, Apr 06, 2010 at 02:41:50AM +0000, corvid wrote: > Jorge wrote: > > On Fri, Apr 02, 2010 at 07:07:50PM +0000, corvid wrote: > > > > I'd only suggest considering whether adding a URL flag (e.g. > > > > URL_FilterOut) provides more flexibility/clarity without having > > > > to add the 'requester' parameter to the API. > > > > > > Can you elaborate a bit on how/where the flag would be set, and > > > how it would help? > > > > I haven't looked at it in enough depth to offer a good > > alternative yet. Just noticed of the API changes, made an extra > > couple of passes above the code considering the flag or having > > referer in the DilloUrl struct. > > > > The idea is to commit it and to consider the alternatives > > later. > > All right, then. Committed. > > Everyone: > 1) This will surely require various tweaks. > 2) If it threatens to drive you insane in the meantime, there's a dillorc > option. While testing a bit more I found a problem with redirects: http://nibble.develsec.org doesn't seem to load properly when same_domain is enabled. The problem seems to be a_Nav_push(bw, bw->meta_refresh_url,a_History_get_url(NAV_TOP_UIDX(bw))); in Nav_redirection0_callback(). a_History_get_url(NAV_TOP_UIDX(bw)) is not necessarily the proper requester. Things seem to work in this example with a_Nav_push(bw, bw->meta_refresh_url,bw->nav_expect_url); but I guess bw->nav_expect_url is also not always set properly.

April 8, 2010

web bug save?

by corvid＠lavabit.com

Johannes wrote: > On Tue, Apr 06, 2010 at 02:41:50AM +0000, corvid wrote: > > Do you think we should put image/stylesheet redirection under its control? > > I guess, if we would also restrict redirects, we could guarantee, > that we only load from a domain the user has entered at the loacation bar > or clicked on in a link - which sounds reasonable to me. > OTH do we know how that would affect usability with major sites? In Cache_redirect(), non-root urls never redirect currently.

April 8, 2010

patch: white-space: pre-line as well

by Johannes.Hofmann＠gmx.de

On Wed, Mar 31, 2010 at 03:39:26AM +0000, corvid wrote: > I don't know whether it's of much use, exactly, but while I was > in the conceptual area... Excellent! One step closer to full CSS2.1 compliance. Please commit!

April 8, 2010

web bug save?

by Johannes.Hofmann＠gmx.de

On Tue, Apr 06, 2010 at 02:41:50AM +0000, corvid wrote: > Jorge wrote: > > On Fri, Apr 02, 2010 at 07:07:50PM +0000, corvid wrote: > > > > I'd only suggest considering whether adding a URL flag (e.g. > > > > URL_FilterOut) provides more flexibility/clarity without having > > > > to add the 'requester' parameter to the API. > > > > > > Can you elaborate a bit on how/where the flag would be set, and > > > how it would help? > > > > I haven't looked at it in enough depth to offer a good > > alternative yet. Just noticed of the API changes, made an extra > > couple of passes above the code considering the flag or having > > referer in the DilloUrl struct. > > > > The idea is to commit it and to consider the alternatives > > later. > > All right, then. Committed. Cool! Quite interesting to look at all those DENY's! > > Everyone: > 1) This will surely require various tweaks. > 2) If it threatens to drive you insane in the meantime, there's a dillorc > option. > > > Do you think we should put image/stylesheet redirection under its control? I guess, if we would also restrict redirects, we could guarantee, that we only load from a domain the user has entered at the loacation bar or clicked on in a link - which sounds reasonable to me. OTH do we know how that would affect usability with major sites? Cheers, Johannes BTW. I also updated the display branch accordingly.

April 8, 2010

web bug save?

by corvid＠lavabit.com

Jorge wrote: > On Fri, Apr 02, 2010 at 07:07:50PM +0000, corvid wrote: > > > I'd only suggest considering whether adding a URL flag (e.g. > > > URL_FilterOut) provides more flexibility/clarity without having > > > to add the 'requester' parameter to the API. > > > > Can you elaborate a bit on how/where the flag would be set, and > > how it would help? > > I haven't looked at it in enough depth to offer a good > alternative yet. Just noticed of the API changes, made an extra > couple of passes above the code considering the flag or having > referer in the DilloUrl struct. > > The idea is to commit it and to consider the alternatives > later. All right, then. Committed. Everyone: 1) This will surely require various tweaks. 2) If it threatens to drive you insane in the meantime, there's a dillorc option. Do you think we should put image/stylesheet redirection under its control? [for reference, this thread dates back to http://lists.auriga.wearlab.de/pipermail/dillo-dev/2009-December/007118.html ]

April 6, 2010

css :visited and security

by Johannes.Hofmann＠gmx.de

On Mon, Apr 05, 2010 at 07:18:26PM +0000, corvid wrote: > Johannes wrote: > > On Tue, Jan 05, 2010 at 03:36:24PM +0000, corvid wrote: > > > The other day, I saw another of those pages about using :visited and > > > display in order to allow others to learn whether the user has visited > > > a page. (I remember Johannes pointing to a page about this last year, too.) > > > > > > I wonder whether it would be sensible to have a dillorc option defaulting > > > to NO for whether to use :visited. > > > > Yes, that sounds good. We should distinguish between remote / > > embedded CSS and user agent and user stylesheet though. > > For the latter two we don't need any restrictions. > > Does this look right? I'm also currently thinking about this issue - reminded by this article: http://blog.mozilla.com/security/2010/03/31/plugging-the-css-history-leak/ Maybe the fix implemented in your patch is too drastic. I would hope that something like the solution presented in the article above would be enough. If so, I would simply hardcode it and not make an option to disable it. Cheers, Johannes

April 6, 2010

css :visited and security

by corvid＠lavabit.com

Johannes wrote: > On Tue, Jan 05, 2010 at 03:36:24PM +0000, corvid wrote: > > The other day, I saw another of those pages about using :visited and > > display in order to allow others to learn whether the user has visited > > a page. (I remember Johannes pointing to a page about this last year, too.) > > > > I wonder whether it would be sensible to have a dillorc option defaulting > > to NO for whether to use :visited. > > Yes, that sounds good. We should distinguish between remote / > embedded CSS and user agent and user stylesheet though. > For the latter two we don't need any restrictions. Does this look right?

April 5, 2010

line-height

by Johannes.Hofmann＠gmx.de

On Sun, Apr 04, 2010 at 12:34:40AM +0000, corvid wrote: > Just committed some line-height code that Johannes and I wrote. Cool, good to have this in the official repo now. > > When line-height is less than the font's ascent+descent, unhighlighting > gets confused. I think it has to do with using the line dimensions for > 'area' for drawing the background. I'll dig into it a little more later on. > > PS I see that firefox puts more space between its paragraphs than we do. > Their value seems to be related to the font size, or the default font size, > or something. Is there anything deep behind our use of 9? I don't know where our 9 comes from. For firefox i guess it's the p, dl, multicol { display: block; margin: 1em 0; } from the useragent style[1], which would explain, why it scales with the font size. Cheers, Johannes [1] http://hell.meiert.org/core/css/firefox-3.0.1.css

April 4, 2010