AnsweredAssumed Answered

PDF Rotating Upon Insertion into a Container Field

Question asked by jprochniak on Feb 18, 2015
Latest reply on Feb 20, 2015 by TSGal

Summary

PDF Rotating Upon Insertion into a Container Field

Product

FileMaker Pro

Version

13.0v5

Operating system version

OS X 10.10.2

Description of the issue

I have an issue when inserting PDFs into a container in that they're rotated either 90 or 180 degrees upon insertion into their respective container field. The settings on the containers are all set identically to "Reduce image to fit" so there seems to be no rhyme or reason to which PDFs rotate.

To no avail I've tried the following:
- Copied a container that does not rotate the PDF and replaced the rotating container with the copied one
- Opened the PDF that rotates, performed a "Save As", and reinserted it

One more interesting find that I just noticed is that while a PDF may display rotated in its container, when that same document is exported to wherever, it's orientation is correct.


After one of the community members tested the suspect files they found the following:

the issue here is that the original is a PORTRAIT document that has been rotated, so that you are 'seeing' it in LANDSCAPE, and assuming that is it is landscape document. This is indeed JUST a flag internally to say to the rendering software, show me this way - same is true incidentally for things like crop boxes, which just limit what you can see, not what is actually In the file.

What is clearly happening is that FileMaker is ignoring the rotation when it inserts the file into the container, so you get to see it as it was created This is not held in the metadata but is an entry in the PageDictionary, so wheat is happening when you are recreating the file, it is actually writing a new file as a landscape file. I absolutely think this needs reporting. It might be expected behaviour on behalf of the engineers who wrote the software, but it is not expected behaviour from our side. SO report it as a bug, with the file as proof.

This is really easy to fix fit a tiny bit of code using ScriptMaster with the iText library, as the method you have outlined is really a very nasty workaround. Using direct manipulation on the file takes 11 milliseconds (well thats what I just measured) , and keeps all the content of the file as it was when you found it.

Please see the following discussion log for the entire discussion on this matter:
https://community.filemaker.com/message/174977#174977

Workaround

To combat this issue I had to perform the following:

1. I opened the PDF in question and saved it in an alternate format, specifically JPEG.
2. I opened the newly created JPEG and exported it as a renamed PDF. Here in-lies the key.....you have to rename the newly exported PDF otherwise, for some reason, the the metadata of the problem file does not get overwritten if you simply replace the previous version.
3. After re-saving and renaming the PDF I was able to drag and drop it into its respective container with the image being oriented correctly.

As far as the whole matter of making the container interactive....no joy. After making the container interactive I was no longer able simply drag and drop the PDF or insert anything into the respective container for whatever reason.

I have the two files that may be of interest: the one that gets rotated upon insertion and the one converted to a JPEG and then again to a renamed PDF to combat the rotational issue.

Outcomes