I think I'll try Firefox soon.

> This simple setting (that needs to be set
> separately for each encoding) makes Firefox
> automatically enlarge all type that is smaller
> than the defined threshold.

Does it propagate the font size increase to the other/larger sizes, or does it just truncate up the bottom end? If it's the latter, that can disrupt proper information hierarchy through size (although that's admittedly not as bad as illegibility).

> ClearType definitely remains OFF on my machine.

It's interesting to hear that from such a "progressive" user. But I trust your judgment.

> What I'm really missing now is a well-done
> superhinted monospaced font that renders in
> two-pixel stems in the common screen sizes
> in the regular cut, and in three or four-pixel
> stems in the bold.

Would you settle for a pixelfont? You'd have to switch fonts with size however. How does Mana-16 look on your screen? It's not monospaced though.

BTW, don't the existing MS core fonts render with 2-pixel stems at your "ideal" size of 18? Oh, they do, but they become anti-aliased... What if you fooled with GASP tables to switch off anti-aliasing?

hhp

For a monospace alternative, I might suggest Bitstream Vera Sans Mono. It's well-hinted and has a bold weight -- even an italic and bold italic. Plus it's open source, so you can freely modify it without running afoul of any EULA. I'm not sure where your common screen sizes end up at, but 17PPM is where the regular weight goes to two pixels and the bold weight goes to three.

http://www.gnome.org/fonts/

Adam, you can also set minimum font size and resolution-specific sizing in the Mozilla Thunderbird e-mail client, which I recommend to anyone who loves Firefox.

Adam, have you considered using a typewriter?

Sergej,

for what, for *reading*? I thought typewriters are only good for writing...

A.

Lol. Okay, that thought somehow escaped me. You could hire a secretary to retype the text then. There

ClearType definitely remains OFF on my machine.

We read best the rasterisation that we read most.

I was looking at one of your recent screenshots, Adam, and couldn't understand how you can stand all those jagged, stepped curves. I've been working with ClearType so long (albeit, now, at a higher resolution than you), that black and white rendering even of superhinted fonts like Georgia, just looks wrong.

Sergej,

I need a monospaced font for programming, not for general-purpose reading.

John,

I like black type, not full-color/brownish ;)

Adam

I thought programming was writing. You are confusing me now

Sergej,

it's a special case. Programming with a typewriter is somewhat difficult, so it does require writing on a computer. There are a lot reasons for using monospaced fonts in programming. For example, when one needs to type vertically (in a "column mode") rather than horizontally.

Adam

Doesn't the tab button solve this issue? I almost want to ask you to show some code as a good example.

Are you saying that as long as there will be programmers, there will be a need for monospaced typefaces?

As long as there are graphic designers, there will be a need for monospaced typefaces. Graphic designers seem to like them, alot.

Especially young Swiss graphic designers, or designers from other places who wish that they could be young and/or Swiss.

Just take a look at the Lineto collection for verification of this far-fetched little hypothesis!

This is indeed an interesting phenomenon, and it's probably due to the "techy" feel of monospaced fonts - plus they look funky of their own, and that's a hot commodity.

I'm not a huge fan of that sort of thing, but one thing that does impress me is fonts that convey the feeling of monospaced-ness without being strictly monospaced - pretty sophisticated "language". Such fonts are rare though - I think Spiekermann/Schaeffer have some designs like this.

hhp

Luc(as) de Groot summed up the phenomenon very well in the specimen for Consolas in the Now read this book from MS: 'In display sizes, monospaced font's can't help having a punkish radiation, a voice to solve many a design problem.'

As a graphic designer / programmer, I appreciate the benefit of monospaced fonts when spitting out code. It's a formatting issue more than anything, but there are all sorts of other benefits. I also find monospaced type important for email. To each their own, of course.

Thanks for the colorzilla suggestion. That's one I hadn't heard of. Looks great!

More good news:
http://news.bbc.co.uk/2/hi/technology/4037833.stm

hhp

On my 100dpi Powerbook I use a monospace font for almost all my writing: programming, e-mails, diary, conference write-ups and MyFonts newsletters. In programming I've always liked to have similar lines lining up exactly: array[i] should align perfectly with array[j] and array[k]. The visual tidiness is a reminder of their semantic similarity. In other types of writing, I like to notice stray spaces, lowercase l's, and periods as I type. This is made more difficult if the speed at which the cursor moves is not proportional to the typing speed. To a writer, the w is just as important as the i. When proof-reading too, I find errors easier to spot in monospace: I suppose the seductive wordshapes put me off.

