Overlays/Pre-printed forms in CMOD

[pankaj.puranik]

Hi

I have a report set up on CMOD which uses an overlay (you configure this in the afp2pdf.ini file).
Now suppose there is a re-branding activity (company logo change) and I am asked to put in a new overlay for future reports while the historical reports would still have the old logo.
Is it possible to tell CMOD to use the new logo for future reports and old logo for historical reports without having to create a new Application Group and a new Application and a new entry in the afp2pdf.ini file?

Thanks
Pankaj.

[Alessandro Perucchi]

Hi Pankaj,

I suppose you are archiving AFP in CMOD.
Does this AFP contain the resource of the LOGO?
Because if it does, then you'll have CMOD doing for you the versioning of ressources.

So it means the new document in AFP with the new resource will be archive, CMOD will see that he doesn't know this resource, and Pouff it extracts the new resource and link it to this AFP document.

Well you might need to increase the number of resources that CMOD keep for versioning (it is in the Application setting on the Load Parameter if I remember correctly in version 8.4.1)

That answers your question, or have I not understood your question?

Cheers,
Alessandro

[pankaj.puranik]

It is actually IBM LINE data that gets converted into AFP.
Here is how it works.
I have a single page PDF which has the logo properly placed.
This pdf is stored at a particular location on the cmod server.
The absolute path to this pdf is written in the options file (a2pxopts........).
The options file path is mentioned in the afp2pdf.ini file.

During retrieval time, this pdf is overlayed on the data (like you pot a postage stamp on an envelop ) and rendered to the end user.
So this means, if I change the pdf file to reflect the new logo, the historical reports would also show up the new logo.

So I want to know if there's a way that I can put in a new pdf overlay and only the new reports point to it.

[Alessandro Perucchi]

Hello Pankaj,

Well, from what I see, it's not CMOD which tells afp2pdf which ressource to take, but it is afp2pdf which is called with ODWEK, and then because he has the APPG, then it takes the correct ressource.
Meaning CMOD has no influence on afp2pdf. But ODWEK yes.

But it means also, that if you want to do something else, you need to program it with the ODWEK APIs and AFP2PDF APIs.

If it's not a path you want to take, then the approach would be... create a new application group to have a new logo.

Cheers,,
Alessandro

[Justin Derrick]

Really, nothing in CMOD should be 'rebranded' or altered.  That affects our collective ability to rely on the data in CMOD as a high-fidelity, tamper-proof archive.

That having been said, laws might be different around the world, but I'm fairly certain that tampering with data (even if it's just cosmetic) renders it inadmissible in court.

-JD.

[pankaj.puranik]

Hi JD

Does changing the PPF/logo accounts to tampering of data?
Since it is possible to change an already existing PPF, would that mean that CMOD is not a tamper-proof system?
Is it possible to stop someone (developers) to change the PPF? I mean, is it possible to make it content as well as cosmetic immutable?

Thanks
Pankaj.

[Justin Derrick]

If you store the AFP resources (PDEF, FDEF, OVLY, FONT) at load time, you're guaranteed to get the maximum document fidelity.

Is it possible to change AFP documents stored in OnDemand?  I'll just say that it's extremely difficult, and successfully changing a document would be easily detectable after the fact.

I'm not sure what you mean by PPF.

-JD.

[pankaj.puranik]

PPF => Pre-Printed Form or overlay