Add ability to include metadata and bleed settings

[bousquet]

Bleed

Allows new documents or new pages to have a :bleed value that extends outward from the normal document size. This is being used in production on SteppingStories.com and creates a TrimBox and other dimensions that are compatible with PDF/X-1A spec (see green and blue lines in this screenshot):

Tests for bleed will be submitted to prawn with the other Document tests for margin once this is merged in. The default bleed if unspecified is 0 so this is backwards compatible with all previous pdf-core documents.

Metadata

Extends PdfObject to allow embeded XML metadata required for PDF/X-1A compatibility. Most often this is for the Extensible Metadata Platform (XMP) junk that has to go into these files:

Use of the metadata objects are completely optional, but if you need to use them, you'll be glad they're there.

[pointlessone]

First of all, it's a bit awkward to have two separate features in the same PR. Could you please split it?

Next, I'm not happy about Metadata implementation. Metadata objects are a regular PDF Stream object. There's no need for a specialized class for it, is there?

[bousquet]

@cheba Np, I can split the features. The metadata needs a different dictionary that includes type and subtype values so I felt it was worth creating its own class. It uses the existing PDF::Core::Stream class internally where it can.

[bousquet]

Also, once these bleed settings make it into pdf-core, then I can submit a separate PR to prawn that makes use of in the Prawn::Document.

[bousquet]

Split into #18 and #19. Closing.

[pointlessone]

Also, once these bleed settings make it into pdf-core, then I can submit a separate PR to prawn that makes use of in the Prawn::Document.

Agreed.

The metadata needs a different dictionary that includes type and subtype values so I felt it was worth creating its own class. It uses the stream internally where it can.

Any PDF object can has an associated stream. This is why it doesn't seem like pdf-core is the place for it. It looks like it should be implemented on the Prawn side where you can implement a custom Ruby class/API to represent Metadata but internally it's going to serialize to a plain PRF object. What do you think?

[bousquet]

@cheba I'm open to suggestions on the metadata topic. I actually have a much more involved metadata xml insert that uses this to generate the actual PDF/X embeds (content inside the metadata pdfobject) but figured that was app specific although maybe PDF/X-1A will eventually be a setting in here. What are the long term plans for handling all these dang specs that printers want from us?

[pointlessone]

@bousquet I'm not sure actually. Currently we target PDF 1.4. But practically only a subset of it that's supported by most common PDF viewers (like OS X Preview and Acrobat Reader).

[packetmonkey]

@cheba we also set the minimum version to 1.6 if we use something like page scaling.

I'm totally open to trying to figure out a way to add better PDF/X support to Prawn and I think the overall plan here is a good one, implement the core low level features in pdf-core then implement the higher level features in Prawn::Document or a new Prawn::PDFX

[pointlessone]

@packetmonkey IIRC, we only bump document version up for features that has been introduced later than the current version of the document. Which is logical.