On Tue, Nov 17, 2009 at 11:02:38PM +0100, Johannes Hofmann wrote:
On Sun, Nov 15, 2009 at 11:15:55PM +0100, Johannes Hofmann wrote:
On Sun, Nov 15, 2009 at 06:16:56PM +0000, corvid wrote:
Johannes wrote:
On Wed, Nov 11, 2009 at 12:35:49PM -0300, Jorge Arellano Cid wrote:
On Tue, Nov 10, 2009 at 11:06:30PM +0100, Johannes Hofmann wrote:
Hi Jorge,
On Tue, Nov 10, 2009 at 06:46:45PM -0300, Jorge Arellano Cid wrote: > Hi, > > On some sites I get weird fonts. Today I got to isolate the > problem. See attached file. Here it displays like this: > > http://www.dillo.org/test/xmp2.png > > The embedded CSS says: > > pre { font-family: MS Courier New, Courier, monospace; } > > If I remove "MS Courier New", it works OK. > Any clues?
There are multiple issues with font selection:
* The CSS parser only returns the part until the first blank ('MS' in this case). * StyleEngine currently does not handle comma separated font name lists (see \todo comment). * ::fltk::font(name, fa); in fltkplatform.cc does not offer a way to determine whether a font with that name actually exists on the system. Instead if no exact match can be found, it guesses a replacement font. This makes it impossible for dillo to choose the right one from a given list.
In your specific case, fltk gets the string 'MS' and on your system it seems to find some funny font that has a similar name.
Thanks for the detailed explanation.
I just committed a fix for the first two issues. This should also fix your problem. It still does not test all font names in the list as I don't know how to do that with fltk2, but it's a step in the right direction.
I was also sure that fltk would choose a default font for us, but I was just gdbing FltkFont::FltkFont(), and ::fltk::font() did come back NULL when given a font name that it didn't recognize.
I checked fltk::font() in src/list_fonts.cxx in fltk2. It returns a font if it finds one with a prefix that matches the given font name. This should be good enough for our purposes.
Good that you actually tried it. Then it should be straight forward to implement proper font selection.
Ok, I pushed a patch to implement proper font selection. Please give it a try.
Good. The former patch and this one solve the problem nicely.
There might be a performance issue if we test all possiblities evertime the comma separated list is converted to the real font in StyleEngine. This might need some experiments.
From my tests, the relevant code is only run a couple of times per page, so the current implementation seems ok to me, but please report any slowdowns.
I haven't noticed slowdowns yet. FWIW, if we find nasty slowdowns, it should be easy to map some problematic font requests to our defaults as a workaround. Most probably this will have a different API/implementation/solution in fltk3. -- Cheers Jorge.-