Getting the offset of a placed PDF within the container rectangle

[svenax]

I need to get the offset of a placed PDF inside of the container rectangle. I have figured out that this information should be available in the transformationMatrix of the placed file. So I do something like:

var pdfTransform = pdf.transformValuesOf(CoordinateSpaces.pasteboardCoordinates)[0];
var horzTranslation = pdfTransform.horizontalTranslation;
var vertTranslation = pdfTransform.verticalTranslation;

but the coordinates I get back are just weird. The horizontal value seems reasonable, but the vertical is way off what I expect.

There may be some precondition to doing this that I'm missing. Running the pageitems/TransformValuesOf.jsx sample from the Scripting Guide also gives weird values. That sample creates a rectangle with a center point of [0, 0] and then retrieves the transform. I would expect the translation to be [0, 0] but I actually get [5, -415.95] (horz, vert).

In that sample it talks about ruler coordinates, so I tried setting document.viewPreferences.rulerOrigin to different values, but that does nothing.

I'm stumped. Can someone please give me a hint on what's going on here?

[svenax]

Anyone?

[Peter Kahrel]

What about the zero point? Reset it using myDoc.zeroPoint = [0,0], then try again.

If that doesn't help, maybe try comparing the geometricBounds of the PDF and those of its parent, the containing rectangle.

Peter

[svenax]

Thanks Peter.

Some more info: I basically want to get the coordinates of the objects in a placed file in the coordinate space of the containing document. As an extra twist, the placed file is a PDF created from an InDesign document. So, I first extract the coordinates from that InDesign file, then the coordinates for the document that contains the placed PDF, and finally I merge the coordinates of the two documents as if all the objects were contained in a single document. This workflow is then used outside of InDesign to draw frames around all the object boxes on a JPEG created from the document containing the placed PDF.

Anyhow, to answer my own original question, this seems to work thus far:

rectOffset = containingRect.resolve(AnchorPoint.TOP_LEFT_ANCHOR, CoordinateSpaces.PASTEBOARD_COORDINATES)[0];
pdfOffset = pdf.resolve(AnchorPoint.TOP_LEFT_ANCHOR, CoordinateSpaces.PASTEBOARD_COORDINATES)[0];
horzTranslation = rectOffset[0] - pdfOffset[0];
vertTranslation = rectOffset[1] - pdfOffset[1];

That gives the same values as I can see in InDesign when selecting the placed PDF. So far so good ...

BUT, that is not enough! When placing a PDF using the default option of Crop to Bounding Box, I sometimes get a bit of extra margin (different for different documents) that offsets the translation values. I have no idea where this margin comes from but I need to compensate for it.

Please help! And let me know if this description is unclear so I can try to explain better.

[Peter Kahrel]

You can determine which type of crop to use when you place the PDF, but afterwards you don't have access to what the crop values might be, so I don't think that you can get that 'bit of extra margin'. As a matter of interest, why do you use the coordinate space? Can't you simply use the geometricBounds of the PDF and its container?

[svenax]

To answer your question: Because I didn't know I could use the geometric bounds for this. I am not an InDesign user, and am just starting to get into scripting it. So, I'm pretty much flying blind, looking at values in the ExtendScript Debugger and trying to figure out how they relate to what I want. Anyways, I just tried using the geometric bounds, and that gives me the same values as the coordinate space thing I did above. Good.

That still leaves the issue of the additional margin. Here's the problem:

This is what it looks like when I try to use the box coordinates extracted from the placed file, offsetting them by the difference of the geometric bounds. As you can see, the boxes are somewhat off to top left.

This is what happens when I place the PDF used above in a new document, using the default Crop to bounding box (visible layers) option. Apparently InDesign does not crop to the exact bounding box of the items, but adds a bit of margin for some reason. I haven't verified this yet, but it looks like this margin is the same as the offset I get above. And if you are wondering why the columns in the PDF appears to be swapped, the document above has placed the same PDF twice with different X offsets to get that effect.

Any idea?

[Peter Kahrel]

The scripting model provides these crop types:

app.pdfPlacePreferences.pdfCrop = PDFCrop.cropArt

. . .cropPDF

. . .cropTrim

. . .cropBleed

. . .cropMedia

. . .cropContentAllLayers

. . .cropContentVisibleLayers

When I place a cropped PDF, the last two add a margin such as you describe, but the first four all place the PDF exactly cropped. What happens when you use the first four crop types?

[svenax]

Here's the deal - I am not the one creating the documents, and I have no control over the options used. Trying the different crop options available when placing a PDF using InDesign GUI, the first four (I am assuming cropPDF is the one called Crop here) places the PDF with the full margins from the file.

I just tried to export the InDesign document in IDML format, to see everything that InDesign knows about the objects. Here I find something called FrameFittingOption that looks like it could be relevant. Anyone know what this is and how I can access it from my script?

[Peter Kahrel]

First check in your InDesign document whether it's relevant at all: select a PDF's container, then Object (from the main menu) > Fitting > Frame fittion options. If you see anything suspicious values there, set correct values (whatever they are) in your script. The Rectangle object has an option frameFittingOptions, check details in the object model viewer.

Peter

[svenax]

Thanks. It looks like this actually gives me the values for the horizontal and vertical translation I've calculated in two different ways already. Apparently there are many ways to do the same thing with InDesign.

Do you understand what it is I am trying to do? I guess this is a pretty uncommon use case. I'll try to describe it a bit better:

We are processing data for many different newspapers, and one of the steps is to extract the coordinates for all text boxes so we can display the bounding rects in a web interface for further processing. That's where the first image in my previous post comes from. Now, the documents we get from the newspapers can contain shared contents in the form of placed PDFs. We have access to the original InDesign documents for these PDFs too, and the goal is to relate the box coordinates in the originals to the position of the same boxes in the documents where the PDFs are placed, so we can work with merged data in our web tool. Of course, the PDFs are both scaled and offset inside the container rectangles.

So, the goal is to find out how to overlay the coordinates from the InDesign versions of the placed documents on the container documents, taking care of any scaling, cropping, and offset that may be used.

[Peter Kahrel]

Yes, I think I understand what you're after, but I have nothing else to offer.

Peter