Hi,

A couple of great features for printing:

1. Page bleed. This would simply be added to the page dimensions and inner page margins (or padding in terms of the CSS box model), it's just a few simple calculations done at initialisation time, so it should be fairly easy to do.

For example if you specify an A4 page (21cm x 29.7cm) and have top and bottom page margins of 3cm, horizontal page margins of 1cm and a bleed of 5mm, the recalculated page dimensions would be 22cm x 30.7cm and margins of 3.5cm and 1.5cm.

2. Crop marks. If you implement bleed, it would be very handy (and probably necessary) to generate crop marks. Again these should be fairly easy to implement with a bit of SVG (or whatever Prince uses internally to draw the PDF).

Simply draw straight lines inside the bleed area marking the corners of the original page with a 1 or 2mm gap so the crop marks don't touch the page area - or better yet, let the user specify the length of the crop marks, which start from the outside edges of the bleed.

3. Page spreads. If you could give a page an attribute which marks it as a spread, that page would essentially be two pages joined together. More accurately, we are constructing a new double-size page rather than literally joining two separate ones. Generally this will be a page of opposite orientation, with the join at the vertical edges, though this should be able to be specified with an additional attribute. e.g.

@page large_graphic {
   spread: horizontal;
   bleed: 5mm;
   cropmarks: 4mm;
   @top { content: default }; /* no header on this spread */
   @bottom { content: flow(spread_footer); } /* special footer for this spread */
}

The only bugbear here is the positioning of header and footer elements (which need to be worked on for the currently available orientation switching) and page numbering. My suggestion here is to allow unique header and footer content to be assignable on a page-type basis (actually this may already be possible by using named page flows). Perhaps the default for a page spread should be combined left/right page headers and footers, as if the page spread was made from two separate pages.

Prince 6.0 already supports crop marks, which also give you a page bleed area of fixed size:

@page {
    marks: crop || cross
}

The page spread idea is interesting, although perhaps a bit complicated to implement. Would it result in lines of text spanning across two pages as if they were one big page?

I originally imagined a page spread would generate a single double-sized page rather than two separate pages literally stuck together, so text could spread across the whole area.

However on further consideration page spreads can be imposed in two different ways: Reader Spreads and Printer Spreads. With Reader Spreads, you see the pages in sequential order, while Printer Spreads will arrange all pages in pairs so that they are in the correct order when printed and folded down the middle. Pages paired for printing will be matched differently depending on the total number of pages in the document.

So rather than building an extra "imposition" layout engine into Prince (which could be very useful, but a lot of extra work), it is probably best to generate separate pages and let someone use third party prepress software to generate their own impositions from the individual PDF pages.

In that case, when you create a spread, you would construct and lay out the double-sized page and the contents within it. Then you would duplicate that content on two regular pages with one half on each page.

Right. Does that mean we have to do anything?

That depends if you can already split a large page across two smaller pages with one half on each, taking margins, header, footer and other page attributes from the spread page attributes. My understanding is that this is not currently possible, but I'm happy to be proved wrong

Nope, we can't. It sounds like that would require a new page size keyword, eg.

@page {
    size: A4 spread
}

You could then trigger this with named pages or whatever, and it would result in a double-size page being used for that content that would then be chopped up into two pages in the output PDF. I'm sure there are lots of issues with margins and headers/footers and so forth, but that would be the basic idea. Does it sound like something worth considering for Prince in the future?

Yeah, I think some way of handling spreads would be great. Having them split over standard sized pages is a good start, and opens the path to more sophisticated imposition options further down the line.

Cheers!

Oh by the way, what is the size of the bleed produced by the marks attribute? The (online) documentation doesn't say, but those dimensions will need to be added to the page size in order to create a background image that fits perfectly.

If crop or cross marks are enabled then 6pt of bleed area will be added to all four sides of the page, plus extra trim space for drawing the marks themselves. I've added this information to the documentation for the marks property.

That's great, but crops are only useful when coupled with bleeds - that is, the printable area of the page is increased to allow printing in the gutter area surrounding the page. The crop marks are then used as a guide to cut the page to size with printing right up to the edge of the page. Prince only seems to print up to but not over the printable area as defined by the page size, making crop marks apparently useless.

I guess what needs to happen is that when crop marks are turned on, the effective page size is increased and background colours and images of the margin and body elements are made to fill this expanded area. Other page elements should be able to be positioned into the bleed area with negative relative or absolute values.

That makes sense; no point having a bleed area if printing can't bleed into it! I've added this issue to the roadmap.

Actually, it seems that we have already fixed this in the last maintenance release, when we changed the treatment of @page backgrounds to cover the entire page box. This means that when crop marks are enabled, the page background color or image will fill the entire bleed area, not just the trim area. Can you confirm that the current behaviour of Prince 6.0 rev 2 is okay for what you are trying to do?

I can confirm that the page background prints into the bleed area, however margin (header and footer) elements do not.

There is also a bug when combining multiple html pages into a single PDF where footer margin content is printed only on the first page. The header content prints on all pages though.

In that case it seems that the only solution would be to expand the page size to include the bleed area, so that margin content can extend beyond the trim area. This would have the disadvantage that the page width and hence page layout would be changed by enabling crop marks. A possible solution for this would be to silently add 6pt on to each page margin, which would preserve the layout; this would prevent document body content from extending past the trim area though.

If you could, sometime in the long future, make bleeds configurable that'd be awesome. I believe our art department uses mostly 1/8" bleeds (9pt or .75p (PostScript picas)) instead of the 6t or 1/12" bleed.

Making the bleed area configurable in size makes sense, and should be achievable with a new property for @page rules.

Yes, something like:

@page {
   size: A4;
   bleed: 5mm;
   marks: crop;
}

