The one/two pixel break is generally much better at 14-15 PPEM (especially with your tight spacing). Two pixel spacing is indeed generally better down to quite a small size, like 10 PPEM. "I can easily add a space" is not true when it comes to boundary conditions, like the right side of the "r".

From what I know of it previously, this is a herculean effort, so almost any result would be encouraging! :-) I think you're doing better than that minimum, but mainly it's too blurry.

hhp

but mainly it’s too blurry

That is the mac rendering engine in part. Partly it's the weight which is maybe too low. I will post a screen capture from the hinted TT on a PC soon.

BTW, in order to get a one pixel break without hugely crazy hinting and while preventing visual shift I was forced to align the Glyphs to the left. Eventually I will probably offer a version with very little re-editing needed that has 1 extra pixel of space at 13pt mac on right. That version will be more similar to other monospaced fonts in terms of interletter spacing.

BTW: here is the plan I have to finnish this project: Work out the UPM, spacing, & alignment issues ( done - I think ), Get the print version to look okay ( NOT done), Hint for Type 1 as best I can & see if it's viable at all ( not done at all), and last: Hint for TT. I have done some test hinting which is finally going fairly well so I am nearly ready to do that part. But doing it too seriously apart from lesson learning would be silly because the printed version is still too gawky. So: Would you print the PDF & comment on that too?

BTW- Are any of the hyper expert hinters on Typophile? Glenda, Tom, Vince? Could I call you for 5 min? If I have missed anyone in my ignorance (VERY likely) please let me know.

Cheers!

The main reason it's blurry must be that the outlines are too
printy (and they don't have superhinting to warp everything
towards screen rendering). It's a classic -if obscure- problem.

BTW, Carl is a hyperhinter too AFAIK.

hhp

Yes, You are right. outlines are 'too printy' because I want them to be sorta okay in print. I could match them to the pixels at one mac or PC ppem but the one pixel thing I was shooting for would make them almost unreadable in print. Or that's how it seems to me anyway. I think this is the best compromise between the screen & paper. Maybe not. I am open to suggestions. That said, I probably could move the side of the Cap J slightly for a better pixel grid match at 12 pt on the mac & so on. But before I do I worry about that I want to be a bit more 'print centric'. If I can get it to look better in print and loose a bit for quartz then so be it.

This face is basically for PC programmers who hate Cleartype, and Smoothing, want single pixel stems up to 19pt & want a decent looking printout. If other folks like it too then that's a bonus!

I have a feeling that fixing this for print may actually solve some of the screen issues too though.

The spacing looks too tight to me, especially at the smaller sizes.

It looks pretty good to me.
You could try William's suggestion, but it may be OK the way it is on PC.

As you say, the g might be better with the join between the bowls more centred.

Perhaps the k could have a little space between the vertical and the diagonals, rather than having them all meet at the same point. Either by introducing a horizontal bar, or by starting the bottom right stroke along the top right one.

"Printy," eheh, must be as technical as "squooshed."

m / w - both look short and a little sqooshed
g - nice solve
j - seems a litte wide

I agree about the spacing, it is a little too tight for me in the smaller showing.