I use black-on-white Monaco 10 (1-pixel stems) for e-mail, where I spend a lot of time, white-on-black Bitstream Vera Bold 13 (2 pixels) for programming, and white-on-black Monaco 11 (1 pixel) for my Unix terminal. I should probably change the last one since the bold is synthesized and only legible in context (amazing how an m can be read easily even if it's a solid rectangle).

What a shame that writing and typography have merged in today's applications, and that the perfection attained by WordPerfect 5.1 for writers will not return any time soon.

> I find errors easier to spot in monospace

Because it favors letterwise reading more than immersive*, due to its:
- overall greater looseness.
- out-of whack boumas.

* Where typos are ignored for the sake of efficiency.

> white-on-black Bitstream Vera Bold 13 (2 pixels)

Could you show a screen-grab of that?

> What a shame that writing and typography have merged

Indeed.
WYSIWYG being the succubus.

hhp

Sergej,

in my programming work, I often work in a column mode, where I can make rectangular selections in the text editor.

Example: when editing feature definition files, after having pasted some glyph names from Microsoft Excel, I want to be quickly able to type "sub" and "by" in the appropriate positions. Or, for example, type ".ss02" at the end of some glyph names that are aligned in a column. See:
http://www.twardoch.com/tmp/dlig.png

Programming often involves putting repeating or similar sequences in different arrangements. Your eye needs to jump up and down often, when comparing, for example, two different function definitions. Just like the baseline gives an unified horizontal text structure in a normal reading process, monospace metrics provide a vertical visual aid. It's much easier to notice if a line is "off by one" or that you have mistyped some variable name if your text is aligned in monospace blocks.

As mentioned before, currently, for most of my monospace stuff I stick to Lucida Console which has the nice property of having quite short ascender and descender. This actually doesn't disturb me at all -- I can read it very easily despite minimal interline spacing. Kudos to Bigelow & Holmes!

Regards,
Adam

> http://www.twardoch.com/tmp/dlig.png

That's quite huge! People should note that your display has a very high dpi. At that dpi/size handmade grayscaling is less advantageous.

Questions:
1) That's the Bold, right? The Regular weight (the left column of numbers?) remains aliased, and somewhat malformed. Did you previously say you'd like to have a good second weight, or was that somebody else? Do you use the large size Bold [partly] because that's where anti-aliasing kicks in?
2) Don't you think it's a little bit wide?
3) How do you feel about semi-serifs in a coding font?

> the nice property of having quite short ascender and descender.

I think that makes a lot of sense for a coding font, maybe even mono fonts in general.

hhp

when I first started programming was on a DEC VT 100. then used Think-C and Think-Pascal on Mac SE.. the default was Geneva but I changed to Courier because I couldn't read the code as clean as Courier which was like the terminal font on DEC VT 100.

Now I'm using MS Visual Studio .NET and this is a HTML page in it it's cool. And Macromedia Flash MX does the same thing when coding in actionscript where it suggests reserved words and formats automajically.

on Mozilla Fox I find the way it shows an icon when it's loading a gif or jpg is worse than IE since it looks slowere and IE shows nothing till it loads. I like Mozilla but not sure yet and use Safari on the Mac. IE on it formats some HTML weird and not the same as on Windows.

Hrant,

> That's quite huge!

Well, the height of the capital "Z" on my monitor is about 1.8 mm.

> People should note
> that your display has a very high dpi.

Yes, I wrote about this in my very first message in this thread.

> 1) That's the Bold, right?

What? Of course not! The numbers are set with a different typeface, not Lucida Console. What you see is Lucida Console regular, and it doesn't have a bold. I would love to have a corresponding Bold that renders 3-pixel stems.

> 2) Don't you think it's a little bit wide?

No, I actually quite like it. In programming, many lines are rather short. A narrow font would make the source code occupy some 1/2 of the screen, while the other half would remain empty.

> 3) How do you feel about semi-serifs
> in a coding font?

Mmm... What do you mean? Well, Andale Mono is fine, if you ask me, but should be bolder.

Vincent,

I hate Courier. I *always* change it to Lucida Console or Andale Mono whenever I get the chance: in Visual Studio, Internet Explorer, Notepad, UltraEdit etc. etc.

Adam

So Vincent, I guess the colorful fur doesn't bother you?

Adam, very useful feedback - thank you.

The semi-serif thing is coming from the need to make some letters fill the width while others are wide enough (or too wide, like the "m"). As far as I can tell virtually all mono fonts have this to some extent, usually on the "i" and "el". The thing is, when you have too few of them, they make the font less harmonious. That and the need to fill the space make me think that more serifs (often just half-serifs) can help.

Here's a fake code setting I'd love to hear comments on:



