Imposer pulls size from first page of template

I have a FP template which contains multiple page sizes. It will be merged with data in such a way that the records in one data file always use the same template page (size). I have created separate Imposer layouts for each of the page sizes and choose the appropriate one for the given page size in the Composition tab.

When I begin composing any page size other than the size of the first page in the template, I get an error in my log file that the page size does not match the layout. Based on some quick tests, it appears that Imposer pulls the page size from the first page of the template rather than the page that is actually being imposed.

I consider this a bug.

Since I am trying to implement something on FP Server, I am going to try to "fool" FP by creating unique .dif files for each unique page size assigned from the command line in which I edit the first page's dimensions to match the actual dimensions for each page size. However, it seems like FP should already handle this scenario by pulling the dimensions from the actual page being imposed rather than page 1...

When I begin composing any page size other than the size of the first page in the template, I get an error in my log file that the page size does not match the layout. Based on some quick tests, it appears that Imposer pulls the page size from the first page of the template rather than the page that is actually being imposed.

No, it gets the page size from the imposition template (FPI file). The page size, actually all the page sizes, in your PDF template (layout) have to match that page size defined in the FPI file, or you get an error.

I consider this a bug.

I understand, and I know this is an unsatisfying answer, but: That's just the way it works. The imposition template is very closely tied to the page size, and making it so that you could somehow vary the imposition sheet size on the fly to match a varying page size would be extremely complicated, and would make everyone's heads hurt even more. At least it would make my head hurt a lot more. I can't even imagine what the GUI in FP Imposer to define such a "resizable" imposition template would look like.

Since I am trying to implement something on FP Server, I am going to try to "fool" FP by creating unique .dif files for each unique page size assigned from the command line in which I edit the first page's dimensions to match the actual dimensions for each page size. However, it seems like FP should already handle this scenario by pulling the dimensions from the actual page being imposed rather than page 1...

Like I said, it doesn't pull it from page 1, it pulls it from the FPI file, and the actual page size has to match that.

When using imposition, FusionPro assumes that all pages in the document are the same size as defined in the imposition template. The format-switching functionality in FP Server (with <record format=***> tags) predates imposition, so if you want to compose differently-sized pages with different imposition templates, you need to do separate composition runs. It sounds like you're already modifying the page sizes with the DIF API, so doing separate composition passes for those varying page sizes instead of doing one big composition with varying page sizes and format files shouldn't be much more complicated.

Like I said, it doesn't pull it from page 1, it pulls it from the FPI file, and the actual page size has to match that.

I respectfully disagree (or perhaps I am not stating the "problem" correctly).

If I have a template with 2 pages (page 1 = 5"x7" and page 2 = 7"x10") and also have an Imposer layout for a 7"x10" imposition (2-up on a 12x18 sheet), and attempt to use said imposition when composing a data file containing only records which use page 2, the composition log will state that the page size does not match the size of the page in the layout. This is because FP appears to match the page size defined in the layout with the FIRST page of the template EVEN IF PAGE 1 IS NEVER USED IN THE OUTPUT. If I then delete page 1 from the template (or swap pages 1 and 2), and recompose, I get output with no errors.

I respectfully disagree (or perhaps I am not stating the "problem" correctly).

 

If I have a template with 2 pages (page 1 = 5"x7" and page 2 = 7"x10") and also have an Imposer layout for a 7"x10" imposition (2-up on a 12x18 sheet), and attempt to use said imposition when composing a data file containing only records which use page 2, the composition log will state that the page size does not match the size of the page in the layout. This is because FP appears to match the page size defined in the layout with the FIRST page of the template EVEN IF PAGE 1 IS NEVER USED IN THE OUTPUT. If I then delete page 1 from the template (or swap pages 1 and 2), and recompose, I get output with no errors.

I see. Technically, what I said was correct, that FusionPro uses the page size defined in the FPI template. However, the issue you're seeing is that it validates that size against the first page in the PDF template, even if that page isn't being used.

The problem is that it doesn't know for sure what pages are going to be used in every single record after the first, because the page usage can vary by record. The page usage feature wasn't really designed with the scenario of differently-sized pages in mind. Imposition still assumes that all pages in the template are the same size, even if you're swapping some in and out.

I understand that you consider this a bug, but I don't know how it can be fixed. Again, the page usage can vary by record, so when using Imposition, FusionPro has to assume that all the pages potentially being swapped in or out for different records, which is really all the pages in the PDF template, are the same size. Removing this restriction could lead to all sorts of confusing failure scenarios with page usage. I'm not saying it's impossible, but the intersection of these features is complex, and that not only makes the development work required to sync them up complex, but it also makes the potential error messages that would be reported back to the user even more complicated and confusing than some of the error messages now. How would FusionPro be able to succinctly report back to the user that the page sizes are all matched up, except in one record, and that the user still needs to make sure to modify the OnRecordStart logic to ensure that only like-sized pages are used in any given composition run? It's a lot simpler to just say that all pages have to the be same size (and match the imposition template).

What I said is still true: you'll need to use the DIF API to either add or remove pages from the layout, or modify the page sizes in the layout, and then do a series of separate composition runs, with the page size in the layout matching the FPI template in each run.

The imposition template is very closely tied to the page size, and making it so that you could somehow vary the imposition sheet size on the fly to match a varying page size would be extremely complicated, and would make everyone's heads hurt even more. At least it would make my head hurt a lot more. I can't even imagine what the GUI in FP Imposer to define such a "resizable" imposition template would look like.

I agree that this would be next to impossible to allow for in FP and FPImposer.

I don't know how it can be fixed.

My (only slightly selfish) recommendation would be to use the first page called in the data rather than default to the first page of the template.

In the current scenario, when any page is composed that does not match the size of the first page, an error is generated. This means that currently there can only be one size page per composition and it must match page 1.

If you were to alter that logic to use the size of the first page composed in the first record, a situation like mine would function correctly as would any situation currently encountered. The only thing that wouldn't work is a composition using multiple page sizes -- a scenario that doesn't work now either. You get a little added functionality without losing any of the existing functionality.