Quick comments.

_f_ seems too wide
_i_ fills up the word shape too much when it appears in the middle of a word.
_m_ the middle stroke is too short. It also looks a little narrow
_w_ seems too narrow. UC and lc.
_J_ seems too wide. Could be the tail.

Being that this is monospace, some of my critique could be useless.

Could you set some more text with more caps in use so we can get a better sense of that as well?

New images added to the original post. ( see above )

Now when you reply it seems you can't post new images in the reply - and images are not inline anymore either.

The example images were created in photoshop using a 96 dpi setting to simulate a PC screen. There is a little anialiasing that would not exist in a programming app - but I think the idea/impression given is mostly right.

Who would you say is the monospace guru on typophile?

I don't know if he's on Typophile, but de Groot is a mono grand master.

(More soon...)

hhp

I think you have a good start. A few observations:

You need to use a bit more overshoot on the curves at the tops and bottoms of the rounded characters (A, C, G, O, Q, S, etc.).

I would move the vertical stem of the f one "pixel" to the right. Same with the t.

I agree with Tiffany about the m. I also think the top of it is looking clogged where the two strokes meet. You need to cut into it more like the bottom of the w.

I would move the crossbar on the e up one "pixel". It seems out of step with the rhythm of the rest of the font.

I think the A and R are a little too similar. The lower crossbar on the A helps, but it may be difficult to tell them apart in certain cases. You could do the top of the A like the bottom of the V. Or, you could put an angled tail on the R. Or both.

Check the top of the z. It seems like it's not quite up to the x-height.

The word spacing seems too wide. I would make it much narrower. (Just kidding.)

Harmonising shapes

The vertical parts of the bowls on b, d, etc are rounded, whereas the same parts on c, e, and o are straight. I think these shapes should be consistent. I prefer the rounded shapes; it humanises the design.

I like the arches on h and n. Why not use the same on u (by rotating the n), instead of the smallcap style? This could help disambiguate u and v.

Small s and capital S have different arm styles. The closed style works on capital S, would it work on small s, or would the counters close up too much?

Letter spacing and width

The letter spacing and width appear to be dictated by the lower case bowls and arches. I would say the spacing is tight for a monospace design. This creates problems with m and w, which would like to be wider, but cannot 'rob' any space either side. Also, the narrow letters like 'i' and 'l' cannot fill the space enough to blend with the tighter spaced 'normal' letters, so you get light patches.

Perhaps try loosening the spacing a bit. The words should not fall apart, because the word space is about twice what you would have in a proportional design.

I think the cap height is the same as the ascent (I have not measured it). The caps would look less squashed if they were shorter.

Punctuation and other disambiguation

A programmer's font needs strong and unambiguous punctuation. The dots in your design are too light, I feel. The comma looks right. The different styles of brackets need to be clearly differentiated. The braces have a good shape, with a clear 'dink' in the middle. However, I would widen the braces and square brackets.

I would lengthen the 'nose' on the figure 1, to disambiguate it from small l. My colleague wasted hours fixing some software which had both 'startl' and 'start1' in it, which appeared to be the same thing.

Disclaimer

I am not a professional type designer. I do it for fun. Please feel free to ignore everything I have said.

Hello,
I think:
< > are so small
& should be more clear — I would suggest "classical" shape.

Software developers should turn over to the dark side and start using proportional typefaces instead.

Proportional spaced software text? I think not.

The characters in most software languages function in a different way to the same characters used to represent human languages. In software, each character has similar weight in terms of meaning. Grouping characters into words is just for human convenience. An error in a single character is not merely a typo: the software will not compile, or will malfunction. Conventional proportional spacing aids reading groups of characters as words. This does not help when reading software text, which very often needs to be read character by character.

In my opinion, a monospaced design is beneficial to character-by-character reading, and is therefore most suited to rendering software text.

On the topic of character-by-character reading, I have read of a psychological test (sorry, no ref), where monospace out-performed sans and serif proportional typefaces. As I recall, the test involved finding typos. Does this mean that writers (or at least proof-readers) should use monospace?

I concur: You don't think.

Thanks for all the advice! - I haven't tried it all out yet, but I will this week.

Re: monospace - I have asked about this over & over again, because I, like Segej, didn't grok why the monospace was used by programmers. The programmer who will be getting this font when it is done actually explained it to me best - despite english being a 2nd language.

