Embedding PDF file in Report

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Phil - 29 Sep 2007 04:09 GMT

Hello all,

I have an Access2003 report with an embedded PDF file, and I'm running
into the problem where only the first page of the PDF shows up in my
report.

My question is a two-parter:
1.) Has anybody discovered a solution for this problem (I've noticed
several references to it in old posts, but no solutions)?
and
2.) Does anybody know of a good work-around. Here's a little
background on my particular issue:

I've got a whole bunch of PDFs stored outside my DB. Depending on
user-input parameters, zero or more of them should be included in my
report. To simplify things, I embedded a dummy PDF ("GenericPDF.pdf")
in my report. Then, at run-time, just before opening the report, I
shell out to a separate program that grabs all the desired PDF files,
concatenates them into a single PDF, and names the resulting file
"GenericPDF.pdf". Everything works perfectly, except that I only get
the first page of GenericPDF, which is a real problem, because it is
often 15-20 pages long. I spent a long time playing with the
properties of my sub-report control and the sub-report itself,
thinking I just needed to turn on a 'Can Grow' somewhere, all to no
avail.

If anyone can help, I would be very grateful!

Thanks
Phil

Reply to this Message

AnandaSim - 29 Sep 2007 08:04 GMT

> Hello all,
>
> I have an Access2003 report with an embedded PDF file, and I'm running
> into the problem where only the first page of the PDF shows up in my
> report.

Truth be told, I've never heard of anyone using embedding in this way.
I guess you're using the Unbound Object Frame? We used to embed logos
and graphics (i.e. single screen stuff) this way, not multi-page
things like a pdf file.

> "GenericPDF.pdf". Everything works perfectly, except that I only get
> the first page of GenericPDF, which is a real problem, because it is
> often 15-20 pages long. I spent a long time playing with the
> properties of my sub-report control and the sub-report itself,
> thinking I just needed to turn on a 'Can Grow' somewhere, all to no
> avail.

Let's analyse this approach. Adobe pdf files need to be displayed
using an acrobat reader, typically adobe acrobat reader. Adobe Acrobat
Reader itself only displays the first page of a pdf file when you
first run it. You need to have a human bean to use mouse or keyboard
to click and display subsequent pages.

The Access Report is not an Access Form - it does not interact with
the user much - a human can click on the menu or toolbar but the
Report content itself is not made to interact with the user.

So, two things:
a. the reader wants a human to click on "next page"
b. the report does not expose the content to human interaction.

Ananda

Reply to this Message

Phil - 29 Sep 2007 09:37 GMT

> Let's analyse this approach. Adobe pdf files need to be displayed
> using an acrobat reader, typically adobe acrobat reader. Adobe Acrobat
> Reader itself only displays the first page of a pdf file when you
> first run it. You need to have a human bean to use mouse or keyboard
> to click and display subsequent pages.

This is not true... In fact, If you set the default zoom level in
Adobe Reader's preferences to something like, say 25%, then when you
open a multi-page pdf file, reader will automatically show you
multiple pages, without any interaction from the user.

I'm not trying to be argumentative... I'm just pointing out that a
there's no reason to automatically assume that displaying only the the
first page of a pdf is the default/no-user-input behavior.

If my use of unbound object frames to embed PDFs is unorthodox, then
are there other ways to do what I'm trying to do? Surely I'm not the
first person to want to include some multi-page PDFs inside an Access
report...

Any help appreciated,

Thanks
Phil

> The Access Report is not an Access Form - it does not interact with
> the user much - a human can click on the menu or toolbar but the
[quoted text clipped - 5 lines]
>
> Ananda

Reply to this Message

AnandaSim - 29 Sep 2007 14:24 GMT

> This is not true... In fact, If you set the default zoom level in
> Adobe Reader's preferences to something like, say 25%, then when you
> open a multi-page pdf file, reader will automatically show you
> multiple pages, without any interaction from the user.

Yes, you see as many of those pages to fit a screen full. You
certainly don't see all possible pages and you certainly can't read
the pages - the screen is a 75 or 96 dpi device, the printer is a 600
dpi / 1200 dpi device.

