GNOME Bugzilla – Bug 625455
Fonts are too small compared to application font
Last modified: 2011-03-11 17:17:19 UTC
The default font on many web pages seems to be way too small. See the following screenshots: 1) http://nickurak.ca/~atrus/img/ssdAOzyB.jpg (gmail) 2) http://nickurak.ca/~atrus/img/ssnsk2Ab.jpg (packages.debian.org) 3) http://nickurak.ca/~atrus/img/ssNicDlD.jpg (almost empty html file) 4) http://nickurak.ca/~atrus/img/ssarS7oS.jpg (this bugzilla entry form) Here, my application font is set to 8pt. As shown in the screenshot, this is perfectly reasonable given the DPI settings of this monitor. (90 DPI in gnome-appearance-properties) Gmail, however, comes through almost unreadably small. It's so small in fact that the "bold" fonts for new messages is indistinguishable from the regular font. Details on packagen.debian.org are obscured. On some pages, it's not as profound. Screenshot #3 shows an html file as follows: <html><body>Bug 114228</body></html> Even in that case, it's clearly smaller than the usual application font. Screenshot #4 is this bugzilla entry form. Something is wrong here. It seems that I have a choice between making my desktop-wide font unreasonably large, or having my web browser fonts unreasonably small. Suggestions? Should epiphany be using the "Document" font from gnome-appearance-properties instead of the "Application" font? Is there DPI issue? This appears to be filed downstream as https://bugs.launchpad.net/ubuntu/+source/epiphany-browser/+bug/222256 and https://bugs.launchpad.net/epiphany-browser/+bug/72109 . It may be the same issue discussed at http://mail.gnome.org/archives/epiphany-list/2009-October/msg00041.html Suraia distributes a PPA that includes the following patch, which (if I'm reading it correctly) appears to just use the webkit default, whatever that is. It significantly improves epiphany's usability here: --- epiphany-browser-2.30.2.orig/embed/ephy-embed-prefs.c +++ epiphany-browser-2.30.2/embed/ephy-embed-prefs.c @@ -431,12 +431,6 @@ webkit_pref_callback_cookie_accept_polic static const PrefData webkit_pref_entries[] = { - { CONF_RENDERING_FONT_MIN_SIZE, - "minimum-logical-font-size", - webkit_pref_callback_int }, - { CONF_DESKTOP_FONT_VAR_NAME, - "default-font-size", - webkit_pref_callback_font_size }, { CONF_DESKTOP_FONT_VAR_NAME, "default-font-family", webkit_pref_callback_font_family }, @@ -444,9 +438,6 @@ static const PrefData webkit_pref_entrie "sans-serif-font-family", webkit_pref_callback_font_family }, { CONF_DESKTOP_FONT_FIXED_NAME, - "default-monospace-font-size", - webkit_pref_callback_font_size }, - { CONF_DESKTOP_FONT_FIXED_NAME, "monospace-font-family", webkit_pref_callback_font_family }, { CONF_SECURITY_JAVASCRIPT_ENABLED, @@ -499,7 +490,7 @@ ephy_embed_prefs_init (void) /* Hardcoded settings */ g_object_set (settings, - "auto-shrink-images", FALSE, + "auto-shrink-images", TRUE, "enable-default-context-menu", FALSE, "enable-site-specific-quirks", TRUE, "enable-page-cache", TRUE,
Related to bug 596396?
The application font is not (usually) a reasonable size for the content of a web page. In order to get around epiphany using the application font size I use the following script when launching epiphany to set it back sane defaults: gconftool-2 --set "/desktop/gnome/interface/font_name" --type string "DejaVu Sans 11" epiphany-browser& sleep 4 gconftool-2 --set "/desktop/gnome/interface/font_name" --type string "DejaVu Sans 10"
Reinout: That's a different bug, where layout problems happen if the font size is set oddly. This is about the font size not even being set as desired. Matt: As you can see in my screenshows, the application font is actually pretty reasonable, but the epiphany default fonts are smaller than the application font anyways, so we're in trouble right out of the gates. In retrospect, using the "Document" font makes sense, but is an entirely different issue from that described here.
(In reply to comment #3) > Matt: As you can see in my screenshows, the application font is actually pretty > reasonable, but the epiphany default fonts are smaller than the application > font anyways, so we're in trouble right out of the gates. > > In retrospect, using the "Document" font makes sense, but is an entirely > different issue from that described here. All relative fonts rendered in the browser are scaled relatively to the default font in the browser. So by using a default font based upon the application font (in my case 10pt) means that any website using relative font sizes (like em, or %) will be scaled relative to this font. Which means a 1em font size would be 10pt, and a .8em font size would be 8pt, or very very small (as seen on this very webpage). Using a Default font size of 12pt (or 1 pica (1/6 in) as per CSS spec) makes epiphany fonts render exactly as they do in chromium, midori, FF, etc. by default. The patch you pasted above seems make epiphany use the webkit defaults, which look to be 12pt or 1pc. So i think the real issue is that the application font, which is used in GUI elements, is not appropriate for a default webpage font. Your idea of using the document font would make more sense than the application font, a lot more.
Oddly enough, my font sizing issues dissapered as soon as I removed the ttf-mscorefonts-installer under Ubuntu. My guess is there's actually a problem with the sizing information for a font in there. I'm marking this INVALID, unless somebody can duplicate it without ttf-mscorefonts. (skipping NEEDINFO, since I'm the original reporter)
The sizing issues occur on Debian without ttf-mscorefonts-installer installed. I'm running epiphany 2.30.6. Can someone with the power unresolve this? Thanks.
Allright, shot in the dark i guess.
Indeed, I'm hitting this without ttf-mscorefonts-installer now too. :(
as an update I created a seed extension (you need the seed libraries compiled with epiphany-webkit) that sets the default font size to a more sane size. See here http://bazaar.launchpad.net/~mattread/ephywebsettings/devel/view/head:/ephywebsettings.js line 38 with 12 as default your fonts should look like normal
Seems this is just a duplicate of our old friend bug #598645 *** This bug has been marked as a duplicate of bug 598645 ***