Hello,

I have just started getting my head around PP Capture, I hope everyone kindly bears with me

We have a requirement where the client needs to print a stack of capture ready documents for each of their customers.

The documents are basically authorization slips. In a typical use case, the client carries out certain orders based on their customer's authorization. e.g. a signed document is sent by the client's customer to them, authorizing an action.

We would like to implement the above using PP Capture, where the client prints a number of copies of the authorization slips (capture ready) and sends the printed copies to the customer. Each of their customers will be provided with an Anoto pen. Each time the customer needs to send an authorization, they will fill in one of the capture ready slips that were sent to them by the Client, sign and dock the pen. The PGC will then be transferred to the Clients PP Production server where the rest of the processing will continue (email, archive, etc).

The above will be done for each of the client's customers.

My question is, how do I go about generating multiple copies of a capture ready document for the same client but with different Anoto pattern on each copy.

e.g. The same client number occurs on the authorization slip on each of the copies, but the patterns are different.

The input datafile is an xml file with each record corresponding to the details of each customer of the client. For each record say 100 authorization slips need to be printed and sent to the customer that corresponds to that record.

Does it even require unique Anoto pattern on each copy for the same customer slip?

I am sure that there would be some simple solution to this, but I am lost as I am not proficient with PP Capture yet

Any pointers will be very helpful.

Thanks

Cube,

It is really an interesting case you have here.

The actors are:

CLIENT: The organization owning a PlanePress Production & Capture License.

CUSTOMERS: Individuals owning an Anoto Digital Pen. A CUSTOMER is a client of CLIENT.

The Processes are:

1. A CLIENT process generating 'stacks' of capture-ready documents, say 100 per CUSTOMER, each using a different Anoto Pattern. Each new document that is printed implies that 1) the Anoto Pattern used in it is locked in the PlanetPress Capture Database, and 2) a copy of this document exists in the PlanetPress Capture DB.

2. A CLIENT process for processing Pen data as it arrives from any CUSTOMER docking his pen. This assumes that all CUSTOMERS have locally installed the Anoto PenDispatcher application, and configured it to send the PGC (Pen Generated Coordinates) to the URL monitored by a CLIENT workflow process. Note that there might be more than 1 process involved.


------

Now, let's consider the pitfalls you don't want to fall into.

Pitfall #1: Runnning out of Anoto Patterns.

If you print 100 capture ready-documents per CUSTOMER, you logically want 100 different patterns. Given that there can be 9990 patterns 'alive' at the same time, this means the CLIENT won't be able to print patterns for more than 99 CUSTOMERS. Moreover, if each CUSTOMER takes up to, say 3 months to use the provided documents, then the CLIENT will likely run out of Patterns pretty fast. Now there is a solution for this. The solution involves the use of a pattern sequence. Using pattern sequences, the CLIENT would be able to print and use up to 9990 different patterns PER CUSTOMER. However, this solution involves a gread deal of analysis because it is based on the fact that the PlanetPress Capture Database can contain 2 different documents using the same Anoto pattern, but a different pattern sequence. If each individual pen is registered with its own pattern sequence, then when a pen is docked, PlanetPress Capture is able to retrieve the appropriate document by matching 1) the Anoto Pattern on which the pen wrote and 2) the pattern sequence associated with the document in the Capture DB and the one associated with the pen. Again, this approach must be followed with caution.

Pitfall #2: Runnning out of pen slots.

When you buy a PlanetPress Capture license, you buy it for a certain number of pens, which have to be registered before they can convey PGC and trigger processes. If the CLIENT has a growing number of CUSTOMERS, thus a growing number of pens, then the CLIENT will have to consider buying a license for more pens.



Overall what I think is that there is a potential case for using Pattern sequences because otherwise you will run out of patterns rather quickly. However the use of pattern sequences, as I tried to explain, involves a bit of risk which requires all possible use cases to be extrapolated as well as their consequences.

While the documentation contains information on pattern sequences, it does not explain how to use them. If you are an OL Learn student, I invite you to request a webinar on this topic to learn more.

Hope this helps!

Ben

edit: corrected ol learn link

You could use a loop plug-in.

That being said, maybe you could consider an alternative way of generating your capture ready documents. Sure, printing 100 copies for each customer is nice, but instead, could the CLIENT manage to generate a Capture-Ready document on-demand, in a just-in-time fashion?

For example, each time a CUSTOMER needs to fill a Capture-Ready form, he could first send an email to the workflow tool and receive a response with a new Capture-ready document attached, ready to print. Or else, the CUSTOMER could fill an HTML form and submit it to a Workflow tool process which could generate and send a capture-ready document by email, or even in the user browser.

In other words, have you considered the option to generate Capture-ready document on-demand, in a situation similar to the online PlanetPress Capture demo?

NB. This would imply that the CUSTOMER prints the capture-ready documents instead of the CLIENT.

Hi Benoit,

Thanks very much for such detailed reponse. Now that I know about the pitfalls, it will help me have a more robust requirement analysis for the client.

I guess the client would like to have full control over printing and distributing the capture ready documents, but this needs to be confirmed. However, I agree that an on demand generation of a capture ready doc should be the way to go, as it will not keep most of the patterns tied up.

About the loop plugin-in, each time it loops a new Anoto pattern will be generated automatically or do I need to do something else to ensure a new pattern is assigned at each loop.

For e.g. in my input data stream I have say 3 customer's details. For each customer I have their name and the number of capture ready documents to be printed for each.

name: Cust1
num_docs: 100

name: Cust2
num_docs: 200

name: Cust3
num_docs: 50

The workflow for generating the capture ready docs is simply as follows.

1 - Folder Capture
2 - Create Metadata (with my capture ready doc selected)
3 - Capture fields generator (with my capture ready doc selected)
4 - Printer queue output.

I can select the field "num_docs" from the data stream and give it to the loop plugin to control the number of loops. But where should the loop plugin be placed?, After 2 - create metadata?

cube,

In theory, you could place the loop plug-in right after the Create Metadata plug-in so that metadata is generated only once. But in practice I would recommend placing the loop plug-in before Create Metadata so that metadata is created for each new document.

Anyways, in terms of processing time the process bottleneck is the Capture Fields Generator (more than the create metadata plug-in), as it is responsible for 1) locking Anoto Patterns, 2) generating a PDF and 3) adding the PDF to the Capture Database.

NB. The Capture Fields Generator also contains a 'Document Title' field which you could use to identify each generated document, for example by adding the iteration number as part of the title.

Hope this helps!

Ben