> I'm not trying to be argumentative... I'm just pointing out that a
> there's no reason to automatically assume that displaying only the the
> first page of a pdf is the default/no-user-input behavior.

No, I am not being argumentative either but a pdf viewer needs to have
user interaction if it is to cope with more than a couple of pages. On
most screens, even one full printer page cannot be clearly read on one
full screen.

> If my use of unbound object frames to embed PDFs is unorthodox, then
> are there other ways to do what I'm trying to do? Surely I'm not the
> first person to want to include some multi-page PDFs inside an Access
> report...

I can't answer the second question, but I assume the result you want
is paper or a pdf rather than an Access report - which is not actually
a consumable but just the print preview of a design / layout program.

If you are intent on producing pdfs are result, the orthodox way would
be to output the Access data via the report to a pdf file and then
append all the pdfs you have together into one. At least to me, that
is an orthodox approach.

HTH
Ananda

Reply to this Message

Albert D. Kallal - 30 Sep 2007 09:28 GMT

> This is not true... In fact, If you set the default zoom level in
> Adobe Reader's preferences to something like, say 25%, then when you
[quoted text clipped - 4 lines]
> there's no reason to automatically assume that displaying only the the
> first page of a pdf is the default/no-user-input behavior.

Sure, but your trying to print this too. And, we don't really have a
way to tell ms-access how deal with this pdf.

> If my use of unbound object frames to embed PDFs is unorthodox, then
> are there other ways to do what I'm trying to do?

Well, what you have is not working, and a quick Google don't give a bunch of
answers here. So, it not like there is a bunch of easy links here to solve
this problem.

> I'm not the
> first person to want to include some multi-page PDFs inside an Access
> report...

Well, wanting, and being practical are very much different issues. I can
find you a zillion people that want to fly to Hawaii for free right now, but
it not practical to expect that to happen. Don't confuse want with
practical..they are often a grand canyon apart.

so, sure, it would be nice to include word, or auto cad, or perhaps a copy a
pacman game in the report and have it printout all nice.

However, your asking those applications to run inside of ms-access and
render correctly *inside* of a ms-access report. I think it is a tall order.
I quite much the view with Anada on this one.

Throwing in applications inside of a report opens a lot of uncertainty here,
and now your on a wing and prayer that the application will play nice
*inside* of ms-access..

>are there other ways to do what I'm trying to do?

I see two approaches:

Grab one of the many pdf merge utilities that Google shows up on the web.

a) simply print the ms-access report to a pdf, and then use the above
mentioned approach (ie: simply merge that report (as a pdf) together with
all of the other pdf files using a pdf merge utility. You can then launch
the pdf viewer with this file.

b) don't use a pdf merge utility, but use a pdf printer system that allows
you to you send multiple print jobs to ONE pdf file. Thus, you simply send
your report, and also "print" those several pdfs you also need into that ONE
pdf output file. At that point, you either print the pdf, or again launch
the pdf viewer, or perhaps you attached this pdf as a email attachment.

A quick Google sure comes up with a lot of pdf merge utilities.

However, I like the prnt job idea. And, to do the suggestion "a)", then you
need a programatic pdf system that works with ms-ccess. So, you need to
speclty" the output pdf name in code. And, then you need to merge the
addintal pdf's. (so, a stand alone pdf merge utlity is NOT of use unless you
alerday have a system that creates pdf's *and* also lets you set the output
name in code).

However, a *really* increicle pdf maker is free:

http://www.pdfforge.org/products/pdfcreator

The above has a number of scripts that show how to combine multiple print
jobs...

The above also is a com object, and you can thus use automaton from inside
of access to set the output name for reports etc. And, further, it also has
ability to combine multiple print jobs into one pdf file.

I think this is a KILLER pdf system.

If you good with com automaton and windows scripts, then take a look at the
install directory of the above..it has some GREAT vbs scripts that show how
to combine multiple outputs into one pdf.

Signature

Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pleaseNOOSpamKallal@msn.com

Reply to this Message