want to automate printing of variable record length booklets in one large pdf file
booklets already imposed
- print cover on glossy stock
- print enrollment form on perforated stock
- print ID card on DocuCard stock
- othe pages on plain paper
booklets vary in length 12 pages, 16 pages, 20 pages and 24 pages
- hundreds of all record lengths intermingled in one large pdf file ~ 10,000 pages
How to setup such job in FreeFlow Core??
Enabling this sort of workflow typically requires some customization atop of FFCore. The scope and type of customization will depend on the details (although the typical scope involves some scripting to update the print tickets based on the rules that apply in your specific scenario).
I would suggest contacting the Solutions Enablement Team to discuss options for enabling this sort of workflow. You can contact them via their portal: SET Professional Services
Thanks for prompt response
Before contacting SET Professional Services, want to understand
> Enabling this sort of workflow typically requires some customization atop of FFCore.
"atop of FFCore" means what?
May I know what type of customization?
> although the typical scope involves some scripting to update the print tickets based on the rules that apply in your specific scenario
Guessing updating print tickets with scripting has to do with tray pulls...
Depending on insurance subscriber's profile, a booklet may or may not contain ID card
and it may contain none, one or two blank forms...
So you can see each booklet layout is different, it varies from one booklet to next booklet in the same production run
So how SET is going figure out which page to print on what stock?
Can you elaborate please...
"atop of FFCore" -- I guess externally to FFCore would be more accurate. It would typically be a script that's invoked using the External component. You would pass the required metadata and the script would edit the internal ticket (passed via the $FFxpf$ variable) to add the tray pulls.
As to exactly how they would enable this... I could hazard a guess but ultimately the engagement would produce a statement of work that would lay out exactly how they would approach the implementation. If there are different profiles for each record and they require different tray calls they will need to get some indication of the user profile and then map that to rules for adding the tray pulls (which are fairly straight forward XML constructs).
It all really depends on what metadata you can provide (and the format of said metadata) about the PDF. Figuring that out is typically part of building the statement of work for the implementation. Also, anything that SET build will also be supported by them so they will only propose an implementation if they are comfortable supporting.