Not behaviour that I have seen in all the 14 work I have done so far.
There is obviously something else going on here, bit hard to guess without more details
Is it feasible to uninstall Adobe Acrobat from the system? I found it has given me grief in other situations. On the Mac, Preview is much more 'light weight' and generally less annoying.
BUT preview on the Mac is just that. A preview
It is not, I repeat NOT, a standards compliant PDF browser, and I might argue it not a particularly good preview either.
Try filling in a PDF form, looking at an embedded 3-D model, extract files from a PDF suitcase, inspect a digitally signed file...
There are a million reasons not to do this if you have other grown-up work flows in the business.
I might argue it's less susceptible to Adobe 0-days and plays better with Safari. I find this flip general knock of Preview as unsuitable for "grown-up work flows" to be unwarranted and unpersuasive, because it works perfectly well in some professional settings. That's my personal experience and opinion.
Yesterday - at a client - I saw something odd going on with FileMaker 14 and interactive containers with PDFs that sounds a bit like what you saw.
In 13, the pdfs displayed fine. In 14, FileMaker would trigger the file to open in the default pdf viewer application. This was on Windows 8.1.
I tried this on a different computer in our office with Windows 7 Pro and the behaviour was the same in 13 and 14.
we are trying to get to the bottom of this, as the client wants to roll out 14.
If I find out any more, I will post.
1 of 1 people found this helpful
Another workaround for PDFs that won't display properly within FileMaker is to write a script that exports the file to FileMaker's Temp Directory and auto-opens the file in the default PDF viewer (Acrobat, Preview, etc). Something like this:
Set Variable [$Path; Value:Get(TemporaryPath)]
Set Variable [$FileName; Value:Data_Table:PDF_Container_Field]
Export Field Contents [Data_Table:PDF_Container_Field; "$Path/$FileName"; Automatically open]
Exporting the PDF should not leave the field blank as it is merely exporting a COPY of the PDF. The original will still be in the field.
Create a button and link it to the script. Put a PDF icon on it and a tooltip "View in PDF Reader" to help users understand what is going on.
I raised this issue a week or so ago and had no answers from the group, but at least there is confirmation that others are seeing the some problem. FM14 clearly acts differently to FM13, which is exceptionally annoying particularly as I can find no references to any change in behaviour.
I would agree with your first statement to some degree, but let me clarify the second in case you think this is just being flip
It is known that the issue (if you experience one) is to do with the browser plugin not with Adobe Reader ( or Acrobat Pro) in general, so the 'just remove Acrobat' suggestion is not an answer with enough finesse as it has other implication to the rest of workflows.
PDF is an ISO standard ISO 32000-1:2008
This document specifies the full legal grammar for create a PDF file
If I create a document to this standard that is then only partially supported by a PDF read or preview programme then THAT software, not the document is not standards compliant. The clue on OS X is in the name. Preview. But Apple do not provide a fully featured PDF reader at the same time ( and to be fair we have lots of other choices as to how to do that) so the all the use cases I outlined above are fully ISO standard compliant but broken in Preview.
In all the place where I am supporting PDF workflows with FIleMaker 14 I have not seen the behaviour from the OP, so it requires some careful investigation to get to root cause rather than blunt instruments which may mask the issue but do not enable it to be fixed.
Sorry for not responding quickly to the posts as I'm tied by another project. Thank you all for your help. I still have the problem, but want to add one more thing that we are using Window system, and the problem exists both in Win 7 and Win 8. Thanks.
That behavior is depend on setting of Adobe Reader or browser ( IE ) add-on.
So, if FM13 and 14 behave same on same machine, it is normal behavior, and you can change it by Reader preferences with Reader X or older, or disable/enable add-on in IE for Reade XI or DC.
But different on same machine ?
@user19752: We are seeing different on same machine.
this is what we initially were doing. The intent of the interactive containers is to stop new windows popping up and application switching.
I've also discovered different behavior from 13-14. I had a solution in test mode until last week. It was in FM13 and the containers were embedded. Testing ended and in the move to production I upgraded to FM14 and made the container fields external. All of that was fine.
A script creates a pdf in the temp folder (e.g. filemac:/Macintosh HD/var/folders/xz/d3782t5s7pd5j688j0y23jv80000gp/T/S10/Invoice 4958.pdf)
and populates the container. That works fine.
However, I can only view the contents of the container if the field is optimized for an image (Inspector/Data/Data Formatting). When I change the radio button to "Interactive Content (PDF, MP3, etc.)" then it disappears. I know the container still references the file ok because I can put a new container field on the layout and it will display the container as long as it is marked as an image.
FWIW: Mac Yosemite, FMPA 14.0.1
I have the exact same issue, on Windows 7, 8, 8.1.