Action to send printer marks to back - trouble making it work

[DCurry]

(Acrobat Pro XI 11.0.0) and Pitstop Pro 11, update 2)

I wanted to make an action list that will send printer marks to back, rather than delete them. I don't want them deleted because I often run single page proofs and want the crops visible, but I don't want them overlapping the artwork.

So, I took the canned "Remove Printer Marks" action list, duplicated it, then modified the last step by replacing "Remove selection" with "Change object order to back". Seemed like a logical way to make it happen, but when I run the action it doesn't work.

I can manually select crop marks and send them to back and that works, but I'd rather automate this if possible.

abc - any words of advice? (other than "upgrade to 12!" Would love to, but not an option at this moment) I've attached the EAL if anyone wants to take a peek.

[Slappy]

I can get it to move the Crops behind the artwork based on Line Weight Less Than 0.01389 in, trying to also move the white stroke that appears under the crops back as well.

[Slappy]

I went a different route & set it to Remove the White Strokes, so use with caution!!

[abc]

Your original Action List actually worked for me, the reason it might not work for you is that it requires a Trim Box to work on?

So on my test file I used the Action List to set page boxes to marks and then ran your Action List and it sent everything that was completely outside the trim box to the back (as it was meant to)

[Slappy]

Hmmmm, trying that on the orig Action List and not having any success. I inserted the "Use trim marks to set page box" at the beginning of the Action, can you post a screenshot of yours abc?

[abc]

I ran it as two separate Action Lists (just as a test)

I used the Action List that ships. Page > Set Trim and Bleed Box to Marks.

Then ran the Action List supplied, it worked on my test file.

What I did to test it. After I set the page boxes.

I drew a large full bleed yellow box over the whole page and sent it to the back.

Then I ran DCurry's Action List, and it sent all the marks and the dead centres to the back

I am running a pre-release version of PitStop 12 update 3, but that should not make any difference as nothing changed in those Actions.

[DCurry]

Your original Action List actually worked for me, the reason it might not work for you is that it requires a Trim Box to work on?

I do have a Trim Box. Here's a PDF that is typical of what is supplied to me. Also, the "Remove printer marks" action works fine.

[Joe]

Send to back or bring to front hasn't worked for me in ages. Either in action lists or doing it manually. I just thought it was broke. ABC, could I have a corrupt preference file or something that might need to be deleted?

[abc]

Weird, something strange not working with your file.

If I set the Action List to remove selection they are deleted.

If I substitute remove selection for move to back it doesn't work.

I'll get development to take a look tomorrow and let you know what they say.

[DCurry]

FYI, it's not just that file. I've tried it on several with the same results.

[abc]

Hi all
I got feedback from the team.

The crop marks consist of 2 paths, one white and one black.  I assume you want
both sent to the back together.  Both are Separation All - one with 100% tint,
one with 0%.  This observation suggests 2 possible solutions:

1)
Select spot color All
Change object order to back

2)
Select trim marks with the checkbox for Separation All and a user swatch for
the 0% version of All.
Change object order to back

Either of these works on the customer's file.


As for why the original Action List doesn't work, that's a bit more complex.
The 2 paths comprising the marks each consist of 8 subpaths (two in each
corner).  Our actions work separately on paths and subpaths (this is to allow,
for example, deleting one subpath in a compound path).  The Action List selects
objects outside of the Trim box, and each of the subpaths is indeed outside of
the Trim box so they are selected.  However, the compound path is *not* outside
of the Trim box: it overlaps.  You can visualise this in PitStop Pro by
selecting one of the subpaths and in the right-click menu selecting Expand
Selection -> Compound Path.  The selection manipulation handles are on the
media box, so the path as a whole overlaps the complete page.
So, the subpaths are selected but the actual path is not.  The order of
subpaths (relative to other objects) on a page cannot be changed, only full
paths can.  Therefore, the Action List doesn't work.

The Remove selection action has the same problem that the path itself is not
selected.  However, individual subpaths *can* be deleted, so that's what it
does.  And in the end when all subpaths of a compound path are deleted, that
(now empty) path is in turn deleted.
This explains why removing works while sending to the back doesn't.


Hope that helps

[DCurry]

Thanks, abc - I knew you'd get to the bottom of this!

I'll look into implementing one of your alternatives, although they have a couple of downsides; one being if an unwise designer uses Registration on an element within the design it would get sent to back; and secondly selecting by color doesn't help when there is a color bar included with the marks.

Thanks again!

[abc]

I guess a preflight check for color 'all' limited to inside the Trim Box would help with that, you could also convert to K only as fix.

Then you'd be sure you are only working on marks?

[Tracy]

Send to back or bring to front hasn't worked for me in ages. Either in action lists or doing it manually. I just thought it was broke. ABC, could I have a corrupt preference file or something that might need to be deleted?

interested in this, ABC?

[DigitalCrapShoveler]

I read through all of this, and I agree with Dan's logic and what he's trying to do. A lot of times, choosing the remove printers marks option cuts clipping masks and a bunch of other stuff that bites you in the ass. Pretty ingenious if you ask me, to have an action that sends all marks to back. Unfortunately, you are going to have nitwit desingers that think Reg Black is an option to use for a heavy black.

What really needs to happen? Adobe needs to quit putting Registration Black in the color palette. It is not necessary to use that specific color for marks anymore, and even when we did need them, desingers always did them in straight black anyway.

ABC, there might not be a way to do what Dan asks within the confines of Pitstops limitations. I've been hacking at it for days, with NO good results.

I do like his idea, though.