Variable document length uProduce/uCreate for print

[jayri...@gmail.com]

Hi guys,

Does anyone work with an inserter where you need to know the variable document length per record for MRDF generation? 

I'm trying to figure out how to get this data out for that use case. Hoping that someone has come across this before and might pass on a bread crumb or two on the possible solution. Currently, short of exporting the artwork a second time with individual PDFs turned on and counting the pages of each file programatically, I can't think of a way of doing it.....

Thank you in advance.

J

[Tyrone O’Brien]

They way we did it was to create a lookup of the data so that every row is a page based on a customers ID that way you can add in your page counts and so much more. We did everything in the database layer and then used xmpie at the design layer

--
You received this message because you are subscribed to the Google Groups "XMPie Interest Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xmpie-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/xmpie-users/a3cd1101-7b03-4047-946b-0dc5c658a909n%40googlegroups.com.

[jayri...@gmail.com]

Thanks for that - not sure if I explained it sufficiently in my OP.

The issue I'm having is specifically when molds are utilised in a document. Aside from 'guestimating' how much textual information can fit within a frame (not at all accurate with non fixed width fonts) before a new mold is created, I haven't been able to figure out a solution. Sometimes 2 molds are generated up while other times, 3-4 molds are generated. Each mold adds an extra page - but there's no way of getting that out of XMPiE when it does a process or even proof.

Regards

J

[Tyrone O’Brien]

That was why we did it in the data. So we worked out how many lines of information would create a new mold page and used this information to setup.

So it’s a single indesign page that each row creates a mold page and that way you can know the page counts before hand eg if your data has 20 lines of information and each page will have 5 lines you would have 4 rows of data to create the 4 pages

To view this discussion on the web visit https://groups.google.com/d/msgid/xmpie-users/5fd1c827-1ed2-4a9f-8974-0a42b36b247an%40googlegroups.com.

[ROBERT HOPFNER]

it's been about 5 years now since I last saw XMPie, but I recall we had data matrix barcodes on every page so the machines knew where one book ended and another started. It was harder to fine tune the data and document in such a way that would invoke the correct spread transparency. 

To view this discussion on the web visit https://groups.google.com/d/msgid/xmpie-users/CAL0q0Pwb--4S2HHaE6u3aGB9kLujPgmLa9n8JhweT2YiSqwBYg%40mail.gmail.com.

[couch]

Processing of the plan logic happens before page composition, so if the logic or design changes the number of pages in the document (for example by page/spread visibility, or with autoflow creating/removing pages, or use of the "filler pages" feature to add/remove pages to create signature booklets) then the plan does not have the ability to know about that.

There are two solutions/workarounds to work with your inserter:

1) Process the document to PDF/VT using the settings to enable any necessary ADORs to be stored as metadata (eg if you need address or other details in the MRDF file). Output the file to a folder that is watched and processes a custom script that extracts the metadata, page count / recipient ETC and creates the required MRDF.  If you need such a script created, contact XMPie Professional Services or a 3rd party developer.

2) Every inserter that I know that will take an MRDF file will also take OMR, Linear Barcode, and 2D barcode on the printed item. By changing your inserter workflow from MRDF to 2D barcode, you can use the new Page Numbering Feature. Version 11.2 PersonalEffect provides more state variables that make it easier to configure the barcode for inserters. https://campus.xmpie.com/eLearning/uCreate-Print-Training/Page-Numbering-Barcode

[jayri...@gmail.com]

Thanks for the replies guys!

@couch We can achieve this easily by using the inserter in 'dumb mode' which just reads off the barcode produced (which is what we're currently doing anyway). The powers that be have issued a directive that they would like to transition to MRDF based processing in order to have an audit trail. I'm supposed to be having a conversation with Enda (he was the one asking my CTO about MRDF files) but he hasn't gotten back to me yet. I'll investigate the meta data side - might be the way as we can write a quick prog to extract that and output to a simple CSV.

Regards

J

[jayri...@gmail.com]

Further to my reply above - I just realised that I'd have to output the file as individual files to be able to use the metadata like that... Wouldn't be very feasible as these mailing jobs can number in their 10s of thousands.

[couch]

Not sure why you can only use individual files? (You're right it would not be desirable.)

[jayri...@gmail.com]

Isn't a PDF's meta data for the entire file? I can't output a full 5000 paged file containing 1000 records while each record has varying number of pages and be able to retrieve the page lengths of individual records within the file - either that or I'm not looking in the right place? :)

[Wayne]

A long time ago I wrote an application using VIPP to create an MRDF workflow.

How reprints are handled should also be considered when developing a solution - ideally this should be automated 

Using VIPP was relatively straight forward however you could use plain Postscript if you wanted.

Many composition applications will use Pre or Post Processing in their workflows - some creating intermediate file formats.

Pre or Post Processing both have pros and cons really depends on the Data - post process is probably more flexible IMHO 

XMPie's media feature is a great to drive the behaviour.

If you have Postscript knowledge its worth considering a Postscript to PDF workflow.

Regards,

Wayne

[Amit Cohen]

insider: XMPie is working on a feature that will have this information as part of the processing of the output for one of the next version.

yet, you probably do not want to wait, in the past, I wrote a tool that gets a pdfvt file and records into CSV a record number and the number of pages per record. simply produce a pdfvt file and drag-drop the pdfvt file onto the executable available in the download link. hope that helps for now.

Click To Download Utility

[Frank Hubert]

Greetings all,

I would agree that producing a PDF-VT file is the best way to do this currently.

PDF-VT allows you to build a single large PDF of the whole batch but keeps the logical structure of the mailpieces intact (as DPART objects in the file).
Moreover, if you check the "Add metadata to each record" option, the ADOR information is added to the DPART as well.

In a nutshell, this gives you all the information to build a MRDF file that (I believe based on a quick browse of the spec) requires you not only to provide the number of sheets in every mailpiece but ideally also address information for sender & recipient (that would typically live in ADORs).
A couple of years ago, I used this logic to build a little Java application that creates Neopost JCF files (roughly equivalent to PB MRDF). If you are interested, drop me a line & I will send you what I have got.

Best regards,

Frank  

[jayri...@gmail.com]

Many, MAAAANY thanks to everyone who provided all the necessary breadcrumbs for me to get arrive at a solution.

For the record, the PDF/VT meta data checkbox was the game changer. From there, it was a matter of getting a utility that could read all the DPart metadata and export it out. I originally didn't realise that PDF/VT had extended metadata as I only had the standard Acrobat Pro which doesn't show at all!

Special thanks to cohn for offering his utility but I wasn't able to use it due to company security policies in place. Greatly appreciate the gesture though :D

[jayri...@gmail.com]

Oh and Frank too as well for the offer of HIS utility :) I missed that line when I originally replied!

J