Just curious -- asking on behalf of someone else willing to undertake this :-)

We have 27 different fonts [...] We will likely need to have at least an English font and a Greek font.

Is that 27 different styles, or one "normal" font, with ligatures, Greek, and other characters spread over the other font files?
The good news is that you can probably move every glyph of your "regular" font into one single font file -- that's what Unicode is for. If you originally had four styles (Regular, Italic, Bold and Bold Italic), you'd end up with just four font files. All characters for Greek, for example, are encompassed in the Unicode set.

The principal idea of Unicode is really simple. It'd take some time to copy, then assign the correct Unicodes to every single character, and to copy all existing kern sets (and add new ones, as suddenly entirely new combinations are possible), but then you can add OT features for ligatures and stuff like that.

As Theunis says, you haven't really specified the extent of the work. If all your fonts currently have the same encoding (for example, if all the fonts with the Greek characters have them encoded the same), it would be fairly quick to do.

Think of Unicode as an extension of ASCII -- that's what Unicode is, a standard, just like ASACII. Really big ASCII. Moreover, The first 127 characters in Unicode are the same as ASCII, the work amounts to giving the other characters the proper "name"; properly named, FontLab will assign the correct Unicode hex. One exception is the poloytonic Greek characters, where you'll have to look up the Unicode. Depending on what's in your fonts, there may be a few other characters in this class.

But likely you are undertaking this because you are switching layout programs, and the new, Unicode savvy programs allow for fonts with far more of the niceties programmed in. Some new glyphs will likely have to be drawn up, the "extra" ligatures such as ffi, ffl, ff, fj, maybe fb, fh, fk. Features for switching numbers, oldstyle and lining, in both tabular and proportional, will need to be written, and any missing glyphs created. As a rule of thumb, when converting our old PostScript Type 1 fonts to OpenType fonts, I allow two days for the roman, one day for the italic. This from a starting point where most of the characters/glyphs were already made up, as our old layout program allowed custom encoding. The roman takes longer because of the nature of our work, so our "new" OpenType roman fonts have superscripts (for footnote calls), arbitrary fractions, etc. etc.

If this is an accurate picture of your situation, the work will take longer. I'd almost say you would be better off to do it yourself even given the learning curve of FontLab, as a significant part of the work is understanding what will be needed with *your* workflow. That's were your expertise overshadows the mostly mechanical problem of converting the fonts.

Thanks very much for your input, much appreciated.

Theunis is correct. We would likely end up with just four fonts, Roman, Italic, Bold and BoldItalic along with a few custom characters that aren't likely in the unicode set.

Charles is also correct that we are working toward having everything in InDesign and it WOULD be in my best interest to have at least someone here in our operation know Unicode enough to create a solid font. Thanks for the specifics too, Charles. I hadn't given much thought to all the unicode features we could add, which of course will add more time!

Any suggestions on a source of knowledge for a unicode newbee?

Again, many thanks.

I should have followed your bio to your web page.

If these are Matthew Carter's fonts for Yale, I'd be willing to do the work, out of affection for Carter and YUP. If you want to check my bona fides, ask Carter and Chris Coffin at YUP. If the project isn't the Yale fonts, I wouldn't touch it.

I'd note that what you need done is not to create a "Unicode" font, but an OpenType font from the various PS Type 1 sources. OpenType presupposed Unicode, but not the inverse. The OpenType spec could become obsolete; in all likelihood whatever replaced it would also conform to Unicode.

From the basic Unicode perspective -- the character compliment -- the first thing you have to establish with your client is what languages they want to support. This goes beyond simply "Latin" or "Greek." There are numerous languages that essentially use the Latin alphabet -- several African languages, Native American languages, Vietnamese, etc. -- that use a few extra characters (provided for in Unicode), either directly or with combining diacriticals. Your client may also wish to provide for Latin transliterations of, say, Arabic, the Indic Scripts, Chinese, Japanese, etc. These too require characters with combining diacriticals.

Moving from the characters, you need to provide the OpenType features that will make composition possible with InDesign (or another OpenType-based layout program). This is where it can get complicated.

To give you just one example, we recently got in a manuscript where all the accents in the author's files were accomplished by using combining diacriticals, even the common European accented characters. Speaking precisely, *combining diacriticals* would not be in the Type 1 font, so the Unicode portion of the font work would require creating them. Beyond this, an OpenType feature would need to be written to make their use seamless. This could be done with a ccmp feature, or mark and mkmk features. By the way, the current version of FontLab Studio 5 does not support mark and mkmk, so if you stick to FontLab, you would have to use ccmp. If you wanted to use mark and mkmk, you would need to use the Adobe tool. Each method has pluses and minuses, and each has its advocates.

Finally, do you intend to support these fonts for your client? In our bookwork, we don't do much composition with format design, but we do set a number of academic journals, so I'm familiar with the issues of "templates." As I'm sure you know, it is just a matter of time before some author comes up with something that will require a little more fontwork. If you are going to support the fonts, you are best served to write the OT features in a way that will let you go back into the file and add either characters or new features, as needed. This is an issue the font designers don't often face. The trick is to write the feature code so it might be a little less compact, but is more user friendly.

I know of no single book that covers all this, you just need to comes to terms with both the Unicode Standard, and the OpenType Standard.