We've always had random issues with ID and the pages panel.  If you leave it open (as i do at all times), sometimes it ends up having that issue.

The only soution we've found is to reset your Prefs file, as menioned before in this post.

BeachType Medium?
LHF Happy Fun Ball?

Looked it up on http://www.whatfontis.com/

FYI - Homeland security released a strong statement 2 weeks ago about the current version of Java runtime at the time and it's serious vulnerability.  Here at our place, our IT department removed Java from all CPUs until the newest updated version was released, which I think came out on the 22nd.  See here for all of the Java-related Homeland stuff...

http://search.dhs.gov/search?query=java&affiliate=dhs

We only use the software for browser/database interactivity and communication, but I heard through many sources that NOT addressing the issue and updating could lead to some very bad things - both CPU-specifically and server-wide.

We use both PitStop Pro 11 and Server, both of which can knock out most, if not all, of the stuff you're asking for.  You'll want to play with settings for color and such to make sure that you've got things coming out like you want, but once set and tested, global changes will definitely be you best friend!

Also, the Enfocus website has plenty of videos walking you through how to perform the tasks you need to do!

Thanks!  I just worried about the PDF structure being changed after originally being designed for print.

We have a bunch of high-res PDF files we post on our customer support site that customers can click to download, then re-supply to us for use with the custom books we produce.  So in essence, they can download up to 150, or so, preformatted pages of information that they can add to their own book info wherever they deem fit and send it all as a custom book to be printed.

So, for the web-version of these pages, those who created them have saved the pages with "Fast Web View" turned on, so they would display more quickly when customers are clicking through them - deciding which ones they want.  Some of the PDFs are multiple pages with high-res stuff in there, so some file sizes are rather large for dispersing via the web.  Hence, the decision to use the FWV setting.

But, I'm wondering if those same PDFs we are supplying with "Fast Web View" turned on will affect anything on the backend when we're actually printing them.  Anyone have knowledge on this stuff?  As far as I've read, the FWV setting is simply a type of file protocol to tell the browser how to display and download the entire PDF - allowing the pages to be loaded when selected instead of downloading the entire thing first.  But, does that change to the PDF structure have any affect on the quality and reliability of the same file if being used for printing?

The PDFs have had nothing else done to them compression-wise, resolution- or font-wise either.  Just that checkbox turned on when saving the PDFs out for posting on the web.


Thanks!

We had these issues a while back and, like Joe said, it's all dependent on your Color Management settings within PitStop. 

We don't do much high-end printing in B/W, so we've dummied down those options to using either the Gray Gamma 1.8 or 2.2 - depending on the outcome.  It's gives us a decent contrast ratio across the board, which works fine on our darker-printing presses and those that print in higher-res.

The default PitStop profiles didn't do us much good as far as photos going to B/W, though...

I always buy!  Well, until I  then it's on you!

Well, schools have been good to deal with for the most part, but it's absolutely amazing what you get from them.  But, since pretty much none of them have much experience in design, we do what we can within a short timeframe to get something decent back to them in print.  These templates I reference are our easy way to get them full-color, semi-designed covers.  And, doing all of this work for that one press that does low-volume stuff really isn't up there on my list of things needing to get done.

But, the "self-designed" artwork is where it's at!  Nothing like having to crop out  from photos of kids at their school!  We get that all the time!  Funny how the contacts react when you inform them of the changes you made - then they realize that: 1) one of their kids even did that (oops); and, 2) they didn't catch it to begin with!

Gotta love it!

Yep.  we've added all of the other cover printers within the past few years and started the entire proces by sending them the color profile from our main vendor at the time.  They then adjusted their own curves to match as well as possible to the original set.  Easy peasy!  (Well, from my end at least!)

I took your input and comments and passed them on.  I've done what I can with my limited knowledge of presses, inks, substrates that are all involved in this.  They can take it from here...

It's 'bout Beer-Thirty, I'd say.

Quote from: Joe on November 02, 2012, 01:05:29 PM

Quote from: fishshed on November 02, 2012, 12:59:42 PMWell, to really put a topper on the problem:

<snip>

Thanks for the feedback guys!  If you think of something else that might work, toss it my way!

Well as you've found the conversion of the vector part is easy. The raster part, the only way I can see is a straight conversion to CMYK and then edit in Photoshop to get your desired values. Of the files you posted, the top half is raster. Why is that? If you had an EPS it seems somewhere in the world the vector part of it should be out there. It looks like someone, at some point, needlessly rasterised it.

These files come to us from customers (all schools) and we generally deal with secretaries and/or principals.  So, we basically get what we get.  Some of our college customers send us spot EPS files, full print-ready PDFs, etc.  But those are very rare cases.

We get campus maps made in Word, Excel (yep - adding strokes to cells to make a school map!) and even PowerPoint.  We do all we can to get the best art from them, but generally it's stuff like this...

Quote from: Joe on November 02, 2012, 12:58:09 PMAgreed with Greg and...

The problem is that you are trying to achieve color values that are not built into the files. For example, the CMYK built in values of SDI-Red is C17 - M100 - Y87 - K9 and SDI-Dark Blue is C100 - M67 - Y0 - K23. Doing a straight conversion to CMYK does give you those values. Using a global change can easily change the vector part to whatever values you want but it won't work for the raster files. The most logical thing would be to change the built in color values of SDI-Red and SDI-Dark Blue in the originals to match the values you want them to become. Then just a straight conversion from spot to CMYK will make all of the values read what you want it to read whether it is raster or vector.