He said that character count is important when scanning code. Monospace let's you find patterns in code faster - dissimilar or similar code for instance - than variable spacing. The thing is programmers are not reading for comprehension like we do. It's both more & less abstract than that.

- More, because they are thinking in terms of how the lines interact

- Less, because they are looking for small - sometimes single charcter changes in common kinds of code - not the bigger word sized changes we look for when we read a language.

That my understanding anyway.

DeGroot - Has anybody seen anything written by Degroot on monospace? Has anybody talked with him about it or had a class?

In the book, Now read this: The Microsoft Cleartype Font Collection there is a chapter dedicated to de Groot's Consolas which is his monospace sans serif for the Cleartype collection. Here is a sample courtesty of PoynterOnline.

Thankyou Tif!

- PDF -

Here is the current version of 'software developer' with many of the suggetions worked in. The biggest changes I made were in spacing & weight. I took Glyn's suggestion and there is a pixel's extra space between letters now. Reading about Mark Simonson's Type face 'Anonymous' in an article he kindly set me I decided that I had better reduce the weight of the face as a whole. I have brought some of the variation in weight I found in my lower case into the numbers and I will start looking at puctuation & additional characters next ... In the meantime - here is the update. Fire away!

_w_ seems to be filling in still
_j_ dot over seems to be too low
_m_ the curves are still odd to my eye. uneven. Next to the _n_ it looks even more odd, but this combination doesn't occur too often.
_J_ base seems too wide
_s_ is falling backwards

The letters with a little stroke modulation look odd, but I can see it might be necessary. The W w and m seem out of place to me.

Thanks for the observations! I think I can fix these. In the case of the w & m I might be able to steal an extra pixel for either side. It being monospaced I have struggled with the the m in particular.

I wonder if a different shape maybe a simple arch with a mid leg - like the cap A but a vertical line not a horizontal one - might also be a solution.

BTW - The stroke modulation isn't *needed* - i just thought it looked better than simpler shapes. I probably haven't got it right yet if it looks odd. What about the numbers? Do they look odd too. Any modulations in particular bug you?

The solution to the m problem is straightforward. The left half should work like a very narrow n. The right part should come off the first stroke in a way that looks visually about the same. The counter space for both parts should be identical, or nearly so. Right now you seem to be trying to make it symmetrical, with the cut in the middle centered on the width of the character. Here's what I mean:

http://www.marksimonson.com/m.gif

Awesome. Thank you!

Having a little perspective from the coder's side of things, Here are some things that are important to the utility of the font.

You need bigger punctuation, like, monstrous if possible. Seeing the difference between a colon and a semicolon is important, but not as important as seeing the difference between a colon and nothing. I recommend that the diameter of a dot be somewhere between 1.5 times and twice the width of a stroke. But leave the dots on i and j as they are; they should not distract someone who is looking for punctuation marks.

In some samples, your zero is reading as an eight. I suggest narrowing the mark in the center and making it taller.

From a typography standpoint, example1.gif looks the most clean and impressive to me, whereas the pdf just looks awkward. So I think you should back off on the stroke modulation wherever you don't need it. b, d, p, q should look more like c, e, o, s do.

Cerulean: What about the 'a'?

The 'a' looks all right. Maybe just a tiny bit heavy south-by-southwest. The 'y' is good too.

Eben, sorry it took me so long to take a closer look at this. I just realized what you're trying to do: make an outline font that looks decent enlarged but renders out nice grayscale bitmaps, and is monospaced on top of it! You're really shooting very high with this - the balance of compromises will surely be a bear to keep your head wrapped around... Good luck!

The two main problems I see with your first effort on top (which you might or might not have fixed - it's not possible to really know from that PDF, without a bitmap rendering):
1) Yes, make the interletter spacing two pixels.
2) It's too fuzzy. Fixing this isn't just a matter of making the forms lighter, but also controlling better what partial-pixels they render out.

