Message: previous - next
Month: November 2014

Re: [trinity-users] Email server maintenance [patches available]

From: Felix Miata <mrmazda@...>
Date: Wed, 19 Nov 2014 18:13:00 -0500
[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?

> 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:

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. contains a bunch of iterations in the form


created from a local copy of one archive message



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
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

in the form


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
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 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. 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. 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.

The following has an excellent description of how big big appears to be in
its last half:
"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  ***