"Is it considered poor form to just leave those glyphs empty?"

Not necessarily, but any document formatted with a different font, when changed to yours would have missing characters if the ones you mention had been previously used.

I believe Build forum would be the best one for this question, but it can be answered here anyway.

IMO, to let these positions empty is a poor procedure.

The glyphs included on ISO 8859-1 are actually a quite reduced set these days, when support for languages is always growing. ISO 8859-1 just holds Western European idioms –but it is OK to do a font with it if your goal is to use the fonts just with these languages. In other hand, to offer a partial codepage support is not good. Users would be surprised not to find some basic characters your font is supposed to have. And codepages were designed exactly to define standards to which fonts, OSs, and applications would comply with.

Regarding super and subscript, you are right that most text editors can build these characters from the normal ones. But the software do this scaling down the original figure and this causes very thin stems and strokes. The result is a weak, somewhat anemic super/subscript character.

An example:

The second line shows 1, 2 and 3 scaled down by the editor while the third line uses 1, 2 and 3 included on the font (Helvetica Neue and Minion Pro). Note that vertical positions are also adjusted by the font designer to produce optimal results considering the overall design.

You may evaluate the difference as small, but keep in mind that typographic quality is determined by details. Small differences become huge when in use.

Fractions are an even worse matter as editors are not capable to produce them from the normal figures. Here, you need proper glyphs in the font.

As you pointed, what is included in ISO 8859-1 is not enough. This standard is old, a legacy from the times when fonts were limited to 256 characters. To achieve 0-9 super and subscript you need to include the whole set of figures in your font. These figures are coded in the 2070 block from Unicode, the standard that replaced former ISO codepages. Fractions beyond the basic ones are coded in the 2150 block.

Anyway, there is nothing wrong to adopt ISO 8859-1. This is your first font and you can do additions like super/subscript and fraction in a future moment. Just ensure that all glyphs are properly named and coded since the beginning.

Finally, characters you can add depend on your purpose. Do you want to support Polish or Norwegian? Do think it is nice to offer arrows and bullets? Define your target and then do a research on Unicode tables. Euro sign, proper quotes, en dash, and em dash are a good start point.

There are already all nine ordinal numbers, and software has to be able to make superscripts (and subscripts) using them (and letters too) as well as fractions.

Yes. And as Mr. Freiberger showed, the result looks like dung. When you scale glyphs down, they do get smaller. The weight gets lighter as well. Too light.

Secondly, most layout software (e.g., InDesign) will not programmatically kern unscaled letters with scaled letters -- you have to do it by hand, in each instance. So, for example, with footnote calls, if you scale full-size numerals, you cannot programmatically kern them when they follow quotedblright, as is almost always needed. Or follow a period, comma, etc.

You need to decide if you are making up a font for your own use only, in which case what you do follows the principle of the one that applies to the privacy of your own bedroom, or a font for other people to use, in which case you need to consider what they might expect.

I believe several of us had the same thought at the same time -- I've edited my post, as Mr. Freiberger took the trouble to illustrate the problem rather well.

That several of us had the same reaction should indicate a need for you to get the basics, and as I said before, the best place is from well-thought out books.

I understand that you need Type 1 PFB for your own purposes. But do keep in mind that for most folks OpenType CFF is more broadly useful.

For example, you will be very limited in the usable (outside of TeX) language coverage in a normal name-keyed Type 1 font. The PFB won't work at the system level on Mac OS. Typographic features can't be encoded in the font. And so on....

Well, sorta, kinda Thomas. I don't know LaTeX, or the Mac, but we ran plain TeX out of a DOS box on Windows machines for 10 years, setting all manner of scholarly books. The thing is, you're not limited to the Windows or Mac encoding vectors. Our font files were what I called "font data bases" and most had over 400 characters. They looked remarkably like a modern, up-to-date OpenType font, except must use names. You can only encode 254 at once, but you can pick what you include in an "instance" of a font by a custom encoding vector.

Kerning too is part of the large, database font; if you make a change, you make it there -- no need to worry about, say, cap-cap kerning values in both a small caps font and a regular UC-lc font.

