Printing to pdf - and then printing the pdfs?

[Paul_G]

Hi folks. Is it possible to make a bunch of reports print as pdf, add those pdfs into a container field (each on a separate record), and then sort and print those pdfs?

I think I can see how to get to having multiple records, each holding the final pdf, but I can't see how to then script to sort those records and print the pdfs. It seems like once it's a pdf, I have to export the pdf to my computer and then print them from my computer, which is a bit of a drag...

One idea I had was to have the script go through each record in the found set, export the pdf to a folder on the computer, then have it run an applescript that prints the pdf and then trashes it. But it seems so clumsy, and I'd have to learn applescript as well! It seems like the sort of thing Filemaker ought to be able to do, but I just can't see how...

Can you help?

Edited December 3, 2008 by Guest

[Paul_G]

So, after over 80 views but no responses, I guess it's fair to say that this is something Filemaker just can't do.

What a shame. :)

[Genx]

If you're going to trash the PDF's anyway why make them at all? Just go through each report and print it - you'll get the same output anyway.

[Paul_G]

Sorry, I was a bit unclear. It's crucial that the embedded pdf be retained - I'd never trash it, it's the permanent record of the letter as it was sent.

But it seems that FM won't let you print the embedded pdf. I'd need to export it - that is, create a new copy of it in a To Print folder on my computer, then print that copy. There's no point retaining a second copy as well as the embedded one, so I'd want to trash the copy after printing.

Really, this is only practical if FM will let me print from the embedded copy.

(BTW, I from my reading I think I need to embed the pdf as a Quicktime, to be able to see a preview of it within FM - if I embed it as a file, I only get an icon, and have to open it to see the contents).

[Søren Dyhr]

Still not entirely clear, we are not really speaking filemaker reporting here, but rather arbitrary .pdf'es accidentally stored in a filemaker container field?

Perhaps you should think of why 3rd party developers have found a need to make this meet the marked??

http://www.360works.com/supercontainer/

--sd

[Søren Dyhr]

you cannot get away from learning something about this

What a pity, tearing a database tool out of it's realm is too obvious a desire ...for mankind

--sd

[Paul_G]

What a pity, tearing a database tool out of it's realm is too obvious a desire ...for mankind

--sd

Sorry, what? Where did that quote come from? I'm afraid I don't know what you're trying to say.

[Paul_G]

Still not entirely clear, we are not really speaking filemaker reporting here, but rather arbitrary .pdf'es accidentally stored in a filemaker container field?

Perhaps you should think of why 3rd party developers have found a need to make this meet the marked??

http://www.360works.com/supercontainer/

--sd

No, not accidental at all, nor arbitrary. The pdf is to be permanently stored in a container field as a record of the correspondence, along with associated fields to indicate who the letter was to, when it was sent, etc. The idea is to be able to link those records with the contact, so I can look back through a portal to see a record of all correspondence with that contact, and view the individual letters by going to the layout with the container field (that's why I'd want to embed it as a quicktime - so I could see the preview in the field, allowing me to read it without having to open the pdf).

The other aspect was being able to print the pdf AFTER it's been created - I was hoping I would be able to do large batch prints of the pdfs with the records sorted by the addressee, so all the reports going to Dr A come out first, then those for Dr B, etc - which would make envelope stuffing a bit easier. Still, it's not a big issue - I'll just print the letters and then turn them into pdfs for storage. They'll come out in a less convenient order, (all the copies of letter 1, all the copies of letter 2, etc) but I can live with that.

As for the reference to 3rd Party developers - thanks for the reference to Supercontainer. Looks good, I may well try it. But turning the question around - if 3rd party developers have found enough demand for a function that they create and market a program to add that functionality, perhaps that's a sign that there's a functionality that people want from FMP which it's just not delivering.

It's kind of frustrating having a function that looks like the kind of thing a program this powerful SHOULD be able to do, and not being able to see a way to do it. I mean, really - FMP lets you store a pdf, but won't let you print it - that's just weird. If you're an expert, you can see straight away it can't be done and that you have to look to a 3rd party product. But for non-experts, it's just another thing that we can't figure out how to do - one amongst many - and it's easy to spend ages searching for something that doesn't exist.

So for anyone who is looking at the same issue and finds this thread, I think the overall answer is "Yes, you're right, FMP does not allow you to print a pdf. You'll have to look at a third party product or export the pdf to other programs on your computer to handle".

Thanks folks!

[Genx]

I was hoping I would be able to do large batch prints of the pdfs

A bit of a weird thing to hope for from a database product don't you think?

I imagine you can fairly easily write some apple script to deal with this for you. Getting the reports created as PDF's and re-imported back into a container field isn't that much effort using native FM functions either, but the question is still really why bother? If you need a permanent record of all letters sent in FileMaker - set up a table to store the text. If you at any point you specifically need to generate a PDF of the original text of letter x sent on date Y do so from your saved record... Why bear the extra overhead of PDF header's and filetypes - you're going from 1-2kb (DB Storage) per letter to 20-100 with PDF's (depending on font's and other things).

[Paul_G]

but the question is still really why bother?

Fair point. The reason is medicolegal - I really need a copy of the letter, as sent, not modified later. I could keep a paper copy, but I'd rather keep an electronic one. If I keep the data, that data could be accidentally (or deliberately) changed later, so it doesn't carry much weight. True, a pdf can be changed, but it's more tricky, and certainly wouldn't happen accidentally.

[Genx]

Deny access to the relevant tables... no one says you need to give your users access to the archived letters - make a separate table and deny access entirely to that part of the DB and then when you need to print the letter take them to a layout where the only content of said layout is a merge field...

A properly secured database won't allow it's data to be either accidentally or deliberately changed.

[Genx]

Here's a sample. Login as user / user first. Try and edit a letter that's been saved to the sent_letters table.

Afterwards, feel free to login as admin / admin .

After that, let me know why you would use PDF's for this.

secure_example.zip