It's 14 pixels tall (lc). I think it would be the Regular weight, and would get both lighter and darker companions. I can make a 12, but I don't think I should go below that. If I made a 16 (one pixel shorter than the font in Adam's screen grab) I would probably need to increase the width from 9 to 11, or 12.

hhp

And here's a quick shot at a 16:



The width will be 11, but what I can do instead of the above is make [most of] the bodies wider, instead of having 2-pixel sidebearings. This would give it greater apparent size, but more erratic overall spacing.

hhp

And here's a 16 derived [more] from Mana16R rather than Mana13B:



BTW, the blank spaces in the previous 16 sample were too narrow by 2 pixels.

hhp

And back around again to a new 14, 11 wide and rounder:



OK, I'll stop now. :-)

hhp

Here's a sample of the Bitstream Vera Bold 13 I use in programming. I highly recommend trying light-on-dark text for prolonged periods at the computer. I think it's more than nostaligia for 1980s CP/M machines!

Oh oh, let me play too!

This is my usual set-up in UltraEdit: using Luc(as) de Groot's new Consolas typeface, one of the Microsoft ClearType fonts for Longhorn. My effective screen resolution is even higher than Adam's (146 ppi), and I do use ClearType, so if this looks large and fuzzy on your screen imagine it small and not fuzzy. The green, however, is a poor choice for comments on a white background, as the contrast isn't sufficiently high, so I'm losing weight on the diagonals.



And here is this message, as I was composing it in Firefox, also with Consolas:

Is the larger size using sub-pixels? It doesn't look like it. BTW, you're losing the diagonals a bit even on the black-on-white; look at the "y" in "hyphen"*. There's also some fuzziness in some glyphs, like the "t". Is that perhaps because the font was optimized for smaller sizes (since most users have far lower ppi)?

* Is it possible your gamma is very different than mine? If so, could you embed a profile in the image or something? BTW, PNG is supposed to do that automatically, right?

The smaller size looks like bone fida ClearType, although it has a lot less color-fringing than I've seen on current CT renderers. On the other hand, it still has some blur, and some strangely malformed glyphs, like the "s".

--

So I'm wondering if you guys can answer this:
What are the relative importances of even spacing versus apparent size in a coding font?

hhp

Cleartype works great on this laptop because it's 1680 x 1050. But on cheaper monitors it's fuzzy. So on this Alien laptop I didn't even notice cleartype was on.

The colour of the formating doesn't bother me since it separates what isn't code from what is.

I don't use the pop up suggestion thing much in Flash or VStudio.

What's OSX use in the Unix console?

Hrant: Is the larger size using sub-pixels?

Actually, no, it is not: that's just old-fashioned anti-aliasing. Weird. UltraEdit doesn't seem to be using the latest system APIs for rendering. Now you think I would have noticed that. Doh! The lower sample is, as you note, ClearType.

But here is the same sample, in the same size (nominally 12pt) in a CT test app with subpixel positioning activated. I can't do the code colouring in this app, but I set the text to be the same colour as in the comments above, so that you can see the immense contrast improvement even with such a light colour.

What's OSX use in the Unix console?

The default Terminal font is 10 pt Monaco.

> UltraEdit doesn't seem to be using the latest system APIs for rendering.

I didn't realize that apps get to choose, not just whether to use CT, but even what flavor?

This new sample is indeed much better.
But why was Adam's sample so much better than your previous non-CT one?

> 12pt

And that translates to an 18-pixel lc vertical span? That's like 2 pixels beyond the Em limit... Lucida does this too, right? Can't this become a problem, both technically as well as in terms of usability? What's the advantage of "cheating" like this?

hhp

BTW, could we see that last setting in black?

hhp

Warning:
There are some big mistakes of vertical proportion in those sample I put up. :-/

hhp

I didn't realize that apps get to choose, not just whether to use CT, but even what flavor?

Normally, they don't. I'm going to write to the guy who makes UltraEdit and find out what he is doing. It is even possible that he is doing his own rendering with FreeType, bypassing the system rasteriser.

But why was Adam's sample so much better than your previous non-CT one?

Adam is using a font with very heavy hinting, designed for b/w and greyscale rendering. Consolas is designed only to be used with ClearType, so the hinting is very light, especially in the x-direction.

Here is the same sample in black.



Of more interest, I think, are the comparisons below that show 11pt and 9pt text with subpixel positioning turned off (first line) and turned on (second line). This shows how subpixel positioning adjusts spacing to match as closely as possible at each size the actual advance widths of the glyphs, while the full-pixel positioning loosens the spacing at the larger size and tightens it at the smaller size.

The black is certainly showing it's colored fur more... It's not too bad though. On the other hand, once you resort to [some] blur and fringing, why would you still get malformed rendering in places, like the spine of the "S"/"s"?

The lower comparison is pretty interesting - thanks.

hhp

On the other hand, once you resort to [some] blur and fringing, why would you still get malformed rendering in places, like the spine of the "S"/"s"?

I haven't thoroughly analyzed the new ClearType tech, but it seems to me that the rendering is not fundamentally based on traditional antialiasing. Rather, results seem to be consistent with rendering to a bitmap with 3x the horizontal resolution, then filtering the result to bring it to an RGB subpixeled image with the worst of the color fringing suppressed.

If that's the case, then near-horizontal strokes will more closely resemble old-style monochrome TT rendering than Mac OSX-style grayscale.

I'm not saying they really are going to a bitmap; from what I know of previous generations of the technology, it's most likely that they are going to an intermediate grayscale bitmap (with 3x the horizontal rez as mentioned above), then doing massive contrast enhancement along with the color-fringing filtering. If you read the CT patents, you'll find quite a bit of nonlinear filtering machinery that should be capable of these operations.

The remaining trick, of course, is to tune everything, and supply the hints in the font files, so that it all looks good. I think MS and its stable of font designers have done that, thanks to their ability to invest massive amounts of time, energy, and money.

But one question is, why not hint more to get:
- Fewer malformed parts; that "s" is pretty disappointing.
- Good rendering when CT is off (re: John's first large sample).

hhp

For comparison, here is the same text set in Vera Mono 19ppem using FontFocus technology. The alignment is a bit wobbly because it's tuned for proportionally-spaced fonts; that should be fixed for monospace use.

Hmmm. Although it's free of colored fur, that's actually causing my eyes to struggle focusing, almost like wandering around trying to figure out what to do - pretty unpleasant. I guess blur comes in different flavors.

hhp

...why would you still get malformed rendering in places, like the spine of the "S"/"s"?

Design. This version of ClearType applies font smoothing in the x-direction only, which means that shallow horizontal curves will still be visibly 'stepped'. This is often noticeable in S/s and in some forms of the letter a (e.g. Helvetica). In the Windows XP and earlier versions of ClearType, this was true of all sizes, which is why display-size type actually looks worse in CT than with traditional anti-aliasing, which smooths in both directions. The new version of ClearType, which will ship with Longhorn, applies greyscale anti-aliasing in the y-direction at sizes detemined by the designer in a new gasp table (see page 14 of Now read this). The CT test app I have which can use sub-pixel positioning does not yet use the y-direction anti-aliasing, so I can't show this very well in text samples.

Below is a cascade of ppem sizes for the Consolas S, the top line with the current CT rendering and the bottom with the new y-direction antialiasing activated. Note that the gasp table settings in this font are preliminary, and the final version may differ. Note also that this image uses up all 256 Gif colours, so may not provide total fidelity.

hrant: If the softness of focus is consciously apparent, the resolution of your display is simply too small. It's going to take a while for displays with adequate resolution to penetrate the market. I believe the release of Longhorn will catalyze this due to its planned good support of hi-res displays. When this happens, all advanced font rendering technologies (FontFocus, Cleartype, and the MacOS with RGB subpixelling all count) will deliver sufficiently good results that additional hand tuning is unlikely to be worth it.

John: what's the best way for me to get a copy of "now read this"?

Cool comparison! Thanks.

So you're saying that your bottom sample does use y-direction a-a, but cannot yet do that in conjunction with subpixel positioning, right? (This is getting complicated...)

Speaking of cascading :-) here are two resultant questions:
1) Do you know why they're only turning on the y-direction now and not since the beginning?
2) To get basically vertical, non-subpixel [rendering] of a-a in a non-y-enabled engine, why not render a 3x2 grid per pixel (instead of a 3x1), and then: do your CT magic in the x direction; but sample it down to grays (in the "normal" a-a way) in the y direction? Performance? Wait a second: I think I might have just described what y-enabling basically is! And maybe if it is a performance issue they were waiting for computers to get fast enough...

