I am not entirely sure how fair of a comparison I am making, but I am open to suggestions on how to better compare the hypothetical output of a font designed using METATYPE1, where a Type 1 font would be directly generated, versus a font designed using METAFONT, where a Type 1 font is generated using mftrace.
For my experiment, I chose to compare glyphs from the Type 1 version of Computer Modern maintained by the American Mathematical Society, which was presumable crafted by manually tracing the bitmap version and optimizing various aspects by hand, with glyphs generated by mftrace on 3000DPI bitmaps generated from the METAFONT source. I could imagine that it might be fairer to compare the result of using nearly identical METATYPE1 and METAFONT source to generate the Type 1 glyphs, but then I would be biasing the design process towards the limitations of METATYPE1. I had considered using the METAFONT source for AMS Euler, because the source is simply the outline and would be easy to convert to METATYPE1.
I also decided to use glyphs with plenty of curves for the test, as I figure that tracing software can probably do a pretty good job with straight lines.
In any event, I will leave it to you to decide whether you can distinguish which is version is which below. The order in which the two versions appear differs for each of the three examples below.
As you might have guessed, my opinion is that results are so nearly indistinguishable, that given the design limitations of METATYPE1, it would make much more sense to work with METAFONT and mftrace, and use FontForge or a similar tool to add hinting as a postprocessing step.
I figured I would pass along Emily Steel's Wall Street Journal article: Typeface Inspired by Comic Books Has Become a Font of Ill Will.
I've been spending time lately learning more about working with METATYPE1, mostly for my own projects, but with the eventual hope of writing some tutorials. While working on one of my running examples, I was encountering some difficulty expressing what I wanted in a reasonably declarative fashion. So I decided to see how it was done in Latin Modern.
I was dismayed to learn that Latin Modern is not a meta-font like Computer Modern. Instead the Type 1 versions of Computer Modern (which was developed by either Bluesky or Y&Y) were decompiled into MetaPost code as raw path outlines. So at that point all of the useful abstractions in Knuth's original code and specifications have been lost.
The only other major typeface developed in METATYPE1 that I know about, Antykwa Toruńska, has no source available and from the description I highly suspect that it was developed by creating raw paths that matched the scanned specimens. This got me thinking about whether there are any meta-fonts that have been developed in METATYPE1, or even whether Computer Modern might be the only full meta-font family in existence. I just skimmed through the METAFONT sources that are included in TeXLive, but didn't see anything particularly promising yet.
In any event, going back to the original issue, I have been starting to think that maybe the limitations of METATYPE1 are perhaps not worth being able to directly generate Type 1 fonts. It could be entirely possible that working in METAFONT and using something like mftrace to generate outline fonts from high-resolution bitmaps will produce results of sufficient quality. I'm hoping to do some tests to compare the two approaches this weekend.
(It is worth noting, that the comment about METATYPE1 on the mftrace page is slightly incorrect or out of date. METATYPE1 can handle overlaps, there are just complicated restrictions on how overlapping may occur. Finding clean approaches to avoid these restrictions was why I became interested in looking at the Latin Modern code to begin with.)
The other day on Digg I saw a link for 30 high-quality free fonts for professional designs. Many of the samples seem decent, but I guess it sparked the question in my mind of just what constitutes a "high-quality font".
I suppose when I think of a a quality font, I tend to expect a consistent design along with some of the following:
- composing characters or glyphs for most diacritical marks, ideally Greek and Cyrillic glyphs as well
- proper kerning
- appropriate ligatures
- old-style numbers
- optical sizes
Given these criterion, offhand I have to say that perhaps the best high-quality free fonts that I can think of off the top of my head are probably the TeX Gyre fonts and the Latin Modern family. I would be curious to hear about other recommendations.
The other day, a colleague of mine pointed out to me that Aarhus University recently rolled out a new, somewhat controversial, visual identity that includes a novel geometric alphabet that they call its "fifth element".
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
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
That was a longer hiatus than I had intended. Partly because not everything went according to plan.
My original plan was that, upon returning from my vacation, I would spend my remaining time at EPFL writing a technical report explaining everything I knew about the problems with Scala Classic. Instead, on my first day back in the office, Martin came by with a draft of a new formal system, DOT (for Dependent Object Types), that he came up with while he was on vacation. After about four weeks I managed to root out pretty much all of the obvious problems with DOT, but another four weeks was not enough to get the proofs and the metatheory into a state that we were happy with. I am not really sure what will happen with DOT in the long term.
There are a few clever things about DOT that avoid some of the problems I encountered with Scala Classic. For example, Scala Classic only had intersection types while DOT has both intersection and union types, which solves some problems with computing the members of types. However, with Scala Classic I was trying to model a minimal subset Scala language as it exists, without adding any new features that many never be supported by the full language. I have no idea if we will see union types in the actual Scala implementation anytime soon.
The other thing DOT does is give up the goal of trying to be a minimal subset of Scala and throws out quite a few important things from a user perspective. For example, there are no methods (only λ-abstractions), no existentials, no built-in inheritance or mix-in composition (though you can encode it by hand), and object fields must be syntactically values.
This last restriction is particularly important because it solves by fiat the problems that arose in Scala Classic from using paths that have an empty type in dependent type projections. However, it also means that you may not be able to directly encode some Scala programs into DOT without an effect or termination analysis. Therefore, while DOT has the potential to be a useful intermediary step, there will still be more work to be done to provide a semantics for a more realistic subset of the Scala language.
I have been in Copenhagen for a little over a month now, but I am not really ready to comment on the research I have been doing here yet. So in the meantime I'll probably focus more on fonts and typography.