The GeoPDF CTM and Units: An Implementation Note

Like many projects, GeoPDF escaped from the lab before it was fully developed. An implementation detail that may seem bizarre at first glance are the units of the parameters CTM which defines the a GeoPDF georegistration. Recalling the CTM:

[ a b c d H V ]

the parameters a, b, c, and d are in units of meters per point. Parameters H and V are in meters. A point in PDF is defined as 1/72 of an inch. What's up with that?

If you take it all the way back, it goes back to the arcana of printing. We'll take it back as far as PostScript, where a unit in what's called default user space was defined to be a point, and a point defined as exactly 1/72 of an inch. See the Red Book [PDF] for more. The point unit default user space lives on in PDF, and, in GeoPDF.

Many of the interfaces for dealing with PDF pages take and yield values in points. The GEOTRANS projection engine we used at the time works in meters. The points-in-meters out (and vice versa) interface was convenient for bridging the two worlds and helped to make the georegistration concept -- this part of the page is "registered" to this part of the world -- concrete.

There's even a reason it's meters per point rather than the other way around. The eastings and northings associated with projections used for many practical mapping applications tend to be "large", often ranging around the hundreds of thousands or millions of meters. Points tend to range from zero to the low thousands for most practical page sizes. A ratio of points per meter often yielded fractional values that could not be encoded as a in a PDF file as a PDF number without significant loss of precision. Also, the H and V often took on values that could be recognized as being associated with this or that coordinate reference system. We ran into other issues with limitations of PDF numbers, the solution to which we'll leave for another time.