--

> the resolution of your display is simply too small.

1) Yes, but it's also typical of users.
2) For some reason those smaller-size samples you once posted didn't suffer from this. Also: CT doesn't suffer from it, neither does the (more-blurry) MacOS rendering, and in fact I think neither the full-fuzz stuff (like Photoshop). That's why I was saying there seem to be "flavors" of blur; maybe it's due to some parts of your rendering being very crisp and others very blurry?

hhp

Correct. I have two apps that can show aspects of the new CT rendering for Longhorn, but neither can show all aspects together

1) Do you know why they're only turning on the y-direction now and not since the beginning?

They hadn't worked out the math for the interaction of the CT colour rendering in the x-direction and the greyscale in the y-direction. They also hadn't figured out how best to apply it. Beat Stamm's first trials turned on the y-direction smoothing at all sizes but made it progressive. But eventually they decided that this should be design-specific, so should be controlled via an update to the gasp table. The latter has not been published yet.


Raph, I've afraid I also have problems with your FontFocus example, and my resolution is high (146 ppi). I'm not sure exactly what the problem is, but the symptom is a kind of sparkle. Take a look at the crossbar of the e in the word 'ampersand' for example, there is a loss of both focus and contrast.

If you sent me your mailing address (to tiro[at]tiro.com) I will pass it along to Geraldine Wade at MS, who can send you a copy of Now read this. There will also be copies in London at Typotechnica in February, for those who didn't get them at ATypI.

Take a look at the crossbar of the e in the word 'ampersand' for example, there is a loss of both focus and contrast.

Yes, this is because the FontFocus technique really works in the x direction. The issue with the crossbar of the 'e' is that it always perfectly preserves the vertical proportions of the original glyph. Hinting-based techniques will increase or decrease the counter size to get better grid alignment.

Whether this is a good thing or a bad thing seems to me a judgement call. Obviously, if the overriding goal is maximal contrast, then you want hinting. On the other hand, hinting loses things such as consistency between sizes. Note that the space between the two monocles of the 'g' is considerably larger in the nominal 11pt Consolia than either the nominal 12 or nominal 9.

hrant: Yes, 100 dpi is universal on desktops, and resolutions higher than 130 dpi or so are rare even on laptops. Over the long term, I think it's inevitable that mainstream displays will reach 200 dpi. It all depends on whether you're trying to solve immediate problems or design for the future; I tend to do more of the latter in my own work, but there's a lot to be said for making users happy now.

Just for fun, a FontFocus rendering after a little tweaking of horizontal stem positions in fontforge.

In the morning, all type is blurry.

John,

I just arrived in Boston and am looking on this thread on my PowerBook rather than my usual Dell, so the screen density* is less.

* I use the term density for the ppi resolution, in order not to confuse it with the screen pixels size, traditionally called resolution.

Just some quick feedback: I looked briefly at the Consolas sample that John posted, and had to turn my eyes away immediately. This is really strange -- I really seem to react very heavily to ClearType rendered in low densities (my current PowerBook is standard Mac, which I guess is 96 dpi nowadays).

Regards,
Adam

> Over the long term, I think it's inevitable
> that mainstream displays will reach 200 dpi.

Define "long". I was planning ahead for higher res when I started Mana-16 more than six years ago. It still looks too big. :-/

> had to turn my eyes away immediately.

It's definitely nothing like that bad for me. Although what you describe does sound like my experience with the FontFocus sample.

hhp

Adam, are you familiar with the 'developer syndrome'? This is something that was noted by Microsoft in their studies of acceptability of ClearType. Only five percent of people involved in the studies objected to ClearType and reported it as unacceptably fuzzy (even when tuned), but this percentage was higher among a group identified as 'developers', i.e. of programmers and other software developers. The phenomenon is not explained, but I suspect it has something to do with the fact that such people have been looking at text on screen for longer and in greater volume than the typical member of the population at large. So it may be that developers have become deeply accustomed to particular kinds of screen text display, and find anything divergent to be difficult to handle.

