I have a three-page 2015 document. The bulk of each page is an anchored frame that contains two side-by-side graphics. On each page, either the top or the bottom of one image is missing. For example, on the first page, the left image should be the same height as the anchored frame, which is not quite 7.5". It seems that the image is cropped about 1.5" from the top; I get the larger, lower portion, but not the top. On the other two pages, the problem is with the right image in the pair, and it is the bottom that is missing: about an inch high section on page 2 and half an inch on page 3.
This version of the document is unstructured. The images are taller than the anchored frame, so I expect them to be cut off at the borders of the frame, but not in the middle.
The document prints correctly to my local printer.
Any ideas about how to fix the problem?
Turns out that all the images that were cropped in PDF were rotated and taller than the anchored frame. When I cropped the image outside of FM and imported the smaller images, even though they were still slightly taller than the anchored frame, the PDF seemed to be correct. I have not taken the time to investigate when I see the problem and when I don't.
The original document had a fourth incorrect anchored frame, also involving a rotated image that extended above the containing anchored frame. In this one, the image looked fine in PDF. However, a text line below the image was two inches lower in PDF than in FM. Again, importing a cropped version of the image solved the problem.
What format are the graphics and is there any transparency in them? Are you creating the PDF using the SaveAsPDF route and are you using the RGB or CMYK option?
Is your local printer PS, PCL or some other?
Have you tried to select all in the AFrame to see if there perhaps may be another object (e.g. a text frame) sitting on top?
Can you check in an older version of FM to see if this happens there?
I've submitted bug 4122962 with the text:
I have a document that looks fine in FM 2015 (220.127.116.113). When saved as PDF (Acrobat DC Pro 2015.006.30119), some of the graphics are cut off (either the top or the bottom is missing). The attached zip file contains four versions of the FM file and the corresponding PDFs, as well as two versions of the graphics.
The FM file has 4 pages; it is a landscape document with the body text frame the same size as the page (no margins). However, the page size and presence/absence of margins makes no difference in the result. Each page contains a large anchored frame with a border; the border makes it easy to see the top and bottom of the anchored frame in PDF. Each anchored frame contains one graphic, taller than the anchored frame. The anchored frames are much wider than the graphics. Page 4 is slightly different than the others; the top of the graphic is set to -2.586", so that only the lower portion of the graphic is visible. There is a text line centered just below the graphic.
File left.fm has the graphics on the left side of the anchored frames. When I save the file as PDF, the graphics on the first 3 page are missing about an inch at the top. The graphic on the left page looks OK, but the text line is no longer centered. Different job options and printing to PDF make no difference in the result. File right.fm is a variation in which the graphics have been moved to the right side of the page. In PDF, the top part of the graphics on the first page is fine, but the bottom is missing. On the last page, the text line is not only offset from the center, it is lowered an inch or two.
The imported images were taken with a cell phone camera. They appear fine in Windows 10 File Explorer, Photos, and Paint. When they are imported into FM, however, they are rotated 90 degrees counterclockwise. In files, left.fm and right.fm, the files were rotated clockwise to compensate. I used Paint to rotate the graphics 180 degrees twice which restores the original orientation in Paint. I saved these rotated variations and appended an 'R' to the filename (the original files are called one.jpg, two.jpg, three.jpg, and four.jpg; the rotated fies are oneR.jpg, twoR.jpg, threeR.jpg, and fourR.jpg). The file sizes of the rotated files are different than those of the originals. Files leftR.fm and rightR.fm are counterparts of left.fm and right.fm that use the rotated images. They produce PDF files that appear correct.
What causes this problem? How can I predict it? How can I prevent it?
Thanks for submitting the bug. FYI, checking through the bugbase, there is an additional report of glitchy behaviour with FM2015 and images that have been rotated resulting in incorrect PDF outputs. See: Bug#4087250 - Rotated Image Does Not Maintain Orientation When Rotated
You can vote this bug up and cross-ref to your bug. This might get the engineers to take a more serious look at the issue.
Thanks, Arnis, but this one seems to be a different issue. In my case, the orientation remains correct, but part of the graphic is missing. Still, these could be related problems.
I've used the ImageMagick command line to report how these JPEG files are encoded:
identify -verbose <filename>
Most fields were identical, or could be explained by tiny differences in RGB values after Paint has done a lossy decode/re-encode of the image data. But the orientation- and geometry-related fields differ significantly. Here are the relevant bits of the output:
>identify -verbose four.jpg
Print size: 57.3333x32.25
Page geometry: 4128x2322+0+0
>identify -verbose fourR.jpg
Print size: 32.25x57.3333
Page geometry: 2322x4128+0+0
The faulty images use RightTop orientation:
but the good ones use TopLeft orientation:
(The numeric values of the exif:Orientation fields also encode this same orientation.)
I suspect that FrameMaker has problems with images that use the RightTop orientation.It might be using a library with such issues; some have been reported. I'd suggest using a JPEG-specific tool that can re-orient the file to TopLeft without data loss, such as a combination of jhead and jpegtran. It would be easy to script this change.
For the record, there were some other minor differences, mostly offsets to data within the file. These are almost certainly irrelevant. Interestingly, Paint hasn't updated the recorded orientation of the thumbnail, which remains as RightTop. It's also added a single new field to the properties:
The change is file size is probably because Paint has decoded and re-encoded the JPEG data, and it is a lossy process.
Tried adding the above to the bug database, but it won't let me:
"Sorry this operation could not be completed at this time, please try again later."
I've reported (again) the bugbase issue to the engineering team. You're not the only one having issues adding content to the bugbase.
Thanks for highlighting the issue with bugbase.
We are getting this checked.
Will also try and replicate the issue with images.
Adobe Technical Communication Products
Tried adding the above to the bug database, but it won't let me:
I've now succeeded in adding my contribution as a note on your bug, so hopefully this will give Adobe something to go on.
Thanks for taking the time to do this analysis, Mike. I'll keep the possibility of scripting in mind the next time I do a project like this one. For now, it's enough to know that PDF output for some images may not be correct.