[I started working on a reply mere hours after the post I'm replying to, spending several hours, then getting interrupted by multiple plumbing troubles and other more pressing matters that usurped most discretionary time during the period since.] Timothy Pearson composed on 2014-11-12 21:38 (UTC-0600): > Felix Miata composed on 2014-11-12 21:42 (UTC-0500): >> Timothy Pearson composed on 2014-11-12 20:14 (UTC-0600): >>> Any further suggestions? >> Little new. :-( >> Better, but: >> 1-Spindly, worst looking "common" monospace font I've ever seen, Courier, is >> still what it's using, since Monaco is only found on Macs. On Linux >> installations that do not have M$ web fonts installed, and even on plenty of >> those that don't, Courier is extra bad, since it's usually an ancient bitmap >> font (available in limited sizes) instead of a vector font. > What is your font suggestion? Remember I didn't write the mailing list > archive software, so I am unaware of the design decisions behind these > strange selections. ;-) .... >> 2-font size is still disrespecting users. What purpose is served setting >> small on PRE here? > When I did not explicitly set "small" (i.e. the CSS default of "medium" > was used), on my unmodified Firefox installation the text was so large as > to render it unreadable without significant effort. Perhaps the > difference between my system and yours is related to the font issue? A good bit of the time I spent was trying in TDE on openSUSE 13.1 to get Firefox using as-shipped font settings on a 96 DPI 1280x1024 screen to reproduce "so large as to render it unreadable without significant effort". No joy, unless possibly that comment actually applied to Konq rather than Firefox, SeaMonkey, Chrom*, Safari, or IE.... >> Not previously mentioned: previous/next and month are set to .7em (physical >> size 49% of default). Why? http://fm.no-ip.com/Auth/area70.html > As mentioned above I'm not the designer of the ezmlm-archive software, so > I don't know. Suggestions for fixing it are welcome. Since you asked.... > In fact, if you want to draw up a replacement style.css incorporating your > changes I can test it here and let you know what I see and if there are > issues from my perspective. Monospace is a sticky wicket. There's no way to please everyone by declaring family and/or size for PRE content. Defaults and behavior among browsers vary rather more than one would hope. Some of the reasons for the complication can be found among comments in these old and unfixed Mozilla bugs: https://bugzilla.mozilla.org/show_bug.cgi?id=175415 https://bugzilla.mozilla.org/show_bug.cgi?id=328621 https://bugzilla.mozilla.org/show_bug.cgi?id=380915 https://bugzilla.mozilla.org/show_bug.cgi?id=437531 The best suggestion I can offer is the same as always, defer to the defaults selected by the user. With size and family declarations absent, the user gets those his browser is set to, and if he doesn't like them, it is he in best position to make whatever change it takes to best suit him. http://fm.no-ip.com/Auth/Tmp/ contains a bunch of iterations in the form trinityusers-lists-pearsoncomputing*.html created from a local copy of one archive message http://trinity-users.pearsoncomputing.net/?0::6951 as trinityusers-lists-pearsoncomputingSrc.html for a baseline. The iterations I like best are trinityusers-lists-pearsoncomputing5.html style6.css diff15.txt & trinityusers-lists-pearsoncomputing6.html style6.css diff16.txt 5 simply accepts the browser default font family and size for PRE text; IOW, it applies no font styling to PRE. 6 differs in making medium explicit. The digit in each iteration's filename corresponds to the style#.css each uses from http://fm.no-ip.com/Auth/Tmp/trinityusers-lists-pearsoncomputingSrc_files/ except for 0, which uses no style sheet at all, so that the original page content can be used to judge suitability of the browser's defaults. Style.css is your original. The same directory contains diffs to style.css in the form diff1#.txt for each iteration except 0, which amount to patches you could apply to make whatever set of changes you might choose. 8 screenshots can be found in http://fm.no-ip.com/SS/KDE/ in the form trinitylistarchiveDev*.jpg Zoom level in every browser window in them is 100%, aka 0, aka none. Numbers in the filenames 096, 120 and 144 indicate logical screen density of the X server the image was taken from. 4-digit numbers in filenames indicate the image's px height. The three newest ones, trinitylistarchiveDev096-stack47-3584.jpg, trinitylistarchiveDev096-stack7-3440.jpg and trinitylistarchiveDev120-stack7-4096.jpg have the highest information density, 7 browsers at full screen width in each with one of the test URLs loaded, intended to show subtle and not so subtle differences caused by adjusting browser settings and/or page CSS. From the top down in the three '###-stack??' images are these browsers: 1-Konq: defaults as shipped, stated in pt, which vary in px size by screen density 2-Chromium: defaults as shipped in 096; size raised one from default setting in 120 to keep its default size in physical pt the same as at 96 DPI. 3-recent Firefox; font sizes as indicated within image (by open prefs panels) 4-recent Firefox; font sizes as indicated within image " 5-recent Firefox; font sizes as indicated within image " 6-Firefox 3.6.28; font sizes as indicated within image " 7-recent SeaMonkey; font sizes as indicated within image " Selected comments about what may or may not be apparent viewing (mostly) the three 'stack??' images follow: The as-shipped for Linux Gecko 12px monospace default @96 DPI is physically 9pt (on a display that is in fact 96 DPI). Both Windows and Mac Geckos ship with 13px monospace, which @96 DPI is physically 9.75pt. Chrom* apparently provides 13px @96 DPI as well, which accounts for the PRE paragraph font size difference in '096-stack7' between 2nd (Chromium) and 3rd (Firefox) windows. Browsers, depending on platform, engine and version, sometimes truncate 9.75pt to using 9pt glyphs, while others round up to using 10pt glyphs. Visit http://fm.no-ip.com/Auth/Font/font-rounding.html in various browsers to experience their rounding breakpoints. This variation in rounding is the reason why you'll see in my diffs and stylesheets the seemingly insignificant replacement of .9em with .91em. The bottom two windows on '096-stack7', 6th (Firefox) and 7th (SeaMonkey), show the PRE content difference between 16px monospace unstyled by author declaration, resulting in fontconfig's family used in Firefox, and Courier specified via pref (only for the shot, a choice I would never make for any other purpose) in SeaMonkey. For '120-stack7', 3 of the 5 Geckos have proportional changed from default 16px to 20px, maintaining physical default size @12pt, and monospace changed from (Linux) default 12px to 17px, resulting in physical 10.2pt that the Geckos render using physical 10pt glyphs. The difference in physical size between a 12px font (CSS small) and a 16px font (CSS medium), the Gecko on Linux defaults for proportional and monospace, is nominally 56.25% vs 100%. Comparing this to Windows/Mac 13px (9.75pt) monospace, it narrows to 66.0% vs 100%. Due to the higher granularity between nominal sizes with the limited number of pixels each glyph has to work with at lower screen densities, the difference narrows, to a point, as DPI goes up somewhat. @120 DPI (125% of 96), 17px (~10pt) vs 20px (12pt) is reduced to 72.25% vs 100%. cf. http://fm.no-ip.com/Auth/CSS/css3/3.4/ for more on this granularity between smallest px sizes issue. The gist here is that on modest DPI desktops, the difference between CSS small and CSS medium is quite substantial. The newest (47) exists primarily to show the impacts of personalizing browser settings more than site CSS declarations. The top 3 windows, Konq, Chrom* & top Firefox, show wide disparity among the three with the page CSS declaring PRE text CSS small. Next window down (4th) has PRE text up'd from CSS small to .91em with same browser settings. That results in use of identical glyphs, but with character spacing increased (a feature of the font, not the OS or browser) to produce an illusion of larger size. Down one window further (5th) is the #6 page, CSS medium PRE instead of .91em. That results in taller glyphs with reduced character spacing that produce PRE output virtually identical in line width to the window above it. Next window down (6th) is again the medium page, but with the browser's monospace default increased by 1. Once again, glyphs remain same size as above, but increased character spacing makes apparent size larger. Last is medium once again, with the browser's default another size larger, 14px. Once more, taller glyphs with reduced character spacing produce PRE output virtually identical in line width to the window above it. Among all the PRE fonts in the 47 image, those in Konq are the only ones I find at all appealing, independent of physical size and/or legibility. This underlines why I use low resolution displays only for tasks that cannot be performed otherwise. There simply aren't enough pixels in fonts less than around 15-16px to not be un-appealing to my eyes. At 120 DPI, 14/15/16 cut through the CSS small/x-small range, just on the edge of legible anyway. Everything looks better constructed using more px for any given physical size, even when the density is purely logical rather than physical as well. One might think monospace font sizes among families would have the same pitch, but that is not the case. http://fm.no-ip.com/Auth/Font/fonts-face-samplesM.html shows not only this, but also, much like the just described 47 image, that apparent size varies considerably due to different stroke weights and x-heights incorporated by the displayed font's designer. Coupling apparent size variation with the disparity between CSS small and CSS medium, the possible combinations vary so widely that picking an optimal combination of monospace font family and monospace font size is a tormenting task. Using % or em can reduce granularity between sizes, but doesn't really do more than add to the difficulty of choosing a "best" or "optimal" for anywhere outside the room in which one sits. Luckily for stylists, deferring to the browsers' monospace defaults is not only easier than making those choices, but for the more popular browsers at least, it does a nice enough job for users who don't touch defaults, and a great job for those that do personalize their personal computing environments via browser font settings. Epilogue: The following has an excellent description of how big big appears to be in its last half: http://wm4.wilsonminer.com/posts/2008/oct/20/relative-readability/ -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/