And, of course, you may have particularly acute sensitivity to colour fringing.

I also find ClearType much less pleasant on 96 ppi screens, but still prefer it to the jaggy letters of b/w rendering.

Adam, do you think optics of your glasses are playing a role in your problem with sub-pixel rendering?

About this 5% business:
As I've said before, it sounds highly suspicious. Only a short while ago MS was justifying turning off a-a (in text sizes) because users were overwhelmingly against it. Although improved algorithms and resolutions can shift things around, it's really hard to imagine such a huge flip-flop. And wasn't Simon saying that that number is actually coming from some highly informal process? Or maybe he was talking about something else. Where's that thread?

hhp

Raph: You say, as have many before: "Over the long term, I think it's inevitable that mainstream displays will reach 200 dpi". On what grounds do you base this? We're deluded if we think all computer-related technologies follow Moore's Law. There's simply minimal demand for these improvements that so many engineers and evangelists think are just around the corner.

In printed output there's little further to be done, even on

And big screens placed far away have the obvious problem of physical space constraints. I don't know about you, but my computer isn't sitting on one of those dinner tables you see in mansions. Not to mention that you don't want your laptop to extend to the coffee shop's bathroom or the pilot's lap...

hhp

Hrant, Si's comments about an informal process were in reference to CT tuning preferences. The 5% figure arises out of some of the studies Kevin Larson has been involved with, I believe. My own inclination is to ignore the actual figure, since I don't know how large the sample was (obviously large enough to be classified into separate groupings, e.g. 'developers'), but acknowledge that it is a small percentage, even if one applies typical plus/minus accuracy adjustments.

MS turned off antialiasing for text sizes in non-CT rendering because it reduced contrast (degraded the notan, if you like). ClearType font smoothing maintains the contrast even at text sizes, so I don't think it is surprising that these two font smoothing technologies would be differently received.

John,

yes I chatted with some of the MS guys about the "developer syndrome". I must say that in some places, I find ClearType acceptable, or even pleasant. For example, in MS Word's reading mode, especially using serif type on white background. But well-hinted pure black-and-white sanserif bitmaps e.g. Verdana, Nina, Lucida Console are unsurpassed for programming, user interface elements and the such. I think CT in my menus is useless, but in the main body of Word it's fine. In other words, I think CT is OK everywhere where it's supposed to simulate printing, but there is also place for distinct screen typography that is more like signage than print. I don't dislike CT on some portions of the screen, but every time I turn on CT system-wide, I'm dreaded.

And of course, I've been reading type on screen for the last 19 years (which is 2/3 of my life). So yes, I do have a very strong picture of what screen text should look like. I have a sense that ClearType is NOT very good for long-time reading because it may subconsciously strain the eye. Every time the eye sees something that the brain thinks is off-focus, the eye tries to focus on it. IMO, ClearType may cause this effect. I'm not sure if Microsoft tested how ClearType works in long-time reading.

Sergej, I think it is possible that the optics of my glasses may have something to do with it. But Iit's not the particular pair of glasses I wear, I checked different pairs with the same effect. Since I don't really know the world without glasses (started wearing them at the age of 3), I can't really tell if this is the "problem".

Best,
Adam

> well-hinted pure black-and-white sanserif bitmaps e.g. Verdana,
> Nina, Lucida Console are unsurpassed for programming

1) But the sample you previously showed of your programming text was anti-aliased.
2) In case you really mean that, do you think there's a threshold beyond which gray pixels can help while not adding blur? Or even if this is so, do you think this threshold extremely high, like comparable to print resolution?

BTW, I've been reading onscreen type for 27 years (3/4 of my life) but only in the past 1/6th of my life have I known what it "should" be! :->

> I'm not sure if Microsoft tested how ClearType works in long-time reading.

If John is right that this is related to Kevin's work, considering the conclusions about readability that he's arrived at, I'd have to sadly conclude: no. With the elaboration that more important than how long you test something is how well you test it. And by "well" I don't mean how fancy your hardware is or how much money you throw at it. For one thing, from what I know no serious comparisons have been made between CT and print, just CT and other screen renderings (and notably not including hand-made grayscales).

A lot of corporate field testing seems to address the conscious realm, and furthermore is conducted in draconically controlled labs (not real environments). This is not readability.

hhp

John, what's this thing about a "standard ClearType x-height", and linespacing too?

hhp

That's a reference to decisions made in the development of the six new 'western' (Latin, Cyrillic and Greek) types for Longhorn: the MS ClearType Font Collection. So this isn't a 'standard ClearType x-height and linespacing', it is an x-height and linespacing that is common to this particular set of ClearType-specific fonts, which we wanted to work together in such a way that a user could combine them on the same line and not have the linespacing change or the x-height vary too much. Actually, the x-height does vary a bit, but this is more noticeable in print than at text sizes on screen: Constantia has a smaller x-height than the other designs, and Consolas has a slightly taller x-height. Calibri, Cambria, Candara, Corbel have harmonised x-heights.

I agree that the wording in Now read this is not ideal, because it suggests that these design decisions are somehow standard to ClearType, rather than standard to the ClearType Font Collection.

