on 2021 Apr 13 4:56 PM
We currently use CR in an automated manner to assemble documents. It is a process that has worked well using database and logic to determine which reports or subreports to add. We've now been requested to begin to provide for inclusion of random (attachments/addendums) that are pdf or possibly word files of one or more pages.
In some basic preliminary exploration we find that OLE files are affected by double margins and even a level of distortion which leaves the embedded/visible document skewed and with oversize margins. We've also seen that only a single page will show from the pdf.
Now, the version of Crystal being used is old and I could leverage a new version if that would make a difference.
Essentially, I am looking for recommendations on an approach.
I'm concerned that the only way to do it would be to render the report first as a pdf, then to add the old pdfs using another sort of pdf generation assembly. It could become messy if the original report then needed to be broken apart for these variable documents to be included.
Thanks,
- N
Request clarification before answering.
Nick,
You might want to think about putting some sort of identifier in the report that would be located where the non-standard parts would go if they could be loaded in Crystal. Then you might be able to use PDF API to search for those identifiers, split the PDF generated by Crystal there, put the appropriate non-standard part in and then pull all of the parts together in a single PDF. That way you're at least not having to split the report by page. However, I've not worked with the PDF API, so I don't know whether that's possible.
-Dell
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Unfortunately, the processing of OLE objects has not really changed with newer versions of Crystal, so all of the issues you mention still exist. I'm not sure there is any way around them.
-Dell
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Dell and Don,
Thanks for the input on this. I believe Don that you are correct. Prior to this question, the document was constructed sequentially, based upon a "map" of how the document parts should be assembled. That worked, but we later found that in some cases non-standard parts need to be included. These non-standard parts would include resources like I suggested earlier that were attachment/addendums - supporting material and that material would like be in pdf or potentially even word.
This project ultimately becomes one of how do we managing document parts used for assembly, identify where they belong in the assembly process, and then still provide for final assembly into a single document package.
I did think of breaking the document, which now outputs as one document, into pdf pieces to then reassemble including the non-standard parts. I don't know that these non-standard parts would go at the end, versus being inserted somewhere within the stack of document parts.
The other approach mentioned which was to break pdfs into multiple single page pdfs seems like a technology hack, one that I would do long enough to link to and generate the output before removing the single pages from storage. Not ideal at all, but something I've done when creating a preview solution of reports in the past.
What sits least well with me is any potential issues with paging that might occur when I break the document up to later stitch it back together as a pdf assembly solution.
If either of you have any additional insight or perspectives, I'd be very appreciative, because one way or another my job is to creating a solution that works for the business need.
- N
User | Count |
---|---|
58 | |
10 | |
8 | |
7 | |
6 | |
6 | |
5 | |
5 | |
4 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.