[Webkit-unassigned] [Bug 18001] point text too small at high system DPI

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Jul 20 17:18:41 PDT 2011


https://bugs.webkit.org/show_bug.cgi?id=18001





--- Comment #13 from Felix Miata <mrmazda at earthlink.net>  2011-07-20 17:18:41 PST ---
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.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list