Then the page designer can make sure any background images are sized to include the extra bleed size. That's pretty much how we go about it using traditional DTP software.

BTW silently adding margins/padding inside the header/footer area to effectively limit the content positioning to the page size/trim boundary as you suggest is a reasonable and relatively simple way of counteracting the effect of bleed. Adding or removing bleeds should not result in the repositioning of content on the page (with the exception page and margin backgrounds of course).

A page designer could then still position page elements into the bleed area with explicit negative absolute/relative positioning or margins.

The way I look at it, the header/footer margin areas should inherit @page properties - after all the header and footer margins are literally the top and bottom of the page.

Prince constrains content inside a page to an inner box defined by the BODY element, which, if no width is explicitly set, defaults to the page width. I would expect the margin areas to behave in much the same way, with the exception that dimensions and other properties of the inner box should not be taken from the BODY element, but from the @top and @bottom definitions. Again, if no dimensions are explicitly set on those elements, the inner box should default to the page size.

The marks/crop/cross/bleed features are working fine for me with 6.0r2 (Thanks, Mike!), including bleeding an element statically flowed into a margin box (in my case, dictionary-style "thumb tabs").

However, I too am finding it awkward to not be able to control the size of the crops/cross/bleed areas. I measured in acrobat and the hardcoded values seem to even be inconsistent (.875 top and bottom; .75 left and right). I'm having trouble explaining those choices to my internal clients.

A related option that would be nice would be to have those marks/bleeds present, but to be able to generate the PDF with the crop box already set to the page boundaries. That way, press/imposition operators would still have the data they need, but users could still review and print the PDF looking like they would see it. This can be done manually of course in Acrobat (command-shift-T - Crop), but the whole point of Prince is to avoid those manual steps...

This sounds similar to the request for page scaling, but with a default value when crop marks are enabled that will size the page so that the trim box fills the window?

I'm not sure if this is the same thing or not, but I think not. This is, I believe, setting the Crop Box in the PDF standard. Most viewers by default display only the Crop Box as if it were the page bounds; however the data outside the crop box and inside the page bounds is still present in the PDF. Viewing the page bounds, or altering the crop box reveals it.

Okay, I think we can do this. We have just released Prince 6.0 rev 3, which includes support for a new prince-bleed property for controlling the size of the bleed area when crop marks are enabled. The new release also allows page background images to overlap into the bleed area, as expected. It would be good if you could create a new topic on the forum for further cropping related issues to ensure that they don't get lost, and we can continue to improve support for them in future releases of Prince.

Perhaps I'm doing something wrong here, but page and backgrounds don't seem to be printing into the bleed area. The new prince-bleed property which allows the bleed size to be specified works great, as does adding crop and cross marks and background image resolution. But nothing is printed in that bleed area.

I'm using CSS like this:

@page { 
	size: A4;
	marks: crop cross;
	prince-bleed: 5mm;
	margin: 50mm 0 15mm;
	padding-top: 2em;
	background: url(../img/print/grid.png);
}

The background image grid.png prints right to the edge of the page, but not into the bleed area. The footer has a background colour applied, which also doesn't print into the bleed area.

Finally, I'm having a problem using different background images in the header area of left and right pages. Using the following CSS I get no image at all (though the image path is correct and verified):

@page:left #header { 
   background: url(../img/print/header_left.png) no-repeat center; 
}
@page:right #header { 
   background: url(../img/print/header_right.png) no-repeat center; 
}

Right, there appears to be a problem with the background image not applying to the bleed area, it seems that this was accidentally reverted at some point before release. I've added this bug to the roadmap.

Regarding your other issue, "@page:left #header" is not a valid page selector. Perhaps you mean to use "@page:left { @top { ... } }" to select the page header on left pages?

Yes, I did resort to @page:left { @top {...}} to get the effect I need for the facing headers, but it would be handy to be able to vary the display of page elements depending on the page facing. The position or visibility of a logo for example.

@page:left element or @page:left { element {...}} certainly sounds like a reasonable selector. In theory the page facing and numbering ought to be available when a given page is rendered.

Not a critical feature by any means, but a potentially useful one.

This is a bit tricky for us to implement, as in CSS the properties that apply to an element are determined before any layout has been performed. There are some ways around this restriction, such as the inside/outside values for float and clear and the margin-inside/outside properties which depend on the current page side.

OK, no worries. If both alternate page headers/footers are defined in the source document it would be possible to vary their contents somewhat. Thanks.

Okay, today we have released Prince 6.0 rev 4, which should resolve the issues with background properties in @page rules and make the page background image correctly extend into the bleed area when crop marks are enabled. Thanks for being patient!

When a PDF with images that span facing pages is intended for a printery, you need to handle the image bleed carefully.

If the book is to be sewn and backed, the image should be truncated at the gutter edge on the R and L of the facing pages.

If the book is to be perfect bound, then the image should extend 3 mm into the bleed margin. The L 3mm of the right half of the image is added to the R of the left half of the image. The R 3mm of the left half of the image is added to the L of the R half of the image.

This ensures that when the section is trimmed or abraded on the spine edge and glued, the image continues across the gutter. The repetition of two 3 mm strips on the R and L sides of the image ensures continuity if the blade of the folder does not fall exactly on the nominal fold line, but slightly to its L or R.

It's easier to draw than to explain.

In any case, it is bad practice to second guess (actually, it's really first guess) the printery on imposition. The job scheduler will decide which press and which sheet size or roll width to use, and the imposition will be done to the PDF to suit the press/paper combination. Prince really does not need imposition. If someone wants to print an A5 booklet on an A4 folded sheet on the office printer, they should invest in one of the many PDF imposition applications that are available.