I haven't enough time to read this whole thread at the moment, but I find it greatly interesting and will be back as soon as I can!

What are the relative importances of even spacing versus apparent size in a coding font?

They both have a lot to do with readability, but I would say even spacing is more important. Some monospaced fonts are so easy on the eyes they look nearly like proportional fonts.

> Some monospaced fonts are so easy on the eyes

Like which?

hhp

Regarding screen resolution (or density, to use Adam's distinction), I suspect that the majority of displays, especially for home users, will eventually level out around 133 ppi. Such densities are becoming more common on laptops, and as prices come down they will sell themselves simply because they look so much better in the shops. I share Laurence's skepticism regarding 200 ppi screens, lovely though they are: the demand outside of specialist markets (e.g. medical) is very limited.

I think that ClearType text on screen will actually be a significant factor in establishing a common screen density higher than 120 ppi. The 'sweet spot' for ClearType rendering is somewhere between 120 ppi and 135 ppi, depending on the individual monitor gamma. At that density, I think most people will have little trouble with fuzz, and you start getting decent serif rendering (i.e. serifs that are not the same weight as the main stems, which turns every typeface into an Egyptian at text sizes).

One thing that might create substantial demand for higher density monitors is if studies eventually show net benefits in productivity, i.e. faster and more accurate reading times, for subpixel rendering on such displays. Solid data on this could prompt large corporations to invest in such screens. This seems to me more likely than a significant growth in the user of high-resolution monitors by home users.

> I share Laurence's skepticism regarding 200 ppi
> screens, lovely though they are: the demand
> outside of specialist markets (e.g. medical)
> is very limited.

I actually think the contrary will be the case. These screens will reach the general public, simply as a result of competition and the manufacturers seeking broader financing for their technological development. Look at personal computers these days: for an average Office users, 2.5 GHz processors are far too powerful, so new areas of entertainment are created by marketing experts (such as home video editing) and super-multimedia computers are sold to general public so the people get the chance to throw away their old hardware -- which mostly actually works fine. Look at software manufacturers such as Adobe or Microsoft, releasing new versions of their software every year, or two tops. Adobe keeps developing Photoshop although 95% of the the application actually is good enough for 95% of the users. And Acrobat 7 is waiting to hit the stores although many users hardly switched to Acrobat 6 from previous versions...

In a continuous strive for incoming cash, companies need to put out products that offer evident advantages to users, so the users are willing to give up their old products even though they're still functioning.

The superiority of a 200 dpi screen is evident: the quality of text is much better, and my guess is that the world is moving towards on-screen reading more and more. Printing and paper is expensive and unecological.

The only substantial ship-stopper is that a lot of screen design is bitmap-oriented nowadays. With heavily diverging screen dentisites, it gets more compilcated to design websites, but then again, since high-bandwidth net connections are gaining popularity, it is possible that soon, websites will be designed in high resolution and will be automatically subsampled for low-res screens.

Adam

Developer Syndrome could be because programmers concentrate on reading and writing individual characters rather than long text.

In an environment where ` and ' convey different meanings, the character clarity of well-hinted fonts, or point specific bitmaps, is often preferable to anti-aliasing (at least in my experience).

If this is a developers main experience with on-screen text then "we read best the rasterisation that we read most" probably comes into play for all on-screen text.

> serifs that are not the same weight as the main stems

This is only true if you feel stuck with 1-pixel stems (for which there's no real need as far as I'm concerned, at least not above 13-14 PPEM). And even if you use 1-pixel stems, you can make your serifs a dark gray (around 60) to make them appear thinner than stems.

But anyway, when you think about it, egyptian serifs aren't the worst thing that can happen to onscreen text! Serifs do help readability after all.

> Solid data on this could prompt large
> corporations to invest in such screens.

While I think the desire to sell fancier screens could prompt large corporations to invest in studies that concoct such data. :-/

MS comes up with the data necessary to sell its goods, period.
That's where that 5% for example is coming from.

--

> the character clarity of well-hinted fonts, or
> point specific bitmaps, is often preferable to
> anti-aliasing

Only if the anti-aliasing is lousy (not hand-made).
When anti-aliasing is done properly, it only adds decipherment information.
You can use grays to pull away undesirably close glyphs, such as the italic "ae"/"oe".

hhp

>> Some monospaced fonts are so easy on the eyes
>Like which?

Below is an example of what code looks like in my editor using a bastardized Vera Mono that I've dubbed Lava Mono 9...



Please forgive that the bottoms of some lines are cut off. The editor is using a different font for the equals sign, so any line with an equals sign is pushed down 1 pixel, chopping off the bottom. This drives me CRAZY!!

But other than that, I feel pretty comfortable with this font. Its easy to forget its monospaced (the colors help), though I'm sure it could be even better (grayscale, tweaked by the font masters here, etc).

As for ClearType, I find the font smoothing to be too much, especially for programming. From what I've seen experimenting with it myself, the glyphs become distorted and the character spacing ruined. These are extremely important while programming.

It's certainly crisp, but to me the 1-pixel is too light, and the 2-pixel malformed and badly spaced.

> the character spacing ruined.

As John has explained however, Longhorn will benefit from subpixel positioning, which will certainly help a lot. On the other hand, this means glyph rendering will vary: two "e"s next to each other will come out [slightly] different.

hhp

BTW, here's a comparison with Mana-13:



Although it's not monospaced* I figured it would give you an idea of what's possible. To help the comparison I've tracked Mana looser by a pixel and turned off kerning. Note that both settings have a lc vertical span of 13 pixels, but Mana-13 has a much greater apparent size. For leading however Mana-13 prefers one more pixel than what you have.

* Yet. :-)

hhp

I wrote:
> MS comes up with the data necessary to sell
> its goods, period. That's where that 5% for
> example is coming from.

To clarify:
I don't think a person working at MS is necessarily dishonest*. In fact the few MS type people I have met seem genuinely good; but they only work there. What I was trying to say is that MS (like any other corporation) hires people who are likely to help out their sales. Any opinion about anything is out there, and companies who value money more than "truth"** make it a point to harness what suits them. For example when MS heard Stam give a talk at RIDT about his hinting work in college, they realized it's just what they "needed" and brought him on board. Now that hinting can't generate sales anymore it's been depracated.

* Hey, I do work for DISNEY...

** And the ones that prioritize culture over money do poorly in Capitlastism.

I have a lot of respect for MS Typography, but that's due to the individuals who are there vying for quality and in spite of the nefarious "parent" trying to drive things its way. As always, it's a tug of war, or an "amour violent", between individuals and society.

The same applies at places like Adobe btw. I think Thomas and David are great people who care about type, but in effect they're wrestling with an entity that's driven by shareholders, people who don't give a hoot about anything more than buying that yacht as soon as possible. Well, at least they certainly don't care about type.

We have to apply this context to understand where specific things (like CT) are really coming from.

hhp

people who don't give a hoot about anything more than buying that yacht as soon as possible. Well, at least they certainly don't care about type.

I thought type was the route to a yacht! Now you're telling me otherwise?!? I may have to rethink the retirement plans... ;)

Well, do note that Gerald Giampa seems to have made it to a yacht - although he's an exceptional sort of fellow. I know I don't have the sealegs.

hhp

Right now I would share a monospace with a foxy.
I love the font Monaco, 9 pt.
AS

OK, here's a collage/comparison of Adam's screen grab and my first serious beta of a mono grayscale pixelfont:



Coda-14R takes up the same horizontal space, but is three pixels shorter (in the lc) - although its larger x-height and looser spacing translate to a de facto savings of only 1 pixel of leading per line. Coda trades apparent size* for more regular spacing (using serifs towards this end as well) and a gentler color. Please let me know what you think of it, and whether you'd prefer seeing it paired to a 1-pixel or a 3-pixel cut.

* I could add a pixel to the x-height (making the font a 15) to equalize the size, but not everybody has Adam's and John's ppi! In fact I'll probably need to make a smaller cut as well - maybe a 13 with 1-pixel stems (and a width of 8 instead of 11). And then an 11 size could follow that, although it would still have a width of 8.

hhp

Hrant,

Coda-14R looks pretty rad! It'd be great for writing e-mails as well. It just has nice feel to it. I'm curious what a comma would look like since the "comma" part of the semi-colon looks a little bit high.


Lauri

Thanks for the comparison Hrant! Mana-13 is very nice indeed. Coda looks interesting as well.

I look forward to seeing Mana-11 Mono. I'd be willing to make a donation to speed its development if you are willing to target it toward programming (maybe under a different name?). There are some specific things that I would like in a programming font. I'll ramble off some...

I like the open bottom of the g. /, |, and \ should extend as high and low as possible. "1lI", "ji", ",.;:", "({[", "$Ss", "0Oo", etc all need to be very unique so they are not easily confused. * should be centered. <and> need to be quite pronounced. The bottom of _ should be aligned with the bottom of the alpha characters. $ should be quite tall (it is used as a variable prefix in some languages like PHP: $foobar). The bold version of the font must be the same character width as the regular. Most TT fonts I try in my editor lose their usefulness as monospaced because the bold is wider than regular. I guess I need a seperate version of the font in bold? Vera Mono comes this way and is one of the few that work. The font should make efficient use of its space, especially in the vertical direction. Clarity, clarity, clarity.

Thanks Lauri, Nate.
Lauri, don't you think it's too wide for email?
Note that only the lc is actually done*, the rest is only hurriedly modified from Mana glyphs for now.

* Using the term loosely. :-)

I made Coda at 14 first for two reasons:
- It's better to distill the "character" of a bitmap family downwards rather than upwards.
- Adam. :-) Which is why I'm wondering if it's too big for most other programmers.

Nate, thanks for the offer. I can certainly finish a Coda-11 first, especially if many others think 14 is too big. In terms of weight(s) it would be like Mana-13 above, with the Bold setting at the same width. I'll have to figure out whether it's better to have some bold glyphs be ugly, or have the whole thing wide (like the 14).

Your list sounds great. Please send it to me in private along with how much you think you should pay:
hrant_thatsymbol_inverselogic_dot_corn

--

The big question is:
Do the serifs intrude more than they help the spacing? Would most coders prefer a sans?

hhp

I can understand the "133ppi is plenty" argument, but I'm quite sure as soon as people start seeing photos on a 200+ppi screen they'll want one. There's an effective upper limit, but it's higher than 133.

I used to think 1024x768 was plenty, then I switched to a laptop with a 1400x1024 display. I recently had to use an older laptop for a few days and the smaller screen was driving me crazy--both in terms of less ppi and less real estate.

This also reminds me of my first experience with a serial terminal. 1200 baud was blazing fast; I literally couldn't keep up with it, the end-all and be-all of text display as it were. Then I switched it to 4800 baud... wow. When I switched back to 1200 a few months later, there was no way I could use it--waaaaay too slow.

Another thing to consider is the severe restrictions on TV resolution due to bandwidth limitations; only so much bandwidth per station, even on cable. Given that full-video-over-Internet will be commonplace in the next 2-5 years (sufficient to-the-home bandwidth is finally here) we'll start seeing increasing demands for better quality video. This will drive demand for higher-res video cameras as well as displays, and consumers will want high-res cameras for playback on their HDTVs.

Framerate will go the same way, but increasing it is less noticeable so we'll eventually top out at 100hz. Resolution will increase before framerate.

Higher-res still cameras will become popular not because people necessarily want to do bigger pictures, but because they'll offer increased zoom and editing capabilities. At some point a highres CCD will be cheaper than a quality zoom lens... there are some interesting technical challenges to overcome and I don't think 6+ megapixel CCDs will be out anytime soon, but it will happen.

The one thing I do know is, every time I've heard someone say "XXX is more than sufficient", even if they're correct they still turn out to be wrong

Hrant, very nice, and it might even convince me to switch from "fixed". I love the gs, and the ds and bs are nice. The ; looks a bit cramped, I'd rather see a bit longer tail on it--looks too much like a colon.

The punctuation marks must be very distinct. I know some fonts have problems with | versus ;(especially if they put a break in the pipe), and I've even seen () versus [] problems. ` versus ' too.

Letter shapes aren't quite as important, that's the whole character-at-a-time versus boumas thing.

Serifs, definitely. Sans fonts have always turned out to be way too mushy, especially for coding. Every time I try a sans I go through the same process: a) "That looks quite lovely, I should try that", then three hours later b) "Why is my brain hurting?", followed by c) "Gaaaaah! Begone, ye evil spawn of Velveetica! Thou hast foul'd mine eyes for th'last! Begone, I say!"