As I'm sure you realize, there's a limit to how nice you can make the outlines look, without sacrificing the -more important here- screen rendering. This is because outline fonts rely on continuity to conform to aesthetic expectations, while bitmap fonts rely on discontinuity to avoid blur. I guess if you simply manage to make the outlines non-disgusting (which you're doing fine) that would be enough; don't try to make your outlines conform to the conventional standards of print font quality.

As for the question you're having concerning Em/pixel-block proportions, I'm not sure where the issue is: as long as you choose a nominal point size that has an integer 75% value (to accomodate the "native" Windows dpi of 96) you should be OK. And a value of 8 (resulting in a pixel-block size of 125, in an Em of 1000) does that, plus it's sort of an informal standard in pixelfonts.

--

> Does this mean that writers (or at least proof-readers) should use monospace?

Indeed, there's immersive reading, and then there's deliberative reading. For the former, an efficient, well-proportioned font helps; but for the latter -like when proofreading- those attributes actually hurt! Because you have to be forced to read inefficiently to be able to catch typos; in immersive reading your cognitive mechanisms are simply too clever.

hhp

Updated images

Software Developer vs. Courier
example of C++ code

If anybody has any comments on the current state I would love to hear them. BTW I did try increasing the space beween letters from 2 to 3 pixels at 12 pt but I didn't like it. I am still working on my zero, S & s. They are not right yet & I know it. These examples don't show perfect pixel alignment but they do give a good idea about the current flavor of the font.

Eben, those look blurrier than some of the stuff I saw before - is that normal?

Three-pixel interletter spacing is too much at anything below like 18 pixels. Unless it's a really light and wide design or something. Two pixels is the gold standard for both one- and two-pixel weights at "normal" reading sizes (from like 11 pixels to 16), for designs of typical width. And one-pixel spacing is useful for very small sizes or where economy is much more important than readability.

hhp

These examples are blurry for two reasons

- OSX really like to blur - and these examples are taken from the Mail application which uses the adobe/apple quartz engine.
- and because I scaled the font up recently & I have not got perfect grid fit again yet.

I can turn off the antialiasing in OSX & this is what the examples look like:

text no aliasing
code example no aliasing

It will become crisper again oven with alaising but even then it will also look different in a Microsoft Programming tool ( very crisp indeed - no aliasing at small sizes) , on OSX ( aliasing on all the time) & still different from that in Photoshop( depending on render mode), Illustrator or Flash.

Still, apart from looking at the fit, Any glyphs that jump out as problems? Any that seem good? Apart from the S & s I am noticing obvious problems with the k,b,zero, and I wanted my r to have a littile bite in it at the top.

What about line spacing?

I should also mention that part of goal for this font is to create a text field of code that *doesn't* shout with heavy puctuation. Hence the softer curly brace.

I may still modift the < and the >

-e.

The C++ sample shows a real problem with ambiguity between 'u' and 'v' in my opinion. I looked at some function/variable names, and had to deduce whether there was a 'u' or 'v' from the context. I would shorten the vertical ends to the strokes, and make the diagonals more vertical.

Eben, those two links of your aliased text samples are not working...

The one thing I would say at this point is this:
You have a lot of blur, for something that worries about the screen. Now, considering your particular design constraint -that the outline foundation be decent- that's arguably unavoidable. However, it does mean you can shoot for more letterform fidelity, less orthogonality. This ties in to Glyn's observation about the "v": there doesn't seem to be a reason to have flat sides like a "u" (since it's going to be blurry anyway), and there is reason for it not to have flat sides it (since you would want to avoid ambiguity).

BTW, could you put a character set?

hhp

Here is the latest version pre-hinting. I am starting wonder if my grid is wrong again.

But this is where I am now.

[ Link to Photoshop rendering ]

I am using a 2048 em grid ( MS apps is my target use) & 128 em units is my base pixel size which I thought would give me a match at 12 point... Oddly it's only the 10 pt that gets my curly brackets right when it's in non-antialiased mode...

Comments & advice please!

A block size of 128 in an Em of 2048 yields a nominal point size of 16.
I'd use a block size of 256, arriving at the pseudo-standard of 8 point.

hhp

I have a hinted version now. This set is shown at 12pt, & 24pt. I will post a 10pt & 14pt soon.

+ hinted samples here +

Please comment!

Wow, looking good.