And the glyph names can be correct, so the underlying text file needs no little lies in it about what the characters are. (For character names, I used the AGL supplemented by common sense, but toward the end, I just used "uni0000" (where 0000 was the correct Unicode number) as a name.

You can also fill out the AFM to provide automatic ligaturing, at least, for the very few programs that make use of the AFM file -- something most people didn't know. With TeX, the TFM is based on the AFM, and can be made to preserve such instructions. As one example, we added "gg" and"zz" and "ggy" etc. ligs for a number of italic fonts; when the ligature glyphs were there and encoded, they would be used automatically.

Etc.

OK, I don't know LaTeX, but this is what I mean by saying if one would read enough to understand what was possible -- as well as what's usually considered desirable -- you're miles ahead than if you ask 1,000 basic questions, one at a time, on an internet forum.

Edit:

For the Original Poster -- here's a link showing the use of TeX to set scholarly books. Fonts used were all PostScript (starting from pfb + afm), though most were custom, as indicated above. I imagine anything you an do with TeX you can do with LaTex (though it might take more effort to undo some macros?)

http://www.tsengbooks.com/

See also

http://www.tug.org/texshowcase/

Charles: I don't see anything that you wrote that renders what I said only "kind of" or "sort of" true. All that stuff you said is true in TeX or some derivatives. My point was that none of that stuff works outside the TeX-and-derivatives world, which is a tiny subset of publishing, let alone font use.

Which is why, in the broader world, Type 1 is pretty much dead as a format for new fonts.

Not that Alice shouldn't make what she needs for her own use, of course! Just that if she wants to sell it, or release it as a libre font, or otherwise make it available beyond the TeX-and-derivatives community, she might consider alternatives to Type 1.

I suppose I was nit-picking Thomas, but there are "features" available in type 1 fonts. Tex made use use of them, but they were "in" Type 1 fonts. It is also true that most of the software then in use -- including the two most popular operating systems, rendered those features unavailable.

You're right, of course. As always, any new fonts should be developed in the format currently in use (which will change...).

> but there are "features" available in type 1 fonts. Tex made use use of them, but they were "in" Type 1 fonts.

What are you referring to? There is the TeX-specific TFM file for ligature info, but that is not part of the Type 1 format as such.

InDesign will intuit ligature info from glyph names for the five most common ligatures, even in Type 1 fonts. But that's pretty limited and not really based on the format per se.

Anyhow, this is a bit of a side issue from the discussion at hand, and I don't think we are in disagreement about that.

Yes, probably not important. Still, here's a few lines from our AFM for the old Monotype Garmond (from the 1990s):

C 103 ; WX 323 ; N g ; B -106 -273 383 403 ; L g gg ; L y gy ; L p gp ; L j gj ;
...
C -1 ; WX 677 ; N gg ; B -105 -270 733 403 ; L p ggp ; L y ggy ;
C -1 ; WX 1134 ; N ggp ; B -105 -270 1150 518 ;
C -1 ; WX 1052 ; N ggy ; B -105 -289 1081 403 ;
C -1 ; WX 561 ; N gj ; B -98 -272 642 608 ;
C -1 ; WX 799 ; N gp ; B -105 -272 809 518 ;
C -1 ; WX 708 ; N gy ; B -105 -289 728 403 ;

...

C 122 ; WX 417 ; N z ; B 56 -263 489 403 ; L y zy ; L z zz ;
...
C -1 ; WX 767 ; N zy ; B 16 -277 790 402 ;
C -1 ; WX 840 ; N zz ; B 57 -255 911 402 ; L y zzy ;
C -1 ; WX 1184 ; N zzy ; B 16 -277 1207 402 ;

The "C-1" shows they didn't happen to be encoded in this particular AFM file, but by writing & running the correct encoding vector, they would have been included, and then been used.

* * *

Also, note that the AFM format includes a mechanism for building composite glyphs out of components. It is roughly equivalent to the OpenType mark-to-base feature. AFAIK, nobody uses this, though.

First, apologies to Alice for hijacking her thread. No reason for her to keep on reading this!

Short version: Charles is right about ligatures being supported in the AFM, although it raises a number of questions about where that data continues on to on Mac and Windows. Of course, the existence of ligature definitions in an AFM doesn't imply any other typographic features, nor that the ligature info is used.

Long version:

Charles, I was surprised by your AFM, since I knew that I had actually read the entire Type 1 format back in the day, and hadn't ever noticed this. In fact, I still have it (version 1.1) as a real printed book on my bookshelf. So I simply pulled it down to check.

Turns out that the AFM format is not technically part of the Type 1 spec. It is mentioned exactly once in passing in the book, and even then only in the context of Adobe wanting to get AFM files from vendors under some particular circumstances.

This makes sense in some ways: it is not included in platform-specific Type 1 flavors for Mac or Windows, for instance. But it is certainly a good data source relating to the font, and I'd never read the AFM spec. There is the ligature support at the bottom of page 32, for sure. http://partners.adobe.com/public/developer/en/font/5004.AFM_Spec.pdf

Some things in AFM files, such as kerning info, are preserved in translation to the platform-specific PFM or font suitcase files used on Windows and Mac, respectively. I certainly think of kerning as being “part of” a Type 1 font, even if it isn't in the Type 1 spec per se. I have no idea if the ligature info is preserved in those translations as well, although I doubt it—if it is, few if any clients use it.

Using the commands afm2tfm and vptovf, the kerning and ligature information contained in the .afm file can be converted to the format that TeX uses for kerning and ligatures (TeX Live runs on Mac OS X, Windows and Unix).