I do know programmers who use sans fonts, though it seems monospace serif fonts are more commonly used. Probably depends on one's background.

> it might even convince me to switch from "fixed".

That's encouraging; except my stuff really is "fixed" too! :-)

> especially if they put a break in the pipe

Speaking of which, I've noticed some variety in that, and especially confusing is the fact that there are both a broken and whole pipe in ASCII[-8]. So which slot should be which design?

BTW, it's looking like there might be a 15 instead of a 14, and a 1-pixel-stem 11; and I'd like to put off the decision about exactly how to fill the 3 sizes in between after I get some good feedback about what's actually needed. Normally I'd just plan on a 13, but there are a bunch of factors pulling in different directions (like color, width, apparent size, stylistic harmony, etc.) and I don't want to decide on a whim. The 15 and 11 are seeming pretty easy to pin down though.

hhp

The ASCII pipe (slot 124) is best unbroken, as far as programmers are concerned. ISO Latin-1 (hence Unicode) also has a broken bar character at slot 166; I have no idea what it's used for, if anything.

Also "fixed" is a family of X11 bitmap fonts. In particular the font name "fixed" on its own is usually an abbreviation for the semi-condensed regular weight, which looks like this:

I make my lower-ASCII one solid; but I call it a Bar, and the broken one a Pipe... that's what the hole is for, I figure. :-) Plus I think in CompSci school we used a broken one, but that's all getting hazy fast.

