Archive for meta


I probably should have done this quite some time ago, but it is worth mentioning that this site has no direct relationship with the other "Existential Type" blog: I certainly do know Bob and I even host the Successor ML wiki for him. I am kind of surprised he decided to reuse the name without mentioning it to me, but I can perhaps be blamed for not posting anything here in years.



Assuming anyone is still reading or subscribed to the RSS feed, you have probably noticed the marked lack of updates. There are a variety reasons for this. One is that I joined the compiler team at LogicBlox in January. As such, I am not really doing all that much typesetting or typographical sorts of things these days. Though I have been recently learning the joys of trying to produce HTML and PDF output from a DocBook source and have both look remotely reasonable. As for type systems, well, I've been doing some of that, and may be doing quite a bit more in the near future. But rather than worrying about whether I may say too much, I'm just saying nothing about that for maximal peace of mind.

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.

Comments (2)

Following up on quality fonts and meta-fonts

In response to my post on quality fontsmbana provided a pointer to a Typophile discussion on the Tex Gyre fonts. In particular, Thomas Phinney described their quality as "wildly variable". I suppose at the time I was using "quality" to more describe whether the fonts provided all the features I would expect to need, rather than only aesthetic quality. I have to admit when I did skim the specimens that they didn't look too bad to me. He did say that the glyphs based on the original URW designs were quite good, while the Greek and Cyrillic "range from mediocre to poor to largely useless". Phinney most certainly has more experience with Cyrillic and type design than me, and arguably he probably just has a much better eye than me.

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.


Fonts in LaTeX, Errata

About seven months ago, Vasile Gaburici alerted me to the fact that otftotfm has had experimental support for OpenType fonts TrueType outlines for quite some time. Furthermore, it will use kerning tables that ttf2tfm will ignore.  I am now finally getting around to writing a post to highlight this fact.

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.


Fonts in LaTeX, an intermission

Part one of my tutorial attracted a considerable number of visitors, far more than any single entry in the past, partly because it was posted to reddit.

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.

Comments (1)

Correction on existential unpacking

(WordPress ate my first draft, grrr.)

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:

  1. val x : List[T] forSome { type T } = List(42)
  2. 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:

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


  1. val x : List[List[T]] forSome { type T } = List(List(42))
  2. 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.


When sending messages by post would be faster

We have been experiencing a massive delay in all the scala-* mailing lists at EPFL, both the public and private lists. The admins are so worried about open relays, the firewall prevent us from having our lab's admin run the mailing lists on one of our servers. Of course, despite telling the central admins that this is a serious problem, it has just gone from bad to worse. Last week we were seeing delays of about an hour. The past day or two the delay seems to have hit something like at least twelve hours. That means if someone does a Subversion commit, we do not see the commit e-mail for at least twelve hours. The same goes with submissions to the bug tracking system, or even internal queries.

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

Comments (2)

Occupational hazards

My wrists are continuing to get worse. I am writing this using Dragon Naturally Speaking Preferred, but it is quite a struggle with the software.  I'm not sure whether I need a faster computer, or my enunciation is just terrible.  I certainly won't be  able to use it for typesetting or programming anytime soon. I'm not quite sure what to do now.  Wow I didn't actually have to correct that last sentence.  Or that one.  Sometimes I just get lucky, I suppose.

Comments (2)

Caution: style may fluctuatate

As you may be noticing, I am gradually moving to a new theme for the site.  I do not have a precise finished product in mind, but I am aiming for greater simplicity.  I am hoping to converge on something over the course of the coming week.


Why I hate CSS

I was fiddling with the site's formatting yesterday, trying to better utilize available display space by using relative sizing for the sidebar and main column. Unfortunately, on larger displays (and still noticeable on smaller ones) there is this huge space on the left-hand side.

Small screenshot of the site

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.

Comments (6)

« Previous entries Next Page » Next Page »