Bug 18001 – point text too small at high system DPI

• Component: Layout and Rendering
• Status: NEW

[Felix Miata]

On a 144 DPI system, the system menu text (CSS font-family: menu) used for the app menus is 17px for apps like Firefox. Safari is arbitrarily assuming 96 DPI, which makes its menu text only 13px. That's a net size (size is area, not height) difference of (17^2 - 13^2) / 17^2 = (289 - 169) / 289  = -41.52% for Safari UI text compared to other apps' UI text. The same impact applies on web pages that size text in pt. Safari should at least via option if not by default use the same "menu" text as other apps for its menus and dialogs.

[Felix Miata]

Created attachment 19950 [details]
screenshot on 1920x1440 144 DPI WinXP system

[Mark Rowe (bdash)]

The browser chrome is part of Safari, not WebKit.  As I asked on IRC, please file this bug report at http://bugreport.apple.com/.

[Felix Miata]

You can see in the screenshot the pt sized text in the web page is too small. Compared to Firefox, which renders 12pt at 24px because it obeys the OS defined DPI of 144, Safari is rendering 12pt at only 16px, because it uses an arbritrary 96 DPI instead of the OS defined DPI.

[Felix Miata]

FWIW, https://bugreport.apple.com/cgi-bin/WebObjects/RadarWeb.woa/79/wo/kdoXnVCfPOqztnhP0StP6M/2.57.20.0.3
 is the Safari bug I filed.

[Christian Dywan]

I tried the test website in Midori. I can confirm that the fonts in 'points' are wrong, but the rest does behave according to my system DPI.

[Felix Miata]

This same problem exists on openSUSE 11.0 in KDE3.5.9 with Midori 0.1.2-7.1 from openSUSE's Gnome Community build service.

[Felix Miata]

Adding URL used for screenshot in comment 1 and referred to comment 5. For convenience of that page's users, content of cells with text content styled in pt have title attributes so stating. The images in the first cell are styled thus: 'width 1in' & 'width: 25.4mm'.

[Jean-Jacques Sarton]

Arora on Fedora 10: If the font-size is expressed in pt, the result seem to be calculated with the assumption that the display has always 96dpi. If th monitor has for example 132 dpi, the rendered textes are to small 

[Felix Miata]

