Type Editing in Pitstop

[Nick Danger]

I am using Preps 5 to create Imposition templates. In the template there are typed lines referred to as lap codes to indicate job and sig...

Once I process the template thru Prinergy, I open up the (System) PDF and type in the lap code using Acrobat 7 and Pitstop.

We used to use OS 9 and it was flawless.

After migrating to OS 10.4.11 things are getting flakey...

If there are multiple places to edit on one page, they are now (95% of the time) linked together which means you need to draw rules, type, C/P into the remaining positions.

NOW I check the type (embedded Helvetica), start typing and I get a warning ArialMT does not match and all that shows are bullets.

Once typed, I select and change font to something completely different (the first try they won't embed) I then reselect and go to another font and embed. Sometimes successfully, sometimes they just flow all over the place...

I have thrown out preferences, checked to see if there is anything indicating the "ArialMT" font...nothing

This is very frustrating and time consuming...

Anyone have any ideas?

I have (hopefully) attached a 2 page pdf of screenshots of the problems I am having.

Thanks in advance,

Nd

[Angie]

Your screen captures did not come through but based on your questions I can't help but wonder why you are going through all this. Why not just use the predefined Preps text variables in your template so the job, sig, side, color etc are automatically generated on output? I have attached a screen capture for you reference. Hope this helps.

[kyle]

Nick,

I don't understand your post completely, but based on my assumptions, Angie's suggestion is definitely best. If for some reason that isn't feasible, try putting ARIAL.TTF in Library/Application Support/Adobe/Fonts and restarting Acrobat. If the font is Helvetica, it's rather unusual that Pitstop/Acrobat wants to use Arial. If the font is embedded completely (not subset), you should be able to use any character defined in the font. I have seen PDF files (exported from Indesign CS4) that had two instances of a font with the exact same name but different encodings that goof things up in unusual ways, where extracting a single page from the PDF causes characters to change. Maybe the problem has something to do with buggy font embedding.

I'm not sure what "(System) PDF" means. I'm guessing that it has something to do with the Prinergy workflow.

I assume "linked together" means that multiple text areas that you would like to edit discretely are encoded as a single line. If that is the case, you can use the "split into characters" button in the inspector window to break them up first. If they are close enough to each other, Pitstop will still move text to the right of the segment you are editing. You can prevent it from doing that by first moving text segments up or down by a small amount, exceeding the threshold Pitstop uses to determine if the text should be treated as one line or not. I think .001 inch is enough. The text can be harder to select when split into characters if there is anything behind it - you can hold down alt/option when selecting with the Pitstop selection tool to only select objects that are completely contained within the marquee area.

As Angie stated, your attachment didn't work. If you can, upload a sample PDF file and we can check it out. If file size is an issue, try making a PDF using blank pages - just make sure it has the same problem before uploading.

[Nick Danger]

Your screen captures did not come through but based on your questions I can't help but wonder why you are going through all this. Why not just use the predefined Preps text variables in your template so the job, sig, side, color etc are automatically generated on output? I have attached a screen capture for you reference. Hope this helps.

We tried doing that, however, when operators saw there was a lap code in place, they assumed it was good w/o looking at it...it would be the one from the previous job...

I believe the attachment took hold...

[Nick Danger]

Nick,

I don't understand your post completely, but based on my assumptions, Angie's suggestion is definitely best. If for some reason that isn't feasible, try putting ARIAL.TTF in Library/Application Support/Adobe/Fonts and restarting Acrobat. If the font is Helvetica, it's rather unusual that Pitstop/Acrobat wants to use Arial. If the font is embedded completely (not subset), you should be able to use any character defined in the font. I have seen PDF files (exported from Indesign CS4) that had two instances of a font with the exact same name but different encodings that goof things up in unusual ways, where extracting a single page from the PDF causes characters to change. Maybe the problem has something to do with buggy font embedding.



I believe the issue is this...the encoding is different as I have ArialMT.ps font in my system. But why it's looking for this font vs Helvetica is beyond me...

I'm not sure what "(System) PDF" means. I'm guessing that it has something to do with the Prinergy workflow.



Yes, it's the PDF created of the template we use in the system...



I assume "linked together" means that multiple text areas that you would like to edit discretely are encoded as a single line. If that is the case, you can use the "split into characters" button in the inspector window to break them up first. If they are close enough to each other, Pitstop will still move text to the right of the segment you are editing. You can prevent it from doing that by first moving text segments up or down by a small amount, exceeding the threshold Pitstop uses to determine if the text should be treated as one line or not. I think .001 inch is enough. The text can be harder to select when split into characters if there is anything behind it - you can hold down alt/option when selecting with the Pitstop selection tool to only select objects that are completely contained within the marquee area.


This is correct. I wonder if you move the line of text up or down w/o splitting into characters would work...will try




As Angie stated, your attachment didn't work. If you can, upload a sample PDF file and we can check it out. If file size is an issue, try making a PDF using blank pages - just make sure it has the same problem before uploading.

I was able to successfully upload screenshot(s) replying to Angie's note...

[kyle]

Nick,

Rather than a screen-shot, please post a PDF file that exhibits the problem.

[Nick Danger]

Nick,

Rather than a screen-shot, please post a PDF file that exhibits the problem.

Kyle, my apologies...

I have attached the file...one thing tho, someone already did the type for the sig...

I did try to just type in a few characters and got the same thing about the ArialMT...

Thanks in advance...

Nd

[Angie]

We tried doing that, however, when operators saw there was a lap code in place, they assumed it was good w/o looking at it...it would be the one from the previous job....

Just a couple of clarification questions:
Who is the "operator" (plate room, pressman, etc)
Assumed what is "good"
Previous job- are you talking about a straight rerun without any up front processing?

[Nick Danger]

Just a couple of clarification questions:
Who is the "operator" (plate room, pressman, etc)
Assumed what is "good"
Previous job- are you talking about a straight rerun without any up front processing?

Operators are our Prepress Production staff that prepare jobs for the plateroom...

Good would indicate the code is for the current job # / sig

Previous job would be either the same publication from a prior month or a job with same trim size...

We rewrite the template everytime we get a sig ready for plate.

We produce Monthly Publications and have well over 6000 different template configurations on hand to choose from...

Funny thing tho...we still seem to write a few new ones every week adding to that total...

[Al Ferrari]

We rewrite the template everytime we get a sig ready for plate.

We produce Monthly Publications and have well over 6000 different template configurations on hand to choose from...

Funny thing tho...we still seem to write a few new ones every week adding to that total...

Nick,

With due respect: from your statement quoted above, I believe you have not understood the concept of a template in Preps and have been using the application improperly all along. Your problem, in my opinion is at the concept level for templates and text variables.

You should be able to do all of your work from one job cycle to another with just a few templates. The fundamental idea behind a template based imposition application is that "page units" of a particular job are automatically inserted into place holder pages by the imposition application using a pre established layout or "template". Ditto for the concept of text variables.

The idea of needing to write a few new ones [templates] every week violates the basic concepts of an application such as Preps. Forgive me if I am way off base, but my comments are based on what you have written.

Al Ferrari