Dear Eben, I’d expect to see your 11 pt in the size of your 13 pt, why is that ?
I agree that the spacing is too tight. The very top right of ‘s’ has a sort of mechanical micro shift to the bottom, a think that the ‘S’ doesn’t have ; also the negative of the ‘6’ presents something similar. The ‘2’ has a bump in the center and its bottom part hasn`t got the same temper treatment like ‘1,5’ (what about ‘4,5,7’ or ‘Z,z’). The closed negative of ‘@’ has got a point without smooth connection, and also ‘&’ needs some editing.
I like the horizontal stress of the characters and I like the ‘g’. I think you are doing great. I've passed the link on to Fabrizio Schiavi to inform him about your work, since he his also a very good hinter (I am not).

The spacing being too tight for everybody but my client I will seriously look at pursuing a 2nd face without the imperitive to keep spacing at one pixel.

I’d expect to see your 11 pt in the size of your 13 pt, why is that ? Allessandro, I think may be two reasons. One is that these are Mac pt sizes. The other is that like Consolas or Verdana the glyphs are large so that you can potentially mine the smaller 'pt' sizes.

‘s’ has a sort of mechanical micro shift to the bottom, a think that the ‘S’ doesn’t have I think I see what you mean - do you mean that the s bows inwards in a way that the S does not? If so I agree. I will fix that. About the 2 - you are saying the stroke needs to vary and you find the bump to be uncharacteristic of the rest of the face. Is that right?

The closed negative of ‘@’ has got a point without smooth connection
Do you mean the top of the lower join stroke?

I like the ‘g’ g - nice solve
I like the g too but I don't know if it can exist well in such a tight face. I'll keep it for another project. The next g has to resolve into a b/w bitmap more gracefully.

Either by introducing a horizontal bar, or by starting the bottom right stroke along the top right one.
If you look at the PDF you will see I have taken your 2nd suggestion. In the Pixels this is not apparent though. Perhaps I should exagerate it. Or go to The Luc(as) method of using an unconnected delta next to the stem...

Has anybody printed the PDF? Should I post a different one better somehow better suited to finding the bits that are irregular & wonky in print?

Because I need to add some additional consistancy to the face I am looking now for control glyphs which I would then use to iron out the others. Which glyphs ( looking at the PDF please ) would you keep if any? For instance I think ny 'q' & 'b' are kinda sweet ( imagine cartman's voice there ). My 'e' on the other hand is pretty pockmarked with tweaks. The o and a which should be finnished by now are not. The a needs to have a bigger counter I think. The o should maybe be a bit more boxy to let the counter grow.

I have also tapered the tips of some of my glyphs like the c & j. Maybe that a bad idea. Maybe they should be squarish or expand like the tail of the Q...

What do you think?

"Sweeet!"

I will look at the posted samples and your PDF soon Eben. Still a lot going on.

BTW Carl is definitely not a hyperhinter, not even a hinter, in TT anyway. I did PS hinting years ago but I'm clueless with TT. I'm surrounded by expert hinters though, so maybe I'm blending in with them. Jelle Bosma is the MT Hinter/Designer/Programmer.

Hi Eben, as promised some comments.

- Honestly I don't think you gain much from tapering the serifs on i j l I 1. It's too subtle and also a bit inconsistent with the other letters.
- Although as such the g is interesting, I don't think it works here. It's not very legible, esp. in small sizes. And it doesn't fit with the rest.
- Have you tried a less curved entrance point on n m h u ? (more horizontal)
- To improve the M, i would make the legs straight. It opens it up.
- Generally I agree that the spacing is very tight and the word space too wide.
- The & looks a bit cramped, perhaps a less elaborate shape would work better.
- Do you really need the leg in a in @? I can imagine a straight ending without crotch would be better.
- The bowl on P should be bigger than R
- left stroke on v is too strong
...

You mentioned that it should work in print too. Is there a possiblity to have two versions of the font, one for screen and one for print? The requirements are very different, and you could be more adventureous with the print version, e.g. use the double-storey g and not stick to Mono-spaced. I am not sure that combining both in one font will give you the best result.

I hope that helps :-)

Veronika & Alessandro,

Thank you very much!

I will set to work trying out these ideas. They do help.

Veronika, since this face is meant to do really well only in b/w hinted bitmaps & in print I think it will be okay to leave it as one font. Hinting is remarkably powerful. That means the greyscale in mac/Quartz, font smoothing in Windows & Cleartype in Windows will probably be less than optimal. But I accept that.

Eben,
Most of my comments are echoed elsewhere but here goes anyway.
For one thing, the task is a very difficult one. The dilemma of fighting with the pixel grid while keeping a mono-width glyph set and any feeling for even spacing is like untieing six Gordian knots while blindfolded.
The double bowl g is too complex to deliver in this context. There are just too many strokes to fit without getting dark and muddy.
You definitely need to add a pixel more spacing. All of your straightside-to-straightside pairings of glyphs (mn, np, dh, etc) are too tight and make black junctures. Straight sides need another pixel sidebearing except for cap M which is always a bear—this of course means narrowing the glyphs. It is all robbing Peter to pay Paul with monowidths so it can’t be perfect and just won’t look that good in print unless you do a print version as well. The n and u need to be narrower as does the c. The j should be narrower but add all the space to the right side (look at “ijk” and see the bond to the k).
I don’t know how you started this but IMHO it would be best to do a straight pixel font first and then do the curves afterwards based on it.

Best of luck on this noble endeavor Eben!

ChrisL

Hi Eben,

I notice how narrow the widths are; in very small sizes, i looks right and everything else looks tight. Is there any chance of getting the basic character width to be greater? If not, then the constraint is very limiting.

If you want a 2-storey g try a simplified shape like one of Rudolf Koch's, as in Kabel. You get a distinct shape and narrow waist, but you don't have to cram 4 horizontal stems into such a tight area. I notice your current g descends farther than your y. If vertical space is at a premium, then you really dont need a 2-storey g.

J and j don't need to be narrower, they do need to be more centered. I think for coding, while differentiation is very much the first concern, the next most important concern is evening out the spacing. Moving j and J to the left would help them, and probably not damage their identity much. J could have a little serif on the right. I think the same should be done for r; the ear is so long and r snaps to the left in text.

The tightness and these issues of letters appearing to drift left or right are things you deal with a lot in developing bitmaps. I think Chris has the right idea; if you developed a set of balanced bitmaps that solve the spacing issues (one more pixel would really help), then the outlines would resolve themselves to some degree. Some of my suggestions would be very obvious if this were a bitmap you were working on; try making the small bitmap g and then make an outline for it. If the printed version looks looser, I think that's the cry for help from the bitmap. If coding is the purpose of this font, then onscreen performance is the main criterion.

Hint for Type 1 as best I can & see if it’s viable at all

the new AFDKO has an auto hinter which is supposed to be the best thing since sliced bread.

Paul, Yes! I saw that. I am going to try it out ASAP!

My powerbook died ( well, it may come back eventually ) and I am just getting back up to speed now. Also I had a typophile accound problem which was resolved today!

So, sorry it's taken so long, Carl & Chris: Thank you !

I have decided to use a pitch 10 model like Fedra Sans mono & Luc(as). The ten pitch will have double pixel spacing at most sizes. My clent has agreed to try it. I can always craft a custom version of the face or a custom hinted version for him later if he doesn't like it.

Someone needed to close the "cite" command.
edit: That didn't work. So, I'm very sorry for a pointless post.

Nathanael, it's more effective to contact a moderator directly to solve this type of problem.

It's coming back around soon. Here is a teaser.

The i and l look like they are from a slab and the other glyphs from a sans. It is kind of jarring from what you show. It may look better as pixels on a text reader though. I assume you are still thinking of this as a progarammers font?

ChrisL

The i and l look like they are from a slab and the other glyphs from a sans. It is kind of jarring from what you show.

Hmmm yes. I see what you mean. I have been looking at this kiund of thing long enough now that it seems normal to me. Happily I am good company with Lucida console, Consolas and Fedra Mono all doing similar stuff. Can you think of another way of handling the needs of the mono? I guess I could do something more OCR-B than OCR-A. Something with a bent tail on the 'el'. Or something like Monaco with it's almost z like shapes. Certainly that would distance the l from the 1 even further. I'll consider the bent l maybe...

still thinking of this as a progarammers font?

Yes, definitely. But if can look nice quite big on tshirts in 2008 a la my prediction that would be fine too. ;-)

Here it is in context:

I need to give it more linespace as well.

If this is mostly a programmers font, I wouldn't worry about my slab comment. You have enough limitations with that already.

ChrisL

I will probably leave it as is- but apart from style issues ( extra points maybe ) where I think you certainly have a point there might be some value in ramping up the distiction between 1 (one) and l (el). I hope to have a nice PDf soon. Then you can decide what you think in a broader context.

Slabs help a monospaced font greatly reduce a much bigger problem: spacing.

hhp

And then there is the issue of visual balance & that n word. Much of a muchness that. I think that's why Luc(as) runs with the slabs in Consolas & < a href= "http://www.lucasfonts.com/index_neu.html">The Sans Mono

Eben, my hat is off to you.

For the last four years or so, I have been attempting very nearly the same task. I program for a living, and very quickly got fed up with looking at Courier and friends. I banged out a first draft, got a copy of MS VTT (for mac os 9!), and have been polishing and tweaking the font ever since.

I use it as my main programming, email, and web page mono font, at first as motivation to keep improving it, but these days, more because I don't think it looks half bad.

But ... only in the last month or so have I run across Typophile. No sooner do I get here, of course, than I discover that this particular windmill already has lots of broken lances stuck in it, and I'm late to the party.

I've now read through the various threads on monospaced type design now. It's great to recognize problems I've fought with myself addressed here (and, sometimes, feels affirming to see similar solutions to my own!)

Anyway, I hope it isn't too gauche to toss my own font up for review, here, in your topic. For your consideration, a gif of my terminal window, antialiased and not:

-- R.

Wow, where I zigged you zagged. Considering that our aims are so similar and the range of options available to us so narrow it is quite refreshing to see all that variation. So many differences! At the request of my client I am gearing my font to light feeling punctation for instance. You are going heavy. Your g is intergesting. It looks like a Cedilla in part! Your asterisk is quite fine. It looks like your outlines are significantly geared to getting the bitmaps you want. Given all the differences what are your crits of my choices? After all, you are my target in theory!

I suggest that you go ahead & start a new thread for comments related to your font. I expect there is a great deal that people would have to say about it. It's quite interesting.
But most importantly - people who are looking for your design will have focused/organized information. When you do, will you comment on what you think about the other options: Consolas & Lucida Console especially? Have you seem Fabrizo's font?

Thanks, I think I will take your suggestion.

As for the other usual mono fonts, I didn't want to come across as too harsh or hubristic with a laundry list of each font and its flaws. But here's the short form. The problems usually come down to some set of:

• bitmap only, no outline

okay, now I've given sdv3.pdf a closer eye. Most of my comments' subjects are so subtle as to be invisible at screen sizes, outside a hinting goof. It looks like none will "jump" into an exaggerated position, which is good. (e.g. exaggerated contrast at a few sizes where different stem widths get out of phase.)

'm' is the definitive trouble spot for this kind of font. The trade off between 'squished', lighter weight, and trespassing on neighbors is a tough one with no good answer, so I'll just suggest that its tops could be a little more curved. As it is, with increasing size, the upper-right corner pixel of 'n' will disappear long before the equivalent 'm' pixel does, without some annoying delta hints.

Interesting that you have a 'twisted' eight where mine is strict vertical. I might experiment with that in my font.
Huh. While () and [] have subtle vertical axis, {} is dead horizontal! probably invisible, but anything to keep {} and () distinct is good. Period and comma are nicely distinct.
I like the #. It wants to be the party character.

Curve ends of e.g. 'a', 'f', don't taper. Similar curves on 'c', 'e' etc. do. Is there a criterion? it looks like on 's' one does and one doesn't. Illusion?
The tapered megaserifs on i, j, l, I seem out of place with (e.g.) untapered f, g strokes. The i, l seem topheavy, leaning left a little. The leaning effect actually helps the j and J though.
Something about the upper curve of 'e' caught my eye, and I was about to say it felt poking up to the left... then I scrolled up, saw the white-on-black version, and it felt like it was poking up and to the right. Something doesn't quite match but I can't put my finger on how.
The nightmare diagonals of 'vwxyz' seem well matched. It looks like you lightened the 'w' mostly in the outer strokes; lightening the inner strokes too / instead might yield a more even antialiased render, with less of a "hot spot".
The inner left curve of '6' could be smoother where the bowl joins it. That's a tough curve to get. Likewise the '9'.

In fact... (/me goes back and looks again)
Are any of those curves micro-tweaked to get a certain bitmap pixel on or off, pre-hinting? If so, that's a lot of trouble you don't need to put yourself through. TT hints can more than handle per-pixel adjustments.

Anyway, that's all mostly guessing, without a programming trial. Like I said, most of the above won't even be visible at screen resolutions.

-- R.

Eben, except for the lower case k and lack of Cyrillic and Greek, this looks like Consolas. What is gained?

The really big difference is that it will be hinted for b/w bitmaps from 10-18pt on a mac & whatever that shakes out as on PC. I will have that sorted soon.

Some other glyphs are significantly different too. Many of them are things like * $ & #. Some people may prefer them - or they may not. These glyphs make a bigg difference to how the code feels.

Also the (*){*}[*] feel quiet which is unusual. Again maybe not what everybody wants but it's a difference that in programming may be more ( or less ) comfortble.

In print Consolas will feel like it is filling the word space more that this font will. Fedra being the opposite pole with even more regular gap spaces. Consolas has a bigger x height. My Caps & ascenders differ more than they do in Consolas. Consolas is more monoline & mine is more humanist/contrasted.

And I think the forms 'feel' quite different when they print & on screen too. But will admit I may have an exagerated sense of that.

Do you still program in non-monospaced (variable spaced) fonts? What do you use these days? Or have you started using Consolas?

Oh, and I slash my zero the other way to keep Danish programmers happy.

Those pesky Danish programmers are a tough crowd to please :-)

ChrisL

I don't program. I use my own bitmap font for the text terminal, and Lucida Sans for everything else.

I think somebody is ought to try and make a "programmer's typeface" which is not monospaced ... Has it been done?

I don't think anyone has. Someone who wants to program and use something other than a mono has a TON of type to pick from. That would be a super small market I think. What is your bitmap font like?

There are good reasons for sticking with mono, like terminal windows and page layout, and less good ones, like tradition.

Using non-mono type to program would have to somehow yield an immediate benefit greater than just "it looks better". I think it could work as part of a larger integration of meaningful typography and autoformatting into an IDE. Apple's taken a few baby steps in this direction in the AppleScript Editor, although you have to hit "compile" before you see the results. IntelliJ IDEA has wonderful, extensive language-aware changes you can make to its editor formatting, although it limits you to one base type family at once for some reason.

This would be an interesting direction to experiment with in, e.g., Eclipse.

-- R.

Reasons. Why does a terminal window have to have a fixed grid to require a monospaced typeface?

One good reason I have often heard is that you can tell quickly if a line has too many characters in it in cases where the code is repetitive & the variance uses the same # of characters each time. Mono let's you spot the mistake quickly. I have heard other examples of 'at a glance' distictions made possible by the use of monospace when coding but I don't recall them in detail.

I am feverishly working to unleash a new PDF on you guys in a few days. I have it all tested via laserprinter for eveness now except for some CE glypshs' diacritics and the new reverse 3 based ampersand which I have discovered looks fine(ish) in text but nearly disappears in the white foam of actual Perl code.

I need a more distinctive form. I am going to avoid going back to the one I had because it was hard to hint. rgeorge: Yours is awefully clever looking I must say. Not so hard to hint!

BTW Which is your first name? 'Rogers'?

Please take a look at the PDF at the begining of the Post.

Here are some GIf captures showing what it looks like on a Mac in a text editor at 4 sizes: 13,12,11 & 48.

Eben,
Is this the same PDF that you emailed me last night?

ChrisL

Yes.

Eben,
It looks much better. The lower case g is really better!
My main confusion is with the ligatures--why do you need them? Doesn't this defeat the purpose of monospace? They also just don't work visually to me. It may be impossible to fit double f in the space of single f and not look squashed and forced.
Because it is a monospace, you will always have more difficulty with glyphs like ae and oe. I can't think of any better solution than what you have.
I really like the figures. They are very clean and distinguishable.

Good Job!

ChrisL

Looking cool. Just one thing: the "e" is the most frequent letter in English, so the blur in the crossbar (in the 12 and 11 point renderings above) needs fixing!

hhp

Hmm. I thought OS X turned off hinting when antialiasing, but there's a glitch I would normally attribute to strange hinting behavior: in the 12pt, the dots on 'i' and 'j' shift to the right one pixel more or less randomly.

Maybe I should whip up a 1-char font with wacky hints that will display what the rasterizer's actually up to.

(oh, and my first name is "Rogers." Really!)

-- R.

Chris, about the ligatures; I agree that the ff & fl ligatures make litle sense in principle but it was fun to do them. And I don't want to tell a designer what to do. In the case of 'ij' 'ae' or 'oe' I think there is perhaps a real language or orthographical reason to include them. I am still looking to see how Unicode handles things like 'dz'

Hrant, thanks! Your right, I will have to check if the type 1 hints can help me beat that or if I am better of moving the bar on the e & now that I look again the 'a' to. I think 13 is the likeliest size to be used on a mac.

Rogers, OSX gives you the ability to turn smoothing on below 12 but not to turn it off above 12. So I can look at it both ways in 12 but not say 13.

I will post some shots of what it does at 11 & 12 with smoothing turned off in OSX. It isn't perfect because it's not formally hinted yet but when the outlines are resolved that task will be next.

I just realized that while I think TT hinting isn't used for the smoothed rendering of fonts in OSX I think TT hinting is probably used for the non-smoothed B/W. Anybody know the answer to that? Maybe you have to include bitmaps if you want that dealt with in OSX. I will find out!

I know that for bw/unsmoothed text in all versions of Windows TT hinting is *the* relevant model. And I am 98% sure that's true for both flavors of smoothed text as well. However I don't think I am going to be hinting this for cleartype on the PC side. ;-) Regular hints for the b/w will have to do I think.

there’s a glitch I would normally attribute to strange hinting behavior: in the 12pt, the dots on ‘i’ and ‘j’ shift to the right one pixel more or less randomly.

Do you mean in general, or in this font's screen grabs?

"...In the case of ‘ij’ ‘ae’ or ‘oe’ I think there is perhaps a real language or orthographical reason to include them. I am still looking to see how Unicode handles things like ‘dz’"

I agree, those are glyphs, not ligatures. They even have a Unicode ID. By all means, include them. They are needed characters of languages.

ChrisL

It turns out that OSX does use hinting for 1-bit rendering, and a user can change the threshold at which smoothing is turned off. BUT: the threshold's max is 12, which is not very high at all; the default setting is 8, which is tiny; users pretty much never change settings like that anyway.

hhp

Threshold: Yes, and you can decide how much smoothing to ask for as well, I had mine set at Medium for flat panel. It was a kind of worst case scenario for this font.

Unicode: There are also Unicode holders for ff & fl. But As far as I can tell no holders for some digraphs such as sz used in Hungarian. In open type you could offer a contextual altrenate that is automatic or user selected. Have you looked at Fedra mono? His PDF is helpful. What he did for the Post script is to have an alternative or expert font. Choosing r and selecting exper will give you the digraph rr for instance. I am also confused about rr in spanish and or catalan. Is that a real digraph? I tried looking it up on google but so far no luck. Also no unicode holder yet. Google thinks it's rr fosr a start not a digraph. The impression I have is that under cultural pressue some digraphs die out. And then there are the irish letters... In any event I will get my head wrapped around this properly soon.

Here are some bw examples. Obviously on some level they are horrible because they are not tweaked at all. But I have to admit to being a little happy about where I am starting from. If anybody has opionins or suggestions about how to handle the hinting feel free to speak up. I noticed that many classic screen fonts end up offering the same pixels at some sizes say 11 & 12 for instance. This seems pragmatic to me - not because it's less work. It isn't - but because it means that 11 can be more useful with 12's x height. In means not being non-linear but I think that seems like the more user freindly trade off to make. What do you think? I plan to stop hinting at 9 pt.

12pt

11pt

10pt

9pt.