Indigo 12k interprets some PDFs as head to toe that arent'

[(Pre)PressingMyLuck]

This is a slightly weird one and we haven't been able to find a setting that changes it yet.

There are three of us in prepress here. All have windows boxes, the latest Acrobat Pro, Pitstop Pro, and Quite Imposing+ 5.3. Our Indigo 12k operator has told us that almost every file I set up, he has to tumble because the DFE thinks it's head to toe. Some of the files M sets up he has to tumble, and almost none of the ones set up by J. We all have the same action lists and automations in QI. We use the same preflight profiles.

Is there a setting somewhere I'm missing that would cause this? I just went back to a job J had done without issue and redid it. Waiting for the operator to see how that file works. Files come from all sorts of sources, lots of different custies.

Any ideas? Thanks!

[David]

What are you using for Imposition? Smartstream?

[(Pre)PressingMyLuck]

We impose onto the B2 sheet with QI+. The operator pulls it into the DFE and does his thing from there. He's seeing the difference right from importing the PDF, no changes on his end are taken before he can see the issue in the preview. It seems to be relatively consistent between the three prepress operators and how often he has to tumble.

[DigiCorn]

Do you drag-and-drop PDFs into the queue or do you Cmd-P Print them into the queue?

[Tracy]

Yeah that happens to me too when I Print to the que an 18x12
when dragged into the que it's correct somehow the Printing to que 12x18 is fine.
I think Digi was referring to that
But I'm not working with an indigo

[(Pre)PressingMyLuck]

I'm not sure but when I see the operator next I'll ask him. Only thing is for that to be the issue he has to be treating our files differently based on who created them.

[DigiCorn]

Yeah that happens to me too when I Print to the que an 18x12
when dragged into the que it's correct somehow the Printing to que 12x18 is fine.
I think Digi was referring to that
But I'm not working with an indigo

Exactly.

[(Pre)PressingMyLuck]

Operators both say they only ever import, no drag and drop.

[DigiCorn]

Is anyone there from Australia? Everything is all upside down and bass-ackwards down there.

[(Pre)PressingMyLuck]

Nope, just the lost and confused on this one.

[Tracy]

In our fiery when dragged in, It is using pdf print engine
when printing to it, it is post script
might want to check that out.
but easy fix is to create a workflow that flips the page when needed

[(Pre)PressingMyLuck]

As I said earlier, MOST of my files have the issue, but  not all. Most of the files created by J are fine. But I can't find any settings or meta data in the PDF that my software would be doing to create the problem. They always import the same way, so if that was the problem we'd all be having the same outcome. Any workflow to correct the problem automatically would just reverse the situation. We need to figure out what the root cause is to address it besides the manual way they are doing now.

[Tracy]

what are the sizes of the files?
for us it happens to 18x12 (Landscape)
and not to the 12x18 (Portrait)
maybe make a log of the sizes/orientation that it's happening to
and you might find a pattern

[(Pre)PressingMyLuck]

The 12k only has 29.5x20.75 and 29.5x20.75. Both sizes do it if I set it up, both sizes don't do it if J sets it up. There has to be some kind of setting or meta data thing. He's about to run the test file we created that's already worked fine with J proofed it, but I went and reset it up as a test. Really interested in how that comes out.

[David]

Are any of these pages rotated in the pdf file? I have gotten some of these before and had a similar outcome. It's where a one page pdf was added or merged into another pdf and the orientation was different (landscape instead of portrait) so they rotated the page in Acrobat to make it better.
It only shows up when the "honor rotation" was not checked at the RIP.

Not sure if that would apply in your situation.