I'm a software developer myself, and I'm extremely picky about the font I use for coding. (I used Andale Mono for many years, and recently switched to a slightly tweaked version of Fabrizio Schiavi's Pragmata.) I've been following the progress of your design with great interest.

The w and W seem to be a little problematic. The A also looks a little anemic. I'm not too sure that old-style figures are a good idea in this kind of font; that 0 looks a little odd in the context of actual code, for example.

On the whole, though, this is shaping up to be a font I would seriously consider using. Thanks for pouring the effort into this project; coders are a sadly neglected market when it comes to type.

Wow, Thats great. I do plan to offer it with & without oldstyle figures. That 'o' is probably my zero, The zero has a dot the o does not & the UC O has no dot either. A slash may be more prgmatic but it can be confused in danish & the dot gives a lighter impression. In general this font is quieter than other code oriented fonts especially in the brackets.

Any other comments?

So basically you've given up hinting-for-grayscale? You're not the first... :-/

I think it looks good overall, especially in the 24. Consider making/hinting a 16 PPEM. BTW, when you choose point sizes to worry about, don't forget Windows! That's what most programmers use after all, and over there "10 point" for example is 13 PPEM.

One other thing: conventionally, the oldstyle "4" is descending.

> A slash may be more prgmatic but it can be confused in danish

You could make it backslash direction. There's also the totally horizontal slash, but that can make the zero too much like an eight. The dot can work, but it requires a counter of three (or five, or seven) pixels.

hhp

> hinting for greyscale

No, It's hinted. Auto-hinting plus extra hints to make it behave. The OS is only willing to show me a non anti-aliased rendering from 12 down. thats why 24 point is anti-aliased. Hinting is crazy but almost fun. I am almost, starting to sort of understand it, in a way. Actually, my hinting seems quite effective for bit maps but only just so effective for anti-aliased text at say 12pt. There at 12 pt it looks pretty wacky at times because of the hinting hoops I am jumping through to make the pure b/w bitmaps look good.

I am glad you like the 24 pt. okay because thats what printouts should look like.

> 13ppem

Hmmm, I'd better look at the 13 again and tighten it up!

> OStyle 4

The 4 is modeled on Degroot's figures. Still, that good to know. See them?

http://www.lucasfonts.com/
http://www.fontfabrik.com/fofafon4.html

> The dot
The fellow I am doing this for likes the dot, maybe the one he doesn't want to use, Old Style figures (or not) will use the slash, heck maybe there could be a third version... It's just one glyph.

I added a sample at the top. It shows the font at 9pt at 96 dpi - equivalent to 12 point on the mac. This is the target rez. The example shows the font anialiased & as a bit map using photoshop as the rendering environment. I have been using the font as a default font in my web browser & I am starting really like it.

Yes, I know it's hinted, just not for grayscale rendering (at text sizes) which is how I think you started. BTW, are you using delta-hints?

> The OS is only willing to show me a non anti-aliased rendering from 12 down.

MacOS?! That's strange, I thought everything was full-fuzz for the past few years, with hints ignored to boot. Maybe it's a cutoff setting in the OS? If so, what's the factory default?

> The 4 is modeled on Degroot’s figures.

?
I'm seeing a descending "4" chez de Groot...

hhp

> delta hints

Yes, They are *totally* needed if you care about the b/w bitmap especially with my redesigned 'Yy' & 'Xx'. My old ones would have behaved better but ...

Actually I found a new way to design for b/w that I wish I had known before. I only figured this out this week when I was hinting; you have to make many round trips between type 1 & tt hinting mode which means going from type 1 to tt outlines over & over (which bites) but you can move your points around & see what they are doing unhinted in multiple ppems. As it is my outlines are between 11 & 12 ppem which is maybe a good thing since they don't 'break' completely in either. Still, if I was doing this all over I would probably build some basic shapes going back & forth into tt & adjusting things for minimum hinting. As it was I did this for the percent symbol & it really paid off. That glyph would have been hell otherwise.

> One other thing: conventionally, the oldstyle “4” is descending.

Ohhhh, I see. One more pixel down. Thanks!

Eben, I think that this is looking really good. I concur that monospace was a great choice, especially given your target audience.

I think that you punctuation is way to small. All of it, even the = sign. I'd pump up your marks. In code, they are just as important as letters/numbers.
__
www.typeoff.de

Dan, I could do this in two ways

- I could pump up the punctuation, in the outline only so it pops better when antialiased & leave the hinted bitmaps witha period being one pixel & so on. That is what I think the programmer who asked for the font would want, or it was when I asked him last, he said he likes the light feeling of the font.

- or I could make the period be 2 or 4 pixels or something similar.

Which one did you mean?

I don't know, really. It was just a feeling that I had when I looked at your most recent images. How do they look with more pixels?

__
www.typeoff.de

Well I tried them with more pixels & I thought, well, not too bad but my pal said, ' I like it lighter - put it back to one pixel please'. So, for him anyway, it will have to stay lighter in one of the pixel versions anyway. I had tried a version where I made the period a verical 2 pixels which was okay until I looked at the colon ':'.

That form looked like the broken line glyph. So probably the alt version would have to be a 4 pixel which has been done for programmers before. So that could be done. It's a good idea for a variant!

On the other hand making the outlines heavier & then making the bitmaps use the one pixel afterwards (using hinting) would make the type read better in anti-aliased form. I think you are right about the puctuation being a bit too light. The period & colon etc.

I think the brackets seem okay - but, if I make a heavy punct version then maybe I will make the brackets heavier too. What do you think?

I think that all of the punctuation should appear equally heavy.

__
www.typeoff.de

Can someone educate me? Both of those samples - in sq9 - are the same typeface, right? One is hinted and one is not? I don't want to critique what I'm seeing until I understand exactly what I'm seeing.

Thanks Dan!

Sorry Tiff, some clarification.

- The one on top is the anti-aliased version, this is the kind of thing designers are likely to see & increasingly we all use since OS preferences are using anti-aliasing at smaller & smaller sizes. (which BTW I intend to tighten slightly so the verticals align to grid & the text matchs in width more perfectly with the bottom one).

The way antialiased text looks will vary somewhat according to the OS being used, videocards & so on. This sample was rendered in Photoshop ( heavy style, one of 6 flavors) which renders differently than my web browser & which renders differently than Flash & so on.

- The bottom one is the hinted black & white, or on & off pixels only, version. It's kind of old school, but this mode of rendering is the mode that programmers seem to like to program in the most.

Hrant, Actually I can turn anti-aliasing on from 6 pts on up. What I cannot seem to do is turn it off ( except in photoshop ) at sizes above 12pt in OSX Jaguar. So I have some choice, just not complete choice.

I like it, but its nice reading what programmers and developers themself would expect of such a typeface.. I think I looove the old style figures.. :)
( The only thing / character that slightly bothers me may be the lowercase 'w'.. )

