So at this point I wouldn't expect much more anytime soon. I have contemplated simply shutting the site down to further simplify my life, but there is still a steady readership for my LaTeX and fonts tutorial according to the analytics.

There was some renewed interest in my document Typographic Style for Computer Scientists on Reddit yesterday, so maybe I will finally take some time to produce a new draft of that soonish.

Leon recommended Junicode, which provides the most important features I discussed. I do think its stems are a bit thinner than I prefer, but it seems very well done.

In my discussion of METATYPE1 and meta-fonts, Till pointed out the existence of the meta-font Antykwa Półtawskiego. At the time I told him that I thought he was misinformed because Antykwa Toruńska seemed to have been created by tracing scanned specimens. A few days ago, Peter Backes pointed out this rather egregious error in reading comprehension on my part. Currently, only the generated Type 1 font files are available for Antykwa Półtawskiego.  However, it sounds like it was prepared using a rather early version of METATYPE1 and therefore the sources could possibly be incompatible with the newer versions of METATYPE1.

Peter also noted that he has also created a font with METATYPE1 called OCEANIA. It is perhaps not as "meta" as he thinks would be ideal, but during the time I've spent working with METAFONT and METATYPE1, I've definitely found that it is often quite difficult to come up with a reasonable declarative specification of a glyph.

It seems likely that otftotfm may also work on pre-OpenType TrueType fonts because the OpenType font format is essentially the same as the TrueType format with potentially additional tables. At least, when I did cursory search on my computer I could not find any TrueType fonts that proved to be incompatible with otftotfm.

Therefore, if you want to use a TrueType font with pdfLaTeX you should ignore the instructions I give in ∃xistential Type Fonts in LaTeX, Part Three: pdfTeX and TrueType and use the same instructions as I gave for OpenType fonts in Fonts in LaTeX, Part Two: pdfTeX and OpenType. For your convenience, I have also created an updated the zip file for the example that uses otftotfm instead of ttf2tfm.

Looking at the comments on reddit, I figured that I would say that luatex does resolve pdfTeX's internal limitation of 256 glyphs that I mentioned in part two, and it should directly support OpenType fonts with PostScript outlines.

However, my understanding is that the authors of luatex do not intend to make using TrueType and OpenType fonts as simple as XeTeX directly.  Instead, luatex merely makes the machinery available for someone else to build upon.  So someone will need to write a LaTeX package for luatex to put it all together, and as far as I know, no one has done this yet (let me know if I'm wrong!).  Also, while the plan is for luatex to eventually be merged back into pdfTeX, I think it is an overstatement to say that it will happen "soon".  The current luatex roadmap says that a "production" ready version will be available in August 2009.  I doubt that the merge back to pdfTeX will happen any sooner than 2010 given that.  But yes, in the long term I think luatex will be a great thing.

It also sounds like I should probably write a fourth part to my tutorial on using fontinst.  I've never personally used it myself, and when I first started working with OpenType fonts and LaTeX I wasn't aware of its existence.  Therefore, I wrote otftofd.  So it might take a bit longer to write as I will have to learn it at the same time.

So after thinking about it further, I was incorrect, and it is possible to explicitly unpack existentials in Scala. As with some other languages, it is done via pattern matching. The following example illustrates how:

val x : List[T] forSome { type T } = List(42)
val w = x match { case y : List[u] => ((z : u) => z)(y.head) }

However, in practice this functionality seems to be rather fragile. For example, the following two variations are rejected:

val x : T forSome { type T } = 42
val w = x match { case y : u => ((z : u) => z)(y) }

and

val x : List[List[T]] forSome { type T } = List(List(42))
val w = x match { case y : List[List[u]] => ((z : u) => z)(y.head.head) }

In both cases it reports that it cannot find the type u. In the second case, it could be attributed to erasure, as there is no way dynamically to guarantee that the contents of List are in turn also a List. However, the first seems reasonable, so it should probably be reported as a bug.

Arguably, it has been good for productivity in some ways.

I have not been able to figure out what is causing it. I've tried adjusting the padding and margins on all of the relative <div> blocks and even tried using the Aardvark Firefox extension to figure it out. What it is probably going to take is to replace to fancy CSS styling of the <div> blocks with old-fashioned HTML tables.