HTML Template with multiple pages only seems to print page 1

[aaronwardle]

Hi,

Great work on this, I have just downloaded the code and added in a test html file which spans across 10 pages however when I run it through the app only page 1 gets produced multiple times in the PDF.

I'm currently doing this

- (id<DLPRPage>)renderer:(DLPRRenderer *)renderer pageAtIndex:(NSUInteger)pageIndex {

    NSError *error = nil;
    NSString *filePath = [[NSBundle mainBundle] pathForResource:@"fire" ofType:@"html"];

    NSMutableString *source = [[NSString stringWithContentsOfFile:filePath encoding:NSUTF8StringEncoding error:&error] mutableCopy];

    CGSize paperSize = [DLPRSourcePage paperSizeForISO216A:4 forOrientation:DLPRPageOrientationPortrait];

    DLPRSourcePage *page = [[DLPRSourcePage alloc] initWithSource:source paperSize:paperSize];
    page.paperSize = paperSize;


    CGFloat insetInInches = 0.5;
    CGFloat insetPixels = insetInInches * [DLPRSourcePage resolution];
    page.margins = DLPRPageMarginsMakeUniform(insetPixels);
    return page;
}

Any help would be appreciated,

Thanks

[regexident]

Hi Aaron,

the current version (at the time of your writing) did not support "sub-pagination" of "pages".

I had simply omitted it as I so far only had hard-formatted pages without any overflow.
It was trivial to add though and as of commit da62b71 support for said feature has been added.

DLPRPage now has a property BOOL cropsOverflow for selectively disabling (when set to YES) said sub-pagination on a per-page basis.

While I was at it I also added some more refinements, making 3e1c1ec the most current commit. (1.1 in CocoaPods)

Could you verify that the new feature works as one would expect and—if so—close the issue?

[aaronwardle]

Wow thats awesome thanks for taking the time to make the code changes I will download it shortly and let you know how I get on :)

Thanks again

[aaronwardle]

Hi,

I just had to drop everything to try this out and it works perfectly and can not output my 20 page HTML to PDF all I need to do now is just work out how to manually add in page breaks in the HTML file so that some info does not span over two pages and breaks nicely and I should be all set.

I'm going to study the code some more and see if I can figure that out and let you know how I get on

Thanks again

Aaron

[falkobuttler]

The overflow feature is awesome, but in my case I have a header and footer that'd like to repeat on every page.

The header is static and the footer shows page numbers.

Do you think that is easy to add as well?

[regexident]

@falkobuttler I'd rather DLPDFRenderer be content agnostic than paint itself into a corner by providing support for rather isolated scenarios. It introduces unwanted complexity in both implementation and interface.

Thus the only thing I could think of right now would be an optional callback block that gets called for each page after it has been rendered. You could then add your own drawing code in there (for drawing a header, footer, you name it). To make place for the header/footer content you'd simply have to provide sufficient content margins.

Also, right now "pages" with more than a single (sub-)page do not increment the page index counter by its (sub-)page-count, but by 1, like every other page. I'll fix that as soon as I find the necessary time. (a header/footer drawing callback would make little sense otherwise)

[falkobuttler]

@regexident I understand your concerns. I believe it is a major use case to print with header and footer but I also think that the callback solution would be a perfectly feasible solution. The header and footer have static sizes and setting a content margin is perfectly fine.

[regexident]

You're absolutely right with headers/footers being a major use case.
My wording could have been clearer on this. What I meant is that providing an API for drawing a predefined (in regards to layout, fonts, etc.) header/footer with page number, etc would (for my taste) give the renderer too much information (and thus make too many assumptions) about the rendered content, painting itself into a corner pretty quickly.

In order to stay content-agnostic one would either have to provide a generic API for passing an optional (HTML) template for header/footer content, which I'd oppose rigorously.

A CGContext-based drawing callback block however should be generic enough not only provide an option for drawing a header/footer, but even stuff like watermarks, you name it.
And given their rather static nature (layout-wise) drawing a header/footer in native CGPoint-based code shouldn't be an issue either.
Further more it's much easier to add a callback block, than to add another templating chain to the process.

[regexident]

@falkobuttler, @aaronwardle commit 83eee79 adds support for custom drawing onto a rendered page (and fixes aforementioned indexing bug). (see section Custom Drawing in README for sample code)