For what it's worth, I would also like to cast a vote in favor of heavier punctuation. The more I look at those single-pixel dots in the period, colon, and semicolon, the more I think that they could be deal-breakers for me.

I do realize that expanding those dots to two or even four pixels would probably end up making the font look somewhat dishamonious; nevertheless, I think it would be the lesser of two evils, given the intended use. When coding, clarity is paramount.

I think I should also clarify my earlier comment on the 0 (zero) looking "odd". It's not the dot that looks odd to me; the dot is a very good thing. Rather, it's the disconcertingly small size of the entire glyph. ("Hmm... is that a zero? It looks awfully small to be a zero. What is that? Oh, I guess it must be a zero.")

In programming, it is very common to see lines of the form:

x = 0;

The 0 appears by itself, without any real context. Traditionally, when old-style figures are employed, they tend to be used in the context of prose, and more often than not, to represent multiple-digit numbers. This provides the context necessary to make the digits easy to identify. In code, single digits often appear without the benefit of that context, making it crucial that they be intrinsically easy to identify in isolation. I think old-style figures hinder that.

On the other hand, in the example you posted later, with the text setting, I think the old-style figures look great.

Perhaps you could offer your two versions of the font as follows: one with exaggerated dots and non-old-style figures (for use by coders), and one with the "normal" dots and old-style figures (for general-purpose use as a monospaced font).

Hi Eben,

Congratulations for your Designs!
They look very clean and legible.

Best,

mh

Thanks! The latest news is that my friend has decided that he likes the slighly smaller caps & quieter look of my original bitmap design best for programing, & the new design for reading text - so I will be making 4 fonts available once they are finally tested.

(1) The tall one shown here with the , (2) plus a version with stronger puctuation as requested, (3) The older shorter version with simpler & quieter forms, (4) The older version with strong puctuation. I might keep sthe old style figures as well. I guess I will offer the old version in bitmap centric format & a smooth line hinted format too. So really, 8+ fonts total.

All the new versions will have a better underscore & a new ampersand.

Anyway I hope to be wrapping this up soon.

Any more programmers here? Want to get your feature requests in?

Cheers!

I have added a link to a bunch of ampersand designs at the top. What do you think?

Ampersands: to me #9 is clearly the best, if also very conventional. Or #6 if you'd like to sacrifice some conventionality for slightly better spacing. In fact to improve the spacing, could you push the head one pixel to the right and still end up with something decent? Either way (and actually especially if you push the head rightward) you might also try an open-headed design.

hhp

Yes, I think I agree. What do you mean by open headed? - I am intrigued. Is there a font that you can point to as an example?

Mana! :-)

hhp