(In reply to comment #8)
> Arora on Fedora 10: If the font-size is expressed in pt, the result seem to be
> calculated with the assumption that the display has always 96dpi. If th monitor
> has for example 132 dpi, the rendered textes are to small 

That may be because of default Fedora configuration forcing 96 DPI without regard to actual DPI (which is what OS X & Windows do). Do all installed browsers render http://fm.no-ip.com/auth/Font/fonts-ptdemo.html the same? If that is the case, Webkit would have no control over it. You would have to override the Fedora forcing of 96 DPI at either the system or user level. One way that can work at system level is to set DisplaySize in /etc/X11/xorg.conf. If you use the binary NVidia driver you can set your choice of DPI directly via xorg.conf. http://fm.no-ip.com/auth/Font/fonts-linux-about.html has general information about dealing with DPI issues.

[Jean-Jacques Sarton]

On Fedora the major browsers (Fitefox, Opera, Konqueror) work correctly, they recognize the correct dpi setting. The assumption that the default Fedora configuration (96 dpi) is therefore not true.

[Felix Miata]

Still bad in 531.9 (Safari 4.0.3).

[Felipe Contreras]

Same here (Fedora 15).

[Felix Miata]

In the GUI Personal Computer world's beginning, there was Apple. Apple begat a computer she called Macintosh, Mac for short. These various Apples only knew one DPI, and that DPI was 72, exactly the same as in the print world, so that WSIWYG could be on a Mac as the acronym implies.

Later was begat a competitor to Mac, whose name was Windows. The great one who begat Windows found it desirable for its larger, less resolute, cheaper displays than those used by Mac to make the display screen surface use a different, larger DPI[1], so that when seated at sufficient distance from its poor screens that poor text quality would not be objectionable, that the text would _seem_ to match in size that of text printed on paper, which is normally held closer for reading than the usual distance from eyes to display screen. [1] http://blogs.msdn.com/b/fontblog/archive/2005/11/08/490490.aspx

About this same time was begat "the web". The ad hoc development of the fledgling web was built from its designers assuming that screen text would always closely approximate text size as printed @ 72 DPI on paper. Thus, thousands, and millions, then billions and even trillions of web pages were constructed, unbeknownst to those designers, that display screens would not always conform to their assumptions, but eventually yield unforeseen and undesirable consequences causing those pages to be difficult or impossible or mere mortals to view and use in web browsers. While these many pages were being built, those who built them continued to teach new designers to build in same manner, such that alternative methods that avoid undesirable consequences were uncommonly known to even exist.

After many years of losing customers to the now more gigantic 96 DPI competitor, mother of Mac decreed that henceforth Mac would know only 96 on its screens. This decree encompassed the Mac's own native web browser eventually derived from a lesser competitor, KHTML, which subscribed to the theory that it should not lie to its users, but instead could display text on the screen to match specifications, be it actually a DPI of 86, 133, 147 or anything else, and yet not lie, able to produce 12pt text that measured 12pt on the screen surface when 12pt text as specified. Thus was born WebKit as a fork of KHTML, which would only know 96, and be unable to display 12pt text that measured 12pt except in the uncommon circumstance that the screen also happened to have a 96 DPI density.

After more years passed, another giant appeared, with goal to steal away users of Mac's browser and mega competitor's browser. Because Mac's browser was built upon an engine shared with all the world, the new giant deemed it suitable merely to put a different face on the shared engine. This new face was appreciated by many, and the new giant won away many users. Nevertheless the new giant's users were protected from discovering the many broken web pages, as it was using a shared engine built upon Mac's "there is only 96" edict.

It eventually came to pass, a very very long long time in coming, that Mac's major competitor noticed that the billions of web pages included many that were difficult to use because of either the millions of designers' assumption that there is only 96, and/or the mother of Mac 96 decree. Thus the competitor decreed that its 7 browser would only know 96, so that millions of poor pages would magically appear to be unpoor, and the user exodus could be retarded.

Once this occurred, there remained only one major and two significant minor competitors to Mac's mega competitor. Eventually the major noticed that fewer pages looked broken in others' browsers, and issued its own decree. This other major's decree differed from mother of Mac's and mega competitor's, by only making its browser to know 96 normally, additionally allowing it the option to know others.

Now all is well for the many bad pages, for all the majors know 96. Unfortunately, it has become nearly impossible for a web browser to not lie to its users and designers about sizes. When it doesn't, it almost always is an accident of fate that the user's screen is in fact 96. And still the designers continue to design stupidly, usually ignorant that 96 is _not_ all there really is, or ever will be.

[Gérard Talbot (no longer involved)]

(In reply to comment #0)
> On a 144 DPI system, the system menu text (CSS font-family: menu) used for the app menus is 17px for apps like Firefox. Safari is arbitrarily assuming 96 DPI, which makes its menu text only 13px. That's a net size (size is area, not height) difference of (17^2 - 13^2) / 17^2 = (289 - 169) / 289  = -41.52% for Safari UI text compared to other apps' UI text. The same impact applies on web pages that size text in pt.

Felix,

I agree with your analysis. If I could vote for this bug, I would but it is not possible at bugs.webkit.org

I always wondered why the text of menu bar and of other toolbars in Safari was so tiny and has been tiny for so long with no one apparently complaining about this or noticing this.

2 other points with regards to the menu bar and other toolbars in Safari 5.1.

1-
The text is black on mid-dark grey. Compared to Firefox in your attachment 19950 [details], the grey used by Firefox is lighter. This too makes it objectively harder, more difficult to read. There are known standards for sufficient color contrast/color brightness (for web content legibility though but even there...) and I believe Safari would fail here (one can use the The Juicy Studio CSS analyzer on this) .

Effective Color Contrast by Lighthouse International
http://www.lighthouse.org/accessibility/design/accessible-print-design/effective-color-contrast

Techniques For Accessibility Evaluation And Repair Tools from W3C
http://www.w3.org/TR/AERT#color-contrast 

2- Even the system command buttons for the window are smaller too: just compare them in your attachment 19950 [details] . That too contributes to makes the interface more difficult to use: it requires more mouse control (motricity) precision.

> Safari should at least via option if not by default use the same "menu" text as other apps for its menus and dialogs.

I think it should be by default, not via option.

regards, Gérard Talbot

[Gérard Talbot (no longer involved)]

> 2 other points with regards to the menu bar and other toolbars in Safari 5.1.
> 
> 1-
> The text is black on mid-dark grey. Compared to Firefox in your attachment 19950 [details]

> 
> 2- Even the system command buttons for the window are smaller too: (...)

Please forget about these 2 points. I just loaded Safari 5.1 in Windows XP SP3 to be absolutely sure and - what an unpleasant surprise!! - I was very wrong. The background is not mid-dark grey but light grey and the system command buttons for the window are those of Windows XP and so they are not smaller. My mistake!! Duh!!

Even the text in the menu bar appears appropriately sized (96DPI); it's the same size compared to Firefox 5.0.1. Windows XP SP3 here.

regards, Gérard

[Felix Miata]

You'll note as per comment 2 and comment 3 that this bug is particularly about the WebKit rendering engine behavior, not Safari's UI.

[James Craig]

Not specific to AX. Reassigning to Layout and Rendering component.