The problem is that the other printers already have global curves/color swaps setup on their ends to make this swatch set work.  And again, since these jobs get assigned to vendors at the last second, all of these files are already done in the process that works for the other printers.  They grab the swatches and do whatever they do to make it work.  I don't want to create a whole other set of swatches simply for this one printer - then have to re-make the files using these once we see it's been assigned (or re-assigned) to this one printer.

I know that you're saying Joe, but it's only this one printer that's having issues.  The current swatches work fine for everyone else as-is.  So again, I'm putting it back on these guys to make it work.  I have a strong feeling that this might be the last year we use this thing anyway due to the huge non-color-related problems it has, as well.  Pretty sure no one actually researched this thing much before making the purchase.

Well, to really put a topper on the problem:

The press that's the issue is a small digital press we bought and installed here in-house!  Not at all my decision, but much of my position and responsibilities here is dealing with our cover print vendors.  All of the external partners we have are fine.  Their workflows are all different, but we use one vendor's interpretation of our color swatches as the basis for all the other printers' color-matching curve setups.  And again, they all work pretty well and there isn't much of a difference in the final color from different printers despite all of their own differences - digital, off-set, water-based, toner-based, waterless.

The issue here is that this press was brought in to do our very low-volume work (less than 350 or so).  Generally, we use this press for re-orders of small quantities for jobs that were initially produced at another one of the printers to produce the original quantity of, say, 1000.  So, the problem really shows up when they have 1000 from one vendor that's correct, then we have to do a TON of color work like this in order to get them another 150 or whatever that needs to match the originals.  Cost-wise, this thing costs pennies compared to the others, but this crap is enough to really give you a headache.

Yeah, not a fun position to be in.  I'm trying to get them to simply "figure it out" on their end, since I've spent 10+ years making sure the rest of our printers are all on the same page - and they are.  We have 2 overseas printers that I've got to print color like our US-based ones to - including on different substrate.  So, I was just wanting to see if i missed something with all of this that might make it work for this stupid thing.

If not, it's time to move on to my next project and let the guys in back find out how to make this stuff work properly on their end, without adding more to our current workflow for jobs as small as these are and that might switch at the last second.


Thanks for the feedback guys!  If you think of something else that might work, toss it my way!

Quote from: DigiCorn on November 02, 2012, 11:40:20 AMAre the .eps with spot vector or raster? You can remap some raster stuff like this screenshot:

In this case, I took a CMYK raster version and converted it to a 2-color spot within Photoshop.  So, it's raster and most, if not all, will be - since they come to us straight from the customer as JPG or TIF.

I got it to work through the Inspector, but the EAL won't work.  Maybe I'll rewrite it from scratch to see if maybe I missed something the first 30 times I tried.  LOL.  Or, is it your understanding that doing "raster" remaps don't really work through actions?  Just weird that you can do it, but then again, you can't!     Again, the CMYK GC remap works fine for the bottom blue, since it's simply a box on the page assigned a value.

Thanks for the inital guidance!  I'll keep working on it and see what else I can come up with.  I'd really like to just convert the files to CMYK PDF and GC then, but I'm starting to think that's not a possibility.

This press I'm trying to "help out" has been a total pita for a year now.  I guess the rip and even impo sucks bad, but there's not really a better option (or so I'm told).  Our other printers simply run their own curves to all jobs to consistenly hit our default spots.  It's worked for years just fine across the board, but this damn thing...  UGH

We have jobs that print at 4, possibly even 5 now   , print vendors and I'm trying to find a way to get one of the more-touchy presses to match the color coming off the other presses as closely as possible.  All are digital by the way and I'm attempting to convert colors to their mapped equivalents on their press on our end.

All of our covers (4000+ custom designs) are produced using ID templates consisting of vector- and text-based objects (some with effects like shadows), in addition to logos and such that our customers add to the templates. 

I'm trying to convert either spot- or CMYK-specific values to other CMYK values.  The 2 attached examples are the same file - one with a 2-spot EPS for the logo on the top color and the other with the entire thing converted to CMYK.

I'm trying GC > Remap color, but it won't work as I currently have it going.  It only changes the bottom blue (vector-based) to the proper color I need, but doesn't address the spots from the EPS.  Is that even possible?  The problem is that the print vendor for these can change at any minute, so getting this setup to work on the fly would be much easier that manually adjusting color for these logos once the vendor is determined.  And since I don't have control over that decision, I'm trying to lessen the pain on the poor people prepping these for print.

Trying to convert the "SDI-Red" to 19/100/72/7 and the "SDI-Dark Blue" to 95/37/0/25.  again, either through the spot change or through CMYK-to-CMYK.

Uhhhh...   Yeah.  And seeing as we have about 6,000 customers sending us either their own PDFs (mostly created from Word files) or the Word file itself, this is the joy we deal with every day!

We're just wanting to automate as much as possible.  But it's detecting the "object" as having/not having a fill (see scrrenshot).  I've attached the PDF, as well.  Just trying to detect these on-the-fly, but I'm not sure it's gonna happen.