> "fixed" is a family of X11 bitmap fonts.

Oh. And it's non-capitlized too?
I thought you meant a size-specific bitmap font (as opposed to a single outline font), sorry.

hhp

There's actually a font named fixed as well, which corresponds to the font 6x13, which is nowdays

---

quote:

-misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso8859-1

---

Gotta love those intuitive names, especially trying to type this stuff in at 8am. "Let's see... is it the resolution or the horizontal size that comes next? Ah, well, just guess."

I'm pretty sure it came with X10, so it's been around for... a while.

The solid pipe/vertical bar is the modern standard, but VT52s, Telerats and friends used a broken one. I'd say, "Damn the historical precedent! Full speed ahead! Fix that thar pipe!" (Seems the history of the | character is politically messy, believe it or not...)

OK, here's a quite rough first shot at Coda-11:



I have pretty much settled on 11 (instead of 12) because of a few things, like stylistic consistency with the 14 (which I've come to realize would look not nearly as "together" with an x-height one pixel larger), equivalence between ascenders and descender space (since it's for coding and not text), and aspect in the x-height; but I worry that it's really too loose, which makes me see two possible avenues: make the black bodies of all the glyphs (except "m", "w", etc.) one pixel wider but leave the spacing to 8; or make the counters of "m", "w", etc. one pixel, and bring the 8 down to 7 (or even 6). The former approach would compromise the spacing more (and in a way it's not in the 14), while the latter will most probably cause serious problems in the Bold.

Feedback?

hhp

At first glance I think it's a bit too loose too, but I notice the problem mainly in the narrower glyphs and the lowercase o. "lookup" is tough to read at a glance, same with "dlig_dflt". But I'm also wondering if it's a question of just getting used to it; each time I look back at it it, it gets better

It's tough to say whether narrowing the glyphs would be better than widening without seeing it, but my instinct is that it'd be better to widen.

oh but back on Mozilla now after using it I hate it since it doesn't seem to use CSS style sheets the way IE or Safari use them. It doesn't use the font or colour that has been specified in them. Maybe it's too literal but I hate literal browsers.