Skip to main content
L
Lynne A. Price
Inspiring
February 28, 2016
Question

Top or bottom of imported image missing in PDF

  • February 28, 2016
  • 2 replies
  • 2298 views

Hi,

    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?

             --Lynne

    This topic has been closed for replies.

    2 replies

    Arnis Gubins
    Arnis Gubins
    Inspiring
    February 28, 2016

    Hi Lynne,

    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?

    Arnis Gubins
    Arnis Gubins
    Inspiring
    February 28, 2016

    Rotated images have been problematic before. I thought it was fixed,  but looks like it may have crept back in. Please report it via the bugbase (https://bugbase.adobe.com/index.cfm)

    M
    Mike-Hardy
    Participating Frequently
    March 1, 2016

    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

    Image: ...\four.jpg

      Geometry: 4128x2322+0+0

      Print size: 57.3333x32.25

      Page geometry: 4128x2322+0+0

      Orientation: RightTop

      Properties:

        exif:Orientation: 6

      

    >identify -verbose fourR.jpg

    Image: ...\fourR.jpg

      Geometry: 2322x4128+0+0

      Print size: 32.25x57.3333

      Page geometry: 2322x4128+0+0

      Orientation: TopLeft

      Properties:

        exif:Orientation: 1

    The faulty images use RightTop orientation:

    • the 0th row of the image data is the right edge of the image
    • the 0th column of the image data is the top edge of the image

    but the good ones use TopLeft orientation:

    • the 0th row of the image data is the top edge of the image
    • the 0th column of the image data is the left edge of the image.

    (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:

    Image: ...\four.jpg

      Properties:

        exif:InteroperabilityOffset: 4942

        exif:thumbnail:JPEGInterchangeFormat: 5102

        exif:thumbnail:JPEGInterchangeFormatLength: 26355

        exif:thumbnail:Orientation: 6

    Image: ...\fourR.jpg

      Properties:

        exif:InteroperabilityOffset: 4920

        exif:thumbnail:JPEGInterchangeFormat: 5118

        exif:thumbnail:JPEGInterchangeFormatLength: 3351

        exif:thumbnail:Orientation: 6  

        unknown: -4126

    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."

    Sigh...

    L
    Lynne A. PriceAuthor
    Inspiring
    February 28, 2016

    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.

             --Lynne

    Terms & ConditionsAccessibility statement
    Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices