Pagination

[pankaj.puranik]

Hi

We have a big AFP file that is loaded into CMOD.
Each account has 2000 plus pages.

During retrieval this AFP is tranformed into a PDF using the afp2pdf transform.
Understandably, it takes long (40 seconds) to render this PDF due to it's size.

I wanted to know if there is a way to solve this problem.
Can CMOD stream only first few pages of the PDF as and when the user scrolls further?

Thanks
Pankaj.

[Alessandro Perucchi]

Hello Pankaj,

stupid question :-) but why do you need to transform such big lists in PDF? Would it be no better to have them looked in AFP?
Otherwise, it would be to store the documents directly in PDF... it would be better for the retrieve time.

Using ODWEK to do that, I suppose you need to know the AFP format in order to know where begin a new page and finish a page.
Then you could simply cut the pages, and deliver part after part of PDFs... or something like that.
That's only an idea.

Sincerely yours,
Alessandro

[pankaj.puranik]

Alessandro

The end users will possibly not have AFP viewers and the current code doesnot use the applets.
So these are converted to PDF using AFP2PDF transform.

Going by your idea, do you know how can I convert the AFP into PDF before starting the ingestion process?
Can I somehow use the afp2pdf transform on my AIX server before I start ingesting the file using PDF indexer or generic indexer?

[kbsiva]

Hello Pankaj,
 If you have infoprint manager you can convert AFP to PDF and vice versa on your aix server.

Thanks,
Siva

[Justin Derrick]

Standard procedure when retrievals are going to take a long time (conversion or retrieval delays) is to tell the user to check back later for their converted / retrieved file.

The alternative is to convert everything, and cache it.  That may take a considerable amount of time and disk space, and might even represent a security problem.

The only sneaky/creative method I can think of is...  If the user only searches for a small subset of documents (ie, one login == one customer number) you could retrieve and convert the last X months of data in advance, and cache it for 24h or so.

Let us know how you solve this one...

-JD.

[pankaj.puranik]

These are actually daily trade confirmations. We have some accounts whose trades for a given day exceed 2000 pages.

So I think we will have to convert the big files into PDF and load them.
I need to figure out how this could be done. But it seems like this is the only solution.

However, when you say "you could retrieve and convert the last X months of data in advance, and cache it for 24h or so"; I am not sure how to do this.
Any pointers?

[ewirtz]

Hi Pankaj,
just an idea. If you have something like 'page nnnn' on every page, you could configure another break for instance 'page nn'. By this you will get an additional break every 100 pages. Maybe this helps.

regards Egon

[pankaj.puranik]

Thanks Egon.
These are AFPs with TLEs, soI really don't have that option.

[ewirtz]

Hi Pankaj,

another option is to use an index exit. You define an additional field p.e. portion and you fill it with a default. The index exit is used to change the default to generate document breaks.

regards

Egon

[jeffs42885]

Not sure if this would apply in this situation, but what about enabling fast web search in your afp2pdf settings. (a2pxopts.cfg)