Creating a 300 dpi PDF context

Question

I am trying to create a multipage PDF document that I intent to print from an OSX app.

The hard part is finding a decent tutorial to understand the whole process. One has to use paranormal abilities to guess how it works or ask here :)

This is the point.

Every time a PDF context is created I see this line

UIGraphicsBeginPDFPageWithInfo(CGRectMake(0, 0, 612, 792), nil);

If I understood correctly, given that a PostScript point is 1/72 inch then

612 x 792 points = 8.5 x 11 inch = 215.9 mm x 279.4 = US Letter paper size.

But I see a problem here, this page will be printed at 72 dpi, right? Pretty much low resolution. How do I create something like 300 dpi?, just increase the number of points proportionally, or in that case create a context of 2550x3300 points?

Is this the correct way of doing this?

Another point is this: I am creating a context of the whole page. How do I know the are I can really print? Is all area printable in a PDF document?

Answer 1

The page is not printed at 72 dpi, that's merely the co-ordinate system. PDF files are (usually) vector based, and even if not can contain images of arbitrary resolution, the 'P' in PDF stands for Portable, so you don't generally need to worry about resolution.

The printable area of a PDF is that which is contained in the MediaBox, or the BleedBox, as limited by the CropBox, again in general you don't need to worry about these.

Answer 2

I wanted to write a bit more on the second part of your question (because I think the first part has been answered sufficiently by KenS. But I see too much possibility for confusion in your second question and wanted to elaborate.

As KenS says, the "P" in PDF stands for "Portable" which is another way of saying that PDF was designed to be device independent. That is why there is a coordinate system that works with 72 points which is then "converted" at print time to whatever resolution the actual printing device works at (or viewing device for that matter as we might just as well be talking about seeing a PDF on screen or on an iPad).

The second consequence for that is that PDF by itself doesn't know nor does it care what your printer can do. When you create a page with the call you showed in your code example, you're creating a PDF file that has a page with a MediaBox set to US Letter size. As far as PDF is concerned, you can draw content on that whole page area (and outside of it for that matter).

This does not say anything on whether that content will actually be printable. If you have a printer that can print page-wide, you may be able to get away with putting content right unto the edge of the page. If your printer requires half an inch gripping area where it can't print, some of your content may be clipped by the printer. If you're sending your PDF to a professional graphic arts workflow, some of the content may actually need to "bleed" (extend outside the page) so that cutting your page to final size doesn't cause problems.

The PDF file by itself doesn't care - it's device agnostic. It's your decision where to put content on the page. You may:

a) decide to use some other code to get the actual printable area for a particular printer and format your content accordingly.

b) decide to create a PDF that will print correctly on "most" decent printers.

Doing b) certainly follows the spirit of the PDF specification more than doing a), but sometimes a) is just easier :-)

Answer 3

Ken's and David's answers are both correct. This answer intends to address (what I consider to be) the deeper level of confusion underlying the question. PDF (and my beloved Postscript) are vector graphics formats, not -- I repeat -- not like an image (byte-map) format at all. This distinction extends down to the very atoms of the PDF universe, points.

A point in PDF is like a point in Geometry class. It merely designates a location on the plane. It does not cover any area. It is infinitely small.

But -- you say -- PDF can contain embedded images! So they have to be combined into the same level of detail to coexist in the same file!

No. PDF maintains embedded images, embeddedly. The image data exists in its own local context where the placement and location on the page (the larger, common context) is governed by a vector-geometry tool, an Affine (bi-linear) transform.

Now, there is a sense in which points do have resolution. Since a point is expressed as a computer word, it must be representable within the range of a computer word. So we have a range of about 4 billion for a 32bit integer, and a much broader range but with less precision for a 32bit floating-point (normalized mantissa-exponent form). So the numbers themselves bottom out if you go low or small enough. I believe Adobe's interpreters claim 8 decimal digits of precision for a floating-point value, whereas the standard C library only claims 6. So you can't really deal with images of dimensions 50 million by 50 million, because the vector machinery breaks down.

But none of that need concern you for any normal usage. It only comes up if you're trying to something crazy like a deep fractal zoom, but you probably wouldn't do that with pdf either.