How, within privileges, do you prevent export of a pdf or printing to pdf? I'd like the pdf to remain interactive.
Printing may no be able to control by FM, you need PDF itself as unprintable.
For exporting I can't find workaround now.
on the printing: When the PDF is created, you can set options, such as password required to print:
Do this before the PDF is inserted into the container field.
If the PDF is created elsewhere, it should have this security already set up or changed. But must be re-uploaded if changed.
Here is the help topic on the privileges (such as print and export):
So I can use inherent pdf security to stop printing on applications that respect this. But are you saying that I can't prevent viewing and therefore effectively export of the pdf outside FM? I should mention it will be a Runtime solution with Admin rights removed.
I would try to view it via a web viewer, without showing the container it resides in.
If the FM file is local, the PDF file viewing in interactive container or web viewer is already saved in disk (temporary path), so I think you can't prevent user get it as file.
Did you disable Export? And if so, did it disable the ability to use the "interactive container" from paging through a multi-page document?
Try a few settings on a small sample database and let us know the results.
Thanks for the suggestions:
1. I've secured the pdf aside from permitting opening without a pw.
2. FM printing/exporting is off.
However, I can still open the pdf in both Acrobat and Preview.
I found a comment by Philmodjunk: pdf security
Unfortunately l'd not adequately tested it at the time and he's since not been on the site. However, he seems to suggest you can secure the pdf within an interactive container field.
yes, this is what I asked. did you set up a login the prohibits Export and test with the PDF? Phil says a different layout.
Yes I have layout with a large container field to view the pdf within FM and have prohibited Export, but it still opens outside FM.....can we 'park' this line a moment......
Idea: If I 'pw-protect' the pdf and put an instruction on the 'reader layout' for the user to place the cursor in the pw dialogue I had thought:
1. The script that opens the reader layout copies the hidden pw and selects a button the the layout.
2. User places the cursor in the pdf pw-dialogue, causing an 'onexit' trigger on the button to fire and paste the pw in the dialogue.
a. I'd need to include 'allow user abort = off' and later copy a 'blank' to prevent users pasting the real pw somewhere they can read.
i) Script paste didn't work so is there another way of 'keying' in text once the cursor is in the correct dialogue?
ii) Pasting when in the dialogue replaces the pdf with the pw because the pdf is selected as an object.
iii) I need the script to simulate 'Enter'; can it do this?
None of the above stop users getting the pdf out of FM, but it would be locked and that would be preferable........I just haven't figured out whether FM has a mechanism to cope yet.
There are ways to simulate keystrokes using vbs or applescript or something. Search "SendKeys" on vbs.
Both interactive container and web viewer are depend on installation of pdf-addin on browser, so it is not controllable in some case when you distribute runtime.
It will be same on viewing PDF outside of FM, if you can't make users to install certain PDF viewing programs.
Once passwords are auto- entered, user can print it to PDF selecting their printer as some pdf writer, then get it as unlocked PDF file. Is this allowed?
(I tried it using 2, one can't save, one save its texts as picture. This may be result of allowing "print" only)
1. Sendkeys: I'll look into this.
2. "Both interactive container and web viewer are depend on installation of pdf-addin on browser, so it is not controllable in some case when you distribute runtime."
>> Are you saying that because with an RT you can't pre-determine the application that displays the pdf, you may not be able to prevent the pdf being displayed outside FM?
a) I'm sure there will be ways to 'break in' but if you pw-protect opening a pdf and not allow any changes/printing, it appears you block users from printing to pdf etc. Yes, they can Save As, but they still need the pw and you don't appear to be able to copy pw from the pw-dialogue.
b) I tried the script combination below, but it failed to get the cursor into the pw dialogue. I still need to substitute in the 'Sendkeys' part but how do I script into the pw dialogue:
i] Script to get pw:
Copy [ About::pw ] [ Select ]
Go to Object [ Object Name: "About_title" ]
ii] Script triggered by 'on object exit' [ie. when the user clicks into the pw dialogue]
Paste [Select ]
Commit Records/Requests [ No dialog ]
3. Very sorry, I was confused after testing many settings of PDF security that you want to print. You want only interaction, not print nor save.
pw dialogue for PDF security is shown by PDF-plugin, it is another process than FM so "on object exit" trigger not fire.
Kiosk mode appears to prevent export of pdf (or QuickTime) files from containers fields. Also Kiosk, unlike RunTime alone, appears to allow Encryption at Rest. Assuming this is correct using Kiosk appears a far more secure means of distributing RTs.......though please correct me if this is wrong!!
I have run into similar problem. The client wants records to allow only reading of PDF document by one user type, and replace/update by other users. I have created two controls on top of each other. One control has data entry disabled (read-only mode). I hide and show either of the two controls depending upon user permissions. Would this work for you?
I'm not sure what you mean by 2 'controls'?
You can keep PDF in one container and only show another container to user with a preview picture of the page.
e.g. With MBS Plugin you can make high resolution pictures for each page on demand.
Monkeybread Software - MBS FileMaker Plugin: DynaPDF.RenderPage
when you have a PDF in an interactive container people can simply copy file from temporary folder.
I have created two container controls on the layout. both have exactly same size and behavior, except editability - one is for editing and other is for viewing. The buttons on top set user field value to editor or viewer. Follow the settings in the Inspector window. See attached example.
The 2 views would work if I only wanted the user to view say p1. But I actually want them to be able to have the interactive functions or an equivalent. So unfortunately, I don't this or the MonkeyBread plug-in would help my particular needs.
What I've done so far is use a Runtime in Kiosk mode, just to make life a bit harder for people wanting to copy. I had explored using a password-protected pdf, but for this to work the user would have to install 3rd party software for FM to automatically enter the pw.
It's a bit catch 22. Either the pdf if pretty useless, or easily copied. I haven't found a practical way around this.
Retrieving data ...