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.